www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How can I get a backtrace on segfault?

reply Tobias Pankrath <tobias pankrath.net> writes:
struct Foo 
{
	int bar_;
	 property
	int bar() { return bar; }
}

Foo myFoo;
myFoo.bar; // (1)

The program will segfault at (1). I would have spot the error
much faster, if I've got a decent backtrace, instead of
"segmentation fault".

How can I get one? I've found the backtrace handler in
object_.d, but I don't know how to make it work.
Sep 14 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, September 14, 2011 10:07:54 Tobias Pankrath wrote:
 struct Foo
 {
 	int bar_;
 	 property
 	int bar() { return bar; }
 }
 
 Foo myFoo;
 myFoo.bar; // (1)
 
 The program will segfault at (1). I would have spot the error
 much faster, if I've got a decent backtrace, instead of
 "segmentation fault".
 
 How can I get one? I've found the backtrace handler in
 object_.d, but I don't know how to make it work.
What OS are you on? On 32-bit Linux, it should just work. On 64-bit Linux, there's a bug which makes it so that you don't get one. If you're on Windows (which I'm guessing that you're not since you're talking about segfaults rather than access violations), then I believe that it should just work, but there might be something that you have to do to get it to work (I don't use Windows much, so I'm not sure). - Jonathan M Davis
Sep 14 2011
parent reply Tobias Pankrath <tobias pankrath.net> writes:
 
 What OS are you on? On 32-bit Linux, it should just work. On 64-bit 
Linux,
 there's a bug which makes it so that you don't get one. If you're on
 Windows (which I'm guessing that you're not since you're talking about
 segfaults rather than access violations), then I believe that it should
 just work, but there might be something that you have to do to get it 
to
 work (I don't use Windows much, so I'm not sure).
 
 - Jonathan M Davis
