If I have a program like:

import std.stdio;
void main()
{
    try
    {
         char* p = cast(char*) 1234;
         *p = '?';
    }
    catch (Exception x)     // same story with Exception or Error
    {
        writefln("Caught Exception");
    }
}

If I build and run in in Linux, with either DMD 1.055 or the current GDC, the program quits with a Segmentation fault message. Under Windows (and I am running an old D2 there), it says:

object.Error: Access Violation

Which looks like a message from D. If I write a D Linux program that just throws an exception, then it says:

Error: My exception message

Which is clearly a message from D.

So it seems there is a safety net in Windows, but not in Linux. Is this how it is supposed to be?

Steve Teale wrote:
> ...
> 
> So it seems there is a safety net in Windows, but not in Linux. Is this how it is supposed to be?

Under Windows, access violations cause the OS to throw an exception. Since D uses the same EH mechanism as the OS, this integrates nicely.

Under linux, SIGSEGV is a signal, and you can't safely throw exceptions from signal handlers, so D just aborts.

As far as I understand it, it's a limitation of the way linux is designed.

On Tue, Jan 26, 2010 at 11:07:11AM -0500, Steve Teale wrote:
> So it seems there is a safety net in Windows, but not in Linux. Is this how it is supposed to be?

Yes - it has to do with the difference in how the two operating systems alert the program about hardware signaled errors.


-- 
Adam D. Ruppe
http://arsdnet.net

Daniel Keep Wrote:

> 
> 
> Steve Teale wrote:
> > ...
> > 
> > So it seems there is a safety net in Windows, but not in Linux. Is this how it is supposed to be?
> 
> Under Windows, access violations cause the OS to throw an exception. Since D uses the same EH mechanism as the OS, this integrates nicely.
> 
> Under linux, SIGSEGV is a signal, and you can't safely throw exceptions from signal handlers, so D just aborts.
> 
> As far as I understand it, it's a limitation of the way linux is designed.

Thanks Daniel, now I've had time to get something to eat and a couple of beers, that makes complete sense.

So basically, under Linux, there's not much your program can do to protect itself against errors in library code, right?

I hate signals, particularly when doing multi-threaded stuff.

Steve Teale wrote:
> Daniel Keep Wrote:
> 
>>
>> Steve Teale wrote:
>>> ...
>>>
>>> So it seems there is a safety net in Windows, but not in Linux. Is this how it is supposed to be?
>> Under Windows, access violations cause the OS to throw an exception.
>> Since D uses the same EH mechanism as the OS, this integrates nicely.
>>
>> Under linux, SIGSEGV is a signal, and you can't safely throw exceptions
>> from signal handlers, so D just aborts.
>>
>> As far as I understand it, it's a limitation of the way linux is designed.
> 
> Thanks Daniel, now I've had time to get something to eat and a couple of beers, that makes complete sense.
> 
> So basically, under Linux, there's not much your program can do to protect itself against errors in library code, right?

Well, you can intercept signals, but it requires you to get down and dirty with some C-style programming:

  http://agenda.ictp.trieste.it/agenda_links/smr1335/rt2001/node8.html

The relevant modules are:
  D1:  std.c.linux.linux
  D2:  core.sys.posix.signal

-Lars

"Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message news:hjn49d$2kfe$1@digitalmars.com...
>
>
> Under linux, SIGSEGV is a signal, and you can't safely throw exceptions from signal handlers, so D just aborts.
>

Just out of curiosity, is that a limitation that comes from the basic concept of signals, or just a detail of how the OS just happens to do signals?

On Tue, 26 Jan 2010 15:07:50 -0500, Nick Sabalausky <a@a.a> wrote:

> "Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message
> news:hjn49d$2kfe$1@digitalmars.com...
>>
>>
>> Under linux, SIGSEGV is a signal, and you can't safely throw exceptions
>> from signal handlers, so D just aborts.
>>
>
> Just out of curiosity, is that a limitation that comes from the basic
> concept of signals, or just a detail of how the OS just happens to do
> signals?

I think it's because a signal handler is entered at any point in the call stack.  This means that to unwind the stack, you need to unwind possibly C functions and (I think) even system calls.  The safest thing to do in a signal handler is to set a flag indicating a signal was recieved, and then asynchronously process it.

Given that you could be in C or C++ land where exceptions either don't exist or are different, you face a very difficult task to unwind the stack correctly.

-Steve

Steven Schveighoffer wrote:
> On Tue, 26 Jan 2010 15:07:50 -0500, Nick Sabalausky <a@a.a> wrote:
> 
>> "Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message
>> news:hjn49d$2kfe$1@digitalmars.com...
>>>
>>>
>>> Under linux, SIGSEGV is a signal, and you can't safely throw exceptions
>>> from signal handlers, so D just aborts.
>>>
>>
>> Just out of curiosity, is that a limitation that comes from the basic
>> concept of signals, or just a detail of how the OS just happens to do
>> signals?
> 
> I think it's because a signal handler is entered at any point in the call stack.  This means that to unwind the stack, you need to unwind possibly C functions and (I think) even system calls.  The safest thing to do in a signal handler is to set a flag indicating a signal was recieved, and then asynchronously process it.
> 
> Given that you could be in C or C++ land where exceptions either don't exist or are different, you face a very difficult task to unwind the stack correctly.
> 
> -Steve

Yah it's the asynchrony of signals. Exceptions are synchronous, which makes them a great deal simpler than they otherwise could.

Andrei

Hello Daniel,

> 
> Under linux, SIGSEGV is a signal, and you can't safely throw
> exceptions from signal handlers, so D just aborts.
> 

While you can't *safely* throw, you can often (but not always) get away with it, and in many cases trying to will result in nothing worse than just letting things crash.

--

<IXOYE><