G'day all,

I've knocked up an IDE/compiler combo for a chip I've been playing with for a while. In order to keep the GUI responsive I've farmed the chip loader and the compiler out into separate threads.

This has had a very unexpectedly pleasant side-effect of not killing the application when I dereference a null pointer in the compiler. The compiler thread crashes and the application keeps on keeping on. I only just noticed this and I think it's fab, *but* (and there is always a but).

Previously when it crashed I'd get a backtrace to the terminal. Now I don't get a backtrace if the one of the sub-threads crash.

Is there any way I can get a backtrace from a crashed thread or is it related to the RTL not knowing there is an exception and therefore not dumping it out?

Another interesting thing I observed (this app runs on OSX / Linux / Win32) is that OSX and Linux don't mind various threads dumping to stdout from anywhere, but if I leave a stray Writeln in the child code, on Win32 it locks the whole app hard. No biggie, I just remember to remove the debugging writes before I compile the Win32 version, but I thought it might save someone some headaches one day.

Brad

En/na Brad Campbell ha escrit:

It's not really fabulous: if you have a long running thread but you forget to catch any exception, it will simply die and the main application won't notice.

I don't know, but I know that delphi did the same (i.e. unhandled exceptions in a thread would silently kill it).

Bye

In my application I have a signal that each thread sends at least once a second. If the main thread sees no signal for 10 seconds it assumes the child has crashed and notifies the user. None of my threads run longer than 10 seconds anyway, but updating progress bars and captions when it was all in one thread was enough to throw out sensitive serial timing.

From my perspective it's nice to be able to notify the user that the compiler has crashed and they should save their work before restarting the application.

Brad