libpari segfault related to sage-4.5.3?

[Jan Groenewald]

Hi

* Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
* Linux muizenberg 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64 GNU/Linux, Ubuntu 10.04.1, gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
* sage-4.5.3 from source, optional database*, gap*, biopython and jsmath
* with patches #9720v4, #9803v2, #9802v2, and #9754v7

sage -testall
...
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 8180.6 seconds
Please see /root/.sage//tmp/test.log for the complete log from this test.

However, I happened to notice something in dmesg around the same time
0 jan@muizenberg:/var/autofs/misc/home/jan$dmesg |grep pari
[ 8319.576447] python[21505]: segfault at c40000007b ip 00007fee3338efa1 sp 00007fff95d79530 error 4 in libpari-gmp.so.2[7fee3319a000+2c6000]

I'm not sure I can recreate that, but perhaps someone here is interested?

regards,
Jan
--
.~.
/V\ Jan Groenewald
/( )\ www.aims.ac.za
^^-^^

[Dr. David Kirkby]

IMHO we really should be recording the times of doctests so we can see if
there's any correlation to the time of a doctest failure and system log files.

Dave

[Jeroen Demeyer]

On 2010-10-12 12:54, Jan Groenewald wrote:
> Hi
>
> * Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
> * Linux muizenberg 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64 GNU/Linux, Ubuntu 10.04.1, gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
> * sage-4.5.3 from source, optional database*, gap*, biopython and jsmath
> * with patches #9720v4, #9803v2, #9802v2, and #9754v7
>
> sage -testall
> ...
> ----------------------------------------------------------------------
> All tests passed!
> Total time for all tests: 8180.6 seconds
> Please see /root/.sage//tmp/test.log for the complete log from this test.
>
> However, I happened to notice something in dmesg around the same time
> 0 jan@muizenberg:/var/autofs/misc/home/jan$dmesg |grep pari
> [ 8319.576447] python[21505]: segfault at c40000007b ip 00007fee3338efa1 sp 00007fff95d79530 error 4 in libpari-gmp.so.2[7fee3319a000+2c6000]

Could the failure have been from another Sage session, i.e. not the one
doing the test? If all tests passed, I guess there was no segfault
during the tests (or something is wrong with the doctesting framework).

Jeroen.

[Jan Groenewald]

Hi

On Tue, Oct 12, 2010 at 02:12:58PM +0200, Jeroen Demeyer wrote:
> Could the failure have been from another Sage session, i.e. not the one
> doing the test? If all tests passed, I guess there was no segfault
> during the tests (or something is wrong with the doctesting framework).

There was no other sage running, nor pari.

I am currently waiting on another sage -testall on the same CPU.
It had no segfault in dmesg before, I will check after.

[Jan Groenewald]

Hi

Testall is currently this far...

sage -t "devel/sage/sage/coding/source_coding/all.py"
[0.0 s]
sage -t "devel/sage/sage/coding/source_coding/__init__.py"
[0.0 s]
sage -t "devel/sage/sage/coding/linear_code.py"

It is already there:

0 jan@capepoint:~$dmesg |grep pari
[ 8217.960337] python[12786]: segfault at 829 ip 00007feeafa24fa1 sp 00007ffff3d54b90 error 4 in libpari-gmp.so.2[7feeaf830000+2c6000]

0 root@capepoint:~/.sage/tmp#grep pari test.log
sage -t "devel/sage/doc/en/numerical_sage/comparison_to_cython.rst"
sage -t "devel/sage/doc/en/reference/sage/libs/pari/gen.rst"
sage -t "devel/sage/sage/rings/pari_ring.py"
sage -t "devel/sage/sage/rings/finite_rings/finite_field_ext_pari.py"
sage -t "devel/sage/sage/rings/finite_rings/element_ext_pari.py"
sage -t "devel/sage/sage/groups/pari_group.py"
sage -t "devel/sage/sage/libs/pari/setlvalue.pxi"
sage -t "devel/sage/sage/libs/pari/gen_py.py"
sage -t "devel/sage/sage/libs/pari/decl.pxi"
sage -t "devel/sage/sage/libs/pari/gen.pyx"
sage -t "devel/sage/sage/libs/pari/misc.pxi"
sage -t "devel/sage/sage/libs/pari/pari_err.pxi"
sage -t "devel/sage/sage/libs/pari/all.py"
sage -t "devel/sage/sage/libs/pari/gen.pxi"
sage -t "devel/sage/sage/libs/pari/to_gen.pxi"
sage -t "devel/sage/sage/libs/pari/__init__.py"

How do I run just those tests one by one?

[Jan Groenewald]

Hi

