[Pvfs2-developers] Odd problem

[Walter Ligon]

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 
something.

Walt

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