www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SegmentationFault exception throwing, request for feedback - segfault.d

reply derick_eddington nospam.dot.yahoo.dot.com writes:
I've made a Linux SIGSEGV signal handler which throws a SegmentationFault which
can be caught and used to get info about the segfault.  (The signal handler is
called on the stack which is why the throw works.)  I'm wondering about the
implications of this and how useful it could be.  I've attached it.

Since Linux dmd doesn't support -g yet I've been using it to help squash
segfaults.  SegmentationFault tells the type of segfault and the offending
address, and try-catching for it helps me narrow down where the segfault is
happening.

I'm hoping people more knowledgeable can tell me if there are bugs with my
implementation and reasons doing this might not be a good idea.
Mar 25 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 26 Mar 2005 07:15:56 +0000 (UTC),  
<derick_eddington nospam.dot.yahoo.dot.com> wrote:
 I've made a Linux SIGSEGV signal handler which throws a  
 SegmentationFault which
 can be caught and used to get info about the segfault.  (The signal  
 handler is
 called on the stack which is why the throw works.)  I'm wondering about  
 the
 implications of this and how useful it could be.  I've attached it.

 Since Linux dmd doesn't support -g yet I've been using it to help squash
 segfaults.  SegmentationFault tells the type of segfault and the  
 offending
 address, and try-catching for it helps me narrow down where the segfault  
 is
 happening.

 I'm hoping people more knowledgeable can tell me if there are bugs with  
 my
 implementation and reasons doing this might not be a good idea.

You can catch segmentation faults using catch(Object) eg. void main() { try { (cast(Object)cast(void*)0x321).print(); } catch (Object o) { } } Regan
Mar 26 2005
parent reply derick_eddington nospam.dot.yahoo.dot.com writes:
In article <opsn8tr6pw23k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Sat, 26 Mar 2005 07:15:56 +0000 (UTC),  
<derick_eddington nospam.dot.yahoo.dot.com> wrote:
 I've made a Linux SIGSEGV signal handler which throws a  
 SegmentationFault which
 can be caught and used to get info about the segfault.  (The signal  
 handler is
 called on the stack which is why the throw works.)  I'm wondering about  
 the
 implications of this and how useful it could be.  I've attached it.

 Since Linux dmd doesn't support -g yet I've been using it to help squash
 segfaults.  SegmentationFault tells the type of segfault and the  
 offending
 address, and try-catching for it helps me narrow down where the segfault  
 is
 happening.

 I'm hoping people more knowledgeable can tell me if there are bugs with  
 my
 implementation and reasons doing this might not be a good idea.

You can catch segmentation faults using catch(Object) eg. void main() { try { (cast(Object)cast(void*)0x321).print(); } catch (Object o) { } } Regan

Doesn't work for me on Linux. It results in the default process death. Does it really work for you? How does this work?
Mar 26 2005
next sibling parent John Demme <me teqdruid.com> writes:
derick_eddington nospam.dot.yahoo.dot.com wrote:
 In article <opsn8tr6pw23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 
On Sat, 26 Mar 2005 07:15:56 +0000 (UTC),  
<derick_eddington nospam.dot.yahoo.dot.com> wrote:

I've made a Linux SIGSEGV signal handler which throws a  
SegmentationFault which
can be caught and used to get info about the segfault.  (The signal  
handler is
called on the stack which is why the throw works.)  I'm wondering about  
the
implications of this and how useful it could be.  I've attached it.

Since Linux dmd doesn't support -g yet I've been using it to help squash
segfaults.  SegmentationFault tells the type of segfault and the  
offending
address, and try-catching for it helps me narrow down where the segfault  
is
happening.

I'm hoping people more knowledgeable can tell me if there are bugs with  
my
implementation and reasons doing this might not be a good idea.

You can catch segmentation faults using catch(Object) eg. void main() { try { (cast(Object)cast(void*)0x321).print(); } catch (Object o) { } } Regan

Doesn't work for me on Linux. It results in the default process death. Does it really work for you? How does this work?

I recall something like this working on Linux if you recompile phobos with the -debug and/or -g switches, and without -release. John Demme
Mar 26 2005
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 26 Mar 2005 23:08:18 +0000 (UTC),  
<derick_eddington nospam.dot.yahoo.dot.com> wrote:
 In article <opsn8tr6pw23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 On Sat, 26 Mar 2005 07:15:56 +0000 (UTC),
 <derick_eddington nospam.dot.yahoo.dot.com> wrote:
 I've made a Linux SIGSEGV signal handler which throws a
 SegmentationFault which
 can be caught and used to get info about the segfault.  (The signal
 handler is
 called on the stack which is why the throw works.)  I'm wondering about
 the
 implications of this and how useful it could be.  I've attached it.

 Since Linux dmd doesn't support -g yet I've been using it to help  
 squash
 segfaults.  SegmentationFault tells the type of segfault and the
 offending
 address, and try-catching for it helps me narrow down where the  
 segfault
 is
 happening.

 I'm hoping people more knowledgeable can tell me if there are bugs with
 my
 implementation and reasons doing this might not be a good idea.

