Bricscad v14 dropping lisp routines?
I seem to have a new problem with Bricscad v14, with lisp routines loaded from on_doc_load.lsp being dropped from memory. I have to reopen the drawing to reload my routines.
Not sure yet when/why this happens, except it happens on a regular basis. Does anyone else have this problem?
0
Comments
-
I see a problem with Bricscad V14 keeping lisp routines in memory here also. My lisp routines load properly, but after some arbitrary period of time the lisp functions will suddenly no longer be available. I can usually reload the lisp files loaded by on_doc_load, but I've found that when my list routines disappear that Bricscad will not be stable. I am also seeing stack overflow errors and "Pure virtual function call' errors that I do not recall seeing in V13. One on-line page I looked at for the pure virtual function call error says its can be caused by going indirect on a "dangling" pointer. That's a pointer to an object that's been deleted, or memory that's been freed, or both.
The errors happen here regularly, but I don't have a way to reproduce them on demand.0 -
Dear All,
please check whether you have LISPINIT=0 ... there was a bug indeed, which could result in releasing already released objects (selectionsets, COM objects).
But using LISPINIT=0 is really discouraged, better to have default LISPINIT=1.
Other reason that Lisp might disappear - if there is a crash below Lisp (in eihter Teigha database core, or BricsCAD core), while Lisp is running, then
a usual error message (about stack/system error) will happen - that is, Lisp finally catched that error, which would otherwise crash BricsCAD entirely ...
so thanks Lisp, the system is at least alive :-)
But as Martin remarked - most often the system is unstable then (due to underlying problem) ... saving + restarting seems the best after such "Lisp"
system/stack errors.
Of course, if there is any hint about a (more or less) reproducable scenario, we will be glad to investigate & fix this.
Many greetings to all !0 -
Torsten,
Thank you for the reply. LISPINIT has been set to "on" on my system for many months.
The "pure virtual function call" is the one that worries me. Based on what I've read this has to be a problem in the Teigha core or Bricscad core. I understand that not having a reproducable scenario may make this hard to find, and if it a problem in the Teigha code it may be difficult to get fixed.
Is there a way to turn on logging so that we can get more meaningful error data? The simple error messages are not particularly helpful for troubleshooting.
Best regards,
Martin0 -
Hi Martin,
perhaps try check the option under QAFLAGS to create a crash dump file (QAFLAGS = 2048)
Regards,Jason Bourhill
0 -
Dear Martin,
yes, those "pure virtual function calls" usually signals a call into deleted objects ...
For logging :
- there is "crash_report.txt" as you likely know; normally placed in OD' active directory;
you can scan all your hrad disks and delete them ... then, after next error case, search for it again, and
you fill find it; often quite helpful
Additionally, LOGFILEON and LOGFILEOFF also turn-on normal input logging; usually the log file is named after
the drawing, with .log ... like "Drawing1.log";
this is helpful to see what has been done.0 -
Of course, if there is any hint about a (more or less) reproducable scenario, we will be glad to investigate & fix this.
Many greetings to all !I can't help with a reproducable scenario either, but it should be very relevant that this problem is completely new in v14.0 -
Seems what is going on here i really quite simple - any switching between two open drawings causes lisp routines to be unloaded from memory. It does not appear related to any particular lisp routine or drawing, as two empty drawings will do the trick, and commenting out all but one lisp routine from on_doc_load still produces the error.What I am really wondering about is why there arent more complaints about this, as this should affect everyone. Is my installation corrupt perhaps?0
-
I define about 8 small lisps and load about another 8, along with a number of setvars, all in on_doc_load.
Everything works across multiple open files in v14 as well as earlier versions.
All other lisps are loaded each time I call them from pull down menus, so it wouldn't matter and I wouldn't know if they were unloaded between calls.
A long time ago I had something in the startup.lsp (on_doc's predecessor) which clashed with a basic change in the lisp rules - that caused the program to crash every time I opened a file.
0 -
Seems what is going on here i really quite simple - any switching between two open drawings causes lisp routines to be unloaded from memory. It does not appear related to any particular lisp routine or drawing, as two empty drawings will do the trick, and commenting out all but one lisp routine from on_doc_load still produces the error.What I am really wondering about is why there arent more complaints about this, as this should affect everyone. Is my installation corrupt perhaps?
i have created 2 NEW drawings and loaded 2 different lisp routines, 1 in every drawing respectively.
Every routine loads and runs in its drawing without any problems.
Switching between the 2 open drawings more times and running the lisp routines again and again works without problems as well.
No new loading of the lisp routines is necessary after switching !
So i can't reproduce the described behaviour ... everything runs as expected !
My Version 14.1.11 (x64) revision 32511
Greetings0 -
I still have problems with lisp routines being unloaded, but my schedule has been so busy that I haven't though to check the logs. I will do so next time this happens.0
-
I found the underlying cause of the problem: the SDI variable. Turning on SDI causes lisp routines to unload when switching between drawings.I have probably switched SDI on a while back to see if it does anything useful in Bricscad (it does not, quite the contrary as it turns out).0
-
I cannot verify whether the setting of SDI has any effect on dropping lisp routines or not, but it does seem that there is a problem with the documentation for SDI. In SETTINGS there is a note that SDI is read only and SDI cannot be changed. At the command line SDI can be changed to ON or OFF, and changing the setting does change the program's operation.
SDI does not appear to be quite the same in Bricscad as in Autocad, but it is valuable for some of us. For what I do running several instances of Bricscad, each with only one drawing opened, is far better than having one instance of Bricscad with multiple drawings opened in that instance. I have written a revised OPEN command that assures that the existing drawing in an existing instance of Bricscad is closed before a new drawing is opened in that Bricscad instance to get Bricscad SDI closer to Autocad SDI. If I have a vote would prefer to have the Bricscad SDI command fully match the function of SDI in legacy Autocad, but in any case SDI should not be eliminated. Some of us do depend on it.0 -
Not sure what use you have of SDI in Bricscad, when clearly it is not implemented? I have no problem opening multiple drawing windows regardless of the SDI setting. My understanding is that SDI only exists for legacy reasons, e.g. not to break lisp routines when calling missing variables.SDI was necessary in earlier versions of Autocad (perhaps still is?) for running scripts on multiple drawings in succession. I don't personally see what use a working implementation would have in current Bricscad versions.Since the variable is deprecated anyway, I think it must be a programming error that changing its setting does anything at all in Bricscad.0
-
Here's what SDI does on my computer:
- Set SDI = ON
- Go to a folder with several DWG files. Double click on several DWG files to open them. The files will open in separate instances of Bricscad.
- Set SDI = OFF
- Go to a folder with several DWG files. Double click on several DWG files to open them. The files will open as multiple documents in one instance of Bricscad.
As I said, having one document per instance of Bricscad is very important for my work process. It may not be valuable for your purposes but it is important enough for me that I would stop using Bricscad if SDI was eliminated completely. It is true that SDI is not fully implemented in Bricscad but it is easy to work around most of the differences with some lisp code.
There do seem to be several problems in the SDI implementation. Having lisp routines disappear may or may not be tied to SDI. I don't have a way to test that. I also have a problem that on some occasions the size of the command history window is not correct when a new instance of Bricscad is created and there are existing Bricscad instances. When this occurs the top of the command history window will be about mid screen (about 34 lines shown in history rather than the three lines I have Bricscad set for). I have not been able to find a sequence of operations to duplicate this on demand but I see this almost every day. Bricscad Support has not been able to duplicate this but it happens on both workstations here.0 -
I understand, I wasn't aware of that functionality. Originally, the SDI variable appeared in Autocad when it went from only SDI to MDI interface in R2000 (to allow the "old" behaviour when required). The Bricscad implementation seems to be related but not the same.0
-
I still have problems with lisp routines being unloaded, but my schedule has been so busy that I haven't though to check the logs. I will do so next time this happens.
Are you sure your lisp routines are being "unloaded", do they still function in the drawing they where originally loaded with? (not with one of the subsequently loaded drawings)
I have not experienced this behavior at all, the lisp functions do need to be loaded in each document (dwg) independently to work, as any variables (global) will not be automatically transferred from one drawing to the next.0 -
-
Dear Martin,
is it possible, that "automatic save" saved the drawing inbetween (when you checked for emails) ?
In that case, if anything goes wrong with that save operation - i.e. if you have a reactor active, acting on "save" event *and*
if there is also a custom error handler as *error* active, then there might be a clash between error handler code and save
operation ?
The special thing with automatic save is, that it uses a temporary filename, rather than the normal save filename ...
here, custom "save" reactor handler might get confused on the filename ...
I experienced such scenarios with a few other developers ... but in any case, it was always difficult to reproduce ...
I hope this helps ?
In any case, if you find something reproducable I will immediately try to reproduce and fix ....
Many Greetings !0 -
Dear Torsten,
Automatic save is turned on, but based on the files I see I do not believe that Bricscad is automatically saving unless Bricscad has focus. Autosave is set for full save and for a 10 minute interval. I do not know whether Autosave fired during the idle period yesterday. I am reasonably sure I left Bricscad at the command line, not in a command, so I do not believe an *error* error handler would have been active. The latest information that I have is that Lisp automatically resets *error* when a function exits cleanly so I have taken out all the code in my standard lisp routines which would manually reset *error*.
I am not running any reactors in my lisp code. I do run ToolPac from Dotsoft, OpenDCL, and AutoHotKey. To the best of my knowledge I had not run any functions from Toolpac or any functions that use OpenDCL in the Bricscad session yesterday. I use AutoHotKey to be able to read the arrow keys and begin/end keys for an on-screen dtext editor. I'm not sure what any of these programs do with reactors. [Perhaps this is a good time to request a vle- function that would read characters from the keyboard buffer? GRREAD does not return all keys, and there are times when it would be good to be able to read the keys that GRREAD does not return.]
What I do notice is that all of the crashes reported in crash_report.txt since I updated to V14-1-13 (x64) have been in lispex.dll. I generally see errors/crashes after several hours of using Bricscad, so I'm not sure there will be a reliable way to reproduce the crashes.
Martin0 -
Dear Martin,
thanks for explanations ...
The Lisp engine has a try/catch handler active, whenever Lisp expressions are processed / evaluated - this catch handler
fortunately also could catch any exception from underlying code (BricsCAD core, Teigha database core etc.) while Lisp
expressions are processed.
Such exceptions from outside Lisp itself are catched and signaled by "stack overflow or exception ..." error message,
indicating that Lisp engine catched such an error (otherwise, entire BricsCAD would crash).
Hence, the crash report lists "lispex.dll", as this catched the exception :-)
The software you mentioned likely uses reactors (i.e. OpenDCL), which might be connected to Lisp ...
so there are chances that automatic save could trigger such a problem.
If it is not too risky, you might try with AutoSave disabled (setting 0) to see whether the mysterious problems are gone;
you might also delete the crash_report.txt and once recreated by a crash, you might add that here, maybe it gives me some hints ...
Many greetings !0 -
Torsten,
Thank you for your help with this.
The last entry in the existing crash_report.txt was for version v14.1.11.32511 and was before the holidays. I am now running v14.1.13.32754 so that data would no longer be valid. I will erase crash_report.txt and will send the contents when something is added to it. I will also disable AutoSave and will let you know what happens.
Martin0 -
Torsten.
The latest crash_report.txt file is attached. The automatic save interval was set to 60 minutes when the entries in the report were collected. I will clear the file, set the automatic save interval to 0, and see what happens.
Martin0 -
After setting the automatic save to 0 I continue to have several entries per day added to crash_report.txt. Almost all are in the form
Unhandled Exception:
ACCESS_VIOLATION (C0000005) in module lispex.dll at 0033:0000000021xx7113
I will try turning off SDI and see if that stops the errors.0 -
Dear Martin,
the crash_report you attached indicates a problem which happens *during* Lisp file load, namely when a MenuLisp (.mnl) is loaded.
You might also have a closer look at the .mnl files loaded, maybe it gives some hints ...
many greetings !0 -
Dear Torsten,
That is quite interesting. The only .mnl files that exist on my computer that are not for old versions of Autocad are for DotSoft's Toolpak and XL2CAD. I load ToolPak by default but XK2CAD is not loaded. There is no error message at the command line when Bricscad loads this mnl file. If this was a problem with the mnl file I would expect an entry in crash_report.txt every time Bricscad is started. The mnl file is not changed, so it should error every time or never error. I have tried starting Bricscad several times, both with SDI set to ON and SDI set to OFF, and there are no entries added to crash_report.txt just by starting Bricscad. Running commands in ToolPak does not add an entry to crash_report.txt. There are error entries in crash_report.txt for earlier today but I know that I did not run any functions in ToolPak before I started testing after reading your post today.
Even if this does somehow relate to loading mnl files I don't see how a menu file can cause a memory leak. From my experience in programming (which was mostly back when we ran Microsoft DOS) having a lisp function that was working perfectly in a Bricscad session suddenly be reported as having no function definition indicates that something is writing to the wrong area of memory and corrupting that memory area. As I understand it lisp routines in Autocad and Bricscad are "sandboxed" and cannot directly access system memory.
If there is anything else I can look at to help diagnose this please let me know.
Thanks for your help.0 -
Dear Martin,
there must not be a memory leak, necessarily :-)
It could also be the case that some ARX/BRX module sporadically writes into wrong memory (i.e. Lisp's memory),
and later on, Lisp could fail.
What I see in your crash_report.txt file seems related to loading a MNL file ...
there is a sequence of
execString()
wxg::UICustomizer::loadMnlFiles()
execString()
so this looks like some code flow like this :
- some Lisp is executes
- that Lisp modifies a menu
- as result a (partial) menu is (re-)loaded
- a MNL file is loaded by that menu load
- that repeated loading of MNL then runs some code in Lisp, which finally causes an exception
It might be possible, that one of the tools modifies a menu dynamically, and as (unintended), BricsCAD or the application triggers the process ...
So the only option I see is to disable the 2 main tools, and see if the problem remains ...
I know, this likely impacts yoru workflow :-(
Many greetings !0 -
I highly recommend you try removing ToolPac/XL2CAD from your system for a couple of days (Add/Remove programs) to determine if it's a contributing factor. If you do this and the problem persists, you can rule them out.
If there is a problem with ToolPac we will work with you and Bricsys to get it resolved. However, we have several applications that install and initialize the same way and they are running on three engines with seven total configurations supporting numerous versions. We haven't heard of this before.0 -
Torsten and Terry,
I will remove ToolPac temporarily and will report back.
I have made one change recently that may be related. I had one toolbar with a flyout button which was using vla-getbitmaps and vla-setbitmaps to update the button on the parent toolbar to match the last selected button on the flyout. I have changed the OWN ICON setting for the parent so that I no longer have to manually change the icon. I do not know if this causes any menu file to reload. As I noted before there are only two .mnl files on my computer that are on Bricscad's path.
The only ARX/BRX I intentionally load is OpenDCL.
I want to be on record as an avid fan of Bricscad, ToolPac, and OpenDCL. I have recommended all three many times and will continue to do so. The support I have had for all three has been outstanding and very much appreciated.
Martin0 -
The "disappearing lisp" problem does not appear to be related to ToolPac. I upgraded a different workstation to V14 (beta). No add-ons are installed on that computer. I did notice after the fact that the autosave interval was set to 10, not 0. After about two hours work in one file we began seeing lisp functions that we had run minutes before being reported as being unknown commands. Reloading the appropriate lisp file with APPLOAD restored the command. No entry was added to crash_report.txt
I load two custom lisp files at start-up. One is 5036 lines, 132KB, and holds mostly patched versions of Express Tools. The other is 17638 lines, 790KB, and holds custom functions I have written. We saw problems with functions in both lisp files.0
This discussion has been closed.