SVGALIB, C++ destructors, signals and general peculiarities...

SVGALIB, C++ destructors, signals and general peculiarities...

Post by Keith M. Luca » Mon, 09 Dec 1996 04:00:00



I appreciate this is a somewhat bizarre area, but I am having a little
difficulty in a destructor for an object encapsulating SVGLIB calls.

The problem I have is that when the program terminates, the "TVga"
object is destructed, which places a series of SVGALIB calls to return
the system to text mode etc. It then outputs a debug message saying
"end of constructor". This is the last line of code of mine that
executes (as far as I can work out -- I have no other global objects
to be destructed). It then gets a SIGSEGV, apparently while doing some
system tidying up before exiting to the system. SVGALIB's SIGSEGV
handler catches it and outputs a message. (I can just install a
SIGSEGV handler which SIGKILLs the app, but that's fudging the issue.)

So my question, (for those still reading !) is -- does anyone know
anything about this sort of behaviour -- is it, as I suspect, due to
an alarm or handler being raised that doesn't exist anymore somewhere
in the depths of SVGALIB, or ( more likely ) have I missed something
glaringly, grotesquely obvious that I should have known all along and
does someone want to fill me in it ?

(This is a segment of the output from stracing the program,
just after it enters the destructor, note that some debug output
is going to different files.)
-----------STRACE-OUTPUT-------------------------------------
write(7, "Destructor.\n", 12)           = 12
close(7)                                = 0
write(1, "Keybd Kill\n", 11)            = 11
write(1, "Mouse Kill\n", 11)            = 11
close(8)                                = -1 EBADF (Bad file number)
sigaction(SIGINT, {0x50016690, [INT], 0}, NULL) = 0
write(1, "Screen Kill\n", 12)           = 12
ioctl(0, TCGETS, {B0 opost isig icanon echo ...}) = 0
ioctl(0, TCSETSW, {B0 opost -isig icanon echo ...}) = 0
ioctl(5, KDSETMODE, 0)                  = 0
select(1, NULL, NULL, NULL, {0, 150000}) = 0 (Timeout)
ioctl(0, TCSETSW, {B0 opost isig icanon echo ...}) = 0
write(1, "End of Destructor\n", 18)     = 18
--- SIGSEGV (Segmentation fault) ---
ioctl(0, TCSETSW, {B0 opost isig icanon echo ...}) = 0
ioctl(5, KDSETMODE, 0)                  = 0
open("/usr/share/locale/C/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/etc/locale/C/libc.cat", 0xbffff7d4) = -1 ENOENT (No such file or directory)
stat("/usr/lib/locale/C/libc.cat", 0xbffff7d4) = -1 ENOENT (No such file or directory)
stat("/usr/lib/locale/libc/C", 0xbffff7d4) = -1 ENOENT (No such file or directory)
stat("/usr/share/locale/C/libc.cat", 0xbffff7d4) = -1 ENOENT (No such file or directory)
stat("/usr/local/share/locale/C/libc.cat", 0xbffff7d4) = -1 ENOENT (No such file or directory)
write(1, "svgalib: Signal 11: Segmentation"..., 49) = 49
sigaction(SIGSEGV, {SIG_DFL}, NULL)     = 0
getpid()                                = 913
kill(913, SIGSEGV)                      = 0
sigreturn()                             = ? (mask now [])
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
-----------STRACE-OUTPUT-------------------------------------

Thanks in advance to anyone who renders help on this topic.

 -----------------------------------------------------------------------------

          Current project: Computer war*'s next generation...
 ------------------------------------------------------------------------------

 
 
 

1. Signals and C++ Destructors

Hello all,

I was wondering which standards guarantee what (if anything)
with respect to C++ destructor calls, in the event that a process
receives a fatal signal ...

For example, say I write a simple C++ program which creates an object
on the stack, then calls sleep(3), and exits. The compiler does not
optimize the object out of existence ...

If I run the program, then send it a SIGINT during its sleep() call,
the destructor for the said object is *not called* ...

I realize that the default signal handler is a C call, but I would
expect it to call exit() to terminate the process, and that my compiler
would ensure the stack was properly unwound before terminating ...

Is this not the case?

And if not, how do most people mix C++ and signal handling ...

One idea I had was to have my own signal handler throw an exception ...
that way the resources might get cleaned up properly?

All comments welcome ...

Cheers,
Brian

--
Brian S Hanley                | "Fear is the main source of superstition,
2A Systems Design Engineering |  and one of the main sources of cruelty.
U of Waterloo                /|\ To conquer fear is the beginning of wisdom."
___________________________/_\|/_\__ - Bertrand Russell _____________________

2. Low level networking.

3. misc errors, dosemu and svgalib, errors in general

4. why can't lock share memory

5. Matrox Mystique ands X.

6. IP Masquerading + Ascend router

7. Svgalib Signal 11 error. Please HELP

8. Web authoring tool

9. General Cleanup in Response to Signals

10. svgalib, signals and currupt screens

11. Svgalib Signal 11 error. Please HELP

12. SVGAlib Signal 11 Error / gnat raised STORAGE_ERROR

13. Timeout module for general use, signal/alarm