Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 31,553 of 33,346    |
|    Ulrich Eckhardt to All    |
|    Re: Best practice to handle segmentation    |
|    07 Oct 11 06:33:15    |
      d5397751       From: ulrich.eckhardt@dominalaser.com              Am 06.10.2011 20:34, schrieb Harry:       > Is it a best practice to handle segmentation fault inside a shared       > library(.so) C++ ?              Generally, a segmentation fault signals a programming error. It might       happen some time after you invalidated internal data structures in code       that is not directly connected to the faulty part. For that reason, you       can't assume your program is in a sane state from which you could       recover. Since a shared library has access to the whole memory space of       a process, your whole process is potentially compromised and you should       terminate it.              That said, there are programs that are prepared to handle such faults,       but you need to design them from the scratch for it. Also, all code that       could be affected by the internal inconsistency must be aware of it. In       most cases, this is not what you want to do.                     > The shared library is used by C/C++ and java applications.       > My intention is that the program using my shared library should get       > return values in all cases even in case of segmentation faults.              What makes you think in the first place that C++ code would always want       to return something? For example, errors are usually signalled using       exceptions, not error codes! In order to use this with C, you have to       convert exceptions to errorcodes. For Java, similar approaches might be       required.                     Anyhow: If you are not convinced that you want to terminate on       segmentation faults, there is another clean way to catch them without       compromising your program as a whole, and that is to run the library       code in a second process. I think that an out-of-proc COM server would       achieve that, but the idea is always that you put a process and some       inter-process communication (IPC) layer in between. If the library       causes segfaults, it is only that process which is affected. You can       detect this from the main process and handle the fault accordingly.              Good luck!              Uli                     --        [ See http://www.gotw.ca/resources/clcm.htm for info about ]        [ comp.lang.c++.moderated. First time posters: Do this! ]              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca