How to debug C0000005 error? 4

[markftwain]

Hi experts,

In the click() method of a button, I essentially have:

with this.parent
if vartype(.ox)=[O]
try
do form editor.scx with .ox
catch to oerr
..............

endtry
endif
endwith

This code works well 15 to 20 times before Windows reports the fatal error C0000005 with "Microsoft visual foxpro has stopped running." If the program is cancelled and re-started, the program again works fine for another 15 to 20 times. The only information I can get is that "do form editor.scx with .ox" is causing the error. The error always occurs on exiting the editor form. The editor form is modal without anything in the unload or destroy events. "ox" is being saved and used in an editor property at initialization. "Try..Catch..Endtry" is never executed, so I can't get any futher information.

Very fustrating, ideas?

Thank you for your consideration.

 

[GriffMG]

What is on the form? Is there anything unusual on it?
Something that could be using up memory outwith the control of VFP?

Is it perhaps running something through automation?

Regards

Griff
Keep [Smile]ing

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

 

[Mike Lewis]

I would take out the WITH / ENDWITH construct.

Anything that causes an interruption in program flow while a WITH / ENDWITH is active is liable to cause a C5 error.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike has a vital point, you can easily replace it by
lo = This.parent and then write lo.ox, etc., which also keeps it short. It's recommended to use WITH ENDWITH only locally, neither return from within, nor call anything from within.

Wat you could also do is:

Local llDoCall, loParam

with This.parent
  llDoCall = (vartype(.ox)=[O])
  loParam = .ox
endwith

If llDoCall
   try
      do form editor.scx with loParam
   catch to oerr
            ..............
   endtry
Endif

Also, what is This.Parent.ox ? Is it a control? Is it a custom object? Is it created by CREATEOBJECT("EMPTY")?

Passing object references is okay in itself, but you can easily get into trouble if you release objects in a wrong way.

I'd also never pass a reference to a control to another form, especally with another private datasession. Pass on the form reference THISFORM, if the secondary form should call back, and then don't let the secondary form manipulate controls or their values, let it call back into a form method that does this. Keep the knowledge about the form structure encapsulated, otherwise you're causing interdepndencies noone can understand in a few years.

Bye, Olaf.

 

[Dan Freeman]

"ox" is being saved and used in an editor property at initialization.

Saved? How? In a property of the called form?

The editor form is modal without anything in the unload or destroy events.

Sounds like you're leaving a dangling object reference.

If that "saved" object reference is in a property of the called form, set it to .NULL. in the form's unload method.

 

[craigber]

TRY/CATCH won't be executed because C5 is not a VFP error. It's a Windows error, so VFP can't catch it.

Turn off usage of the Foxuser file via CONFIG.FPW.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[markftwain]

Clearly many issues. Is there anyway I can get the debugger to help?

The setup is this. Ox is created (as a collection) once from the first form and made public (global). No form except the one creating ox is destroying it. All forms edit different aspects of ox. All forms use the default datasession--no private datasessions are used. In my above case, the parent form saved a reference to the global ox object in its own property and then called the editor form passing its property reference to the editor form. The editor form itself is generic using textbox controls to edit information on ox.

The editor form does save a reference to Ox in its own property sheet. No automation is used.

The ox object itself is a collection object modeling the real-world physical object. The editor form is neither destroying nor creating the object, only writing to its properties. The editor form does <save> the part of ox it edits to disk and then returns control to the calling button (as above). It is after <save> and return that the C0000005 error occurs.

Thank you very much for your help. I will make the suggested changes and report back in a couple of days when I can see what happens.

Thanks

 

[Dan Freeman]

The debugger can't help you because C*5 means "EVERYTHING IS SO WHACKED I CAN'T CONTINUE". By the time the C*5 happens, there's nothing left to debug.

You mention the object "being saved to disk" which makes no sense since objects have no disk presence other than their class definitions.

