[PATCH 4 of 6 v6 lazy-manifest] manifest: use custom C implementation of lazymanifest

Matt Harbison mharbison72 at gmail.com
Wed Mar 11 23:25:41 CDT 2015


On Wed, 11 Mar 2015 22:18:44 -0400, Matt Harbison <mharbison72 at gmail.com>  
wrote:

> On Sat, 07 Mar 2015 12:16:19 -0500, Augie Fackler <raf at durin42.com>  
> wrote:
>
>> # HG changeset patch
>> # User Augie Fackler <augie at google.com>
>> # Date 1425695387 18000
>> #      Fri Mar 06 21:29:47 2015 -0500
>> # Node ID 821f59a10986d380352d4f88f65f9398e3671d4e
>> # Parent  74e64852b07f9cfb5a7b89d827dd9e1f01314b1b
>> manifest: use custom C implementation of lazymanifest
>
> I'm getting a python crash on Windows, starting with this when running  
> './run-tests.py --local test-locate.t', with 2.7.2.  Letting Visual  
> Studio debug it only indicates that it dies in a free(), on top of a  
> fairly large python27.dll call stack.
>
> What's the best way to go about debugging this?  Is there a way to build  
> the dll in debug mode, and maybe it will trigger some assertion closer  
> to the original heap corruption?
>
> --Matt

I managed to get a debug version built with various _ASSERTE(  
_CrtCheckMemory( ) ) calls sprinkled around.  It asserts in  
lazymanifest_setitem() after calling 'sprintf(dest + plen + 1 + (i * 2),  
"%02hhx", hash[i]);'.

I don't see an 'hh' size prefix [1], but dropping one of the 'h' didn't  
change anything.  I got this from DebugView, tracing the relevant  
variables:

[7704] dest is 006F1A90, plen is 1, i is 17, total is 006F1AB4
[7704] dest is 006F1A90, plen is 1, i is 18, total is 006F1AB6
[7704] dest is 006F1A90, plen is 1, i is 19, total is 006F1AB8
[7704] HEAP CORRUPTION DETECTED: after Normal block (#100) at 0x006F1A90.
[7704] CRT detected that the application wrote to memory after end of heap  
buffer.
[7704] Normal located at 0x006F1A90 is 43 bytes long.

It seems to happen the first time it gets to 19 in the loop.  After  
selecting 'close program', a ton more tracing comes out where it goes  
through that loop with no issue.

I'll pick this up tomorrow when I'm not half asleep if nobody else figures  
it out first.

--Matt

[1] https://msdn.microsoft.com/en-us/library/56e442dc.aspx


More information about the Mercurial-devel mailing list