Hi Avery,
Nice catch. Looks like the job_trove_bstream_read_list call sets
parameters and returns, so the result.bytes field is actually out of
scope later (as part of the one element array passed in). It doesn't
always segfault because the value remains unchanged, even though its
unallocated at the point where its accessed.
For safety's sake, I probably shouldn't even define a local result,
even though its convenient, as I end up forgetting what needs to be
kept around past the scope of the state action.
In any case, I'll clean this up and commit a fix. Thanks again!
-sam
On May 23, 2006, at 10:12 AM, Murali Vilayannur wrote:
Hi Avery,
Yup.. Your fix is correct, but let's wait for Sam's comments..
Why exactly is result.bytes different from s_op-
>u.small_io.result_bytes?
I wonder how this did not get triggered in the normal scenarios
(perhaps
it needed a sparse data file or something?)
Thanks,
Murali
On Mon, 22 May 2006, Avery Ching wrote:
I kept getting segmentation faults with the read case in the small
I/O
state machine. I think there's a problem with the parameter
passed in
to job_trove_bstream_read_list() around line 194 of small-io.sm.
instead of:
&result.bytes,
I think it should be:
&s_op->u.small_io.result_bytes,
Avery
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
