On Tue, Aug 31, 2010 at 1:52 AM, Wes Hardaker <
[email protected]> wrote:
>
> The following patch ensures that the status file still exists. I
> watched a process disappear in the middle of debugging and actually saw
> this error live (when looking for something totally unrelated).
>
> diff --git a/net-snmp/agent/mibgroup/host/data_access/swrun_procfs_status.c
> b/net-snmp/agent/mibgroup/host/data_access/swrun_procfs_status.c
> index 0c562f6..54cc71e 100644
> --- a/net-snmp/agent/mibgroup/host/data_access/swrun_procfs_status.c
> +++ b/net-snmp/agent/mibgroup/host/data_access/swrun_procfs_status.c
> @@ -83,6 +83,8 @@ netsnmp_arch_swrun_container_load( netsnmp_container
> *container, u_int flags)
> */
> snprintf( buf2, BUFSIZ, "/proc/%d/status", pid );
> fp = fopen( buf2, "r" );
> + if (!fp)
> + continue; /* file (process) probably went away */
> memset(buf, 0, sizeof(buf));
> fgets( buf, BUFSIZ-1, fp );
> fclose(fp);
>
The above patch only addresses one of the two fopen() calls in the loop.
What about the second fopen() call ? Why not to check its return value too ?
And, more importantly, if fopen() fails, shouldn't the just created entry be
removed again from the container ?
An alternative is to wait with container insertion until 'entry' has been
initialized entirely.
Bart.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
