[OpenSIPS-Devel] Some ways to crash OpenSIPS with current SVN

[Thomas Gelf]

Bogdan-Andrei Iancu wrote:
>> I tried revision 5854, using both pkg_malloc and system malloc (if
>> compiled correctly, I'm not sure -> see other thread). Easiest way
>> to crash them: restart, start a new dialog, restart while calling,
>> maybe put on hold and pick up - works most of the times. Example
>> backtrace:
>>   
> Tried to reproduce the scenario....but no luck. Could explain a bit in 
> more details ? - the restart takes place during ringing stage or after 
> the call is answered? what is the cfg of the dialog module?

Call, pick up, say something, restart... Tried once again, r5784:

[New process 10528]
#0  0x00002b26fc198ed5 in raise () from /lib/libc.so.6
(gdb) bt full
#0  0x00002b26fc198ed5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00002b26fc19a3f3 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x000000000041f72f in sig_alarm_abort (signo=<value optimized out>)
at main.c:422
	__FUNCTION__ = "sig_alarm_abort"
#3  <signal handler called>
No symbol table info available.
#4  0x0000000000474b13 in fm_status (qm=0x2b2702763000) at
mem/f_malloc.c:513
	f = (struct fm_frag *) 0x2b2702de1f80
	i = 4015888029
	j = 0
	h = 1535
	size = 471329333004194
	__FUNCTION__ = "fm_status"
#5  0x000000000041f45c in cleanup (show_status=1) at main.c:363
No locals.
#6  0x000000000041f864 in handle_sigs () at main.c:464
	chld = <value optimized out>
	chld_status = <value optimized out>
	i = <value optimized out>
	do_exit = <value optimized out>
	__FUNCTION__ = "handle_sigs"
#7  0x0000000000422577 in main (argc=<value optimized out>, argv=<value
optimized out>)
    at main.c:871
	cfg_log_stderr = <value optimized out>
	cfg_stream = (FILE *) 0x0
	c = <value optimized out>
	r = 16
	tmp = 0x7fffaef76eb0 ""
	tmp_len = <value optimized out>
	port = <value optimized out>
	proto = <value optimized out>
	ret = <value optimized out>
	seed = 2550124078
	rfd = <value optimized out>
	__FUNCTION__ = "main"

OpenSIPS stopped working - but it took about one minute unless coredump
happened?! Usually it is faster - but that's not something I'd like to
complain about ;-)

> or maybe we can see some cores + logs on your system ;)

Sure, whenever you have some spare time - cores are awaiting your visit!

> actually, all the BTs, taken out of the context (scenario, logs, etc) 
> are not very helpful ....so, maybe we do some joined testing on your 
> platform and find the problem out.

I've sent you another interesting one off-list...

Cheers,
Thomas