perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Dunlap <>
Subject Re: exception handling
Date Thu, 13 Feb 2014 20:59:57 GMT
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.


On Thu, Feb 13, 2014 at 3:41 PM, Bill McCormick <>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.

View raw message