[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