необъяснимый стектрейс

[undefined]

А вот это что за фигня?

Там смысл такой:
Юзер тащит кусок пазла из n кусочков (массив sel_group)
этот массив кешируется в old_group
Дальше после отпускания группы, она может слипнуться с другой группой кусков(т.е. в sel_group добавятся еще куски из присоединенной группы) и код

for (i = 0; i < sel_group.length; i++)
	sel_group[i].checked = false;
// mark dropped pieces
for (i = 0; i < old_group.length; i++) 
	sel_group[i].checked = true;

сначала выставляет false всем кускам новой объединенной группе и потом у той группы, что юзер отпустил выставляется true.Т.е. false остается у кусков, которые присоединились к группе после отпускания мыша.Дальше эти свежеприсоединенные куски выравниваются относительно отпущенной группы.Я знаю это достаточно костыльно, но зато не надо лишний раз дергать рекурсивную функцию getConnected

И зачем его удалть откуда-то, а потом снова добавлять? Метод addChild уже и так подразумевает удаление из любого другого контейнера

А потому что были замечены артефакты в виде непонятных черных прямоугольников на месте откуда DO по идеи должен был удалиться бы.Ручное удаление исправило это.Лишнее усливие надо удалить.
Вообщем еще раз повторяю этот код выполняется от начала и до конца т.к. последняя строка

LoggerBox.addLog("onMU log 6");

Не зависит ни от каких условий и исполняется, значит и все что выше тоже исполняется без косяков.

Выглядело так, словно любой рандомный блок кода генерировал исключение в любом месте выполнения программы.

А тут как раз всегда один и тот же метод и один и тот же эрор.Вообщем хз,видимо придется смириться.

[maxkar]

Да нет тут ничего загадочного. Ошибка в первой же строке функции, когда e===null. Скорее всего, метод где-то явно вызывается (может даже и в кадре) передавая null. Хотя и через всякие onMU.bind(null, [null]) в качестве слушателя тоже можно добиться подобного.

Вывод

Т.е. метод выполняется без ошибок, а на выходе из него вылазит пакость.

неверен. Аккуратность расстановки логирования не позволяет его сделать. Первая запись в лог - в середине метода. До него уже много чего может сломаться. За факт многократного вызова метода - его название (on*) и ваше дальнейшее описание (обработчик событий). Пакость происходит не "на выходе из него", а на "в процессе выполнения следующего вызова метода".

В пользу версии говорит и улика в виде загадочного

if (e)
  LoggerBox.addLog(some.long.message);

Загадочный if потому, что в этой строчке e уже точно не null. Ведь в начале метода идет доступ к e.target. И этот доступ падает с ошибкой в слуае e===null (что мы собственно и наблюдаем в рассматриваемой ситуации). Зато улика говорит нам, что раз есть проверка, значит автор кода явно подозревал наличие вызова onMU(null), а может, и сам написал этот вызов.

Всё сходится. Где-то есть вызов onMU(null), который и дает ошибку в логе. Лог успешного выполнения ни при чем и демонстрирует успешное выполнение функции при e!==null.

[undefined]

Пакость происходит не "на выходе из него", а на "в процессе выполнения следующего вызова метода".

Согласен, это объясняет лог,вот только я прошелся поиском по всему классу единственное,где встречается onMU - подписка/отписка на маусивенты,наружу ссылка на метод тоже не передается. Проверку if(e) была поставлена на автомате,не глядя на сигнатуру метода, чтоб точно знать что запись в лог не сломает все(это же все в проде).Такое ощущение, что где-то внутрях avm между созданием ивента и передачей его в обработчик, ивент грохает мусорщик.

Хотя и через всякие onMU.bind(null, [null]) в качестве слушателя тоже можно добиться подобного.

А можно по подробнее что это за конструкция и что она делает?

[caseyryan]

Что будет если вызов этого метода обернуть в try / catch?
Если поймает исключение, можно будет посмотреть весь стек вызовов и проверить каждый объект null.

Второй вариант - расставь по всему методу, на каждой строчке брейкпоинты и отследи вызов каждой строчки до того момента, как вылетит этот баг.
Вообще, не знаю как получилось, что ты так долго в одном методе ищешь ошибку. Есть же отладчики / профайлеры.
Я бы понял, если бы баг происходил где-то в непонятном месте во всем приложении. Но тут он локализован до одного метода. Поиск сводится к простым "брякам"

[undefined]

Что будет если вызов этого метода обернуть в try / catch?

В том то и дело что вызова метода нет

единственное,где встречается onMU - подписка/отписка на маусивенты,наружу ссылка на метод тоже не передается

Вообще, не знаю как получилось, что ты так долго в одном методе ищешь ошибку

из прода последнее время начал приходить такой стектрейс:

У меня то это не вылазит никогда

[maxkar]

Сообщение от undefined

Согласен, это объясняет лог,вот только я прошелся поиском по всему классу единственное,где встречается onMU - подписка/отписка на маусивенты,наружу ссылка на метод тоже не передается.

Значит я не угадал. Но это не отменяет факта, что у вас логирование с середины метода начинается. Там и промежуточные методы вызвыаются (теоретически могут вернуть null). И к каким-то глобальным переменным доступ идет. Начните логирование с самой первой строчки метода, мало ли что выяснится. Ну или хотя бы подтвердится, что метод ниоткуда не вызывается, а ошибка выводится.

Сообщение от undefined

А можно по подробнее что это за конструкция и что она делает?

Если я с синтаксисом не напутал, то конструкция называется вызов метода.Она вызывает метод. В аргументах там передается литерал массива (array literal), он создает массив . Семантика метода bind - частичное применение функции (partial application), в данном случае применение к одному аргументу null. Данный вызов bind вернет функцию, которая при вызове будет вызывать onMU(null).

[undefined]

Там и промежуточные методы вызвыаются

ну тогда и стектрейс в этих методах был бы,а судя по логу, глубина стектрейса =1

Добавлено через 7 минут
хотя да,надо добавить логов

[caseyryan]

Кстати, вот только что пришло в голову. У меня как-то раз, по неопытности, вылетал почти такой же странный баг, который я долго не мог отловить. Так же вылетало обращение к свойству null, хотя проверки показывали, что в методе все ок.
Как потом оказалось, дело было в том, что ошибка вылетала в экземпляре, который уже был удален, но не достаточно хорошо зачищен от ссылок. Он продолжал существовать в памяти и работать. Но так как часть ссылок там была null, это и вызывало сбои.
Что у тебя это за класс? Уж не создается ли он случаем при каждом новом уровне?
И если создается, как ты его зачищаешь от ссылок?

[undefined]

Что у тебя это за класс? Уж не создается ли он случаем при каждом новом уровне?

Игровой класс, создается на каждой новой игре.Сейчас проверил - отписки все стоят.Ладно посмотрим что новые логи покажут.

[undefined]

действительно, стектрейс вылетает где-то до первой записи в лог.Всем спасибо, пойду копать.