[PVFS2-developers] CVS pvfs2-server server daemons crashing

Robert Latham robl at mcs.anl.gov
Thu Jun 2 16:44:01 EDT 2005


On Thu, Jun 02, 2005 at 02:13:28PM -0400, Pete Wyckoff wrote:
> In src/io/description/pint-request.h just before line 97 where the
> values of ereq and sreq are filled, can you zero the entire word and see
> if that fixes it? (untested)
> 
>      /* put integer offsets into pointers, let PINT_Request_decode fix */ \
> +    (rp+i)->ereq = 0; \
> +    (rp+i)->sreq = 0; \
>      decode_uint32_t(pptr, (u_int32_t*) &(rp+i)->ereq); \
>      decode_uint32_t(pptr, (u_int32_t*) &(rp+i)->sreq); \
> 
> Even though linearization produces <32-bit offsets, perhaps the decode
> here only fills in the bottom half of an otherwise uninitialized 64-bit
> memory region.  The new assignments I hope will get rid of the 0xe70 or
> other junk that was hanging around the top half.

Great.  That got bonnie++ to progress further than it has so far for
me:

Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...

(and it's still running, but it's taking not-quite-literally forever
for the file 'sequential creation' step, and there's still the
deletion and 'random creation' to go. )

Walt and I were talking and we figure there is probably more than one
place with a bug of this class.   Is there a way to gaurantee we zero
out every bit of these decoded requests?

==rob

-- 
Rob Latham
Mathematics and Computer Science Division    A215 0178 EA2D B059 8CDF
Argonne National Labs, IL USA                B29D F333 664A 4280 315B


More information about the PVFS2-developers mailing list