This is a little outside my area of expertise and it's been years since I've touched C++ but, shooting from the hip, even if debugging symbols are compiled into the shared object, I'm not sure you'd be able to get any detailed information unless you were also running from within in a debugger, which is unlikely outside of a development environment. Beyond that, if memory serves, I don't think that you can catch segmentation faults at all. Your best chance for catching this sort of thing would be to run the C++ code in another process and checking its stdout stream or better yet the process exit status. This would, at least, allow you to detect that an error had happened. If creating a new process is not be desirable in your circumstances then you'd probably be better off implementing some extremely draconian parameter validation logic to ensure that you KNOW what is being passed to the shared object.
Cheers! John On Thu, Feb 13, 2014 at 3:41 PM, Bill McCormick <wpmccorm...@gmail.com>wrote: > I have a Perl module that calls a function from in a Swig generated > module, which in turn calls a function in a shared library. It's been a > while since I put it all together and made it work, so I'm kind of hazy on > the technical details - and since it mostly works I never need to look at > it. > > There is occasion, when called with incorrect parameters, that the wrapped > function(s) will create a segmentation fault. I'd like to be able to get > the details of the seg fault up to the Perl/CGI script that runs all of > this. Is there some way I should be wrapping calls to the shared lib in > something like an eval BLOCK, so I can croak a message back to the web page? > > Thanks! > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > >
