[Pvfs2-developers] Odd problem
walt at clemson.edu
Wed Jul 15 18:09:55 EDT 2009
Right. That is a big union, and if you look at it, there are some
really weird values if you don't clear it. But you make a good point, I
will have Becky check her new request and make sure she didn't forget
Pete Wyckoff wrote:
> walt at clemson.edu wrote on Wed, 15 Jul 2009 16:09 -0400:
>> whilst working with a branch (not the trunk) I came upon an odd bug.
>> During server initialization in the function lebf_initialize() the
>> function creates a dummy request and encodes it over and over again,
>> once for each request type in order to discover the max size. This
>> dummy request is never zero'd between iterations. I found that in some
>> instances this caused a seg fault - but changing almost anything might
>> undo it. Same code compiled/linked a different way may or may not fail.
>> Simply putting a memset() in the loop fixes it, as far as I can tell.
>> Anyone know why we don't zero the request, or object to adding that?
>> Seems to have no performance impact since it is in initialization.
> I toyed around with this code almost six years ago. The idea at the
> time was that the switch in lebf_initialize set just the right
> parameters needed by the various encode_PVFS_servreq_.... handlers.
> Although now that you mention it, setting everything back to zero
> does make sense, in that things generally behave nicely when
> presented with zeroes.
> Since this code has in the past failed to make valgrind complain, I
> do have to wonder if you forgot to initialize some fields needed for
> your new request type. But a memset() in that loop would be pretty
> harmless if it fixes things for you; it only happens once at
> client/server startup.
> -- Pete
More information about the Pvfs2-developers