allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/23/91)
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
ronald@robobar.co.uk (Ronald S H Khoo) (01/24/91)
allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: > 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. To pick a nit, SCO Xenix V.2.3 has sighold()/sigrelse(). Question: where do these come from ? BSD 4.1 ? Actually, what I'd really like to know is, is there an abstract interface to "held" signals that maps reasonably well on top of all the seemingly endless different kinds of signal interfaces ? Or is it really the case that all we can really use in half-portable code is just plain signal() ? -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
asmodeus@tree.uucp (Jon Ballard) (01/24/91)
I've tried to use signals also. I was programming a pager like more. When you hit a BREAK it would stop printing and give you the prompt. Never did get it to work right. Diagnostics points to the signal handling is bad. I did it just like is in the manual. -- Jonathan Ballard (a.k.a Asmodeus) UNIX Tree BBS - A new generation in BBS programs! EMAIL: csusac.ecs.csus.edu!tree!asmodeus ...!pacbell!sactoh0!tree!asmodeus ...!ucbvax!ucdavis!csusac!tree!asmodeus
piet@cs.ruu.nl (Piet van Oostrum) (01/31/91)
>>>>> In message <1991Jan22.230448.28521@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (BSA) writes:
BSA> There's no real fix for this, I suspect. Anything that does I/O or uses
BSA> malloc() (including many list operations) can fail catastrophically (read:
BSA> core dump) in a signal handler.
The GNU malloc() is reentrant. I have read the code and I have reason to
believe that free() may give rise to problems, but that might have been
solved in the current release.
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet
Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete')