Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!tut.cis.ohio-state.edu!VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast!allbery
From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR)
Newsgroups: comp.lang.perl
Subject: Re: Problems with signal handler
Message-ID: <1991Jan22.230448.28521@NCoast.ORG>
Date: 22 Jan 91 23:04:48 GMT
References: <1991Jan22.151906.9695@daimi.aau.dk>
Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR)
Followup-To: comp.lang.perl
Organization: North Coast Computer Resources (ncoast)
Lines: 37

As quoted from <1991Jan22.151906.9695@daimi.aau.dk> by kaja@daimi.aau.dk (Kaja P. Christiansen):
+---------------
| The program's behaviour became erratic: sometimes it runs smoothly, 
| sometimes produces faulty results (always due to failed pattern match), 
| sometimes it produces a core dump. Once it broke in the handler itself
| (gdb trace is shown below), otherwise it breaks in the (well tested) 
| routines doing their own pattern matches.
| 
| It seems that the misery is caused by the pattern matching routines,
| in particular do_match, when trying memory reallocation. 
+---------------

There's no real fix for this, I suspect.  Anything that does I/O or uses
malloc() (including many list operations) can fail catastrophically (read:
core dump) in a signal handler.

The problem is that C routines that have global information --- for example,
stdio and malloc()/free() --- can't be guaranteed that the global information
is consistent.  The most one can do is to lock against multiple invocations,
which leaves you with stdio or malloc failing in the signal handler.
(Consider what happens if a signal is caught while malloc is coalescing the
free list.)  (Actually, most modern Unixes allow signals to be "held", so that
critical operations like this can complete before the signal trap executes.
However, this is non-portable:  SVR3.2 does it differently from BSD4.3 does it
differently from SunOS 4.x does it differently from ... you get the idea.  And
you can't do it at all under Xenix or V7.

I don't know if Larry can figure out a way out of this, unfortunately:  too
much of the standard C library is relentlessly non-re-entrant (despite a
number of attempts to bulletproof stdio).

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY