Where to find crash_report.txt on Linux?

Roy Klein Gebbinck

I am trying to debug a Lisp program on Linux. If there is a crash where can I find crash_report.txt and other 'error' files such as log.tmp?

Torsten Moses

Dear Roy,

it should appear in "current working directory" of the BricsCAD process ... so normally, in user's home folder;
at least, I usually see the crash_report.txt there :-)

I hope this helps ?
Wish you a nice day & many greetings !

Roy Klein Gebbinck

Thank you Torsten.
It seems the crash has somehow not created a crash_report.txt. A search of the complete file system comes up empty.

Regarding 'log.tmp':
On Windows if you start BC by double-clicking a .dwg file and then cause a Lisp error, there will be a 'log.tmp' file in the folder of the .dwg file.
On Linux this does not happen. Is there a setting for this?

Mehmet Soyturk

The code that traverses the stack make use of the DbgHelp library, which is Windows specific. Therefore crash_report.txt is not generated on Linux.

You can use GDB to generate a stack trace on Linux. Look here for an example.

Torsten Moses

Dear Roy,

there are LOGFILEON and LOGFILEOFF commands / system variables ... please try this :-)

Many greetings !
and thanks to Mehmet for corrections :-)

Roy Klein Gebbinck

@Torsten Moses:

Dear Roy,

there are LOGFILEON and LOGFILEOFF commands / system variables ... please try this :-)

Many greetings !
and thanks to Mehmet for corrections :-)

Those settings refer to a different type of log file (command history).

Roy Klein Gebbinck

@ Mehmet:
Thank you. Using GDB gives me a backtrace (Segmentation fault).

Is this backtrace useful for developers? I certainly do not know how to use it...

Tijs Vermeulen

Hello Roy,

A backtrace or stack trace can be very useful.
It shows the current stack of nested function calls at the moment of the crash, from the main (entry) function of your program to the last called function.
Normally it is only useful if you have the source code, although the name of the functions alone can give an idea of the context in which the crash occurs.

Some bugs cause crashes at a later point, sometimes even in unrelated code (eg memory corruption).  In such cases a backtrace is of little or no help.

If the bug can be reproduced by a developer, a stack trace is normally no longer needed.  Indeed, a stack trace is typically asked for a bug that cannot be reproduced from its description.


Regards
Tijs