Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^5: Hard to Debug windows memory error

by jandrew (Chaplain)
on May 12, 2016 at 13:01 UTC ( [id://1162857]=note: print w/replies, xml ) Need Help??


in reply to Re^4: Hard to Debug windows memory error
in thread Hard to Debug windows memory error

I did check the application event logs as well as running several windows style c debuggers but none of the things I found and worked on with my skill set seemed to impact the core problem. (re-installing another version of Visual Studio, adding to Path so .dlls would be recognized etc.) I still don't have a solid understanding of where the root of the problem even lies. In truth I have never had a fail like this with perl before. I deeply respect XML::LibXML too so the fact that they don't play well together in this case was painful.

Replies are listed 'Best First'.
Re^6: Hard to Debug windows memory error
by BrowserUk (Patriarch) on May 12, 2016 at 14:04 UTC
    I still don't have a solid understanding of where the root of the problem even lies.

    The worst part about "heap corruption" is that a) it can be caused by anything that can write to memory; b) can not be discovered until long after it happens.

    A strcpy from a string with a missing null will write on for a long time and usually corrupt so much that it fails quickly.

    But a write of an integer through a miscalculated pointer will only affect 4 or 8 bytes and won't be discovered until the program tries to make use of the value that should be there. If the data that gets overwritten happens to be a heap internal value -- say a sentinel or offset -- then the corruption may not be discovered until much later; often not until global cleanup as the program terminates.

    The only way I know of to debug heaps -- and I only tried it once -- is to recompile the program (perl.exe in this case) with CRT Debug Heap configured. That will (theoretically) discover the corruption much earlier and get you closer to the errant code. The big problem is then translating the machine address from which the write occurred into something that you can relate to your Perl code.

    And, it is not unheard of that configuring the debug heap makes the problem "go away". Of course, it doesn't really. It just causes the errant write to hit something that doesn't hurt -- a piece of freed, never reused memory or similar -- until you remove all the extra space used by the debug routines; and then it just comes back again.

    I feel for your irritation at not knowing; but sometimes you just have to know when to let stuff go :)


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1162857]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2024-03-29 04:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found