Walter,

I am aware of that ability, but the missing link for me is that I don't know how to unwind the stack from the signal handler.

In other words, consider a case where I am eight function calls deep into the program, and a problem occurs.  I want to send a 500 error message to the client.  To do this, I need to get back to the main function, so I can return to Apache and Apache can be happy.  I don't know how to do this other than by an exception.

I suppose... I could throw an exception in the signal handler.  This thought does not seem like one that might be completely assured to work, however.  Would it?

Thanks again,
-[Unknown]


> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:ds9e1j$1dpu$1@digitaldaemon.com...
>> However, I do believe you have significantly more experience than I do as it comes to compilers and programming.  What should I do, excepting "never dereference null pointers" (which I already mean to do, I want a backup plan.)
> 
> Under Linux, you can set up a signal handler to intercept the seg faults, and use it to shut down your plug in gracefully. 
> 
> 

Unknown W. Brackets wrote:
> Walter,
> 
> I am aware of that ability, but the missing link for me is that I don't know how to unwind the stack from the signal handler.
> 
> In other words, consider a case where I am eight function calls deep into the program, and a problem occurs.  I want to send a 500 error message to the client.  To do this, I need to get back to the main function, so I can return to Apache and Apache can be happy.  I don't know how to do this other than by an exception.
> 
> I suppose... I could throw an exception in the signal handler.  This thought does not seem like one that might be completely assured to work, however.  Would it?

I don't think this is legal.  Signal handlers have fairly tight restrictions on what's allowed.  The pragmatic approach might simply be to use a proxy program that in turn calls the main program.  If that program aborts or fails to return the correct data then the proxy program can report a "500" error to the client and restart the target app if appropriate.  Since the code in such proxy apps is exceedingly simple, the chance of it crashing is pretty much nil.  I consider this almost a required technique for 100% uptime services.


Sean

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dsadrj$2ac0$1@digitaldaemon.com...
> I am aware of that ability, but the missing link for me is that I don't know how to unwind the stack from the signal handler.
>
> In other words, consider a case where I am eight function calls deep into the program, and a problem occurs.  I want to send a 500 error message to the client.  To do this, I need to get back to the main function, so I can return to Apache and Apache can be happy.  I don't know how to do this other than by an exception.
>
> I suppose... I could throw an exception in the signal handler.  This thought does not seem like one that might be completely assured to work, however.  Would it?

I am less familiar with how signals work on Linux than I ought to be. It should work - as long as the signal is on the same thread.

Derek Parnell wrote:
> 
> So with the current D, one does get null pointer dereference checking; its
> just that it looks like an access violation instead. So maybe we can plead,
> cajole, whatever to make Walter give us a more meaningful message when an
> access violation is the result of a NULL pointer (file name and line number
> would be a bloody big help too).
> 
If this should be made, and I too agree it should, it should work in the form of throwing an exception, as was also was noted.

Implementing this (throwing an exception) should be simple enough, just modify some code in the access violation handler.
But showing the line number on a violation I'm not sure it's that easy. The exception handler would have to have some very complicated debugger-like code, no? These are all suppositions as I'm not very knowledgeable in this, so explain to me, if I'm wrong.

I wonder how that other fellow (shinichiro) implemented the stack trace. Does it show only the called functions, or line nunmbers too, à la Java?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Bruno Medeiros wrote:
> Derek Parnell wrote:
> 
>>
>> So with the current D, one does get null pointer dereference checking; its
>> just that it looks like an access violation instead. So maybe we can plead,
>> cajole, whatever to make Walter give us a more meaningful message when an
>> access violation is the result of a NULL pointer (file name and line number
>> would be a bloody big help too).
>>
> If this should be made, and I too agree it should, it should work in the form of throwing an exception, as was also was noted.
> 
> Implementing this (throwing an exception) should be simple enough, just modify some code in the access violation handler.
> But showing the line number on a violation I'm not sure it's that easy. The exception handler would have to have some very complicated debugger-like code, no? These are all suppositions as I'm not very knowledgeable in this, so explain to me, if I'm wrong.
> 
> I wonder how that other fellow (shinichiro) implemented the stack trace. Does it show only the called functions, or line nunmbers too, à la Java?
> 

Has anyone bothered to look at the code in deh.c in phobos?  It's all right there.  Bruno is correct - the Access Violation is a D exception that was translated from a Windows SEH.  In order for the Windows SEH to know about D source code lines we'd have to modify it, and I don't see that happening any time soon.

There is a solution that I can see:

Assumptions:
* We have the memory address in D code at which the access violation occurred.
* We know which executable the access violation occurred in. (look it up by the memory address ranges for all DLLs/EXEs loaded by the application)
* We can read the CV debugging information from the executable directly. (DDL can certainly provide support here - does it support reading CV information?)  (Would this read be from within memory or from the executable file itself?  I'm not sure if CV information is copied into memory...)

Following that, it is a simple matter of looking up the code address (possibly after some translation) and retrieving the filename and line number.  Then, the Exception class should be modified to account for this extra information (if it does not already), or perhaps simply encode it within the Exception's message string.

However, this is largely dependent on implementation details.  We know that Digital Mars makes use of CodeView (CV) debugging information and this is also a Windows-specific modification.  Similar work can be done for Linux.

Of course this is all a hefty price tag for such a useful feature.  Is it worth it?

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

Bruno Medeiros wrote:
> I wonder how that other fellow (shinichiro) implemented the stack trace. Does it show only the called functions, or line nunmbers too, à la Java?

It displays both, e.g.

Unhandled win32 exception!
backtrace:
 00402055 _Dmain (+9) console_main.d:19
 0040235f main (+77)
 00412b35 mainCRTStartup (+a9)
 7c816d4f ???

And it acually is a stack trace for a simple program which uses null pointers...



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

"James Dunne" <james.jdunne@gmail.com> wrote in message news:dsd2bk$1nlm$1@digitaldaemon.com...
> Of course this is all a hefty price tag for such a useful feature.  Is it worth it?

Or, like I suggested before, insert an implicit

assert(objReference !is null)

Before dereferencing any object references.  The compiler already does something like this for array bounds checking.  And like array bounds checking, this could be turned on or off.

Jarrett Billingsley wrote:
> "James Dunne" <james.jdunne@gmail.com> wrote in message news:dsd2bk$1nlm$1@digitaldaemon.com...
> 
>>Of course this is all a hefty price tag for such a useful feature.  Is it worth it?
> 
> 
> Or, like I suggested before, insert an implicit
> 
> assert(objReference !is null)
> 
> Before dereferencing any object references.  The compiler already does something like this for array bounds checking.  And like array bounds checking, this could be turned on or off. 

Why not just use the Phobos hack ?


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:dscnvs$1eb4$1@digitaldaemon.com...
> I wonder how that other fellow (shinichiro) implemented the stack trace.

I took a brief look at it. What he did was intercept the exception generated by the operating system, then used the Microsoft debug interface to read the debug data in the executable to associate a file/line number with it.

It is the same thing that a debugger does, and so it relies on the executable being compiled with -g (full debug info).

To implement this requires a pretty advanced technical knowledge of how Windows SEH works, and shinichiro deserves a lot of respect for figuring this out, since it's mostly undocumented.

The code is highly Windows dependent, and none of it is useful under Linux. But the equivalent could presumably be done on Linux given someone who knows how debuggers work under Linux.

"Tom S" <h3r3tic@remove.mat.uni.torun.pl> wrote in message news:dsdo9a$293t$1@digitaldaemon.com...
> Why not just use the Phobos hack ?

You're right.  I forgot that it checks for all kinds of access violations.

What a wonderful hack :)