PARI/GP Bug report logs - #124
handling interrupt

Full log

🔗 View this message in rfc822 format

X-Loop: allomber@math.u-bordeaux.fr
Subject: Bug#124: handling interrupt
Reply-To: Karim Belabas <Karim.Belabas@math.u-psud.fr>, 124@pari.math.u-bordeaux.fr
Resent-From: Karim Belabas <Karim.Belabas@math.u-psud.fr>
Resent-To: bug-submit-list@pari.math.u-bordeaux.fr
Resent-CC: Karim.Belabas@math.u-psud.fr
Resent-Date: Tue, 14 Dec 2004 20:48:04 UTC
Resent-Message-ID: <handler.124.B124.110305720928292@pari.math.u-bordeaux.fr>
Resent-Sender: allomber@math.u-bordeaux.fr
X-PARI/GP-PR-Message: report 124
X-PARI/GP-PR-Package: pari
X-PARI/GP-PR-Keywords: 
Received: via spool by 124-submit@pari.math.u-bordeaux.fr id=B124.110305720928292
          (code B ref 124); Tue, 14 Dec 2004 20:48:04 UTC
Received: (at 124) by pari.math.u-bordeaux.fr; 14 Dec 2004 20:46:49 +0000
Received: from matups.math.u-psud.fr ([129.175.50.4])
	by pari with esmtp (Exim 3.35 #1 (Debian))
	id 1CeJZJ-0007MF-00
	for <124@pari.math.u-bordeaux.fr>; Tue, 14 Dec 2004 21:46:49 +0100
Received: from geo.math.u-psud.fr (geo.math.u-psud.fr [129.175.50.56])
          by matups.math.u-psud.fr (8.12.10/jtpda-5.4) with ESMTP id iBEKkklN017934
          ; Tue, 14 Dec 2004 21:46:46 +0100 (MET)
Received: by geo.math.u-psud.fr (Postfix, from userid 20603)
	id 15B5426F21; Tue, 14 Dec 2004 21:46:46 +0100 (MET)
Date: Tue, 14 Dec 2004 21:46:46 +0100
From: Karim Belabas <Karim.Belabas@math.u-psud.fr>
To: igor@txc.com, 124@pari.math.u-bordeaux.fr
Message-ID: <20041214204646.GA29446@geo.math.u-psud.fr>
References: <20041209215919.GV13401@txc.com> <20041210170624.GB13401@txc.com> <20041210175231.GC30613@seventeen> <20041214201724.GM13401@txc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041214201724.GM13401@txc.com>
User-Agent: Mutt/1.4.1i

* Igor Schein [2004-12-14 21:35]:
> On Fri, Dec 10, 2004 at 06:52:31PM +0100, Bill Allombert wrote:
> > On Fri, Dec 10, 2004 at 12:06:24PM -0500, Igor Schein wrote:
> > > Package: pari
> > > Version: 2.2.9 (development CHANGES-1.1080)
> > > 
> > > This is a major recurring problem for me.  In an interactive session
> > > running on Opteron machine, ^C stops working, meaning the session is
> > > lost.  I can tell it the command ( usually a loop ) does get
> > > terminated because the process is in S state, but I never get a prompt
> > > back.  I never saw this on a 32bit machine.  Here's a stack trace:
> > 
> > I already saw that problem while running 32bit GP under screen. I
> > assumed it was screen fault, perhaps wrongly.
> > 
> > > #21 0x00000000005e4add in pop_stack (pts=0x2) at ../src/language/init.c:98
> >                                        ^^^^^^^
> > I don't know what trust we can have in this value, but if it is really
> > 0x2, then something is seriously wrong.
> 
> Here's another instance, slightly different:
> 
> #0  0x0000002a95fb0f6b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
> #1  0x0000000001c0c450 in ?? ()
> #2  0x0000000014000000 in ?? ()
> #3  0x0000002a95f475b0 in free_atfork () at stdlib.h:317
> #4  0x0000000000000006 in ?? ()
> #5  0x00000000005e599d in killbloc (x=0x1c0c468) at ../src/language/init.c:184
> #6  0x00000000005e599d in killbloc (x=0x1c0c4c8) at ../src/language/init.c:184
> #7  0x00000000005e599d in killbloc (x=0x1c0c520) at ../src/language/init.c:184
> #8  0x00000000005e599d in killbloc (x=0x1c0c6e8) at ../src/language/init.c:184
> #9  0x00000000005e5900 in killbloc (x=0x1c0c468) at ../src/language/init.c:158
> #10 0x00000000005c9d8e in pop_val_if_newer (ep=0x85c700, loc=0) at ../src/language/anal.c:631
> #11 0x00000000005e6f72 in recover (flag=-1777281344) at ../src/language/init.c:879

One possible hint: recover() [ called whenever an error interrupting the
computation occurs ] _does_ disable SIGINT, but is supposed to re-enable it
when exiting.

If another error occurs while we're in recover, we're in trouble. I have just
double checked the instructions between 

  sigfun = os_signal(SIGINT, SIG_IGN)

and

  os_signal(SIGINT, sigfun)

and none of these can raise an exception UNLESS it is of the 'signal' kind,
as handled by gp_sighandler(). [ e.g SEGV .... ]

From the code, it seems that SIGBREAK is _not_ disabled in recover()
[ which is a bug ].

Anyway, you may want to add debugging statements before the 2 os_signal
calls, just to check that the 2nd one is always being called properly.

    Karim.
-- 
Karim Belabas                     Tel: (+33) (0)1 69 15 57 48
Dep. de Mathematiques, Bat. 425   Fax: (+33) (0)1 69 15 60 19
Universite Paris-Sud              http://www.math.u-psud.fr/~belabas/
F-91405 Orsay (France)            http://pari.math.u-bordeaux.fr/  [PARI/GP]

Send a report that this bug log contains spam.