Падение при завершении программы - 3

[alx]

Запустили программу, вошли в сеть и сразу завершили. Результат - исключение std::bad_alloc:

ESL Connected
 Window Icon setted
MainAppFrameWindow2 ctor
pLogViewWidget created
pSplitterSoundPlay created
Main Window created
CUSTOM - sofia::register - 111
BACKGROUND_JOB - 
CHANNEL_CALLSTATE - CS_HANGUP-HANGUP-outbound-HANGUP
CHANNEL_CALLSTATE - CS_ROUTING|RINGING|
CHANNEL_CALLSTATE - CS_HANGUP-HANGUP-inbound-HANGUP
CHANNEL_CALLSTATE - CS_HANGUP-HANGUP-outbound-HANGUP
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
PRESENCE_IN - Аварийный останов (сделан дамп памяти)

Вот что сказал gdb (к сожалению программа была собрана без отладочной информации):

Reading symbols from ./MC04Dispatcher...(no debugging symbols found)...done.
[New LWP 22259]
[New LWP 22253]
[New LWP 22256]
[New LWP 22257]
[New LWP 22261]
[New LWP 22260]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./MC04Dispatcher'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fbcc4742418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: Нет такого файла или каталога.
[Current thread is 1 (Thread 0x7fbcba1bd700 (LWP 22259))]
(gdb) bt
#0  0x00007fbcc4742418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007fbcc474401a in __GI_abort () at abort.c:89
#2  0x00007fbcc508484d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007fbcc50826b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007fbcc5082701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007fbcc5082969 in __cxa_rethrow () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007fbcc571d6ee in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007fbcc560c549 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007fbcc560ee3c in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x00007fbcc537e6fa in start_thread (arg=0x7fbcba1bd700) at pthread_create.c:333
#10 0x00007fbcc4813b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[alx]

Забыл уточнить - это r244.

[dimag]

повторяется в r246?

[alx]

Replying to dimag:

повторяется в r246?

Учитывая, что r246 отличается от r244 только тем, что из репозитория были удалены несколько ненужных в нем файлов, сложно ожидать, что это могло как-то повлиять на данный баг...

[dimag]

Не удалось воспроизвести в r251

[alx]

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

Во-вторых, как я уточнил в первом комментарии, падение наблюдалось в r244, а не в r251.

[san]

Дим, если не удаётся воспроизвести баг, не закрывай тикет, а пиши в комментарии "не удалось воспроизвести". Возможно что баг проявится ещё у какого-нибудь пользователя.
А если долгое время он так и не воспроизведётся, обсудим и закроем как "воркс фо ми"

[alx]

Replying to san:

Возможно что баг проявится ещё у какого-нибудь пользователя.

Добавлю, что, даже если не удается воспроизвести баг, полезно провести анализ кода, определив хотя бы приблизительно возможные причины возникновения бага. Во-первых, есть ненулевая вероятность обнаружить ошибку прямо в процессе этого анализа. Во-вторых, определив вероятные места возникновения проблемы, можно придумать что-то чтобы

a) минимизировать возможные последствия проблемы (например, программа не должна падать, если для выполнения какой-то операции ей не хватило памяти - не зря же Qt открытым текстом говорит:

You must reimplement QApplication::notify() and catch all exceptions there.)

и b) подготовиться к новому появлению бага - например добавить какой-то отладочный вывод в каких-то ключевых местах, чтобы не просто ждать подтверждения самого факта, что баг по-прежнему присутствует, и у пользователя программа опять упала, а чтобы такое падение дало какую-то полезную дополнительную информацию для нахождения и исправления бага.

Вот когда эта работа (анализ и подготовка) проведена - тогда можно сказать: "я сделал все что мог", и ждать результата...

[san]

Replying to alx:
Добавил последний коммент в TracEffectiveWork

[san]

Воспроизвёл что-то подобное, показал Диме. Новой информации для размышлений не добавилось по причине #219

Хотя это немного другой баг, создал #227

[dimag]

r261

[san]

Очень лаконично закрыл )

В чём была проблема? как исправил?

[dimag]

Проблема с мьютексами, сейчас я исправил работу с мьютексами по вашим рекомендациям, сделал один глобальный мьютекс.

[alx]

Replying to dimag:

Проблема с мьютексами,

??? А где в changeset:261 хоть слово, касающееся мьютекса? Я вижу только какие-то исправления, касающиеся инкремента итераторов, и в 4 местах закомментарен вызов free()...

[alx]

Replying to alx:

??? А где в changeset:261 хоть слово, касающееся мьютекса?

Ну, раз ответа нет, будем считать вопрос риторическим. :)

[dimag]

Я исправил работу с мютексами в r251, r252.
Я описался.

[san]

Milestone renamed