Asterisk Segmentation fault after call pickup

Hello,
i have a strange problem that newer happened before
after i pickup a call Asterisk crashes
Please help to figure out whycore.882-locks.txt (599 Bytes) core.882-info.txt (400 Bytes) core.882-full.txt (67.6 KB) core.882-brief.txt (47.3 KB) core.882-thread1.txt (2.0 KB)

Please provide a dump that is from your segmentation violation, and which was made with the debug symbols available.

If this really was an abort and not a segmentation violation, it occurred when trying to allocate memory in app_konference, and there will be an assertion failure message, but you haven’t captured it directly, and, because you have no debug symbols, you haven’t captured it as a parameter of a function call.

Assertion failures in malloc are normally caused by memory corruption, and that corruption may have been associated with another thread and happened somewhat earlier.

The app_konference module is also third party, and I’ve seen a few crashes in it posted by people previously.

sorry did not get
should i send U a file core that was created by asterisk ?
or what ?
Regards

You shouldn’t report a segmentation fault unless you actually have a segmentation fault. The evidence you have provided is of cases where the user space software has called abort().

You should not provide the core file. It is of no use to us without the symbol tables.

You should make sure that gdb has access to the debugging symbols, before trying to get the backtrace. These are either included in the executables or in separate files.

If you expect more than a cursory glance at the backtraces, you must reproduce the fault in a current, unmodified, version of Asterisk. If a modified version is essential, you either need to debug down to the actual faulty code, or you need to get the supplier of the modified version to debug it. You appear to have a modified version.

Even for standard, current versions, if the code isn’t compiled with NOOPTIMISE, it may be too difficult to see enough of what is going on to be able to debug it.

Especially where memory corruption is indicated, as in your case, you need to provide a lot of detail as to what was happening at the time, including any unusual message within a few minutes of the crash, as the underlying fault may have been created by code which isn’t on the current stack.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.