64 bit linux :-(. Thank you for your fast response.
Sep 14 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, September 14, 2011 10:38:38 Tobias Pankrath wrote:
 What OS are you on? On 32-bit Linux, it should just work. On 64-bit
Linux,
 there's a bug which makes it so that you don't get one. If you're on
 Windows (which I'm guessing that you're not since you're talking about
 segfaults rather than access violations), then I believe that it should
 just work, but there might be something that you have to do to get it
to
 work (I don't use Windows much, so I'm not sure).
 
 - Jonathan M Davis
64 bit linux :-(. Thank you for your fast response.
Actually. wait. I wasn't thinking right. You never get a backtrace from a segfault. There _is_ a bug on 64-bit Linux which makes it so that backtraces don't work, but you don't get a stacktrace from a segfault regardless. The way to handle that is to get a core dump and use gdb on it. However, unfortunately, 64-bit programs generated by dmd don't seem to be work with gdb (though 32-bit programs will). It's a result of the fact that 64-bit support for dmd is pretty new. Still, they're annoying bugs. In any case, the best way to handle your problem would probably be to compile your program as 32-bit, run it with core dumps enabled, and use gdb on it. That should show you where the problem is unless the segfault is 64-bit specific for some reason. - Jonathan M Davis
Sep 14 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 14-09-2011 11:47, Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 10:38:38 Tobias Pankrath wrote:
 What OS are you on? On 32-bit Linux, it should just work. On 64-bit
Linux,
 there's a bug which makes it so that you don't get one. If you're on
 Windows (which I'm guessing that you're not since you're talking about
 segfaults rather than access violations), then I believe that it should
 just work, but there might be something that you have to do to get it
to
 work (I don't use Windows much, so I'm not sure).

 - Jonathan M Davis
64 bit linux :-(. Thank you for your fast response.
Actually. wait. I wasn't thinking right. You never get a backtrace from a segfault. There _is_ a bug on 64-bit Linux which makes it so that backtraces don't work, but you don't get a stacktrace from a segfault regardless. The way to handle that is to get a core dump and use gdb on it. However, unfortunately, 64-bit programs generated by dmd don't seem to be work with gdb (though 32-bit programs will). It's a result of the fact that 64-bit support for dmd is pretty new. Still, they're annoying bugs. In any case, the best way to handle your problem would probably be to compile your program as 32-bit, run it with core dumps enabled, and use gdb on it. That should show you where the problem is unless the segfault is 64-bit specific for some reason. - Jonathan M Davis
As an aside, I still think DMD needs an option to insert null checks everywhere, at least for debugging... - Alex
Sep 14 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Alex R. Petersen:

 As an aside, I still think DMD needs an option to insert null checks 
 everywhere, at least for debugging...
Maybe if 200 people nag Walter about it in the main D newsgroup he will change his mind... Bye, bearophile
Sep 14 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, September 14, 2011 11:55:48 Alex R=C3=B8nne Petersen wrot=
e:
 As an aside, I still think DMD needs an option to insert null checks
 everywhere, at least for debugging...
That would fix only a portion of segfaults, so as far as the general se= gfaults=20 go, that's not a complete solution. Regardless of that however, Walter = is=20 dead-set against adding null checks, because his take on it is that the= OS=20 does them already (hence the segfault) and that you can always get the=20= backtrace (along with other useful information) by using a debugger, so= he's=20 not going to add null checks. Now, I do agree that it would be nice to have them for debugging purpos= es, but=20 it's just not going to happen. Walter is too opinionated on the issue. The way to get stacktraces for all segfaults is to add a handler for SI= GSEV=20 which prints a backtrace. And arguably, it's a better solution than doi= ng null=20 checks anyway, because it gives you a stacktrace without the extra over= head of=20 doing the null checks. It is an OS-specific solution though. - Jonathan M Davis
Sep 14 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 14 Sep 2011 05:55:48 -0400, Alex R=C3=B8nne Petersen  =

<xtzgzorex gmail.com> wrote:

 On 14-09-2011 11:47, Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 10:38:38 Tobias Pankrath wrote:
 What OS are you on? On 32-bit Linux, it should just work. On 64-bit=
 Linux,

 there's a bug which makes it so that you don't get one. If you're o=
n
 Windows (which I'm guessing that you're not since you're talking ab=
out
 segfaults rather than access violations), then I believe that it  =
 should
 just work, but there might be something that you have to do to get =
it
 to

 work (I don't use Windows much, so I'm not sure).

 - Jonathan M Davis
64 bit linux :-(. Thank you for your fast response.
Actually. wait. I wasn't thinking right. You never get a backtrace fr=
om =
 a
 segfault. There _is_ a bug on 64-bit Linux which makes it so that  =
 backtraces
 don't work, but you don't get a stacktrace from a segfault regardless=
. =
 The way
 to handle that is to get a core dump and use gdb on it. However,
 unfortunately, 64-bit programs generated by dmd don't seem to be work=
=
 with gdb
 (though 32-bit programs will). It's a result of the fact that 64-bit =
=
 support
 for dmd is pretty new. Still, they're annoying bugs.

 In any case, the best way to handle your problem would probably be to=
=
 compile
 your program as 32-bit, run it with core dumps enabled, and use gdb o=
n =
 it.
 That should show you where the problem is unless the segfault is 64-b=
it
 specific for some reason.

 - Jonathan M Davis
As an aside, I still think DMD needs an option to insert null checks =
 everywhere, at least for debugging...
That would not fix this problem (stack overflow). I hazard to guess that stack overflow likely would not produce a helpful= = stack trace either, but maybe I'm wrong. In any case, have you tried this? Works on unixen only. import core.stdc.signal; extern(C) void handleSegv(int) { assert(0); } void main() { signal(SIGSEGV, &handleSegv); ... } Not sure if it prints a stack trace on a stack overflow, however. -Steve
Sep 14 2011
parent Jonathan Levi <catanscout gmail.com> writes:
On Wednesday, 14 September 2011 at 12:16:02 UTC, Steven 
Schveighoffer wrote:
 In any case, have you tried this? Works on unixen only.

 import core.stdc.signal;

 extern(C) void handleSegv(int) { assert(0); }

 void main()
 {
    signal(SIGSEGV, &handleSegv);
    ...
 }

 Not sure if it prints a stack trace on a stack overflow, 
 however.

 -Steve
Update for anyone reading this old thread: You need to add `nothrow nogc system` to `handleSegv`. ``` import core.stdc.signal; nothrow nogc system extern(C) void handleSegv(int) { assert(0); } shared static this() { signal(SIGSEGV, &handleSegv); } ``` This answer worked great for me.
Dec 11 2020
prev sibling parent Tobias Pankrath <tobias pankrath.net> writes:
 
 Actually. wait. I wasn't thinking right. You never get a backtrace from 
a
 segfault. There _is_ a bug on 64-bit Linux which makes it so that
 backtraces don't work, but you don't get a stacktrace from a segfault
 regardless. The way to handle that is to get a core dump and use gdb on
 it. 
Works fine for me so far. Thank you.
Sep 14 2011