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.

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

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?

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

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

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

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.

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