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: igor@txc.com, 124@pari.math.u-bordeaux.fr
Resent-From: Igor Schein <igor@txc.com>
Resent-To: bug-submit-list@pari.math.u-bordeaux.fr
Resent-CC: Karim.Belabas@math.u-psud.fr
Resent-Date: Thu, 07 Apr 2005 06:33:03 UTC
Resent-Message-ID: <handler.124.B124.111285518924803@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.111285518924803
          (code B ref 124); Thu, 07 Apr 2005 06:33:03 UTC
Received: (at 124) by pari.math.u-bordeaux.fr; 7 Apr 2005 06:26:29 +0000
Received: from transfire.transwitch.com ([208.5.237.254] helo=mailproxy2.txc.com)
	by pari with esmtp (Exim 3.35 #1 (Debian))
	id 1DJQTF-0006Rw-00
	for <124@pari.math.u-bordeaux.fr>; Thu, 07 Apr 2005 08:26:29 +0200
Received: from [192.168.10.84] (helo=jim.btc.txc.com)
	by mailproxy2.txc.com with esmtp (Exim 4.42)
	id 1DJQSi-000606-HQ
	for 124@pari.math.u-bordeaux.fr; Thu, 07 Apr 2005 02:25:56 -0400
Received: by jim.btc.txc.com (Postfix, from userid 7003)
	id 3420B36C048; Thu,  7 Apr 2005 02:25:55 -0400 (EDT)
Date: Thu, 7 Apr 2005 02:25:55 -0400
From: Igor Schein <igor@txc.com>
To: 124@pari.math.u-bordeaux.fr
Message-ID: <20050407062555.GR1330@txc.com>
References: <20041209215919.GV13401@txc.com> <20041210170624.GB13401@txc.com> <20041210175231.GC30613@seventeen> <20041214201724.GM13401@txc.com> <20041214204646.GA29446@geo.math.u-psud.fr> <20050109182516.GV23145@seventeen>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050109182516.GV23145@seventeen>
User-Agent: Mutt/1.4.2i
X-TXC-MailScanner-Information: Please contact SysAdmin group (help@txc.com) for more information
X-TXC-MailScanner: Found to be clean
X-MailScanner-From: igor@txc.com

On Sun, Jan 09, 2005 at 07:25:16PM +0100, Bill Allombert wrote:
> Another similar problem:
> ? g(n)=forvec(v=vector(n,i,[1,2]),s=sum(i:small=1,#v,v[i]);print1(v," "),1);
> ? g(1000)
> ^C
> 
> Unfrequently, this cause GP to hang.
> 
> I can still reproduce that using gp2c-run to compile g().
> 
> Apparently, you need fast I/O to have a chance to press ^C at the
> correct time, so gp under gdb or through ssh is ruled out.
> 
> Here the backtrace (under gp2c-dbg)
> #0  0x401f587e in sigsuspend () from /lib/libc.so.6
> #1  0x402f1879 in __pthread_wait_for_restart_signal ()
>    from /lib/libpthread.so.0
> #2  0x402f3636 in __pthread_lock () from /lib/libpthread.so.0
> #3  0x402eff3a in pthread_mutex_lock () from /lib/libpthread.so.0
> #4  0x402f2b51 in flockfile () from /lib/libpthread.so.0
> #5  0x4022d3e4 in fflush () from /lib/libc.so.6
> #6  0x081bc8a8 in normalOutF () at ../src/language/es.c:207
> #7  0x081bca15 in pariflush () at ../src/language/es.c:248
> #8  0x081c8648 in pari_err (numerr=19) at ../src/language/init.c:1084
> #9  0x0822acb2 in gp_handle_SIGINT () at ../src/gp/gp.c:2235
> #10 0x0822acf5 in gp_sighandler (sig=2) at ../src/gp/gp.c:2250
> #11 0x402f1f54 in pthread_sighandler () from /lib/libpthread.so.0
> #12 0x401f56b8 in sigaction () from /lib/libc.so.6
> #13 0x402f0253 in pthread_mutex_unlock () from /lib/libpthread.so.0
> #14 0x402f2b79 in funlockfile () from /lib/libpthread.so.0
> #15 0x4022dad2 in fputs () from /lib/libc.so.6
> #16 0x081bc870 in normalOutS (s=0x825d0b3 ", ") at ../src/language/es.c:201
> #17 0x081bc9fc in pariputs (s=0x825d0b3 ", ") at ../src/language/es.c:245
> #18 0x081c15a1 in bruti (g=0x407f9e20, T=0xbffff7f4, addsign=1)
>     at ../src/language/es.c:1774
> #19 0x081c3942 in gen_output (x=0x407f9e20, T=0xbffff7f4)
>     at ../src/language/es.c:2403
> #20 0x081bcc47 in vpariputs (format=0x4001708e "%Z ", args=0xbffff868)
>     at ../src/language/es.c:310
> #21 0x081bccbc in pariputsf (format=0x4001708e "%Z ")
>     at ../src/language/es.c:325
> #22 0x40016d49 in g (n=0x408078fc) at foo.gp.c:65
> #23 0x081b859f in identifier () at ../src/language/anal.c:2069
> #24 0x081b5e67 in truc () at ../src/language/anal.c:1331
> #25 0x081b5b25 in facteur () at ../src/language/anal.c:1267
> #26 0x081b4443 in expr () at ../src/language/anal.c:799
> #27 0x081b4247 in seq () at ../src/language/anal.c:759
> #28 0x081b3334 in lisseq0 (t=0x8310fe8 "g(1000)", f=0x81b41d4 <seq>)
>     at ../src/language/anal.c:373
> #29 0x081b373c in readseq (c=0x8310fe8 "g(1000)", strict=0)
>     at ../src/language/anal.c:445
> #30 0x0822bc9a in gp_main_loop (ismain=1) at ../src/gp/gp.c:2667
> #31 0x0822cbd5 in main (argc=1, argv=0xbffffce4) at ../src/gp/gp.c:2983
> 
> Another trace, with gp2c-run by attaching dbg after the lock up:
> 
> #0  0x401f587e in ?? ()
> #1  0x402f1879 in ?? ()
> #2  0x402f3636 in ?? ()
> #3  0x402eff3a in ?? ()
> #4  0x402f2b51 in ?? ()
> #5  0x4022d3e4 in ?? ()
> #6  0x081bc8a8 in wr_vecsmall (T=0x402fcae0, g=0x0) at ../src/language/es.c:921
> #7  0x081bca15 in round_up (resd=0x402fcae0, n=136695850, res=0xbffff1c8)
>     at ../src/language/es.c:951
> #8  0x081c8648 in shiftaddress_canon (x=0x13, dec=136935616)
>     at ../src/language/init.c:1565
> #9  0x0822acb2 in read_opt (A=0x402fcae0, argc=137000800, argv=0x13)
>     at ../src/gp/gp.c:2916
>     at ../src/language/es.c:2070
> #20 0x081c157f in texi_nobrace (g=0x407f9e20, T=0xbffff864, addsign=1)
>     at ../src/language/es.c:2196
> #21 0x081c3942 in is_long_ok (f=0x407f9e20, L=-1073743772)
>     at ../src/language/es.c:3210
> #22 0x081bcc47 in wr_float (T=0x4001708e, x=0xbffff8d8, f_format=-1073743668)
>     at ../src/language/es.c:996
> #23 0x081bccbc in wr_float (T=0x4001708e, x=0x407f9e20, f_format=-1073743564)
>     at ../src/language/es.c:1003
> #24 0x40016d49 in ?? ()
> #25 0x081b859f in entry () at ../src/language/anal.c:2641
> #26 0x081b5e67 in identifier () at ../src/language/anal.c:1899
> #27 0x081b5b25 in identifier () at ../src/language/anal.c:1843
> #28 0x081b4443 in truc () at ../src/language/anal.c:1367
> #29 0x081b4247 in truc () at ../src/language/anal.c:1332
> #30 0x081b3334 in init_buf (len=137433064, ptbuf=0x81b41d4, ptlim=0xbffffc4c)
>     at ../src/language/anal.c:1011
> #31 0x081b373c in any_string () at ../src/language/anal.c:1104
> #32 0x0822bc9a in hashtable_generator (text=0x1 <Address 0x1 out of bounds>,
>     state=500000, hash=0xbffffcec) at ../src/gp/gp_rl.c:419
> #33 0x0822cbd5 in print_escape_string (s=0x1 <Address 0x1 out of bounds>)
>     at ../src/gp/gp_rl.c:771
> #34 0x401e514f in ?? ()
> 
> Cheers,
> Bill.

Here's another scenario (64bit-only):

                  GP/PARI CALCULATOR Version 2.2.10 (development CHANGES-1.1186)
          amd64 running linux (x86-64/GMP-4.1.4 kernel) 64-bit version
       compiled: Apr  6 2005, gcc-3.2.3 20030502 (Red Hat Linux 3.2.3-49)
                (readline v4.3 enabled, extended help available)
? forprime(p=3000,9!,forprime(q=3000,p-1,if(isfundamental(p)==isfundamental(q),d=p*q;print(p" "q" "d" "sum(k=1,1000,quadclassunit(d,,[.1,.1])[1])/1000.))))
3019 3011 9090209 1.0000000000000000000000000000000000000
3023 3011 9102253 3.0000000000000000000000000000000000000
  *** sum: user interrupt after 2,720 ms.

It hangs write there.  It's weird that it says interrupt in sum.
Normally, if you just randomly hit ^C, you'd most certainly be
interrupting quadclassunit, which is what happens on 32bit.

I can hang a fresh session like this almost always.  Once in a while,
I'll get a session where interrupt is handled gracefully.  Then it'll
continue behave like that in subsequent sessions, almost like it's
somehow reusing memory from the previous session.  Then if I step away
from the monitor for N minutes, it'll start hanging every time again.  

Isn't it like a weirdest thing you can imagine?  Needless to say, I am
doing it on a completely quite system.  And I try to randomize my
^C-hitting pattern.  I also tried kill -QUIT from a different window,
that kills the session swiftly - no hangs.  

Igor

Send a report that this bug log contains spam.