----- Original Message -----
> On Fri, Aug 24, 2012 at 11:12:26AM -0400, Darryl L. Pierce wrote:
> > On Fri, Aug 24, 2012 at 10:27:29AM -0400, Chuck Rolke wrote:
> > > This sounds like a gratuitous trailing null.
> > > Added nulls could be happening on all buffer sizes but don't
> > > cause an issue until the power-of-2-size payload puts the null
> > > into territory that gets checked for buffer overruns.
> > 
> > I think you're onto something there. Putting some debugging code
> > into
> > the wrapper, I'm seeing that at those points the data returns by
> > pn_message_save is corrupted; i.e., on those specific lengths the
> > data returns doesn't even remotely match. For example:
> > 
> > [TEST AT 64 CHARACTERS]
> > Testing data at 64 characters.
> > Trying with a bufsize of 1024.
> > rc=0
> > bufsize=64
> > *ALLOC_OUTPUT is 65 bytes.
> > *ALLOC_OUTPUT ==
> > "vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcgP"
> > Exiting with a return code of 64
> > Comparing:
> > vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg
> > vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg
> > Do they match? Yes
> > 
> > [TEST AT 65 CHARACTERS]
> > Testing data at 65 characters.
> > Trying with a bufsize of 1024.
> > rc=0
> > bufsize=65
> > *ALLOC_OUTPUT is 4 bytes.
> > *ALLOC_OUTPUT == "�j� "
> > Exiting with a return code of 65
> > Comparing:
> > obinopuaxubdehrwmkqqxhitzcfroiqnzdoxjqcqvkgpwsdprryegwxluiheklaul
> > �j�
> > 
> > pkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg
> > Do they match? No
> > 
> > As you can, at 64 bytes (and all lengths prior to it) the strings
> > internal always match. But, at 65 bytes the result is those weird
> > few
> > characters and nothing even remotely like the string passed in
> > previously.
> 
> More investigation and debuggin on this:
> 
> When the string fails (you can see it in the above case) the failed
> string consists some garbage and then the previous message's string
> starting at n bytes into that string, where n = 8 if the length is
> 65, n
> = 16 if length is 129 or 257.
> 
> Still digging into this but haven't found where the problem is. Still
> wrapping my head around the encoding and decoding pieces.

As I'm reading this "I Still Haven't Found What I'm Looking For" from U2's 
Joshua Tree was playing in the background. 

Where is the offending code?  What is ALLOC_OUTPUT for? Why is it 4?

William
 
> 
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
> 
> 

Reply via email to