This probably isn't possible, or at least not easy, but is there a way to redefine abort() to call your own abort_exception() function?
I've seen some C code that does something like this:
I'm guessing you'd have to do that in all the files that call abort() though... So I guess I'm wondering if there's a way to globally re-link all the object files to call your abort() instead of the regular C abort()?Code:#define malloc myMalloc
cpjust makes a good point: just replace "abort()" with your own function - and you don't really need a different name, as long as you link that object file before the standard C library, it should take your abort instead of the other one.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
This sounds like an interesting experiment, so I'll probably try it out when I get some time.Originally Posted by matsp
Do you know if that would still work if the code that's calling abort() was in a separate .lib file that's being linked or would the .lib file need to be recompiled first?
Also, wouldn't you get Linker errors about abort() already defined in file blah...? I've always found those kinds of errors a pain in the ass to get rid of.
Dear cpjust,
Dear Mats,
Thanks for your input. Maybe it is possible to do something along those lines. I am unsure whether it is possible to shadow abort since I am not calling it directly. Also, sometimes the code gets SEGV. However, I will try to work in that direction and post the outcome. I was also thinking I could set some flag instead of throwing an exception (if exception handling needs a valid stack to backtrace and the signal handler caller corrupts it), then hope that the code somehow reaches the place where my catch is, and query the flag there instead of catch()ing.
Thanks again for you help, everyone who has replied!
Kind regards,
Nils.
Nothing should be calling it. I don't know of any C library routines which call abort(). If you're not calling it, nobody is calling it.
Under UNIX, the result of ignoring a SIGSEGV signal which was not generated with raise() or kill() is undefined. It will probably lead to an infinite loop. Here's what happens:Also, sometimes the code gets SEGV.
1. Code attempts to access bogus memory location
2. Processor signal interrupt, calls SIGSEGV handler
3. Handler returns, CPU goes to the same instruction again
4. Go to step 1
yes, Yes, YES.I was also thinking I could set some flag instead of throwing an exception
assert() does. But then assert could also be easily replaced my myassert() which in my code would unfortunately only solve a small part of the problem.
Oh, it goes to the same instruction? That may make sense from the point of view of the OS but here it creates trouble. So, in that case any signal handler that sets a flag should not return, or should it? But if it waits and a different thread throws an exception, our thread will not go to the catch either, or will it?!
Nils.
What other behavior would make any sense? The idea is to trap a bad memory access, do something that hopefully fixes the situation, then try again. If it just moved on to the next instruction, then that memory access acts like it never existed in the first place, which means your program has just become a big mess of "undefined."
Exceptions only propagate within a single thread. So the exception has to be thrown by the same thread which will ultimately handle it. As for whether the signal handler should return... It must always return. How could it not?So, in that case any signal handler that sets a flag should not return, or should it? But if it waits and a different thread throws an exception, our thread will not go to the catch either, or will it?!
Yes, that's what I meant, from an OS point of view it does make sense. From a programmer's point of view retrying that instruction would mean that the source of the problem must be fixed first. Since we are not dealing with a page fault but with something unknown in an unknown (to the signal handler) context it would be better for us to return elsewhere... But that would require contextual information and cannot be guessed by the compiler, I do realise that.
Well, since the data is apparently faulty we really do not want it to return to the method where the signal occurred in order to avoid an infinite signal/catcher loop. Instead we really want the IP to point to the catch() clause or some other defined position. Maybe with a long jump we could do that, but in each stack state (i.e. method, possibly in each for loop etc?) we would then need to register the address to jump to so that the signal handler would only jump within the "same stack state" location. Sounds like our own try-catch construct, too bad the real one does not do it :-(
OK, I will try something but tomorrow -- right now my head is spinning...
You say that the model here is: Test piece of data. If fault caught, discard data and try something else. Why not test each piece of data in its own thread. If the thread crashes, who cares? You don't have to create a new thread for every single piece of data you test. Just make one, go into your loop, and run until you crash, logging your progress all the while. When the crash inevitably occurs, spawn a new thread and start your loop again where you left off.
