Structured Exception Handling in C++
in [C++]
|
Prev: programmatically get a stack trace from within C++, ported to unix and windoze
Next: Warning: Can't find linker symbol
From: TJ Bandrowsky on 8 Sep 2009 17:26 > hi all, > I want to handle invalid pointer operations in my application using > exception handling, in visual studio __try , __catch are used for SEH > ( Structured Exception Handling) but how can I handle the same in GCC. > Your question really is to assume a fair amount of hardware support and compilers that bend the rules of the C++ "only throw() can trigger an exception" ideal. Libraries that are meant to portable tend to live and die by this idea that catching an exception means the computer is not fundamentally hosed up in some way. When you are catching structured exceptions and moving on, obviously, that is just a hope. But, if you must know... You are not the first to think of this. Been there, done that. It's not as good as you think, but to do it, there's two paths:First, there is a LibSEH for GCC that is a set of some magricky that gives you structured exception handling for Windows programs compiled with GCC. The other is use the /EHa (Yes with structured exceptions) option of exception handling for your program. That tells Visual C++ that catch (...) can catch SEH. The problem is this: As it stands, on today's Intel / AMD hardware you can only really tell if a pointer is bad if you try to write to a segment you don't have access to. Since both x86 and x86-64 use flat models for both Linux and Windows and Mac, that's basically your whole address space that is writable is still hosed if you have an errant pointer and there's nothing the hardware could do about it. Still, the x86 does have a solution for you, but it is drastic: If you really wanted to have genuinely good hardware pointer detection, you would have to write your own operating system that uses 386 but with a segmented memory model. Basically your application would have its own LDT and each entry would be one pointer you would be allowed to own. The hardware could be used to establish memory bounds on it I think in 4k increments and I think you could have a maximum of 8192 outstanding at any one time. You would pay something of a terrible performance penalty for this as you would have to hit the segment registers every time you accessed a pointer and this would be pretty slow, but... the hardware would guarantee your app would be pretty safe. Of course, you would need to write your own C++ compiler or hack up one to know about segments and so you'd have quite a bit of work cut out for you. The unfortunate thing is, after you did all that, you'd be hosed for 64 bit mode because x86-64 basically says you are in flat mode and that's that... the segment registers are just, well an appendage... -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrew on 9 Sep 2009 03:41
On 8 Sep, 16:43, Sada <steggi...(a)gmail.com> wrote: > hi all, > I want to handle invalid pointer operations in my application using > exception handling, in visual studio __try , __catch are used for SEH > ( Structured Exception Handling) but how can I handle the same in GCC. > > For example I want to catch EXC_BAD_ACCESS exception in my C++ > application. There is no portable way to do this. MS compilers tend to convert SEGVs to C++ exceptions by default but compilers in unix environments will not do this (quite right too, IMHO). But I understand the need to want to trap SEGVs and do something with them. I once wrote a GUI program that trapped SEGVs so it could pop up a dialog box that said "A fatal error has occurred, do you want to produce a core dump?". You won't be able to do much in your SEGV handler since you will be in the land of undefined behaviour. Also, you will not get the nice stack unwinding that you get with exceptions. Signals handlers work like non-local GOTOs (urrggh) so there will be no cleanup, no destructors called etc. I am not quite sure why you want to do this. Maybe it is similar to the GUI program I mentioned. Handling errors in this way is IMO better than just silently dying. But for command line standalone apps it might be better to just let it core dump. This can be trapped by the script that invokes it, or maybe even left to a general purpose health monitoring facility such as HP OpenView, depending on the operational environment. Regards, Andrew Marlow -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |