Okay. I see that it is a complex problem that you've at least worked your way past if not actually fixed.
(Did you check the Application Event logs on the failing machines?)
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [Watch: Dir/Any] |
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.
| [reply] [Watch: Dir/Any] |
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [Watch: Dir/Any] |