Question

I’m trying to connecting to some DB and get some data. and the requirement is: if the DB connection fails, I will fall back to some file-based approach.

The problem however is: every time the DB connection fails, the program ends up with an “Memory fault(coredump)” error, and it won’t continue to the file-based approach.

I’ve tried “eval {} or do {};” which doesn’t work either (i.e. stops at the Memory fault error).
Any idea about how can I recover from a “Memory fault(coredump)”? Thanks so much.

So basically, here’s the problematic code:

 my $db =
 "dbi:Sybase:server=$dbserver;database=$dbname;kerberos=$dbKerbPrincipal";
 my $dbh = DBI->connect($db, '', ''); 
 # BANG! if $dbname doesn't exist, you get the Memory fault,
 # and can't recover from it.

So I explicitly chose a wrong DB name, just to fail the DB connection and then verify the following-on “fail over” functionality. But I can’t get recovered from the above “DBI->connect()” call.

Answer 1

First of all, I agree with the previous posters and commenters – normally, you shouldn’t be getting segfaults from this situation, and a proper fix is figuring out why it segfaults and correcting (could very well be a library bug as Jonathan said).

HOWEVER, to answer your direct technical question, you can NOT recover a Perl interpreter (or any other program for that mater) once it segfaults. You wouldn’t WANT to anyway – it is likely in a messy state.

Therefore you solve your problem via a “backup” mechanism of a second process ready to pick up the shattered pieces and make sure that the show goes on, as follows:

• Just prior to attempted DB connection, you fork off a child process.

  Please note that you may need to daemonize the child process right after forking, as the parents death can kill the child. It’s ~2am so my brain’s too asleep to be sure whether it’s the case or not. If that’s the case, daemonization was covered numerous times on SO.

• The parent process attempts the DB connection, timed out by a standard Perl alarm (set to, say 10 seconds or whatever you want).

• If the connection was successful, it sends a signal to a child to indicate that DB connection is OK, and the parent code can proceed as usual.

  If the connection fails, the parent either coredumps, or issues a die assuming the connection failed in non-coredump way or timed out.

• The child process, right after forking, sets the signal handler to catch the parent’s “DB connection successful” signal, and then sets the alarm for 10+epsilon seconds.

• If the child process catches the parent’s “DB connection successful” signal, the child process dies.

• On the other hand, if the child process alarm handler is triggered, it means the parent couldn’t connect to DB. Therefore, the child process sends a signal to parent “I am about to do the fail-over”; and then execute the fail-over logic as needed

The above logic is very rough, it may need to be refined to deal with race conditions, perhaps by virtue of a lock obtained by both processes before using the data.

UPDATE

As noted in the comments, a variation of the above where the CHILD process tries to establish a DB connection and the parent process catches problems and acts as a fall-back may be somewhat easier to implement.