Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2010-09

HookSignal, "halt", and unhandled exceptions

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Seth Grover

Greetings! An interesting problem I've run into:

Under Linux, I have a small example program written in C (we'll call it cprog) which uses a FPC-compiled shared object library (libfpcso1.so) inside which I want to catch access violations in try/except blocks. I don't care about access violations in the C program, and by "don't care" I mean "don't care if it halts the program."

Thanks to HookSignal(RTL_SIGDEFAULT) (see
http://www.freepascal.org/docs-html/rtl/sysutils/hooksignal.html) once the .so installs its signal handler, catching the exceptions in the try/except blocks works beautifully.

However, if a segfault is raised in cprog, strange behavior happens. The FPC signal handler catches the signal, and goes into the "handle unhandled exception" code, which is what I wou
ld expect. It raises a runtime error 217, which is what I would expect. However, it does not halt the program. What actually happens is it gets into an infinite loop of raising runtime error 217. Here's the output. Note that the first 3 lines of output are me testing that the exceptions are handled correctly in the try/except block in the .so, which they are. Then my c program causes a segfault, after which I get the infinity r.e. 217 output:

===================================================
$ ./cprog

handled inside so 2: Access violation
handled inside so 2: Division by zero
called libc, handled inside so 2: Access violation

An unhandled exception occurred at $08048534 :
EAccessViolation : Access violation
$08048534 line 50 of cprog.c

Runtime error 217 at $F7761740
$F7761740
$F77617B4
$F7783DA5
$F77647FE
$F75D1BD6
$08048431

Runtime error 217 at $F7761740
$F7761740
$F77617B4
$F7783DA5
$F77647FE
$F75D1BD6
$08048431

An unhandled exception occurred at $F77617EF :
EAccessViolation :
$F77617EF
$F7783DA5
$F77647FE

Runtime error 217 at $F7761740
$F7761740

Runtime error 217 at $F7761740
$F7761740

Runtime error 217 at $F7761740
$F7761740

Runtime error 217 at $F7761740
$F7761740

An unhandled exception occurred at $F77617EF :
EAccessViolation :
$F77617EF
$F7783DA5
$F77647FE
$F7783DA5
$F77647FE

Runtime error 217 at $F7761740
... (at this point it continues like this forever) ===================================================

It seems the cause of this is that halt, which calls InternalExit and System_exit, which in turn calls haltproc, does not actually halt the program in the case of a library. Instead, haltproc for the library just calls InternalExit again and returns.

I took my test case to an even simpler one, and simple removed the try/except block around the access violation in my test .so. So now, all my test C program is call libfpcso1.so's "crash" function and I get the infinite loop of r.e. 217's, never returning to the main understand that it's only possible to have one signal handler installed at a time (which, in this example, I'm perfectly happy with; HookSignal does exactly what I want), but it seems wrong that an unhandled exception in a library should cause your program to go into an infinite loop, rather than doing the same thing an unhanded exception would do in an executable.

Thoughts? Should I log it as a bug?

Thanks,

-SG

This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com

Reply by email

Jonas Maebe
to Seth Grover
Seth Grover wrote
It seems the cause of this is that halt, which calls InternalExit and System_exit, which in turn calls haltproc, does not actually halt the program in the case of a library. Instead, haltproc for the library just calls InternalExit again and returns.

It's probably caused by r14184, which was in response to http://bugs.freepascal.org/view.php?id=14958

The problem is probably that the lib's exit code is called both when the library is unloaded (in which case you don't want the process to terminate) and when the "library" terminates (either via an unhandled exception, or by calling halt). I can't say off-hand how to decouple them, but a patch would be welcome.

Jonas

Reply by email

Seth Grover
to Seth Grover: Greetings! An interesting problem I've run into: Under Linux, I have a small example…
Jonas wrote 6 lines
It's probably caused by r14184, which was in response to http://bugs.freepascal.org/view.php?id=14958 The problem is probably that the lib's exit code is called both when the library is unloaded (in which case you don't want the process to terminate) and when the "library" terminates (either via an unhandled exception, or by calling halt). I can't say off-hand how to decouple them, but a patch would be welcome. Jonas

Hm, I see what you mean. I'm going to be on vacation for the next two weeks (up in the mountains away from computers, electricity, etc.) but I'll ruminate on it while I'm gone.

In the meanwhile I've logged a mantis issue to track: http://bugs.freepascal.org/view.php?id=17383

Have a good weekend,

-SG

This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com

Reply by email