This is most embarrassing. It turns out that the _real_ problem I've been having all along is that I did something with a GUI toolkit I'm using in my application that the toolkit author didn't envision.
The author did in fact tell me he did things a certain way, but he thought it would be OK if I did it my way. But what happened when I did it my way was that disposing of a pane that was populated with subpanes would delete all the subpanes twice, corrupting memory horribly. Of course what I did in my case, was to add a pane to my app that would read in an XML file to get stuff to display in the pane. I would delete the pane that was previously in that place. Up until that point I had only been putting panes into the app that stayed in place, so it seemed OK to do what I was doing. So I quite coincidentally wrote code that addled the heap and then created a DOM_Parser and parsed a file, which does a lot of allocation and so would crash. Why did it seem to help to roll my own memcpy? One possible reason is that the memcpy provided by codewarrior is a compiler intrinsic rather than a library function. Another possibility is that simply by writing new code I changed the conditions just a little bit to delay a crash. But what happened is that after rolling my own memset last night I was able to read in a whole XML file and walk the tree. But I couldn't do that again today, and after investigating further all kinds of chaos occurred. I had to be very careful about my testing because testing twice with apparently the same initial conditions wouldn't get the same results. For most of my work the last couple weeks, stepping through things with the source debugger would make crashes not occur. On the other hand, simply recompiling source that hadn't changed would turn a non-crash into a crash, probably because I wrote lots of nice garbage into memory. I guess I've been suitably punished for my error. The GUI library I'm using is a very nice cross-platform library that a friend wrote, that he's used for some successful products of his own. But he's never been willing to release it, feeling that it wasn't ready yet. I'm the first person besides himself to get to use it, and part of the deal is that I'm to give him feedback on getting it ready for release, and also I'm going to write documentation for it. I'm not sure what he should do about my problem if anything; it's nicer to write my code the way I did than the way he recommended, but it would be a lot of work for him to rearchitect his code to work the way I want it to. Anyway, thanks for all your help. What I'd like to do, once I get my fabled build to my client, is do a fresh check out of the latest xerces sources, apply my patches to the clean source, and submit my changes after making sure it all works right. In the course of debugging I've put all kinds of diagnostic code into everywhere and there's probably lots of footprints left. So, should this merit some kind of award? Porting to a new platform with a corrupted heap? Mike Crawford GoingWare - Sometimes Confused Software Development and Consulting http://www.goingware.com [EMAIL PROTECTED]
