Hi Dave,
I think that the fix worked. However, I got another core dump.
Core was generated by `/usr/local/sbin/snmpd -D cpu'.
Program terminated with signal 8, Arithmetic exception.
[New process 90196 ]
#0 0x000796bc in var_hrproc (vp=0xffbfef88, name=0xffbff194,
length=0xffbff594, exact=0, var_len=0xffbff598, write_method=0xffbff59c)
at host/hr_proc.c:183
183 long_return = 100 - long_return;
(gdb) p cpu
$1 = (netsnmp_cpu_info *) 0x351b50
(gdb) p *cpu
$2 = {idx = 12, name = "cpu12", '\0' <repeats 4090 times>,
descr = "CPU 12 Sun 1167 MHz sparcv9 with sparcv9 FPU on-line", '\0'
<repeats 4043 times>, status = 2, user_ticks = 100349629,
nice_ticks = 0, sys_ticks = 0, idle_ticks = 988620081, wait_ticks = 0,
kern_ticks = 3227959, intrpt_ticks = 0, sirq_ticks = 0,
total_ticks = 1092197669, sys2_ticks = 3227959, pageIn = 0, pageOut =
0, swapIn = 0, swapOut = 0, nInterrupts = 0, nCtxSwitches = 0,
history = 0x349970, next = 0x2c4d80}
(gdb) p cpu->total_ticks
$3 = 1092197669
(gdb) cpu->history[0].total_hist
Undefined command: "cpu->history". Try "help".
(gdb) p cpu->history[0].total_hist
$4 = 1092197669
-----Original Message-----
From: dave.shi...@googlemail.com [mailto:dave.shi...@googlemail.com] On
Behalf Of Dave Shield
Sent: 27 January 2009 11:15
To: Hindley Nick
Cc: Net-snmp-users@lists.sourceforge.net
Subject: Re: net-snmp and solaris dynamic reconfiguration
2009/1/26 Hindley Nick <nick.hind...@hfbp.co.uk>:
> A few weeks ago I noticed that I had a problem with snmpd core
dumping.
> .... which is caused by an attempt to dereference cpu2 which is NULL
>
> (gdb) print cpu2
> $1 = (netsnmp_cpu_info *) 0x0
> Now what I think has happened, is that the cpu... structures have been
> instantiated with a view of what CPUs have been allocated to the zone
> which has subsequently been changed by the solaris dynamic
> reconfiguration. This then means that when the new processor ID is
> introduced to the zone, its not found and a null pointer is returned.
>
> Does this make sense?
Yes.
The code does assume that the number of CPUs is constant.
> Any ideas how to fix?
One option would simply be to skip any "new" CPUs.
The attached patch is untested, but should handle that.
(Though I'm not sure whether it would work better with 'break'
or continue - you should experiment).
If you change the 'break' statement to call 'init_cpu_kstat()'
instead, then this should cope with updating the list of CPUs.
Obviously, that's even more untested than the basic patch, but give it a
go and let us know how you get on.
Dave
=======================================================================
Scanned for virus infection by Messagelabs
=======================================================================
=======================================================================
This email has been scanned for Virus infection by MessageLabs
For more information please contact messagel...@atomwide.com
=======================================================================
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
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
