C5 error happening at line READ EVENTS 2

[Olaf Doschke]

The call stack is very concrete on this. I have a READ EVENTS at the line on the top of the call stack written in VFP9Err.log
So actually it can't be anything Foxpro, which causes this C5.

I have more info on this, but would like to hear your suspicions about this. Perhaps you have ideas about other vectors to attack or to look at than I think about.
What could be a reason?
The usual suspects like adressing an object with dangling references (zombie object), dbf or vcx corruptions of foxuser.dbf for example, are out of discussion.

Bye, Olaf.

 

[DSummZZZ]

I can think of a couple items that could be causing some grief beyond the usual VFP suspects. Things such as flaky or sporadic network communications, bad I/O states for comm ports, third party OCXs, insufficient permissions, bad drivers, ...
Care to elaborate?


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[GriffMG]

C5 errors are usually external things - automation errors or stuff like that aren't they?

Must be a component that isn't happy - use TaskMgr to see if any processes are running that
weren't before the READ EVENTS?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

Very good, thank you. That already has some ideas I didn't thought of because of focusing on my suspect.


I know the form uses an ActiveX control DLL (Exontrol Exgrid), it is a bit old now, Version 4 something (current version is 10 something). Anyway it worked flawless until recent recompilation, I am still a bit focused on that, but not as narrow anymore. It could be some event firing in it, while READ EVENTS still waits for some foxpro control/form/class event.

I think one client workstation might have a wrong version of the controls DLL, but you get me to thinking about process monitoring. Or VFP specific also COVERAGE logging. There is no process I start, but I might observe my own EXE and that ActiveX DLL file to see something going on right before the C5.

By now I could cause the slightly more gracious exiting of the application with "... has stopped working" myself. Not exactly that C5, but I think it has the same reason.

I have another indicator of something odd in an event logging file, there is one "reference array" class causing grief lately. I see an ADEL on an array of references failing. This unspecific class uses an array to manage form references in this case (any references in the general case). For the form handling I would rather redo that with a collection nowadays, maybe that reimplementation will actually be the solution, because a) some reference might be a dangling form object reference left over in such an array element and it deletion causes the C5 exception at garbage collection and b) that can't happen withh a collection, which self adjusts the references it contains. If a collection item is removed, this can release a form, if it's the last reference and a form releasing removes the collection item automatically.

Bye, Olaf.