digitalmars.D - SegmentationFault exception throwing, request for feedback

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

derick_eddington nospam.dot.yahoo.dot.com Mar 25 2005

"Regan Heath" <regan netwin.co.nz> Mar 26 2005

derick_eddington nospam.dot.yahoo.dot.com Mar 26 2005

John Demme <me teqdruid.com> Mar 26 2005
"Regan Heath" <regan netwin.co.nz> Mar 27 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Mar 26 2005

derick_eddington nospam.dot.yahoo.dot.org Mar 27 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Mar 28 2005

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

"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

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

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

"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

=?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

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

=?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

D Programming

C/C++ Programming

Other

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