Hi Brian, the backtrace is completely bogus - probably the stack is corrupted after some illegal mem ops.
Please send me privately the complete logs . Also, can you reproduce this crash ? Thanks and regards, Bogdan [email protected] wrote: > Hello Bogdan, > > An lun., févr 22, 2010, Bogdan-Andrei Iancu schrieb: > >> Maybe you should consider reporting the crashing you are mentioning >> (if they are so many as you say), so somebody could fix them - in >> this case everybody will be happier , I guess. >> >> > Here's a backtrace of the OpenSIPS 1.6.1 sometime after REGISTER > request comes in: > > # gdb /pfx/sbin/opensips opensips.16452.name.host.tld.core > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i386-pc-solaris2.11"... > (no debugging symbols found) > ... > Loaded symbols for /lib/ld.so.1 > > Core was generated by `/pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid > -m 64'. > Program terminated with signal 11, Segmentation fault. > [New process 83290 ] > #0 0x0810d931 in qm_malloc () > (gdb) bt > #0 0x0810d931 in qm_malloc () > #1 0x0835b5a8 in mem_pool () > #2 0x0835bf9c in mem_pool () > #3 0x08046670 in ?? () > #4 0xd0d55fd0 in ?? () from /pfx/lib/opensips/modules/auth_aaa.so > #5 0x0835d9b8 in mem_pool () > #6 0x08313240 in ?? () > #7 0x08046658 in ?? () > #8 0xd0d51bb9 in authorize (_msg=0x20, _realm=<value optimized out>, > _uri_user=<value optimized out>, _hftype=0) at authorize.c:126 > #9 0x00000000 in ?? () > (gdb) > > >> If it crashes or not it depends a lot of what functionalities >> (modules) you are using (nobody can claim he tested all the modules >> in all possible combinations). >> >> > Seems to me that the crash from the core dump above relates to flaws > in the AAA authorization logic. Here's the last message in the sip > trace before the crash (not sure if it's representative.) > > 125:1267207762:3c2d04c4da9c-95w1oc5r17eu::SIP/2.0 401 Unauthorized > Via: SIP/2.0/TLS > 192.168.130.35:2291;branch=z9hG4bK-kv7jq7chf8p1;rport=2291;received=1.2.3.4 > From: "My Name" <sip:[email protected]>;tag=xlrkkswd5y > To: "My Name" > <sip:[email protected]>;tag=d170206e0ec14c1ccd1967a0f5e85cb9.9210 > Call-ID: 3c2d04c4da9c-95w1oc5r17eu > CSeq: 515 REGISTER > WWW-Authenticate: Digest realm="name.host.tld", > nonce="4b880e705d5b5fafcb33b4df08f7689d6850ac25", qop="auth" > Server: OpenSIPS (1.6.1-tls (i386/solaris)) > Content-Length: 0 > Warning: 392 name.host.tld:5061 "Noisy feedback tells: pid=17754 > req_src_ip=1.2.3.4 req_src_port=2291 in_uri=sip:name.host.tld > out_uri=sip:name.host.tld via_cnt==1" > > Here are the last few lines from the log before hundreds of memory > debug lines appear (because I have memory debugging on.) > > <warning> opensips[12744]: WARNING:core:init_tls: disabling compression due > ZLIB problems > <warning> opensips[12744]: WARNING:core:init_ssl_ctx_behavior: client > verification activated. Client certificates are mandatory. > <warning> opensips[12744]: WARNING:core:init_ssl_ctx_behavior: server > verification activated. > <critical> opensips[12756]: CRITICAL:core:receive_fd: EOF on 20 > <warning> opensips[12748]: Memory status (pkg): > <warning> opensips[12748]: qm_status (8313260): > > If you like I can send more of the memory debug log lines, but > please tell me just what to send (so I can avoid sending hundreds > of lines of log text.) > > >> For example I'm running opensips.org SIP service with SVN trunk >> and I do not get any core dumps... and it is an almost 3K lines >> config... >> >> > Building OpenSIPS 1.6.0 with the same radiusclient-ng installation > (which is up to date) results in a more stable runtime. It's usually > good for several days before crashing. > > >> So, again, if you get crashes, please report them. >> >> > Okay, but I've noticed that some crashes do not produce core dumps. > > >> PS: if the build is bogus (like in Nathaniel), the runtime will be >> unstable also - OpenSIPS has a lot of asm code that really depends on >> arch, so messing the build params may lead to bogus code. >> >> > My build is correct. > > Regards, > Brian > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
