Cannot say I envy you with this situation


If you are out of ideas - you may want to change the code in the error handler. Assuming that the memory may already be corrupt before getting to the error handler may make sense - but you really don't know - do you ?

I've had cases where changing the value of editboxes (in the keypress event) errors out on C0000005 once in a while. Why ? I couldn't tell
I've solved that one by replace controlsource wuth newvalue, followed by editbox.Refresh(). Same result but by another means

I've had cases where I had to take DoDefault() out of the programmaticChange() - Error C0000005 once in a while

So, changing the code of the error handler is not likely to solve the problem, but there's a chance it may - even if the memory was already corrupt it may not bomb out there

_________________


>>If you are getting a buffer overrun in 'list memory', chances are that the memory was already corrupted. Then working with (or in) memory that is corrupted may expose the earlier corruption by giving a buffer overrun (or error c0000005)
>
>That makes sense, especially given that I got the overrun on a test with a more complicated object hierarchy sitting in memory, but not on the same bug with a simpler one.
>
>>
>>Some thoughts - possibilities - may be worth trying
>>
>>(1) instead of (which tries to expand the string in place)
>>

>>cStackInfo = m.cStackInfo + ;
>>

>>use
>>

>>cStackInfo = '' + m.cStackInfo + ;
>>

>>
>>
>>(2) Is it possible to write the stacktrace using low level IO (fwrite) instead of appending to a variable which then gets written (list memory)
>
>My instinct is that the problem isn't related to the other code in the error handler, but to what's already in memory when I get to the error handler.
>
>This app operates on a complex hierarchy of objects involving lots of collections. There's a COM object referenced by the app object, and it points to another COM object that pokes stuff into the main object hierarchy (either directly or, more often, by calling methods of objects in that hierarchy).
>
>>
>>(3) Are you using a lot of chrtran() ?
>>This one ( http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q221617 ) was supposed to be fixed in vfp6sp3 but I remember that my trouble in message#1251395 (may have been vfp6sp5) disappeared after I replaced most of my chrtran() with sys(15) and/or strtran()
>
>Not sure I have CHRTRAN() in the app at all. Okay, looked. It's hardly used. More importantly, I don't think any of the places it's used would have been executed in my most recent tests.
>
>Tamar