On Mon, Jun 14, 2010 at 8:53 PM, W Z <lh_1...@hotmail.com> 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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