On Tue, Oct 12, 2010 at 03:34:46PM +0200, Jan Groenewald wrote:
> 0 root@capepoint:~/.sage/tmp#grep pari test.log
> sage -t "devel/sage/doc/en/numerical_sage/comparison_to_cython.rst"
> sage -t "devel/sage/doc/en/reference/sage/libs/pari/gen.rst"
> sage -t "devel/sage/sage/rings/pari_ring.py"
> sage -t "devel/sage/sage/rings/finite_rings/finite_field_ext_pari.py"
> sage -t "devel/sage/sage/rings/finite_rings/element_ext_pari.py"
> sage -t "devel/sage/sage/groups/pari_group.py"
> sage -t "devel/sage/sage/libs/pari/setlvalue.pxi"
> sage -t "devel/sage/sage/libs/pari/gen_py.py"
> sage -t "devel/sage/sage/libs/pari/decl.pxi"
> sage -t "devel/sage/sage/libs/pari/gen.pyx"
> sage -t "devel/sage/sage/libs/pari/misc.pxi"
> sage -t "devel/sage/sage/libs/pari/pari_err.pxi"
> sage -t "devel/sage/sage/libs/pari/all.py"
> sage -t "devel/sage/sage/libs/pari/gen.pxi"
> sage -t "devel/sage/sage/libs/pari/to_gen.pxi"
> sage -t "devel/sage/sage/libs/pari/__init__.py"
>
> How do I run just those tests one by one?

Particularly stupid question ;(

[Jason Grout]

Well, don't forget sage -t -verbose filename

Jason

[Jan Groenewald]

Hi

On Tue, Oct 12, 2010 at 03:38:02PM +0200, Jan Groenewald wrote:
> > 0 root@capepoint:~/.sage/tmp#grep pari test.log
> > sage -t "devel/sage/doc/en/numerical_sage/comparison_to_cython.rst"
> > sage -t "devel/sage/doc/en/reference/sage/libs/pari/gen.rst"
> > sage -t "devel/sage/sage/rings/pari_ring.py"
> > sage -t "devel/sage/sage/rings/finite_rings/finite_field_ext_pari.py"
> > sage -t "devel/sage/sage/rings/finite_rings/element_ext_pari.py"
> > sage -t "devel/sage/sage/groups/pari_group.py"
> > sage -t "devel/sage/sage/libs/pari/setlvalue.pxi"
> > sage -t "devel/sage/sage/libs/pari/gen_py.py"
> > sage -t "devel/sage/sage/libs/pari/decl.pxi"
> > sage -t "devel/sage/sage/libs/pari/gen.pyx"
> > sage -t "devel/sage/sage/libs/pari/misc.pxi"
> > sage -t "devel/sage/sage/libs/pari/pari_err.pxi"
> > sage -t "devel/sage/sage/libs/pari/all.py"
> > sage -t "devel/sage/sage/libs/pari/gen.pxi"
> > sage -t "devel/sage/sage/libs/pari/to_gen.pxi"
> > sage -t "devel/sage/sage/libs/pari/__init__.py"

Each of these was run again, they didn't produce a nother
segfault in dmesg.

How do I run testall but between each test grep for pari
in dmesg? Slightly better question, I hope.

regards,
Jan

[Jan Groenewald]

Hi

Found it.

root@capepoint:/usr/local/src#dmesg |grep pari | wc -l
6
root@capepoint:/usr/local/src#sage -t "devel/sage/sage/interfaces/sage0.py"
sage -t "devel/sage/sage/interfaces/sage0.py"
[8.8 s]
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 8.8 seconds
root@capepoint:/usr/local/src#dmesg |grep pari | wc -l
7
root@capepoint:/usr/local/src#grep pari sage-4.5.3/devel/sage/sage/interfaces/sage0.py
root@capepoint:/usr/local/src#dmesg |grep pari

[ 8217.960337] python[12786]: segfault at 829 ip 00007feeafa24fa1 sp 00007ffff3d54b90 error 4 in libpari-gmp.so.2[7feeaf830000+2c6000]

[19437.530957] python[25849]: segfault at c40000007b ip 00007f0025d20fa1 sp 00007fffe064cc30 error 4 in libpari-gmp.so.2[7f0025b2c000+2c6000]
[19667.892196] python[27756]: segfault at ce0000004d ip 00007f1bac66cfa1 sp 00007fff33dc6f60 error 4 in libpari-gmp.so.2[7f1bac478000+2c6000]
[19701.671539] python[27899]: segfault at c40000007b ip 00007fb46633cfa1 sp 00007fff7a98c630 error 4 in libpari-gmp.so.2[7fb466148000+2c6000]
[19733.153146] python[28179]: segfault at c40000007b ip 00007f6c3c660fa1 sp 00007ffff9fe5870 error 4 in libpari-gmp.so.2[7f6c3c46c000+2c6000]
[19751.111347] python[28333]: segfault at 1500000073 ip 00007f2db936cfa1 sp 00007fff95817960 error 4 in libpari-gmp.so.2[7f2db9178000+2c6000]
[19768.130679] python[28476]: segfault at 72000000ae ip 00007fc0e4e47fa1 sp 00007fff06aa9920 error 4 in libpari-gmp.so.2[7fc0e4c53000+2c6000]
root@capepoint:/usr/local/src#

regards,

[Jan Groenewald]

Hi

On Tue, Oct 12, 2010 at 05:28:45PM +0200, Jan Groenewald wrote:
> root@capepoint:/usr/local/src#sage -t "devel/sage/sage/interfaces/sage0.py"
> sage -t "devel/sage/sage/interfaces/sage0.py"
> [8.8 s]
> ----------------------------------------------------------------------
> All tests passed!
> Total time for all tests: 8.8 seconds
> root@capepoint:/usr/local/src#dmesg |grep pari

> [ 8217.960337] python[12786]: segfault at 829 ip 00007feeafa24fa1 sp 00007ffff3d54b90 error 4 in libpari-gmp.so.2[7feeaf830000+2c6000]

This is the piece of sage0.py that causes the segfault:

We can have the child interpreter itself make another child Sage
process, so now three copies of Sage are running::

sage: s3 = s('Sage()')
sage: a = s3(10)
sage: a
10

This `a=10` is in a subprocess of a subprocesses of your
original Sage.

Specifically, the line sage: a = s3(10). Not before, creating the subsubprocess
is OK, but USING it is a pari segfault. But not always, e.g. this passes and no
segfault either:

sage: s3 = s('Sage()')
sage: s3.parent()
Sage

Running the following manually in a normal sage shell (not via sage -t) does
NOT cause a segfault:

s = Sage()
s3 = s('Sage()')
a = s3(10)

So it has something to do with the way it is called via sage -t?
Same result for an 10, 1, 1.0, or 'true' in the last line: when
called via sage -t I get the segfault in dmesg.

Also, in a sage shell,

s = Sage()
s. #<-- tab autocompletion works
s3 = s('Sage()')
s3. #<-- tab autocomplation hangs, keyboardinterrupt breaks it.
s3.AA? #<-- works OK

Tasty.

regards,
Jan

[Jan Groenewald]

Hi

On Wed, Oct 13, 2010 at 10:35:44AM +0200, Jan Groenewald wrote:
> > root@capepoint:/usr/local/src#sage -t "devel/sage/sage/interfaces/sage0.py"
> > sage -t "devel/sage/sage/interfaces/sage0.py"
> > [8.8 s]
> > ----------------------------------------------------------------------
> > All tests passed!
> > Total time for all tests: 8.8 seconds
> > root@capepoint:/usr/local/src#dmesg |grep pari
> > [ 8217.960337] python[12786]: segfault at 829 ip 00007feeafa24fa1 sp 00007ffff3d54b90 error 4 in libpari-gmp.so.2[7feeaf830000+2c6000]

This problem persists with
1) a newly compiled sage 4.5.3 (64bit) without the 4 patches and without any optional packages
2) a precompiled tarball sage-4.5.3-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux

root@capepoint:/usr/local/src/sage-4.5.3-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux#dmesg |grep pari|wc -l
37
root@capepoint:/usr/local/src/sage-4.5.3-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux#sage -t "devel/sage/sage/interfaces/sage0.py"
sage -t "devel/sage/sage/interfaces/sage0.py"
[8.9 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 8.9 seconds
root@capepoint:/usr/local/src/sage-4.5.3-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux#dmesg |grep pari|wc -l38
root@capepoint:/usr/local/src/sage-4.5.3-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux#

Perhaps someone can test this on 32bit, another CPU, etc. I will get
a hold of some laptops for other CPU testing. Can anyone else even
reproduce this?

[mhampton]

This doesn't seem to happen on OS X 10.6, but on linux (Ubuntu 9.10,
on an intel i7 860) I get:

sudo dmesg |grep pari
[1137442.823450] python[25794]: segfault at 429 ip 00007fba72ee2de1 sp
00007fffa33e3530 error 4 in libpari-gmp.so.2[7fba72cee000+2c6000]
[1352579.933964] python[17881] general protection ip:7f28db8a3de1 sp:
7fff4734ea20 error:0 in libpari-gmp.so.2[7f28db6af000+2c6000]
[3048340.378550] python[4559]: segfault at 1500000073 ip
00007fa58d664de1 sp 00007fff0a77ba50 error 4 in libpari-gmp.so.
2[7fa58d470000+2c6000]

-Marshall

[mhampton]

I should have also mentioned that this was on sage-4.6.alpha3, so the
problem is still there.

[Jan Groenewald]

Hi Marshall

On Thu, Oct 14, 2010 at 04:40:43AM -0700, mhampton wrote:
> This doesn't seem to happen on OS X 10.6, but on linux (Ubuntu 9.10,
> on an intel i7 860) I get:
>
> sudo dmesg |grep pari
> [1137442.823450] python[25794]: segfault at 429 ip 00007fba72ee2de1 sp
> 00007fffa33e3530 error 4 in libpari-gmp.so.2[7fba72cee000+2c6000]
> [1352579.933964] python[17881] general protection ip:7f28db8a3de1 sp:
> 7fff4734ea20 error:0 in libpari-gmp.so.2[7f28db6af000+2c6000]
> [3048340.378550] python[4559]: segfault at 1500000073 ip
> 00007fa58d664de1 sp 00007fff0a77ba50 error 4 in libpari-gmp.so.
> 2[7fa58d470000+2c6000]

Is this on a 32bit or 64bit install?
From source or from a tarball?

[mhampton]

Its 64-bit linux, built from the sage-4.6.alpha3 source.

-Marshall

[Jan Groenewald]

Hi

Summary: On a mixture of sage 4.5.2, 4.5.3, and 4.6alpha3

Linux:
i7 64bit: sefgault
E8400 64bit: segfault
T4300 64bit: segfault
T3200 64bit: segfault
T2300 32bit: no segfault

OS X 10.6 (Marshall: 32 or 64 bit?): no segfault

