• Steve Teale <steve.teale britseyeview.com> Jan 26 2010
• Daniel Keep <daniel.keep.lists gmail.com> Jan 26 2010
• Steve Teale <steve.teale britseyeview.com> Jan 26 2010
• "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> Jan 26 2010
• "Nick Sabalausky" <a a.a> Jan 26 2010
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jan 26 2010
• "Steven Schveighoffer" <schveiguy yahoo.com> Jan 26 2010
• BCS <none anon.com> Jan 26 2010
• "Adam D. Ruppe" <destructionator gmail.com> Jan 26 2010

Steve Teale <steve.teale britseyeview.com> writes:

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?

Daniel Keep <daniel.keep.lists gmail.com> writes:

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.

Steve Teale <steve.teale britseyeview.com> writes:

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.

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

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?


 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

"Nick Sabalausky" <a a.a> writes:

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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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

BCS <none anon.com> writes:

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

"Adam D. Ruppe" <destructionator gmail.com> writes:

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