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/
pgpE9vC3mgvSV.pgp
Description: PGP signature