Conjecture: It is a Linux specific 64bit problem.

Can some people on 32bit and 64bit and different CPUs (amd as well)
send in the output of

grep name /proc/cpuifo
uname -a
sage -v
sage -t devel/sage/sage/interfaces/sage0.py
dmesg|grep pari

[Jason Grout]

On 10/15/10 2:48 AM, Jan Groenewald wrote:
> Hi
>
> Summary: On a mixture of sage 4.5.2, 4.5.3, and 4.6alpha3
>
> Linux:
> i7 64bit: sefgault
> E8400 64bit: segfault
> T4300 64bit: segfault
> T3200 64bit: segfault
> T2300 32bit: no segfault
>
> OS X 10.6 (Marshall: 32 or 64 bit?): no segfault
>
> Conjecture: It is a Linux specific 64bit problem.
>
> Can some people on 32bit and 64bit and different CPUs (amd as well)
> send in the output of
>
> grep name /proc/cpuifo
> uname -a
> sage -v
> sage -t devel/sage/sage/interfaces/sage0.py
> dmesg|grep pari
>

~/sage% grep name /proc/cpuinfo
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
~/sage% uname -a
Linux good 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010
x86_64 GNU/Linux
~/sage% sage -v
| Sage Version 4.6.alpha2, Release Date: 2010-09-29 |
* Warning: this is a prerelease version, and it may be unstable. *
~/sage% sage -t devel/sage/sage/interfaces/sage0.py
sage -t "4.6.alpha2/devel/sage/sage/interfaces/sage0.py"
[17.7 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 17.8 seconds
~/sage% dmesg|grep pari
~/sage%

With 4.6.alpha3 (same system):

~/sage-4.6.alpha3% ./sage -v
| Sage Version 4.6.alpha3, Release Date: 2010-10-08 |
* Warning: this is a prerelease version, and it may be unstable. *
grout@good:~/sage-4.6.alpha3% ./sage -t devel/sage/sage/interfaces/sage0.py
sage -t "devel/sage/sage/interfaces/sage0.py"
[16.8 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 16.9 seconds
~/sage-4.6.alpha3% dmesg|grep pari
~/sage-4.6.alpha3%

Hope that helps.

Jason

--
Jason Grout

[Jan Groenewald]

Hi

On Fri, Oct 15, 2010 at 03:02:07AM -0500, Jason Grout wrote:
> Hope that helps.

So it is NOT 64bit specific. Perhaps it is Ubuntu specific.

[Jan Groenewald]

Hi

> On Fri, Oct 15, 2010 at 03:02:07AM -0500, Jason Grout wrote:
> > Hope that helps.
>
> So it is NOT 64bit specific. Perhaps it is Ubuntu specific.

Uhm no, Jason had ubuntu there.

[Jeroen Demeyer]

Also, I can NOT reproduce the segfault on the following system with
sage-4.6.alpha3:

$ Linux arcanis 2.6.32-gentoo-r7 #5 SMP Thu Jun 10 23:07:26 CEST 2010
x86_64 Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz GenuineIntel GNU/Linux
$ gcc --version
gcc-4.4.3 (Gentoo 4.4.3-r2 p1.2) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.

Jeroen.

[Jason Grout]

On 10/15/10 3:15 AM, Jan Groenewald wrote:
> Hi
>
>> On Fri, Oct 15, 2010 at 03:02:07AM -0500, Jason Grout wrote:
>>> Hope that helps.
>>
>> So it is NOT 64bit specific. Perhaps it is Ubuntu specific.
>
> Uhm no, Jason had ubuntu there.
>

10.04.1, I believe.

Thanks,

Jason

[mhampton]

One more data point: on Ubuntu 10.10, sage-4.6.alpha3,
grep /proc/cpuinfo
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
uname -a:
Linux sancho 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC
2010 x86_64 GNU/Linu

I do not get the segfault.

-Marshall

[Jan Groenewald]

Hi

As I've had one external confirmation, more than one
sage version, and several laptops here, I'll continue to think
about this.

Looking for libpari-gmp.so, I found these:
root@capepoint:/usr/local/src/sage-4.5.3/local/lib#ls -l libpari*
-rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari-gmp.so.2
-rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari-gmp.so.2.3.5
-rw-r--r-- 1 root root 5011724 Oct 11 17:06 libpari.a
-rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari.so
root@capepoint:/usr/local/src/sage-4.5.3/local/lib#

How come they are not symlinks to one? Why three copies
of the same thing?

Would it help to somehow turn on debugging info from
libpari-gmp.so? Not sure how yet...

[John Cremona]

On two different 64-bit ubuntu machines:

1 works fine:

jec@fermat%uname -a
Linux fermat 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC
2010 x86_64 GNU/Linux
jec@fermat% sage -v

| Sage Version 4.6.alpha3, Release Date: 2010-10-08 |
* Warning: this is a prerelease version, and it may be unstable. *

jec@fermat% sage -t devel/sage/sage/interfaces/sage0.py
sage -t "devel/sage/sage/interfaces/sage0.py"

[13.8 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 13.8 seconds
jec@fermat% dmesg|grep pari
jec@fermat%

1 does not:

jec@selmer%grep name /proc/cpuinfo | uniq
model name : Quad-Core AMD Opteron(tm) Processor 8378
jec@selmer%uname -a
Linux selmer 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC
2009 x86_64 GNU/Linux
jec@selmer% sage -v

| Sage Version 4.6.alpha3, Release Date: 2010-10-08 |
* Warning: this is a prerelease version, and it may be unstable. *

jec@selmer% sage -t devel/sage/sage/interfaces/sage0.py
sage -t "devel/sage/sage/interfaces/sage0.py"
[11.5 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 11.5 seconds
jec@selmer% dmesg|grep pari
[8562085.592129] gp[1128] trap invalid opcode ip:7f7f003b5be7
sp:7fff08dcd840 error:0 in libpari-gmp-2.4.so.3[7f7f000d3000+421000]
[8562093.886034] gp[26164] trap invalid opcode ip:7fafab0bdbe7
sp:7fffb3ad7540 error:0 in libpari-gmp-2.4.so.3[7fafaaddb000+421000]

John

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

[Jeroen Demeyer]

Very strange that these errors do not result in a failing doctest...

John, Jan:

On the failing machines, could you install the PARI spkg with checking
enabled? i.e. please do

env SAGE_CHECK=yes ./sage -f
http://sage.math.washington.edu/home/release/sage-4.6.alpha3/sage-4.6.alpha3/spkg/standard/pari-2.4.3.svn-12577.p7.spkg

Note that this might mess up your Sage installation, so do this only on
a copy of Sage that you don't need anymore.

Jeroen.

[John Cremona]

After doing that the doctest still passes, and I still get

jec@selmer%dmesg|grep pari

[8562085.592129] gp[1128] trap invalid opcode ip:7f7f003b5be7
sp:7fff08dcd840 error:0 in libpari-gmp-2.4.so.3[7f7f000d3000+421000]
[8562093.886034] gp[26164] trap invalid opcode ip:7fafab0bdbe7
sp:7fffb3ad7540 error:0 in libpari-gmp-2.4.so.3[7fafaaddb000+421000]

but I think these are the same messages as before, so things are now working?

John

[Jeroen Demeyer]

On 2010-10-17 20:09, John Cremona wrote:
> After doing that the doctest still passes, and I still get
>
> jec@selmer%dmesg|grep pari
> [8562085.592129] gp[1128] trap invalid opcode ip:7f7f003b5be7
> sp:7fff08dcd840 error:0 in libpari-gmp-2.4.so.3[7f7f000d3000+421000]
> [8562093.886034] gp[26164] trap invalid opcode ip:7fafab0bdbe7
> sp:7fffb3ad7540 error:0 in libpari-gmp-2.4.so.3[7fafaaddb000+421000]
>
> but I think these are the same messages as before, so things are now working?

If that's the code, I absolutely have no explanation for this. The
newly installed spkg should be the same as the old, so...???

Jeroen

[Rob Beezer]

Two data points:

Sage 4.5.2.alpha0, Sage 4.6.alpha0 32-bit, no segfault on either

everything else is the same for both:

model name : Intel(R) Pentium(R) M processor 2.00GHz

Linux atoll 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC
2010 i686 GNU/Linux


sage -t "devel/sage/sage/interfaces/sage0.py"
[39.9 s]
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 40.0 seconds

[Jan Groenewald]

Hi

I still get the segfault with the new spkg.

John's result is perhaps valuable. I don't know how.

[Ben Goodrich]

On Oct 15, 3:48 am, Jan Groenewald <j...@aims.ac.za> wrote:
> Can some people on 32bit and 64bit and different CPUs (amd as well)
> send in the output of

64bit Debian here, no problem

goodrich@Y560:/media/disk30/sage-4.6.alpha3$ grep name /proc/cpuinfo
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
goodrich@Y560:/media/disk30/sage-4.6.alpha3$ uname -a
Linux Y560 2.6.35-7.slh.1-aptosid-amd64 #1 SMP PREEMPT Wed Sep 29
02:30:35 UTC 2010 x86_64 GNU/Linux
goodrich@Y560:/media/disk30/sage-4.6.alpha3$ ./sage -v

| Sage Version 4.6.alpha3, Release Date: 2010-10-08 |
* Warning: this is a prerelease version, and it may be unstable. *

goodrich@Y560:/media/disk30/sage-4.6.alpha3$ ./sage -t devel/sage/sage/
interfaces/sage0.py
sage -t "devel/sage/sage/interfaces/
sage0.py"
[26.3

s]

----------------------------------------------------------------------
All tests passed!

Total time for all tests: 26.5 seconds
goodrich@Y560:/media/disk30/sage-4.6.alpha3$ dmesg | grep pari
[167793.880983] ACPI: Preparing to enter system sleep state S3
[201102.253580] ACPI: Preparing to enter system sleep state S3
[253592.296030] ACPI: Preparing to enter system sleep state S3
[254532.778486] ACPI: Preparing to enter system sleep state S3
goodrich@Y560:/media/disk30/sage-4.6.alpha3$

Ben

[Jan Groenewald]

Hi

On Sun, Oct 17, 2010 at 09:37:55AM +0200, Jan Groenewald wrote:
> Looking for libpari-gmp.so, I found these:
> root@capepoint:/usr/local/src/sage-4.5.3/local/lib#ls -l libpari*
> -rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari-gmp.so.2
> -rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari-gmp.so.2.3.5
> -rw-r--r-- 1 root root 5011724 Oct 11 17:06 libpari.a
> -rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari.so
> root@capepoint:/usr/local/src/sage-4.5.3/local/lib#
>
> How come they are not symlinks to one? Why three copies
> of the same thing?
>

Also, why does this depend on the system libgmp and not the sage libgmp?

root@capepoint:/usr/local/src/sage-4.5.3/local/lib#ldd libpari-gmp.so.2
linux-vdso.so.1 => (0x00007fff3a5ff000)
libc.so.6 => /lib/libc.so.6 (0x00007f1ecb41b000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f1ecb217000)
libm.so.6 => /lib/libm.so.6 (0x00007f1ecaf93000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f1ecad33000) #<-- over here
/lib64/ld-linux-x86-64.so.2 (0x00007f1ecbcca000)
root@capepoint:/usr/local/src/sage-4.5.3/local/lib#ls -l libgmp.so.3
lrwxrwxrwx 1 root root 15 Sep 13 08:19 libgmp.so.3 -> libgmp.so.3.4.6
root@capepoint:/usr/local/src/sage-4.5.3/local/lib#

[Jeroen Demeyer]

On 2010-10-18 13:43, Jan Groenewald wrote:
> Also, why does this depend on the system libgmp and not the sage libgmp?

This depends on the setting of LD_LIBRARY_FLAG. If you do the same
within "sage -sh" you should get the correct library.

[François Bissey]

Did you do a "source local/bin/sage-env" before running ldd?

Francois

[Jan Groenewald]

Hi

OK, right

SAGE_ROOT=/usr/local/src/sage-4.5.3
(sage subshell) capepoint:lib root$ ldd libpari-gmp.so.2
linux-vdso.so.1 => (0x00007fff9dd55000)
libc.so.6 => /lib/libc.so.6 (0x00007f2efbfb6000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f2efbdb2000)
libm.so.6 => /lib/libm.so.6 (0x00007f2efbb2e000)
libgmp.so.3 => /usr/local/src/sage-4.5.3/local/lib/libgmp.so.3 (0x00007f2efb8bc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2efc85e000)
SAGE_ROOT=/usr/local/src/sage-4.5.3
(sage subshell) capepoint:lib root$

Thanks

[Jason Grout]

As an offhand idea, with the disclaimer that I haven't read this entire
thread, but an idea that has caused such problems before. Did you move
the Sage directory? There are still lots of loose ends that are left
dangling when the build directory is used (or a binary distribution is
used) (e.g., the pkgconfig files that #9210 takes care of).

Sorry if this is noise. Thanks,

Jason

[Jan Groenewald]

Hi

On Mon, Oct 18, 2010 at 07:28:23AM -0500, Jason Grout wrote:
> As an offhand idea, with the disclaimer that I haven't read this
> entire thread, but an idea that has caused such problems before.
> Did you move the Sage directory? There are still lots of loose ends
> that are left dangling when the build directory is used (or a binary
> distribution is used) (e.g., the pkgconfig files that #9210 takes
> care of).

Nope, sorry.

[Jan Groenewald]

Hi

On Sun, Oct 17, 2010 at 07:16:58PM +0200, Jeroen Demeyer wrote:
> env SAGE_CHECK=yes ./sage -f
> http://sage.math.washington.edu/home/release/sage-4.6.alpha3/sage-4.6.alpha3/spkg/standard/pari-2.4.3.svn-12577.p7.spkg

This still caused a segfault for me in dmesg while doctests pass.
Is SAGE_CHECK supposed to give more output? Where?
Can I have pari give more output? I'm just guessing wildly here:

root@capepoint:~#cd /usr/local/src/sage-4.5.3/spkg/standard/
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#tar xjf pari-2.3.5.p4.spkg
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#cd pari-2.3.5.p4/
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#grep -ri "DEBUGLEVEL = " *
src/src/language/init.c: DEBUGFILES = DEBUGLEVEL = DEBUGMEM = 0;
src/src/language/init.c: if (oldval >= 0) { DEBUGLEVEL = oldval; oldval = -1; }
src/src/language/init.c: { oldval = DEBUGLEVEL; DEBUGLEVEL = val; }
src/src/functions/programming/default: ("debug",small):small:parens DEBUGLEVEL = $2
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#sed -i 's/DEBUGFILES = DEBUGLEVEL = DEBUGMEM = 0;/DEBUGFILES = DEBUGLEVEL = DEBUGMEM = 9;/' src/src/language/init.c
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#cd ../
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#sage -spkg pari-2.3.5.p4
Creating Sage package pari-2.3.5.p4
...
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#env SAGE_CHECK=yes sage -f pari-2.3.5.p4.spkg
Force installing pari-2.3.5.p4.spkg
...
Finished installing pari-2.3.5.p4.spkg
root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#dmesg|grep segfault|wc -l; sage -t devel/sage/sage/interfaces/sage0.py; dmesg|grep segfault
0
sage -t "devel/sage/sage/interfaces/sage0.py"
[18.2 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 18.2 seconds
[79234.381854] python[17992]: segfault at 72000000ae ip 00007f3fce620fa1 sp 00007fff0a28cbe0 error 4 in libpari-gmp.so.2[7f3fce42c000+2c6000]

Even if it is slow, is there a way to tell pari to write some output
somewhere?

[John Cremona]

Setting SAGE_CHECK=yes just means that after building the pari
library, the self-test routines are also run. It does not affect Sage
after the new spkg is installed.

John

[Mitesh Patel]

On Sun, Oct 17, 2010 at 07:16:58PM +0200, Jeroen Demeyer wrote:
> root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#env SAGE_CHECK=yes sage -f pari-2.3.5.p4.spkg
> Force installing pari-2.3.5.p4.spkg
> ...
> Finished installing pari-2.3.5.p4.spkg
> root@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#dmesg|grep segfault|wc -l; sage -t devel/sage/sage/interfaces/sage0.py; dmesg|grep segfault
> 0
> sage -t "devel/sage/sage/interfaces/sage0.py"
> [18.2 s]
>
> ----------------------------------------------------------------------
> All tests passed!
> Total time for all tests: 18.2 seconds
> [79234.381854] python[17992]: segfault at 72000000ae ip 00007f3fce620fa1 sp 00007fff0a28cbe0 error 4 in libpari-gmp.so.2[7f3fce42c000+2c6000]
>
> Even if it is slow, is there a way to tell pari to write some output
> somewhere?

Would it help to try again with a PARI compiled with less aggressive
optimizations than our default -O3? For example,

env SAGE_DEBUG=yes ./sage -f pari-2.3.5.p4.spkg
dmesg | grep segfault | wc -l
./sage -t devel/sage/sage/interfaces/sage0.py
dmesg | grep segfault

[leif]

On 14 Okt., 13:40, mhampton <hampto...@gmail.com> wrote:
> This doesn't seem to happen on OS X 10.6, but on linux (Ubuntu 9.10,
> on an intel i7 860) I get:
>
> sudo dmesg |grep pari
> [1137442.823450] python[25794]: segfault at 429 ip 00007fba72ee2de1 sp
> 00007fffa33e3530 error 4 in libpari-gmp.so.2[7fba72cee000+2c6000]
> [1352579.933964] python[17881] general protection ip:7f28db8a3de1 sp:
> 7fff4734ea20 error:0 in libpari-gmp.so.2[7f28db6af000+2c6000]
> [3048340.378550] python[4559]: segfault at 1500000073 ip
> 00007fa58d664de1 sp 00007fff0a77ba50 error 4 in libpari-gmp.so.
> 2[7fa58d470000+2c6000]
>

> -Marshall

One should mention that this is with the *old* PARI (libpari-gmp.so*),
though Marshall said it happened with Sage 4.6.alpha3, which includes
the new PARI (libpari-gmp-2.4.so*).

Cf. #9896.

With 4.6.alpha3 built from scratch (or updated via one of the test
upgrade paths at #9896) this shouldn't occur.


-Leif

[leif]

On 15 Okt., 09:48, Jan Groenewald <j...@aims.ac.za> wrote:
> Summary: On a mixture of sage 4.5.2, 4.5.3, and 4.6alpha3
>
> Linux:
> i7 64bit: sefgault
> E8400 64bit: segfault
> T4300 64bit: segfault
> T3200 64bit: segfault
> T2300 32bit: no segfault
>
> OS X 10.6 (Marshall: 32 or 64 bit?): no segfault
>
> Conjecture: It is a Linux specific 64bit problem.
>
> Can some people on 32bit and 64bit and different CPUs (amd as well)
> send in the output of
>
>    grep name /proc/cpuifo
>    uname -a
>    sage -v
>    sage -t devel/sage/sage/interfaces/sage0.py
>    dmesg|grep pari

Summary:

I didn't get any segfaults with Sage 4.6.{alpha*,rc0}, upgraded or
built from scratch on

* Ubuntu 9.04 x86 (32-bit Pentium 4 Prescott, gcc 4.3.3)

* Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3)

* Ubuntu 10.04 x86_64 (Core2, gcc 4.4.3)

(I've built or upgraded to these dozens of times on those
machines... ;-) )

Those people getting the segfaults should perhaps delete $SAGE_ROOT/
local/lib/libpari-gmp.* if they exist, rerun the doctests and see if
they really get /new/ messages from dmesg. (I personally rarely reboot
my machines; "sudo dmesg -c" clears previous logs.)


-Leif

[leif]

On 23 Okt., 16:42, leif <not.rea...@online.de> wrote:
> On 15 Okt., 09:48, Jan Groenewald <j...@aims.ac.za> wrote:
>
>
>
> > Summary: On a mixture of sage 4.5.2, 4.5.3, and 4.6alpha3
>
> > Linux:
> > i7 64bit: sefgault
> > E8400 64bit: segfault
> > T4300 64bit: segfault
> > T3200 64bit: segfault
> > T2300 32bit: no segfault
>
> > OS X 10.6 (Marshall: 32 or 64 bit?): no segfault
>
> > Conjecture: It is a Linux specific 64bit problem.
>
> > Can some people on 32bit and 64bit and different CPUs (amd as well)
> > send in the output of
>
> >    grep name /proc/cpuifo
> >    uname -a
> >    sage -v
> >    sage -t devel/sage/sage/interfaces/sage0.py
> >    dmesg|grep pari
>
> Summary:
>
> I didn't get any segfaults with Sage 4.6.{alpha*,rc0}, upgraded or
> built from scratch on
>
>  * Ubuntu 9.04 x86 (32-bit Pentium 4 Prescott, gcc 4.3.3)
>
>  * Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3)
>
>  * Ubuntu 10.04 x86_64 (Core2, gcc 4.4.3)
>

P.S.: For Sage *4.5.3* (all built from scratch), I also get the
segfault when testing sage/interfaces/sage0.py on the latter system,
but *not* on the first or second.

(The difference between the second and the third system is only the OS
version and the GCC version; Sage was compiled with the same settings
on both of these.)


-Leif

[Jan Groenewald]

Hi

On Sat, Oct 23, 2010 at 10:26:45AM -0700, leif wrote:
> >  * Ubuntu 9.04 x86 (32-bit Pentium 4 Prescott, gcc 4.3.3)
> >  * Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3)
> >  * Ubuntu 10.04 x86_64 (Core2, gcc 4.4.3)
>
> P.S.: For Sage *4.5.3* (all built from scratch), I also get the
> segfault when testing sage/interfaces/sage0.py on the latter system,
> but *not* on the first or second.
>
> (The difference between the second and the third system is only the OS
> version and the GCC version; Sage was compiled with the same settings
> on both of these.)

All confirmations of the segfault have been on ubuntu 9.10 or ubuntu 10.04
using sage 4.5.2 to 4.6.X and on 64bit.

It would be interesting, on the same hardware, to try Ubuntu 10.10.
I'm not sure I'll get around to that this week.

[Jan Groenewald]

Hi

On Fri, Oct 22, 2010 at 05:30:35PM -0500, Mitesh Patel wrote:
> Would it help to try again with a PARI compiled with less aggressive
> optimizations than our default -O3? For example,
>
> env SAGE_DEBUG=yes ./sage -f pari-2.3.5.p4.spkg
> dmesg | grep segfault | wc -l
> ./sage -t devel/sage/sage/interfaces/sage0.py
> dmesg | grep segfault

Does SAGE_DEBUG=yes lower -O3 to -O2?

Tests still pass, and I still get the segfault.

[Jeroen Demeyer]

On 2010-10-24 16:07, Jan Groenewald wrote:
> Does SAGE_DEBUG=yes lower -O3 to -O2?

Actually, -O0

[Jan Groenewald]

Hi

After some ubuntu 10.04.1 upgrades:

Aptitude 0.4.11.11: log report
Sun, Oct 24 2010 16:00:35 +0200

IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.

Will install 14 packages, and remove 0 packages.
4096B of disk space will be used
===============================================================================
[UPGRADE] comerr-dev 2.1-1.41.11-1ubuntu2 -> 2.1-1.41.11-1ubuntu2.1
[UPGRADE] e2fslibs 1.41.11-1ubuntu2 -> 1.41.11-1ubuntu2.1
[UPGRADE] e2fsprogs 1.41.11-1ubuntu2 -> 1.41.11-1ubuntu2.1
[UPGRADE] libc-bin 2.11.1-0ubuntu7.4 -> 2.11.1-0ubuntu7.5
[UPGRADE] libc-dev-bin 2.11.1-0ubuntu7.4 -> 2.11.1-0ubuntu7.5
[UPGRADE] libc6 2.11.1-0ubuntu7.4 -> 2.11.1-0ubuntu7.5
[UPGRADE] libc6-dev 2.11.1-0ubuntu7.4 -> 2.11.1-0ubuntu7.5
[UPGRADE] libc6-i386 2.11.1-0ubuntu7.4 -> 2.11.1-0ubuntu7.5
[UPGRADE] libcomerr2 1.41.11-1ubuntu2 -> 1.41.11-1ubuntu2.1
[UPGRADE] libss2 1.41.11-1ubuntu2 -> 1.41.11-1ubuntu2.1
[UPGRADE] nscd 2.11.1-0ubuntu7.4 -> 2.11.1-0ubuntu7.5
[UPGRADE] python-papyon 0.4.8-0ubuntu1 -> 0.4.8-0ubuntu2
[UPGRADE] update-manager 1:0.134.10 -> 1:0.134.11
[UPGRADE] update-manager-core 1:0.134.10 -> 1:0.134.11
===============================================================================

Log complete.

The segfault no longer occurs on *every* run of sage -t devel/sage/sage/interfaces/sage0.py,
only on *most* runs. With sage-4.5.3 I got 70 segfaults in 83 runs. I'm pretty sure before
these upgrades every run of sage -t caused a segfault. ICBW.

On another desktop I did sage -upgrade http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
and afterwards out of 100+ runs no segfault.

I guess we'll never know now.

[leif]

On 25 Okt., 16:03, Jan Groenewald <j...@aims.ac.za> wrote:
> On another desktop I did sage -upgrade http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
> and afterwards out of 100+ runs no segfault.

That's expected, since doing the above rebuilds all packages and
modules depending on PARI, s.t. they'll use libpari-2.4.so*
(regardless of libpari.so*, the old one, still being present, too).


-Leif