Fatal Error 2010

[jbuzbee]

I'm getting a pretty nasty fatal error in Acad 2010 when the OpenDCL.arx is loaded.  I've painstakingly isolated it to OpenDCL.  It happens when closing a document and executing the "new" command.  At first I thought it was my command reactor but ruled that out as well.

Has anyone else seen this?

jb

[BazzaCAD]

What version of OpenDCL are you using?

[jbuzbee]

8.0.0.5

Also happened with 7.0.1.4

[owenwengerd]

I could not reproduce the problem with AutoCAD 2010 64 bit on Windows 7 64 bit. I started AutoCAD 2010, entered OPENDCL to load OpenDCL Runtime 8.0.0.5, entered QNEW and started a new drawing, entered CLOSE to close the second drawing, entered NEW to start another new drawing. All worked as expected.

[jbuzbee]

Ok, everyone knows that if I proclaim the problem is solved with the latest version the problem will return with a vengeance.   >:(

So, I'm not going to say the problem is solved - that's not what I'm saying at all.  ;)

[jbuzbee]

DAMN IT  >:( >:( >:( >:( >:(

[jbuzbee]

Could someone load the attached and see if you can repeat what I'm seeing.

1. Open AutoCAD with a single drawing opened.
2. In the VLIDE editor load the attached lisp
3. command "kbadt"
4. Close the only opened drawing . . . Fatal Error

Thanks for any help.

jb

AutoCAD Architecture 2010
OpenDCL 8.0.0.5
Windows 7 64 bit

This didn't happen on ACA 2009, Opendcl 7, WinXP

[owenwengerd]

I can reproduce it in plain AutoCAD 2010. Have you narrowed down which code causes it? I'll have a look under the debugger later today to see if I can tell from there.

[jbuzbee]

It's difficult for me to narrow done any suspect code because it worked flawlessly in 2009.  I'm not doing anything weird like reactors or accessing AEC via com.  It's pretty straight forward stuff. 
Thanks for your help Owen!

jb

[owenwengerd]

I've narrowed the problem down to your (dcl_Form_Close) call in OnEnteringNoDocState. It appears to be a bug in AutoCAD that occurs when an asynchronous event is fired while entering no-document state. Offhand I don't see any easy way to detect and prevent it in the OpenDCL code, but I'll keep looking. A workaround in the meantime would be to set your form's Event Invoke property to Synchronous so that the OnClose fires synchronously instead of asynchronously.

BTW, the code you attached creates registry keys when executed. It's not really a good idea to upload code for testing that modifies the registry or file system, as it adds more time that I have to spend cleaning the code before I can test it. In this case it wasn't too difficult, but worth mentioning in case you had not thought about it.

[owenwengerd]

For the next build, I've implemented an experimental fix for this problem. I added code to force synchronous event handling when a form is closing. This seems reasonable, since an asynchronous event handler will no longer be able to access the form (because the form will be closed before the handler executes). It does prevent this crash from occurring; hopefully it doesn't introduce any unwanted new problems.

[jbuzbee]

Thank you Owen.  I don't know what I would do without OpenDCL and obviously you.

Thank you again  8)

jb

p.s. sorry about the registry stuff

[jbuzbee]

8.0.0.6 seems to have fixed the bug - Thanks again Owen

[jbuzbee]

Well, now I have another Fatal Error: this one is, however, random.  Same palette as posted here, multiple drawings opened, upon closing a drawing - bang.

Any thoughts?

jb

[owenwengerd]

See if you can narrow it down to a specific piece of code like I did with the other crash. If you can get to where you can reproduce fairly reliably, then try Synchronous to see if that resolves it. If it does, then we'll know it's probably the same thing as before, just a different trigger.