home bbs files messages ]

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