www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - un-catched segfault exception

reply philippe quesnel <philippe.quesnel gmail.com> writes:
I have a bug that causes a segmentation fault (null object)...
but try/catch fails to catch it !! ??

even with
 catch (Exception e)
   ...
 catch (Error e)
   ...
 catch // "last catch"
   ...

I still cant catch the exception & the app crashes.

I'm on Windows (XP), with
gdc.exe (GCC) 3.4.5 (mingw special) (gdc 0.24, using dmd 1.020).

I must be missing some important point here .. this cant be the normal
behaviour !!??

any help / suggestions would be appreciated.
thank you
Philippe
Jan 09 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
philippe quesnel wrote:
 I have a bug that causes a segmentation fault (null object)...
 but try/catch fails to catch it !! ??
 
 even with
  catch (Exception e)
    ...
  catch (Error e)
    ...
  catch // "last catch"
    ...
 
 I still cant catch the exception & the app crashes.
 
 I'm on Windows (XP), with
 gdc.exe (GCC) 3.4.5 (mingw special) (gdc 0.24, using dmd 1.020).
 
 I must be missing some important point here .. this cant be the normal
behaviour !!??
 
 any help / suggestions would be appreciated.
 thank you
 Philippe
This certainly can be normal behavior -- C++ does it this way, after all. A segfault is not an exception or an error; it's a signal. You can trap the segfault with a signal handler but you can't catch it in a try/catch block. With exceptions, your program essentially contains a try/catch block around all your code that terminates your program if you didn't handle the exception. That's probably not correct, but it's close enough for my purposes at the moment. With signals, the operating system essentially registers a signal handler; when it gets signal, it determines which application is responsible. If that application has a signal handler, that handler is called; otherwise, your program is toast. What you can do, though, is convert a signal to an exception. It's going to be a lot slower than just checking a pointer to see if it's null, but if you have traced exceptions, the debugging benefit is enormous. Someone else probably has a cleaner version, but here's something that I cooked up a couple weeks back. Tested on Linux, dmd1.023-ish; not guaranteed to work for you. It might destroy your computer, kill your firstborn, raise Cthulhu from the depths, overwrite your doctoral thesis with dancing hamsters, et cetera. The whole point of this code is getting a stack trace rather than an opaque segfault message (if you're using Tango, just inherit from TracedException rather than Exception and reference Flectioned by Thomas Kuehne). It is unreasonable to use anything like this as a regular means of flow control, due to performance reasons and the hideousness of using exceptions for flow control aside from error handling. /** Public domain. Traps SIGSEGV and throws an exception, so you should get a stack trace when you segfault. */ class NullReferenceException : Exception { this (char[] msg) { super(msg); } this () { super ("tried to dereference a pointer to a nonexistent memory region"); } } const int SA_SIGINFO = 4; const int SIGSEGV = 11; extern(C) { struct sig_action { // Dunno if a function* would work here... void* action; int flags; void* restorer; } int sigaction (int signal, sig_action* action, sig_action* oact); } void segv_throw (int i) { throw new NullReferenceException(); } static this () { sig_action act; act.action = &segv_throw; act.flags = SA_SIGINFO; sigaction(SIGSEGV, &act, null); } debug (SegvTest) { void main () { uint* p = null; uint k = *p; } }
Jan 09 2008
next sibling parent reply Hxal <hxal freenode.d.channel> writes:
Christopher Wright Wrote:
 What you can do, though, is convert a signal to an exception. It's going 
 to be a lot slower than just checking a pointer to see if it's null, but 
 if you have traced exceptions, the debugging benefit is enormous. 
 Someone else probably has a cleaner version, but here's something that I 
 cooked up a couple weeks back. Tested on Linux, dmd1.023-ish; not 
 guaranteed to work for you. It might destroy your computer, kill your 
 firstborn, raise Cthulhu from the depths, overwrite your doctoral thesis 
 with dancing hamsters, et cetera.
I have played with throwing exceptions out of signal handlers and it's not going to work in a reliable way at all, on Linux at least. The compiler doesn't generate exception handling frames for blocks of code it doesn't expect to throw an exception, and it doesn't expect single instructions to do so. AFAIK this is true for both dmd and gdc. When you throw an exception and the stack unwinding procedure doesn't find an EH frame, it will abort your application. gcc has two switches to remedy this: -fnon-call-exceptions that expects exceptions to be thrown from dereferences and arithmetics; and -fasynchronous-unwind-tables that generates EH frames encompassing all instructions. Alas gdc doesn't support these. I've played with this a bit in my own stacktracing module (which you can find at http://zygfryd.net/jive/). The same disclaimer applies. PS. Throwing exceptions across C code aborts too, you can however add one of the previously mentioned flags when compiling C code.
Jan 09 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Hxal wrote:
 Christopher Wright Wrote:
 What you can do, though, is convert a signal to an exception. It's going 
 to be a lot slower than just checking a pointer to see if it's null, but 
 if you have traced exceptions, the debugging benefit is enormous. 
 Someone else probably has a cleaner version, but here's something that I 
 cooked up a couple weeks back. Tested on Linux, dmd1.023-ish; not 
 guaranteed to work for you. It might destroy your computer, kill your 
 firstborn, raise Cthulhu from the depths, overwrite your doctoral thesis 
 with dancing hamsters, et cetera.
I have played with throwing exceptions out of signal handlers and it's not going to work in a reliable way at all, on Linux at least. The compiler doesn't generate exception handling frames for blocks of code it doesn't expect to throw an exception, and it doesn't expect single instructions to do so. AFAIK this is true for both dmd and gdc. When you throw an exception and the stack unwinding procedure doesn't find an EH frame, it will abort your application. gcc has two switches to remedy this: -fnon-call-exceptions that expects exceptions to be thrown from dereferences and arithmetics; and -fasynchronous-unwind-tables that generates EH frames encompassing all instructions. Alas gdc doesn't support these. I've played with this a bit in my own stacktracing module (which you can find at http://zygfryd.net/jive/). The same disclaimer applies. PS. Throwing exceptions across C code aborts too, you can however add one of the previously mentioned flags when compiling C code.
I haven't had much need for this stuff yet -- I do mostly metaprogramming stuff -- but thanks for the link. Whenever I do applications work, I'll use your stuff.
Jan 09 2008
prev sibling next sibling parent reply BCS <BCS pathlink.com> writes:
Hxal wrote:
 
 
 I have played with throwing exceptions out of signal handlers and
 it's not going to work in a reliable way at all, on Linux at least.
 The compiler doesn't generate exception handling frames for blocks
 of code it doesn't expect to throw an exception, and it doesn't
 expect single instructions to do so.
I uses this approach and it works just fine. (DMD/Linux and IIRC DMD/Win)
 
 PS. Throwing exceptions across C code aborts too, you can however
 add one of the previously mentioned flags when compiling C code.
 
I've never seen this. OTOH I don't actually catch the exception as the only thing I actually uses the exception for is a poor man's stack trace: // add this at the top of all functions. scope(failure) writef(">>"__FILE__":"~itoa!(__LINE__)~\n);
Jan 10 2008
parent reply Hxal <hxal freenode.d.channel> writes:
BCS Wrote:

 I uses this approach and it works just fine. (DMD/Linux and IIRC DMD/Win)
My bad, I must have remembered wrong, it does indeed work fine with dmd/linux; there aren't even any calls to abort in deh2.d So the problem only applies to gdc, for which the runtime uses gcc's unwind procedure from libgcc_s.
Jan 10 2008
parent Hxal <hxal freenode.d.channel> writes:
 BCS Wrote:
 
 I uses this approach and it works just fine. (DMD/Linux and IIRC DMD/Win)
My bad, I must have remembered wrong, it does indeed work fine with dmd/linux; there aren't even any calls to abort in deh2.d
Actually, I remembered what is the problem with throwing exceptions out of signal handlers with dmd/linux. Such exceptions leak through immediate try-catch blocks. This example would print out "caught in segfault1". void segfault1 () { try { segfault2(); } catch { writefln ("caught in sefgault1"); } } void segfault2 () { try { int* a = cast(int*) 0xdeadc0de; *a = 1; } catch { writefln ("caught in sefgault2"); } }
Jan 11 2008
prev sibling next sibling parent Hxal <hxal freenode.d.channel> writes:
 PS. Throwing exceptions across C code aborts too, you can however
 add one of the previously mentioned flags when compiling C code.
Just a small correction: you need -fexceptions or -funwind-tables, -fnon-call-exceptions and -fasynchronous-unwind-tables aren't necessary unless you're throwing out of signal handlers. (Applies to gcc)
Jan 10 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Hxal Wrote:
 I've played with this a bit in my own stacktracing module
 (which you can find at http://zygfryd.net/jive/).
 The same disclaimer applies.
Your project looks interesting. I'd be especially interested in seeing some usage examples. I'll be extremely interested when the disclaimers for stacktrace are lessened. Specifically, linux-only and "doesn't work very well for either DMD or GDC". If they were gone, I'd be using this library tonight!
Jan 10 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:fm65g8$p7j$1 digitalmars.com...
 Hxal Wrote:
 I've played with this a bit in my own stacktracing module
 (which you can find at http://zygfryd.net/jive/).
 The same disclaimer applies.
Your project looks interesting. I'd be especially interested in seeing some usage examples. I'll be extremely interested when the disclaimers for stacktrace are lessened. Specifically, linux-only and "doesn't work very well for either DMD or GDC". If they were gone, I'd be using this library tonight!
Well you're obviously using Tango; Tango's had traced exceptions for a while, just get flectioned and link it in when you compile your project.
Jan 10 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Jarrett Billingsley wrote:

 "Jason House" <jason.james.house gmail.com> wrote in message
 news:fm65g8$p7j$1 digitalmars.com...
 Hxal Wrote:
 I've played with this a bit in my own stacktracing module
 (which you can find at http://zygfryd.net/jive/).
 The same disclaimer applies.
Your project looks interesting. I'd be especially interested in seeing some usage examples. I'll be extremely interested when the disclaimers for stacktrace are lessened. Specifically, linux-only and "doesn't work very well for either DMD or GDC". If they were gone, I'd be using this library tonight!
Well you're obviously using Tango; Tango's had traced exceptions for a while, just get flectioned and link it in when you compile your project.
Stupid question - what functionality will that get me? A full backtrace is only part of it. The other (bigger?) part is a way to capture seg faults reliably on all platforms. My project runs on windows, linux, mac, 32-bit, and 64-bit. I have yet to find a reliable way...
Jan 10 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Jason House wrote:
 Jarrett Billingsley wrote:
 
 "Jason House" <jason.james.house gmail.com> wrote in message
 news:fm65g8$p7j$1 digitalmars.com...
 Hxal Wrote:
 I've played with this a bit in my own stacktracing module
 (which you can find at http://zygfryd.net/jive/).
 The same disclaimer applies.
Your project looks interesting. I'd be especially interested in seeing some usage examples. I'll be extremely interested when the disclaimers for stacktrace are lessened. Specifically, linux-only and "doesn't work very well for either DMD or GDC". If they were gone, I'd be using this library tonight!
Well you're obviously using Tango; Tango's had traced exceptions for a while, just get flectioned and link it in when you compile your project.
Stupid question - what functionality will that get me? A full backtrace is only part of it. The other (bigger?) part is a way to capture seg faults reliably on all platforms. My project runs on windows, linux, mac, 32-bit, and 64-bit. I have yet to find a reliable way...
Flectioned gives segfault tracing on Linux. If a Windows-compatible way could be found, it might not be too hard to hack in.
Jan 11 2008
prev sibling next sibling parent reply BCS <BCS pathlink.com> writes:
Christopher Wright wrote:
 What you can do, though, is convert a signal to an exception. It's going 
 to be a lot slower than just checking a pointer to see if it's null, but 
 if you have traced exceptions, the debugging benefit is enormous. 
Why would this be slow? seg-v are caused by hardware. When a seg-v is noticed it triggers an interrupt and the OS goes from there. Until you get a seg-v there should be NO cost at all. Am I missing something?
Jan 10 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
BCS wrote:
 Christopher Wright wrote:
 What you can do, though, is convert a signal to an exception. It's 
 going to be a lot slower than just checking a pointer to see if it's 
 null, but if you have traced exceptions, the debugging benefit is 
 enormous. 
Why would this be slow? seg-v are caused by hardware. When a seg-v is noticed it triggers an interrupt and the OS goes from there. Until you get a seg-v there should be NO cost at all. Am I missing something?
Handling an error will be slower. Handling a lack of an error will be faster.
Jan 10 2008
parent reply BCS <BCS pathlink.com> writes:
Christopher Wright wrote:
 BCS wrote:
 
 Christopher Wright wrote:

 What you can do, though, is convert a signal to an exception. It's 
 going to be a lot slower than just checking a pointer to see if it's 
 null, but if you have traced exceptions, the debugging benefit is 
 enormous. 
Why would this be slow? seg-v are caused by hardware. When a seg-v is noticed it triggers an interrupt and the OS goes from there. Until you get a seg-v there should be NO cost at all. Am I missing something?
Handling an error will be slower. Handling a lack of an error will be faster.
"Exceptions are a slow way to handle a seg-v's after it happens" Ok that makes a difference. I missed that because 1) I generally assume that performance after an errors is not an issue and 2) in general my programs respond to a seg-v by quitting (with an uncaught exception) on the assumption that their is nothing else it can safely do. I'd be interested in which of theses assumptions is erroneous in your case and why.
Jan 11 2008
parent Christopher Wright <dhasenan gmail.com> writes:
BCS wrote:
 Christopher Wright wrote:
 BCS wrote:

 Christopher Wright wrote:

 What you can do, though, is convert a signal to an exception. It's 
 going to be a lot slower than just checking a pointer to see if it's 
 null, but if you have traced exceptions, the debugging benefit is 
 enormous. 
Why would this be slow? seg-v are caused by hardware. When a seg-v is noticed it triggers an interrupt and the OS goes from there. Until you get a seg-v there should be NO cost at all. Am I missing something?
Handling an error will be slower. Handling a lack of an error will be faster.
"Exceptions are a slow way to handle a seg-v's after it happens" Ok that makes a difference. I missed that because 1) I generally assume that performance after an errors is not an issue and 2) in general my programs respond to a seg-v by quitting (with an uncaught exception) on the assumption that their is nothing else it can safely do. I'd be interested in which of theses assumptions is erroneous in your case and why.
I was speaking about the case where you're using exceptions as flow control rather than a means of error handling. So if you're just going to catch the segfault exception, log it, and quit, fine; performance doesn't matter. If you're going to do something else if you get a segfault and it isn't an error, that will be slower. Not to mention you'd get pwned in code review.
Jan 12 2008
prev sibling parent Michiel Helvensteijn <nomail please.com> writes:
Christopher Wright wrote:

 It might destroy your computer, kill your
 firstborn, raise Cthulhu from the depths, overwrite your doctoral thesis
 with dancing hamsters, et cetera.
Hehe. :-) That is all. -- Michiel
Jan 14 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"philippe quesnel" <philippe.quesnel gmail.com> wrote in message 
news:fm3q1p$su3$1 digitalmars.com...
I have a bug that causes a segmentation fault (null object)...
 but try/catch fails to catch it !! ??

 even with
 catch (Exception e)
   ...
 catch (Error e)
   ...
 catch // "last catch"
   ...

 I still cant catch the exception & the app crashes.

 I'm on Windows (XP), with
 gdc.exe (GCC) 3.4.5 (mingw special) (gdc 0.24, using dmd 1.020).

 I must be missing some important point here .. this cant be the normal 
 behaviour !!??

 any help / suggestions would be appreciated.
 thank you
 Philippe
That's funny, cause on DMDWin you _can_ catch them.
Jan 09 2008
parent reply philippe.quesnel <philippe.quesnel gmail.com> writes:
Jarrett Billingsley Wrote:

 
 That's funny, cause on DMDWin you _can_ catch them. 
 
 
I just did a test C++ app in Windows (MsDev) .. and I do catch exceptions thrown by a null ptr reference. Which is what I was expecting to happen in D. Of course I can check for a NULL ptr ... but catching exceptions is for error handling too !! bugs happen ;-) One point I forgot to mention that might be important (??) : the D code is called by C(++) code (I'm using FLTK2 gui toolkit, calling D code on events) I'll do some tests to see if I the same thing happens under 'normal' situations... thx
Jan 10 2008
parent reply Sean Kelly <sean f4.ca> writes:
philippe.quesnel wrote:
 Jarrett Billingsley Wrote:
 
 That's funny, cause on DMDWin you _can_ catch them. 
I just did a test C++ app in Windows (MsDev) .. and I do catch exceptions thrown by a null ptr reference. Which is what I was expecting to happen in D.
Segfaults in Windows pass through the Structured Exception Handling mechanism, as do many other hardware-level errors. It's the Windows response to signals in Unix. And DMD is nice enough to turn these into D exceptions for you. It sounds like GDC does its exception handling another way however, and does not. Sean
Jan 10 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly wrote:
 philippe.quesnel wrote:
 Jarrett Billingsley Wrote:

 That's funny, cause on DMDWin you _can_ catch them.
I just did a test C++ app in Windows (MsDev) .. and I do catch exceptions thrown by a null ptr reference. Which is what I was expecting to happen in D.
Segfaults in Windows pass through the Structured Exception Handling mechanism, as do many other hardware-level errors. It's the Windows response to signals in Unix. And DMD is nice enough to turn these into D exceptions for you. It sounds like GDC does its exception handling another way however, and does not. Sean
Any way to get Flectioned tracing them?
Jan 11 2008
parent Sean Kelly <sean f4.ca> writes:
Robert Fraser wrote:
 Sean Kelly wrote:
 philippe.quesnel wrote:
 Jarrett Billingsley Wrote:

 That's funny, cause on DMDWin you _can_ catch them.
I just did a test C++ app in Windows (MsDev) .. and I do catch exceptions thrown by a null ptr reference. Which is what I was expecting to happen in D.
Segfaults in Windows pass through the Structured Exception Handling mechanism, as do many other hardware-level errors. It's the Windows response to signals in Unix. And DMD is nice enough to turn these into D exceptions for you. It sounds like GDC does its exception handling another way however, and does not.
Any way to get Flectioned tracing them?
Generating a stack trace within a signal handler would probably work, though it isn't guaranteed to. I'd say it depends on how the OS handles hardware signals. Throwing exceptions from signal handlers has the same problem. Sean
Jan 11 2008
prev sibling parent philippe.quesnel <philippe.quesnel gmail.com> writes:
ok, it seems this is a Windows vs 'Unix' difference...
actually, more like a "Windows type" compiler vs GNU / 'Unix' compiler !

a simple C++ app that tries to write to a NULL ptr :
On Windows :
 - compiled w. MsDev6 : the 'exception' is "catch"ed
 - compiled w. mingw32 C++ : seg faults
  (same w. cygwin)

So depending on the compiler, the behaviour is different.

AND .. same difference between GDC & DMD !!
(as Jarrett mentionned)
the same code (Windows again) ..
 + compiled w. gdc does not catch the 'exception', (segfault)
 + compiled w. dmd DOES catch the error

niiiice .. NOT ;-)

I'll have to look into this signal stuff .. time to read those other posts
again !
thank you
Phil
Jan 10 2008