[Home]

Summary:ASTERISK-14846: auto-loading res_snmp causes Asterisk to Seg fault
Reporter:Jonathan Thurman (jthurman)Labels:
Date Opened:2009-09-17 17:43:22Date Closed:2011-07-27 13:01:50
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Resources/res_snmp
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gdb.txt
( 1) gdb-1.6.1.10-rc1-20091106.txt
( 2) gdb-1.6.1.10-rc2-20091112.txt
( 3) gdb-1.6.1.10-rc3-20091113.txt
( 4) noload-chan_h323-gdb.txt
( 5) noload-pbx_lua-gdb.txt
( 6) res_snmp.conf
( 7) valgrind-1.6.1.10-rc1-20091107.txt
( 8) valgrind-1.6.1.10-rc2-20091112.txt
( 9) valgrind-1.6.1.10-rc3-20091113.txt
(10) valgrind-1.6.1.9-20091109.txt
Description:If modules.conf has autoload=yes and res_snmp.so is compiled, then Asterisk seg faults every time.  If autoload=no or noload=> res_snmp.so the issue goes away.  You can manually load res_snmp after the initial startup of Asterisk with no issue.

****** ADDITIONAL INFORMATION ******

Platform: CentOS 5.3
Asterisk: 1.6.1.6
net-snmp: 5.3.2.2
Comments:By: Jonathan Thurman (jthurman) 2009-09-17 17:55:00

I should also mention that the system is 64 bit.  Still working on getting a back trace.
By: Leif Madsen (lmadsen) 2009-09-18 07:16:05

Setting this to feedback status while we await the backtrace.

Be sure you have enabled DONT_OPTIMIZE in Compiler Flags of menuselect, or the backtrace won't be very useful.

More information is in doc/backtrace.txt

Thanks!
By: Jonathan Thurman (jthurman) 2009-09-18 14:09:32

If you set autoload=no and load => res_snmp.so the system does not segfault.

While I uploaded my res_snmp.conf file, this still happens if all options are commented out, and if res_snmp.conf file does not exist.
By: Clod Patry (junky) 2009-09-19 00:58:27

Your crash seems to be more related when loading chan_h323.so rather then res_snmp.so

Could you try:
autoload => yes
noload => chan_h323.so

if it works?
By: Jonathan Thurman (jthurman) 2009-09-21 16:26:41

I have two servers configured to test this.  Server1 does not have h323 installed, Server2 does.  All backtraces are from Server2.

Here is what works:

Server1:
 noload => res_snmp.so
or
 noload => pbx_lua.so

Server2:
 noload => chan_h323.so
 noload => pbx_lua.so
or
 noload => res_snmp.so
 noload => chan_h323.so

Here is what doesn't work:

Server2:
 noload => pbx_lua.so
or
 noload => res_snmp.so
By: Tilghman Lesher (tilghman) 2009-09-22 13:54:05

The second backtrace, which loads pbx_lua but not chan_h323, suggests stack corruption.  Can you try starting Asterisk under valgrind, as outlined in doc/valgrind.txt?
By: Jonathan Thurman (jthurman) 2009-11-06 18:48:32.000-0600

Sorry for the delay, it has been difficult to find time for debugging.

I updated to 1.6.1.9 and still have the issue.  I recompiled as specified in doc/valgrind.txt and attached the valgrind.txt.  The malloc_debug.txt file was empty.
By: Leif Madsen (lmadsen) 2009-11-07 14:06:43.000-0600

1.6.1.9 is no different from 1.6.1.6. If you look at the ChangeLogs for 1.6.1.8 and 1.6.1.9, and review the release announcements, you'll see that they are only security releases based on the 1.6.1.6 code.

Please test 1.6.1.10-rc1 for the latest release candidate which has changes post-1.6.1.6.
By: Jonathan Thurman (jthurman) 2009-11-07 20:46:14.000-0600

I updated to 1.6.1.10-rc1 and it still crashes.  I attached the backtrace and valgrind.  Again, the malloc file was empty.

Note: the valgrind.supp didn't work for me, so I used the 1.6.1.9 valgrind directions (no supp file).
By: xiaoyem (xiaoyem) 2009-12-27 20:50:17.000-0600

Seems like rpm-libs has an embedded LUA interpreter, and for some unknown reason, when pbx_lua gets loaded, it tries to use librpmio-4.4.so (from rpm-libs) instead of liblua-5.1.so.

My current workaround is "preload => pbx_lua.so" in modules.conf, but certainly it is not a perfect solution. Anyone had better idea?
By: Alexey Sav (alexsav) 2010-05-04 04:28:00

auto-loading res_snmp causes Asterisk 1.6.0.21 to Seg fault on freebsd6.
this problem solved by
chgrp asterisk /dev/kmem
chgrp asterisk /dev/mem
but it may cause security risk
By: Russell Bryant (russell) 2011-07-27 13:01:41.704-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!