Re: subagent core dump at startup

On Mon, Jun 14, 2010 at 8:53 PM, W Z <[email protected]> wrote:

>  We use net-snmp 5.4.2.1.  We had a subagent core dump at system start up.
> This happens rarely, i.e., cannot reproduce.
>
> After gdb core file, backtrace shows:
> ======================================================================
> Program terminated with signal 11, Segmentation fault.
> [New process 3632]
> #0  0xf757b871 in abort () from /lib/libc.so.6
>
> (gdb) bt
> #0  0xf757b871 in abort () from /lib/libc.so.6
> #1  0xf75b22db in __libc_message () from /lib/libc.so.6
> #2  0xf75ba5e5 in _int_free () from /lib/libc.so.6
> #3  0xf75baa29 in free () from /lib/libc.so.6
> #4  0xf7d58ac7 in snmp_free_pdu (pdu=0x93d3dc8) at snmp_api.c:5088
> #5  0xf7d594ba in _sess_process_packet (sessp=0x93600e0, sp=0x93b4d18,
> isp=0x936a518, transport=0x9372040, opaque=0x93d15b0,
>     olength=110, packetptr=0x93f2370 "\001\022", length=72) at
> snmp_api.c:5354
> #6  0xf7d5a7a4 in _sess_read (sessp=0x93600e0, fdset=0xfff1dcec) at
> snmp_api.c:5707
> #7  0xf7d5ac1b in snmp_sess_read (sessp=0x93600e0, fdset=0xfff1dcec) at
> snmp_api.c:5806
> #8  0xf7d596de in snmp_read (fdset=0xfff1dcec) at snmp_api.c:5423
> #9  0xf7d2c5aa in snmp_synch_response_cb (ss=0x93b4d18, pdu=0x93d53b8,
> response=0xfff1de08,
>     pcb=0xf7f4fd90 <agentx_check_packet+3>) at snmp_client.c:1016
> #10 0xf7f50039 in agentx_synch_input (op=154881304, session=0x93d53b8,
> reqid=-926200, pdu=0x0, magic=0xf7f23192)
>     at mibgroup/agentx/client.c:100
> #11 0xf7f506f7 in agentx_register (ss=0x93b4d18, start=0x90ba098,
> startlen=12, priority=127, range_subid=0, range_ubound=0,
>     timeout=-1, flags=0 '\0', contextName=0x90b9ff0 "") at
> mibgroup/agentx/client.c:213
> #12 0xf7f3d99e in agentx_registration_callback (majorID=1, minorID=1,
> serverarg=0xfff1ded0, clientarg=0x93b4d18)
>     at mibgroup/agentx/subagent.c:632
> #13 0xf7d7e217 in snmp_call_callbacks (major=1, minor=1,
> caller_arg=0xfff1ded0) at callback.c:341
> #14 0xf7f30de0 in register_mib_reattach_node (s=0x90ba038) at
> agent_registry.c:768
> #15 0xf7f30e2e in register_mib_reattach_node (s=0xfff1df58) at
> agent_registry.c:772
> #16 0xf7f3e752 in agentx_reopen_session (clientreg=0, clientarg=0x0) at
> mibgroup/agentx/subagent.c:869
> #17 0xf7f3b8b7 in subagent_startup (majorID=0, minorID=0, serverarg=0x0,
> clientarg=0x0) at mibgroup/agentx/subagent.c:99
> #18 0xf7d7e217 in snmp_call_callbacks (major=0, minor=0, caller_arg=0x0) at
> callback.c:341
> #19 0xf7d7013d in read_configs () at read_config.c:877
> #20 0xf7d4a107 in init_snmp (type=0x824f33c "subsnmpd") at snmp_api.c:811
> #21 0x0805005f in main (argc=7, argv=0xfff22194) at main.c:573
> ======================================================================
>
> I suspect there is a NULL pointer passed to "free()".  However, by looking
> at function snmp_free_pdu(), it does pointer check before calling "free"
> function. So, what is the other cause that free() abort?
>
> Also, notice something weird in backtrace #14 and #15, function
> register_mib_reattach_node() stacked twice?  How could this be?
>
> We only run snmpd and subagent once. There should be no multi-thread issue,
> I would assume.
>

What does Valgrind report when you try to reproduce this issue with snmpd
running under Valgrind ?

Bart.

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users