>>>>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
>
>I have a fairly robust error handler for VFP that I built/updated over about a decade.
>
>IIRC I set print to a file and then list memory and most everything else to the file. Then I roll the file into a memo variable (in the VFP version) or into a varchar(MAX) field in the SQL version.
>
>I can't access my VFP development machine from here (client site) or I'd send you the PRG.
>
>If you still need it this evening I can send you what I have.

The problem is just in this specific app and only after I get a certain amount into the app. In fact, I was just able to make the code (not quite what's above, but a modified version eliminating NOCONSOLE) work when a particular bug occurs with one data set, but got the buffer overrun on the exact same error with a different data set.

Tamar