If you are storing a reference in the called forms, NULL IT OUT (as I said before) before the form releases. It will not release the object, but it will decrement the instance counter and let the form release cleanly. Dangling object references like this are a known cause of C*5 errors, and typically only manifest after repeated calls (exactly as you've previously described).

 

[Olaf Doschke]

This seems to be ok on the level of the ox object. Just why make it public, if you also pass it anyway, keeping it at the parent form level as a property should be sufficient and in fact has the correct scope of existing as long, as the parent form exists.

If it's a form property, I'd pass it on via THISFORM.ox, not This.PAretn.OX or .ox in a WITH ENDWITH.

Have you tried putting the do form outside of WITH ENDWITH? Does that not help? I think that is the main culprit.

Bye, Olaf.

 

[Olaf Doschke]

The only information I can get is that "do form editor.scx with .ox" is causing the error. The error always occurs on exiting the editor form.

This is contradicting information. You get the info about the place of the error in the vfp9err.log. It's giving you the info about the current stack. The line "DO FORM" is surely on the stack, as you did not yet return from the child form, when the C5 occurs.

Could you post the vfp9err.log entry? You are perhaps misinterpreting this.

Also, like the others said c5 errors are not happing within foxpro, but within the c runtime and can both be caused by errors of the foxpro runtime or your code. If it's not corrupt foxuser.dbf, it can be due to dangling object references. The error could be in the child form and has nothing to do with the call and the ox object, but perhaps is happening in the destroy of the child form.

The vfp9err.log could show more on this and one thing you can do is SET COVERAGE TO some log file. Then the last successfully executed command would be at the end of that log. Put code in all events, if it's just something like "LOCAL lVar", then the execution of this also is logged.

From the current informations I would conclude the problem is within the editor.scx and not in the parent form, if the WITH ENDWITH is already put out of the equation.

Bye, Olaf.

 

[markftwain]

Hi,

In each form's unload method, I am setting the reference to ox to ".null.", as suggested. Does not form destruction automatically drop it's reference making this redundant?

I also removed the call from within the "with..endwith" block, but wont' be able to test this until tomorrow.

Correction, I meant, the editor "save's" the object's property values to disk. (At user discretion.)

I made "ox" public to use hotkeys, as in "ctrl+f do form..." and know of no other way to get ox to the hotkey. Suggestions are definetly welcome.

The vfp9err.log, as found under: c:\program files (x86)\Microsoft Visual Foxpro 9\vfp9err.log only gives one entry (which is strange cause this happened a dozen or so times):
"Fatal error: Exception code=C0000005 @ 02/02/2011 10:44:54 AM. Error log file: C:\program files (x86)\Microsoft visual foxpro 9\vfp9err.log"
"Do form" is nowhere to be seen.

Thanks again.

 

[Olaf Doschke]

Well, that's the vfp9err.log for your installation. If the error happens in an EXE a log of that name should be written to the EXE, perhaps also within shared files or the users profile. Search for vfp9err.log

This is how an entry can look, if the error is triggered by a line of code:

Fatal error: Exception code=C0000005 @ 08/14/2004 
18:06:46. ...vfp9err.log

Called from - ctrrkapp.readevents line 14 
{c:\naicprk4\xlib\x3fw.vct c:\naicprk4\xlib\x3fw.vct} 
Called from - ctrrkapp.readevents line 821 
{C:\NAICPRK4\xlib\x3fwmain.prg x3fwmain.fxp} 
Called from - x3fwmain line 1441 {C:\NAICPRK4 
\rkmain.prg c:\naicprk4\prk40.exe}

You see there is a stack of the involved files and procedures/functiosn/methods and the lineno they're at on the stack.

No code in fact, but the lineno of the DO FORM would be in that. I assumed you had such an error log entry as you said the error is triggered by the DO FORM:

The only information I can get is that "do form editor.scx with .ox" is causing the error.

I see you also said the error is happening within the editor form.

As you don't see such entries it's a stronger evidence towards no code involved but rather an "uncomfortable" situation like a dangling object.

Such objects cannot only bite in the moment they are released, freeing memory not belonging to the foxpro process. Anytime such an object is accessed, which actually isn't in the memory adresses referenced, can hurt.

Other very frequent reasons are a corrupt foxuser.dbf, or corrupt frx or other files. Craig already mentioned setting off usage of foxuser.dbf in CONFIG.FPW.

Or, in your case, the call from within a WITH..ENDWITH. Let's wait for the results tomorrow.

Bye, Olaf.

 

[markftwain]

Doing a c prompt search on vfp9err.log, yielded the following log at:
c:\Users\...\AppData\Local\VirtualStore\Program Files <x86>\Microsoft Visual Foxpro 9\vfp9err.log

The topmost "Called From" refrences line 9 which is the "do form..." statement.

Thanks

 

[Olaf Doschke]

Could you show more (the whole log entry)? And this log entry was from earlier or from todays test?

Bye, Olaf.

 

[Olaf Doschke]

...because the topmost called from is not where the error occurred. The topmost entry there being the do form is therefore saying the error is occurring within the editor.scx

But where and when? This is shown in the part of the log entry before the first "called from".

The called from lines can be helpful in showing how the current code position was achieved.

If the part of the log before the first "called from" is not giving a line number and file name, method/function name, then the error may occur just in the moment of getting back or anywhere the editor.scx does access some corrupt dbf or report or anything.

What you can do then is tunr on COVERAGE as I said earlier, to log all executed code lines.

Bye, Olaf.

 

[markftwain]

Hi,

After applying all the suggestions and adding "set coverage" before and after the problem area, all seems to work correctly. That is, after about 50 uses today, no c5 error occured. "set coverage" gives alot of output...but apparently no problems occured.

Perhaps of interest, I added in the main object initialization code:
* code used to debug memory leak
local atalk[1],x,k,j

strtofile(id()+[ ]+ttoc(datetime())+[is being initialized.]+chr(13)+chr(10),[c:\log.txt],1)
strtofile( space(5)+[object memory being used: ]+sys(1016)+chr(13)+chr(10),[c:\log.txt],1)

for k = 2 to astackinfo(m.atalk)-1
x=''
for j = 1 to 6
x = m.x+ [ | ]+ transform(m.atalk[m.k,m.j])
endfor
strtofile( space(5)+m.x+chr(13)+chr(10),[c:\log.txt],1)
endfor

And in the object destroy put:
* code used to debug memory leak
strtofile(id()+[ ]+ttoc(datetime())+[is being destroyed.]+chr(13)+chr(10),[c:\log.txt],1)

My goal being to cleanly see a "destroyed" before an "initialized" event on the public object. It is interesting to see how much memory the object took. Although this number was not constant, it did seem to osscilate about a central number.

Thank you

 

[Olaf Doschke]

Ok, seems like you somehow fixed the problem. The only bad thing about this is, you probably won't ever find out the real reason behind the c5 error.

In regard to memory consumtion, of course Sys(1016) does not show memory consumption of the one current (this) object, but all objects. Logging that before and after Createobject() would yield the memory consumption of the object.

Bye, Olaf.

 

[markftwain]

Hi Olaf,

Here is the complete first vfp9err.log under the installation, it has the correct date but not much info:

Fatal error: Exception code=C0000005 @ 02/06/11 02:52:44 PM. Error log file: C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9err.log

Here is the entire second vfp9err.log. It has the wrong date but some usefull informaton.

Fatal error: Exception code=C0000005 @ 11/05/2010 12:57:30 PM. Error log file: C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9err.log
Called from - frmpatientlist.cmddemo.click line 9 {c:\peewee\forms\patient list.sct c:\peewee\forms\patient list.sct}
Called from - frmpatientlist.grdpatientlisting.dblclick line 1 {c:\peewee\forms\patient list.sct c:\peewee\forms\patient list.sct}

Does not make much sense to me.

 

[Olaf Doschke]

Well,

frmpatientlist.grdpatientlisting.dblclick obviously calls frmpatientlist.cmddemo.click and that callss the editor form, as I know from you, that line 9 is the DO FORM.

The error log is still incomplete, as it does not state the object, method and line in which the c5 error happens. That's a sign the error does not happen through code at all, but eg when you return to the line 9 frmo the DO FORM and there the WITH ENDWITH has lost the (virtual) object foxpro creates for the WITH object specified and thus fails to continue and even fails to log that.

Could be anything else, too. But having applied all recommendations including to get rid of WITH ENDWITH may have solved this.

If you want to know if it was the WITH ENDWITH, you couled reintroduce it and see if c5 errors come back. It might be worth it, just to see if it's really this you need to avoid in the future. That would be the valuable lesson to leearn, wouldn't it?

If you don't check that, you don't know if it wasn't any other recommendation that worked. And that means the current problem solved, but not knowing the general rule of what to do and what to avaoid. That's the only point I'm making. If it already took that much time, I'd want to definitely know what was the reason.

Bye, Olaf.