On Jun 15, 2006, at 2:20 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Thu, 15 Jun 2006 13:59 -0500:
What's actually just as curious to me is that we don't ever call
PINT_serv_free_msgpair_resources() in error cases if we *don't*
succeed.
Does this mean that every msgpairarray failure results in some
resources
being leaked? Making that "else" block would effectively just skip
this
code, avoiding the core dump but not freeing the resources.
Perhaps we should have PINT_serv_decode_resp() initialize
decoded_resp
prior to exit and have PINT_serv_free_msgpair_resources()
understand a
NULL value for that input parameter?
Good point. The server response came with this status:
(gdb) p decoded_resp_p->stub_dec.resp.status
$5 = -1073741828
But in the decode process, after decoded the status, we find it
is EIO, and skip the rest of the decoding in lebf_decode_resp,
so the contents of u.lookup_path were never initialized:
(gdb) p decoded_resp_p->stub_dec.resp.u.lookup_path
$6 = {handle_array = 0xf8, attr_array = 0x537c30, handle_count =
5471472,
attr_count = 0}
And later we try to free(handle_array).
The special case EIO handling in PINT-le-bytefield.c:605
was added, for a reason, maybe because the server sends a bogus
message that shouldn't be decoded. Here's robl's log message when
adding the check:
revision 1.29
date: 2004/09/29 20:32:09; author: robl; state: Exp; lines:
+49 -39
probably did not do this in a general-enough way: don't try to
decode/encode
response-specific portions of a server response if something
catastrophic
happened on the server end.
I'm sure once Sam takes a look at the dbpf issue, the EIO problem
will go away. Not sure what the right way to design this client-
side probem is, though, in case we get more server EIO issues in the
future.
I haven't been able to reproduce this specific error or get dbench to
fail for me, but Murali just committed a bunch of fixes to bugs in
the keyval changes I made recently that I could imagine causing a lot
of weird behaviors. If you find that these commits fix the dbench
errors you were seeing, let me know. I'd prefer to wait to cleanup
the error handling on the server (db->err and the weird EIO case) as
well as the msgpairarray problems until after the release.
-sam
-- Pete
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
