PARI/GP Bug report logs - #124
handling interrupt

Full log

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

Received: (at 124) by pari.math.u-bordeaux.fr; 18 Mar 2006 11:20:45 +0000
From allomber@math.u-bordeaux.fr Sat Mar 18 12:20:45 2006
Received: from smtp3-g19.free.fr ([212.27.42.29])
	by pari with esmtp (Exim 3.35 #1 (Debian))
	id 1FKZUD-0002x1-00
	for <124@pari.math.u-bordeaux.fr>; Sat, 18 Mar 2006 12:20:45 +0100
Received: from yellowpig.yi.org (fac34-1-82-224-137-145.fbx.proxad.net [82.224.137.145])
	by smtp3-g19.free.fr (Postfix) with ESMTP id BA64D4962A;
	Sat, 18 Mar 2006 12:20:42 +0100 (CET)
Received: from bill by yellowpig.yi.org with local (Exim 3.35 #1 (Debian))
	id 1FKZTz-0003VC-00; Sat, 18 Mar 2006 12:20:31 +0100
Date: Sat, 18 Mar 2006 12:20:31 +0100
To: Igor Schein <igor@txc.com>
Cc: 124@pari.math.u-bordeaux.fr
Subject: Re: Bug#124: handling interrupt
Message-ID: <20060318112031.GC11349@seventeen>
References: <20041209215919.GV13401@txc.com> <20041210170624.GB13401@txc.com> <20041210175231.GC30613@seventeen> <20041214201724.GM13401@txc.com> <20050904145150.GV10361@seventeen> <20060318104343.GA8696@txc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060318104343.GA8696@txc.com>
User-Agent: Mutt/1.3.28i
From: Bill Allombert <allomber@math.u-bordeaux.fr>

On Sat, Mar 18, 2006 at 05:43:43AM -0500, Igor Schein wrote:
> I think I've finally tackled this problem.  The dirty solution was:
> 
> chmod 0 /lib*/tls
> 
> Now the background.  First of all, I noticed these problems only occur
> on CentOS 3 machines (both 32 and 64bit).   Then I noticed gp gets
> runtime linking to /lib/tls/libc.so.6, which comes from here:
> 
> % ldconfig -p | grep libc.so
>         libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.20) => /lib/tls/libc.so.6
>         libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6
>         libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6
> 
> I couldn't quickly figure out how to change that order, so I just hid
> the offending library from the user.  As a result, I can't reproduce
> ^C problem at will any more.
> 
> Here's the link describing the difference between 3 versions of the
> library: 
> 
> http://people.redhat.com/drepper/assumekernel.html
> 
> I'd like to use this workaround for some time to check my theory, but
> I have a feeling I nailed it :)

Thanks a lot for your investigation.

> Is there anything in GP signal handling mechanism which would make
> NPTL POSIX thread library a bad choice?  I don't like the dirty
> solution for obvious reason, but I am not sure how to tell Configure
> not to use tls.  So the ideal solution would still be to try to change
> something in pari code, as opposed to on the system level, to fix this
> problem.  CentOS 4 is most likely clean, but my machines must stay
> CentOS 3 for compatibity reasons.

PARI make no use of NPTL POSIX thread, so I don't see any way to fix
the problem inside PARI. Maybe not using non-reentrant libc functions
would help, but some call might be in the readline lib itself.

Also when experimenting with the 'thread local stack' patch, I found
out that gcc-3.3 was broken with respect to tls support. If your glibc
is built with such compiler, it might be buggy.  We found other glibc
problems with SuSE SLES-8.1 on amd64.  

Cheers,
Bill.

Send a report that this bug log contains spam.