Segmentation Fault using ConfBridge

When I create number of conference rooms with about 10 SIP clients connecting to each room I get a segmentation fault???
Here’s the backtrace from the gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb22c3b90 (LWP 30161)]
0x00c83c2d in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) backtrace
#0 0x00c83c2d in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x001ee7a6 in pthread_mutex_lock () from /lib/libc.so.6
#2 0x008e7027 in softmix_bridge_write (bridge=0xb3d41d80, bridge_channel=0xb3f7a078, frame=0x86dfdf4)
at bridge_softmix.c:170
#3 0x0808d788 in ast_bridge_handle_trip (bridge=0xb3d41d80, bridge_channel=0xb3f7a078, chan=0x86e28c8, outfd=-1)
at bridging.c:299
#4 0x009a73dc in multiplexed_thread_function (data=0xb3d5d690) at bridge_multiplexed.c:233
#5 0x0818e17b in dummy_start (data=0xb2daba58) at utils.c:971
#6 0x00c81832 in start_thread () from /lib/libpthread.so.0
#7 0x001e1f6e in clone () from /lib/libc.so.6

Any ideas?

Can you do: “module show timing” from the Asterisk CLI and paste the output?

*CLI> module show timing
Usage: module show [like keyword]
Shows Asterisk modules currently in use, and usage statistics.

If you want the stats I won’t be able to report them anyway since asterisk exits with a segmentation fault after creating that many SIP connections!

I think Malcolm is thinking about problems with particular internal timing sources. He may have given you the wrong command.

Generally though, if you have a crash using current, unpatched, versions, on supported systems, you should report them on the bug tracker, although the backtrace information required is more than you have (unoptimised bt full, and, if possible, thread apply all bt full output).

Yup, whoops.

module show like timing

Cheers.

[quote=“malcolmd”]Yup, whoops.

module show like timing

Cheers.[/quote]

*CLI> module show like timing
Module Description Use Count
res_timing_pthread.so pthread Timing Interface 1
1 modules loaded

[quote=“david55”]I think Malcolm is thinking about problems with particular internal timing sources. He may have given you the wrong command.

Generally though, if you have a crash using current, unpatched, versions, on supported systems, you should report them on the bug tracker, although the backtrace information required is more than you have (unoptimised bt full, and, if possible, thread apply all bt full output).[/quote]

Although I’m using current unpatched version now, I have this issue with actual releases including Asterisk 1.6!
I’ll recompile and submit the backtrace on bug tracker.

hi,

did you solve the issue? i have the same problem when this module is loaded. but i only need it for fax. hapens with 1.8 and 10.

kind regards,
andre