PARI/GP Bug report logs - #124
handling interrupt

Full log

Message #15 received at 124@pari.math.u-bordeaux.fr (full text, mbox, reply):

Received: (at 124) by pari.math.u-bordeaux.fr; 14 Dec 2004 20:18:02 +0000
From igor@txc.com Tue Dec 14 21:18:02 2004
Received: from transfire.transwitch.com ([208.5.237.254] helo=mailproxy2.txc.com)
	by pari with esmtp (Exim 3.35 #1 (Debian))
	id 1CeJ7R-0007BZ-00
	for <124@pari.math.u-bordeaux.fr>; Tue, 14 Dec 2004 21:18:01 +0100
Received: from [192.168.10.43] (helo=sawara.btc.txc.com)
	by mailproxy2.txc.com with esmtp (Exim 4.42)
	id 1CeJ6r-0004TQ-B2; Tue, 14 Dec 2004 15:17:25 -0500
Received: by sawara.btc.txc.com (Postfix, from userid 7003)
	id AC27036C048; Tue, 14 Dec 2004 15:17:24 -0500 (EST)
Date: Tue, 14 Dec 2004 15:17:24 -0500
From: Igor Schein <igor@txc.com>
To: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 124@pari.math.u-bordeaux.fr
Subject: Re: Bug#124: handling interrupt
Message-ID: <20041214201724.GM13401@txc.com>
Reply-To: igor@txc.com
References: <20041209215919.GV13401@txc.com> <20041210170624.GB13401@txc.com> <20041210175231.GC30613@seventeen>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041210175231.GC30613@seventeen>
User-Agent: Mutt/1.4.1i
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 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
#12 0x00000000005e73ad in err_recover (numerr=19) at ../src/language/init.c:1053
#13 0x00000000005e765d in pari_err (numerr=19) at ../src/language/init.c:1205
#14 <signal handler called>
#15 0x0000002a95fa1b1c in mmap64 () from /lib64/tls/libc.so.6
#16 0x0000002a95f466a6 in sYSMALLOc (nb=227232, av=0x2a9610d6c0) at malloc.c:2736
#17 0x0000002a95f431d2 in __libc_malloc (bytes=227224) at malloc.c:3295
#18 0x00000000005e5a51 in gpmalloc (size=0) at ../src/language/init.c:265
#19 0x00000000005e57c2 in newbloc (n=28400) at ../src/language/init.c:131
#20 0x00000000005e8d32 in gclone (x=0x2a9daf8a38) at ../src/language/init.c:1509
#21 0x00000000005c9dd9 in changevalue (ep=0x850480, x=0x2a9daf8a38) at ../src/language/anal.c:647
#22 0x00000000005cb8d1 in identifier () at ../src/language/anal.c:1835
#23 0x00000000005cb6b0 in truc () at level1.h:232
#24 0x00000000005caaf5 in facteur () at ../src/language/anal.c:1267
#25 0x00000000005ca31b in expr () at ../src/language/anal.c:799
#26 0x00000000005ca1fa in seq () at ../src/language/anal.c:759
#27 0x00000000005ce6c1 in identifier () at ../src/language/anal.c:2111
#28 0x00000000005cb6b0 in truc () at level1.h:232
#29 0x00000000005caaf5 in facteur () at ../src/language/anal.c:1267
#30 0x00000000005ca31b in expr () at ../src/language/anal.c:799
#31 0x00000000005ca1fa in seq () at ../src/language/anal.c:759
#32 0x00000000005c9619 in lisseq_void (t=0x0) at ../src/language/anal.c:415
#33 0x00000000005fbf85 in forpari (ep=0x85bac0, a=0x2a9daf9ac8, b=0x2a9dafd108, ch=0x8632a5 "if(matdet(v[i])==j,t=concat(t,[v[i]])));t") at ../src/language/sumiter.c:37
#34 0x00000000005cc025 in identifier () at ../src/language/anal.c:2069
#35 0x00000000005cb6b0 in truc () at level1.h:232
#36 0x00000000005caaf5 in facteur () at ../src/language/anal.c:1267
#37 0x00000000005ca31b in expr () at ../src/language/anal.c:799
#38 0x00000000005ca1fa in seq () at ../src/language/anal.c:759
#39 0x00000000005d5518 in lisseq0 (t=0x0, f=0x5ca190 <seq>) at ../src/language/anal.c:373
#40 0x00000000005d03e5 in identifier () at ../src/language/anal.c:1569
#41 0x00000000005cb6b0 in truc () at level1.h:232
#42 0x00000000005caaf5 in facteur () at ../src/language/anal.c:1267
#43 0x00000000005caf28 in truc () at ../src/language/anal.c:1354
#44 0x00000000005caaf5 in facteur () at ../src/language/anal.c:1267
#45 0x00000000005ca31b in expr () at ../src/language/anal.c:799
#46 0x00000000005d5bdf in any_string () at ../src/language/anal.c:1114
#47 0x00000000005cdc49 in identifier () at ../src/language/anal.c:1978
#48 0x00000000005cb6b0 in truc () at level1.h:232
#49 0x00000000005caaf5 in facteur () at ../src/language/anal.c:1267
#50 0x00000000005ca31b in expr () at ../src/language/anal.c:799
#51 0x00000000005ca1fa in seq () at ../src/language/anal.c:759
#52 0x00000000005c9619 in lisseq_void (t=0x0) at ../src/language/anal.c:415
#53 0x00000000005fbf85 in forpari (ep=0x84fe20, a=0x2a9dc27d10, b=0x2a9dc2afb0, ch=0x86725c "print(k\" \"#subgr(quadpoly(8),k,32)))") at ../src/language/sumiter.c:37
#54 0x00000000005cc025 in identifier () at ../src/language/anal.c:2069
#55 0x00000000005cb6b0 in truc () at level1.h:232
#56 0x00000000005caaf5 in facteur () at ../src/language/anal.c:1267
#57 0x00000000005ca31b in expr () at ../src/language/anal.c:799
#58 0x00000000005ca1fa in seq () at ../src/language/anal.c:759
#59 0x00000000005d5518 in lisseq0 (t=0x0, f=0x5ca190 <seq>) at ../src/language/anal.c:373
#60 0x00000000005c99ea in readseq (c=0x867250 "for(k=3,10!,print(k\" \"#subgr(quadpoly(8),k,32)))", strict=229376) at ../src/language/anal.c:445
#61 0x000000000066c6e1 in gp_main_loop (ismain=1) at ../src/gp/gp.c:2667
#62 0x0000000000668176 in main (argc=1, argv=0x7fbff3d0f8) at ../src/gp/gp.c:2983

>                                        
> > #22 0x00000000005e689a in pari_err (numerr=19) at ../src/language/init.c:989
> > #23 <signal handler called>
> 
> If you have some idea how to reproduce it, you can try them under
> valgrind (on a x86). Maybe valgrind will catch a problem that do not
> upset the 32bit libc.

Well, since I only have this problem on x86_64, I don't see how I'll
be able to run 64bit binaries through valgrind.

Igor

Send a report that this bug log contains spam.