You can catch segmentation faults using catch(Object) eg. void main() { try { (cast(Object)cast(void*)0x321).print(); } catch (Object o) { } } Regan

Doesn't work for me on Linux. It results in the default process death.

Sorry. I realised you were on linux some time after posting this .. i.e when I woke in the middle of the night. IIRC Walter has yet to implement this for Linux, tho it appears John disagrees.. I don't really know I only use D on Windows.
 Does it
 really work for you?  How does this work?

Yes. Walter "magic" makes it work. Regan
Mar 27 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
derick_eddington wrote:

 I've made a Linux SIGSEGV signal handler which throws a SegmentationFault which
 can be caught and used to get info about the segfault.  (The signal handler is
 called on the stack which is why the throw works.)  I'm wondering about the
 implications of this and how useful it could be.  I've attached it.

There is a similar implementation already, in DMD for Windows I believe? Walter seemed to think it was a good idea at the time: (Jan 15, 2005)
 Ok, I see the problem. Under windows, access violations are trapped and
 converted into D exceptions. This isn't done under linux, though it should
 be. 

My simple suggestion was that this runtime exception should be defined as a standard class in Phobos, and be consistant over platforms... Having a special class called SegmentationFault for Linux, or just a Exception with a special message like I believe Windows uses is no good. The error itself is called: - Segmentation Fault (Linux) - Access Violation (Windows) - Bus Error (Mac OS X) Better to name it abstractly ? My suggestion was to call it NullPointerError, or simpler NullError. (this is a little biased towards Java, of course, but consistant...) --anders
Mar 26 2005
parent reply derick_eddington nospam.dot.yahoo.dot.org writes:
In article <d24ter$p7u$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
derick_eddington wrote:

 I've made a Linux SIGSEGV signal handler which throws a SegmentationFault which
 can be caught and used to get info about the segfault.  (The signal handler is
 called on the stack which is why the throw works.)  I'm wondering about the
 implications of this and how useful it could be.  I've attached it.

There is a similar implementation already, in DMD for Windows I believe? Walter seemed to think it was a good idea at the time: (Jan 15, 2005)
 Ok, I see the problem. Under windows, access violations are trapped and
 converted into D exceptions. This isn't done under linux, though it should
 be. 

My simple suggestion was that this runtime exception should be defined as a standard class in Phobos, and be consistant over platforms... Having a special class called SegmentationFault for Linux, or just a Exception with a special message like I believe Windows uses is no good. The error itself is called: - Segmentation Fault (Linux) - Access Violation (Windows) - Bus Error (Mac OS X) Better to name it abstractly ? My suggestion was to call it NullPointerError, or simpler NullError. (this is a little biased towards Java, of course, but consistant...) --anders

Not all segmentation faults on Linux are caused by trying to use null/0 address; it could be 0x1234 which isn't null. Also, SIGSEGV signals are also delivered if use of an address is attempted which violates the permissions of the segment, i.e. a page is non-executable and you try to call an address in it. The SIGSEGV handler can check which type it is and the offending address and could throw NullError if the address is 0, UnmappedAddressError(?) if non-0 but not a permission violation, and AddressPermissionError(?). From my segfault.d it seems there is the difference that with Windows you can try-catch the statement that causes it but with Linux the closest you can catch it is the call-statement of the function it is in.
Mar 27 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
derick_eddington wrote:

My suggestion was to call it NullPointerError, or simpler NullError.
(this is a little biased towards Java, of course, but consistant...)

Not all segmentation faults on Linux are caused by trying to use null/0 address; it could be 0x1234 which isn't null. Also, SIGSEGV signals are also delivered if use of an address is attempted which violates the permissions of the segment, i.e. a page is non-executable and you try to call an address in it. The SIGSEGV handler can check which type it is and the offending address and could throw NullError if the address is 0, UnmappedAddressError(?) if non-0 but not a permission violation, and AddressPermissionError(?).

Good point, I was only thinking of the *null "error" for now... (I'm not 100% sure just what causes Access Violations on Windows) Anyway, the point was that if it was going to throw exceptions at run-time, there should be classes for those in Phobos. And probably a "handler" too, like there is for assert/outofmemory ? i.e. the segfault handler checks the "type" of segmentation fault, and if the address is null it calls an extern(C) function in Phobos that creates and throws a NullError. Like _d_assert/_d_OutOfMemory... I'm not sure if getting this error increases or decreases the chance of finding the line of code that caused it, though ? At least with GDB you have a decent chance of getting a file/line (not every, with DMD) Of course, the Error is still nicer than the default segfault without debugger on (another related thread is regarding how to avoid causing those nulls to be dereferenced in the first place, as it happens even in e.g. Java) --anders
Mar 28 2005