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.

-- 
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/

Attachment: pgpE9vC3mgvSV.pgp
Description: PGP signature

Reply via email to