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
Index: cpu_kstat.c
===================================================================
--- cpu_kstat.c (revision 17363)
+++ cpu_kstat.c (working copy)
@@ -103,6 +103,8 @@
if (strcmp(ksp->ks_module, "cpu_stat") == 0) {
i = ksp->ks_instance;
cpu2 = netsnmp_cpu_get_byIdx( i, 0 );
+ if ( !cpu2 )
+ break; /* or continue ? */
if ((ksp->ks_type != KSTAT_TYPE_RAW) ||
(ksp->ks_data_size != sizeof(cs))||
(kstat_read(kstat_fd, ksp, &cs) == -1)) {
------------------------------------------------------------------------------
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
