>>>I've recently added a fairly simple error handler to an existing application. The error handler, connected to ON ERROR, just collects info about the error and dumps it into a table, then gives the user some choice about what to do.
>>>
>>>In my simple testing, it works fine, but in some cases, it's causing a buffer overrun that's crashing VFP. The line where it crashes is LIST MEMORY. Here's the code up to and including a few lines after the crash:
>>>
>>>

>>>LPARAMETERS tWhen, cWhere, nLine
>>>
>>>LOCAL aErrorInfo[1]
>>>
>>>AERROR(aErrorInfo)
>>>
>>>* Log the data, including the call stack, into the
>>>* ONERROR table. Also, construct a message to the user.
>>>
>>>LOCAL cStackInfo, nStackLevels, aStackData[1], nStackLevel	
>>>
>>>cStackInfo = ""
>>>nStackLevels = ASTACKINFO(aStackData)
>>>FOR nStackLevel = 1 TO m.nStackLevels
>>>	cStackInfo = m.cStackInfo + ;
>>>	             "  Level: " + TRANSFORM(aStackData[m.nStackLevel, 1]) + CHR(13) + CHR(10) + ;
>>>	             "   File: " + aStackData[m.nStackLevel, 2] + CHR(13) + CHR(10) + ;
>>>	             "   Module/Object: " + aStackData[m.nStackLevel, 3] + CHR(13) + CHR(10) + ;
>>>	             "   Line: " + TRANSFORM(aStackData[m.nStackLevel, 5]) + ;
>>>	             ": " + aStackData[m.nStackLevel, 6] + CHR(13) + CHR(10)
>>>ENDFOR
>>>
>>>LOCAL cOldSafety, cMemFile, cStatFile
>>>cOldSafety = SET("Safety")
>>>SET SAFETY OFF 
>>>cMemFile = FORCEPATH("ListMemo.txt", SYS(2023))
>>>LIST MEMORY TO (m.cMemFile) NOCONSOLE 
>>>cStatFile = FORCEPATH("ListStatus.txt", SYS(2023))
>>>LIST STATUS TO (m.cStatFile) NOCONSOLE 
>>>SET SAFETY &cOldSafety
>>>

>>>
>>>The one twist here is that this application is working with a bunch of VFP-based COM objects. They get instantiated pretty early, and in fact, I've seen at least one case where I can put an error in after that and I don't get the buffer overrun.
>>>
>>>It appears that the difference may be whether I have READ EVENTS in effect. If I stick an error in right before or right after READ EVENTS, the error handler works as expected. If I introduce an error in code that will run with READ EVENTS in effect, I get the crash.
>>>
>>>Anybody have any suggestions? For now, of course, I'm commenting that part of the code out, so that I can test other things, but I'd really like to have the memory and status info in the error log.
>>
>>I came back to this today and found a solution. It turns out that the problem goes away if I remove NOCONSOLE from the command. Since my app is running in a top-level window, I came up with a solution that makes the main VFP window "visible" off-screen, allowing the listing to scroll in it, and then hides it again.
>>
>
>Unfortunately, while the solution worked inside the app in a simple test, I'm getting the same buffer overrun when an error occurs farther in. I haven't yet been able to come up with a simple repro case.
>
>If anybody's faced this one, either successfully or not, I'd love to hear about it. Maybe comparing notes about what's going on would help.
>
>Tamar

Tamar,

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)

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)

(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()