You can write a signal handler for SIGSEGV. And that signal handler (probably) can throw an exception. But I am not confident that it would work.
That is because a SIGSEGV can be thrown anywhere, not just in a "normal" piece of code. For example, SIGSEGV might be thrown when returning from a function because the stack was corrupt - throwing an exception would not help there because the stack would still be corrupt as it was unwound, resulting in chaos.
Most C programs I know which catch SIGSEGV use longjmp to jump to a cleanup handler. I don't think it's really feasible to handle it in a correct C++ way, as the CPU might be in the middle of some operation that it couldn't safely throw an exception from.
Mark
Catch a segfault
Author
Quote:Original post by Erzengeldeslichtes
The stack has a fixed size. If you have a huge stack, you have a problem in your code, like an infinite recursion. If you have a huge heap, on the other hand, that could be something as sinister as an infinite loop of news, or as benign as a movie file.
Therefore, if you run out of stack space, it's better to crash and let the developer know there's a problem, rather than silently enlarge the stack and slow to a crawl.
My stack could be large because of local variables, not recursion. Doesn't seem fair to penalise me for that. You might as well print an error "Warning, this program has consumed X bytes of stack" and continue as normal.
Quote:Original post by Basiror
At university our projects have to compile fine with both valgrind and efence otherwise you get zero scores ^^
Oh, can Valgrind be fun. Try running NACHOS from it, and scream. But even rather simple things like pthreads show fun reactions.
Anyway, when you have a SIGSEGV, the best you can try to do is die gracefully with as little data loss as possible, since after that point you shouldn't make assumpions about the state of your address space.
Granted, in most cases you will just have fallen over a NULL pointer.
Quote:walkingcarcass
You might as well print an error "Warning, this program has consumed X bytes of stack" and continue as normal.
How would you continue as normal? When the stack is full, every function call will fail, unless you unwind some levels. You can't just do that without killing the intended control flow. You could as well copy some stuff from /dev/random into your text segment and try to run that.
Quote:Original post by walkingcarcassQuote:Original post by Erzengeldeslichtes
The stack has a fixed size. If you have a huge stack, you have a problem in your code, like an infinite recursion. If you have a huge heap, on the other hand, that could be something as sinister as an infinite loop of news, or as benign as a movie file.
Therefore, if you run out of stack space, it's better to crash and let the developer know there's a problem, rather than silently enlarge the stack and slow to a crawl.
My stack could be large because of local variables, not recursion. Doesn't seem fair to penalise me for that. You might as well print an error "Warning, this program has consumed X bytes of stack" and continue as normal.
If you intentionally have several megs of local variables, you have a bigger problem than just a recursion. One might call it a PBKAC error.[ignore]
Variables on the stack are supposed to be small and quickly accessed. Your big movie files or whatnot are supposed be allocated to the heap. If you violate this, the compiler and linker does not guarentee your program will remain functional. If you follow this, you'll need millions of local variables before you start running out of space; with 2 megs you could have half a million pointers on the stack before you start running out of stack space.
But if you really feel that you want to turn the stack into a slower, resizable monster, go ahead. Just because no one else has done it doesn't mean you shouldn't try.
[Edited by - Erzengeldeslichtes on July 20, 2006 12:19:47 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
