Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#22280 closed defect (fixed)

Giac miscompiles on non-x86_64 platforms

Reported by: jpflori Owned by:
Priority: blocker Milestone: sage-8.0
Component: packages: standard Keywords:
Cc: rws, frederichan, vbraun Merged in:
Authors: Jean-Pierre Flori Reviewers: Thierry Monteil, Jean-Pierre Flori, François Bissey
Report Upstream: Fixed upstream, in a later stable release. Work issues:
Branch: 8dc4c88 (Commits) Commit:
Dependencies: #22101 Stopgaps:

Description (last modified by jpflori)

Executing 1+1 with giac-1.2.2.103 on ppc64le POWER8:

0>> 1+1;
[New Thread 0x3fff7443f180 (LWP 173710)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fff7443f180 (LWP 173710)]
0x00003fffb7b9e544 in giac::gen::in_eval (this=0x3fff7443e768, level=25, evaled=..., contextptr=0x3fffffffda40) at gen.cc:2109
2109              evaled=(*_SYMBptr->sommet.ptr())(evaled,contextptr);
(gdb) bt
#0  0x00003fffb7b9e544 in giac::gen::in_eval (this=0x3fff7443e768, level=25, evaled=..., contextptr=0x3fffffffda40) at gen.cc:2109
#1  0x00003fffb7b9bcdc in giac::gen::eval (this=0x3fff7443e768, level=25, contextptr=0x3fffffffda40) at gen.cc:1899
#2  0x00003fffb789e6ac in giac::protecteval (g=..., level=25, contextptr=0x3fffffffda40) at prog.cc:6881
#3  0x00003fffb767ff44 in giac::in_thread_eval (arg=0x100a9cd8) at global.cc:3463
#4  0x00003fffb5b18070 in start_thread () from /lib/powerpc64le-linux-gnu/libpthread.so.0
#5  0x00003fffb5763230 in clone () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) list
2104              evaled=_SYMBptr->feuille;
2105            }
2106            if (is_ifte)
2107              evaled=ifte(evaled,true,contextptr);
2108            else
2109              evaled=(*_SYMBptr->sommet.ptr())(evaled,contextptr);
2110            elevel=slevel;
2111          }
2112          else
2113            evaled=_SYMBptr->eval(level,contextptr);

Upgrading to giac-1.2.3.25 (#22101) does not fix this problem.


Use > -45 version: The upstream tarball is at http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.2.3-47.tar.gz Repackaged tarball is at:

And pass -Dx86_64 in CPPFLAGS.

Attachments (1)

giac-1.2.2.103.log.7.6.rc0 (773.3 KB) - added by tmonteil 4 years ago.

Download all attachments as: .zip

Change History (81)

comment:1 Changed 4 years ago by fbissey

I can confirm the issue. The trick fells very dirty but I can easily test it I think.

comment:2 Changed 4 years ago by fbissey

  • Description modified (diff)

Has expected passing -D__x86_64__ -DSMARTPTR64 choke the build. Fails as soon as we load gmp headers which complain about the ABI being unsupported. Now by default the thing builds but fails in calling pari. We could temporarily disable building against pari on non x86 (--disable-pari in giac-1.2.3-13).

More fundamentally I suspect the way pari is called is what is really wrong here, as discussed on sage-packaging https://groups.google.com/d/msgid/sage-packaging/ac9575ae-4dd3-4d29-97aa-a3ef785d3509%40googlegroups.com

comment:3 Changed 4 years ago by frederichan

I don't know if it helps but the 1.2.3.25 version such as in #22101 contains the modifications for pari asked there:

http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1776

comment:4 Changed 4 years ago by fbissey

Still failing. Those changes are, I think are a progress but not the full changes that are needed - not that I would really be able to do them myself. The fact that we still have

#ifdef ENABLE_TLS
  extern THREAD void *PARI_stack_limit;
#else
   extern void *PARI_stack_limit;
#endif

which is a private function is a sign you are doing something wrong.

comment:5 Changed 4 years ago by jdemeyer

See http://pari.math.u-bordeaux.fr/archives/pari-users-1702/msg00002.html for a suggestion from the PARI developers on how this should be fixed.

comment:6 Changed 4 years ago by jdemeyer

  • Cc frederichan added
  • Description modified (diff)

(1) What does this refer to:

One can maybe cheat and pass -D__x86_64__ -DSMARTPTR64 in CPPFLAGS but that's dirty, see:

(2) From the comments it seems that you think that there is a problem with PARI. Why do you think that?

comment:7 Changed 4 years ago by jdemeyer

  • Description modified (diff)

comment:8 Changed 4 years ago by jdemeyer

Note that compiling with -D__x86_64__ obviously does not work due to the use of inline assembly in ifactor.cc.

comment:9 Changed 4 years ago by jdemeyer

And compiling with -DSMARTPTR64 (whatever that means) does not change anything.

comment:10 Changed 4 years ago by frederichan

There is a related topic (about SMARTPTR64 that should not be undefined by first.h)here: http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1785

comment:11 follow-up: Changed 4 years ago by tmonteil

  • Priority changed from critical to blocker

I am not sure if it is the same error, but i cannot build+check giac on Debian Jessie 32bits, see the attached log. It fails at chk_fhan1 and before there are tons of "bug in PARI/GP (Segmentation Fault), please report."

Since giac is a standard package, i set the priority to blocker.

Changed 4 years ago by tmonteil

comment:12 in reply to: ↑ 11 Changed 4 years ago by frederichan

Replying to tmonteil:

I am not sure if it is the same error, but i cannot build+check giac on Debian Jessie 32bits, see the attached log. It fails at chk_fhan1 and before there are tons of "bug in PARI/GP (Segmentation Fault), please report."

Since giac is a standard package, i set the priority to blocker.

On linux 32bits there is the following problem #22101 and it should be already solved by giac-1.2.3.25 but I am waiting the next one to have a new config.guess as it was requested in #22101.

comment:13 Changed 4 years ago by vbraun

Unless something happens real soon I'll ignore this for sage 7.6. If it isn't fixed we should think about downgrading giac to optional.

The snippet in the description is hopefully not repesentative of the giac code quality:

  • Randomly mixed French / English names for identifiers.
  • Use of reserved identifiers (starts with leading underscore + capital letter)

comment:14 follow-up: Changed 4 years ago by tmonteil

If the upgrade can not be done soon (i hope it could!), another possibility would be to downgrade giac/giacpy_sage to a previously working version. Indeed, pynac is standard and depends on giac.

comment:15 in reply to: ↑ 14 Changed 4 years ago by fbissey

Replying to tmonteil:

If the upgrade can not be done soon (i hope it could!), another possibility would be to downgrade giac/giacpy_sage to a previously working version. Indeed, pynac is standard and depends on giac.

pynac doesn't currently depend on giac. Ralf wants it to happen, but things keep getting in the way. Enabling giac in pynac will cause at least two doctests to fail.

comment:16 Changed 4 years ago by tmonteil

  • Dependencies set to #22101

comment:17 follow-up: Changed 4 years ago by tmonteil

If people running powerpc and other platforms coudl check #22101, it seems to solve the issue.

comment:18 Changed 4 years ago by jpflori

Trying it on ppc64.

comment:19 in reply to: ↑ 17 ; follow-up: Changed 4 years ago by frederichan

Replying to tmonteil:

If people running powerpc and other platforms coudl check #22101, it seems to solve the issue.

Really? I thought it was only improving for i386. (cf comment4) The only (small) news I have for other architecture are about arm64 from this topic: http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1785

where it seems that the static built of icas is functionnal while the original built crashes with 1+1

comment:20 Changed 4 years ago by jpflori

I can confirm nothing changed on ppc64.

comment:21 Changed 4 years ago by fbissey

I think SMARTPTR64 is unrelated to our problems. It is added in some pre-made makefile, some of them for the debian package specifically. But there is no way I can see for it to make its way in the build system on a regular build - any system. Same story for DOUBLEVAL but this time with windows and OS X - it could be of interest since on OS X it included ppc.

comment:22 Changed 4 years ago by frederichan

does

./configure --enable-shared=no

changes things?

comment:23 Changed 4 years ago by fbissey

I cannot test right now - I am waiting for a world update to finish on the machine (this is a gentoo prefix, everything is compiled) but I am putting it on the things to try.

comment:24 in reply to: ↑ 19 Changed 4 years ago by tmonteil

Replying to frederichan:

Replying to tmonteil:

If people running powerpc and other platforms coudl check #22101, it seems to solve the issue.

Really? I thought it was only improving for i386. (cf comment4)

Sorry, i meant it solves the issue on i386.

comment:25 Changed 4 years ago by fbissey

Currently for me every single tests fails (but I can do 1+1) on ppc64. Trying to run a test manually I get the following back trace which is slightly different from Jeroen

#7480 <signal handler called>
#7481 0x00000400020258e0 in ?? () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7482 0x00000400020258b0 in ?? () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7483 0x00000400020274f8 in .pari_err () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7484 0x0000040002028290 in .pari_sighandler () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7485 <signal handler called>
#7486 0x00000400005565ec in .std::vector<char const*, std::allocator<char const*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, char const* const&) () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7487 0x00000400005550bc in .giac::symbolic::eval(int, giac::context const*) const () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7488 0x0000040000c8e158 in .giac::gen::in_eval(int, giac::gen&, giac::context const*) const ()
   from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7489 0x0000040000c8fb58 in .giac::gen::eval(int, giac::context const*) const () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7490 0x0000040000a35074 in .giac::protecteval(giac::gen const&, int, giac::context const*) ()
   from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7491 0x000004000083d654 in .giac::in_thread_eval(void*) () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7492 0x0000040002bbbb10 in .start_thread () from /shared/work_no_backup/ppc64-prefix/lib64/libpthread.so.0
#7493 0x000004000170b268 in .__clone () from /shared/work_no_backup/ppc64-prefix/lib64/libc.so.6

I have cut all the extra repetition of the pari signal handler. This is 1.2.2-105, with 1.2.3 compiled "statically" (same "test case"):

#0  0x000000001029321c in .std::vector<char const*, std::allocator<char const*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, char const* const&) ()
#1  0x0000000010291eec in .giac::symbolic::eval(int, giac::context const*) const ()
#2  0x000000001098e0c0 in .giac::gen::in_eval(int, giac::gen&, giac::context const*) const ()
#3  0x0000000010291b64 in .giac::symbolic::eval(int, giac::context const*) const ()
#4  0x000000001098e0c0 in .giac::gen::in_eval(int, giac::gen&, giac::context const*) const ()
#5  0x000000001098f570 in .giac::gen::eval(int, giac::context const*) const ()
#6  0x000000001070fe14 in .giac::protecteval(giac::gen const&, int, giac::context const*) ()
#7  0x0000000010568324 in .giac::in_thread_eval(void*) ()
#8  0x00000400017fbb10 in .start_thread () from /shared/work_no_backup/ppc64-prefix/lib64/libpthread.so.0
#9  0x0000040001f0b268 in .__clone () from /shared/work_no_backup/ppc64-prefix/lib64/libc.so.6

comment:26 Changed 4 years ago by frederichan

(Sorry just small news) I have tried with qemu on the following:

Linux debianppc64 3.16.0-4-powerpc64le #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) ppc64le GNU/Linux

to build giac on a basic debian (stable) system with just libgmp-dev and libmpfr-dev.

With the defaut compiler (gcc 4.9) I was able to built giac 1.2.3-31 and reproduce crashes with 1+1 or also just by evaluating: e (it should answer exp(1))

trying with e it seems that the string giving the name of a fonction was not correctly stored.

(gdb) p sommet.ptr()
$12 = (giac::unary_function_abstract *) 0xb7f71ee0
(gdb) p sommet.ptr()->s
Cannot access memory at address 0xb7f71ee8

NB: as I am under qemu I have 1cpu and my threads value was 1. (yours may differ, I don't know if you are able to do: threads:=1)

Then I tried to built with gcc 4.8 and I got a good version of giac.

comment:27 Changed 4 years ago by kcrisman

  • Milestone changed from sage-7.6 to sage-8.0

comment:28 Changed 3 years ago by fbissey

My latest experiment on ppc64 build with -O0 -ggdb, pari and ntl disabled to simplify things and rule them out.

#0  0x0000040000b1a068 in giac::add_print_symbolic (s=..., g=..., contextptr=0xffff075a590) at symbolic.cc:483
483         if ( g.sommet.ptr()->printsommet && g.sommet!=at_plus && g.sommet!=at_prod && g.sommet!=at_pow){
[Current thread is 1 (Thread 0x4000004d460 (LWP 13277))]
(gdb) bt
#0  0x0000040000b1a068 in giac::add_print_symbolic (s="", g=..., contextptr=0xffff075a590) at symbolic.cc:483
#1  0x0000040000b1b18c in giac::symbolic::print[abi:cxx11](giac::context const*) const (this=0x10094d18, contextptr=0xffff075a590) at symbolic.cc:599
#2  0x00000400013ea160 in giac::gen::print[abi:cxx11](giac::context const*) const (this=0xffff0743918, contextptr=0xffff075a590) at gen.cc:12815
#3  0x00000400013069d4 in giac::warn_implicit (a=..., b=..., contextptr=0xffff075a590) at usual.cc:4950
#4  0x0000040001306cbc in giac::check_symb_of (a=..., b0=..., contextptr=0xffff075a590) at usual.cc:4960
#5  0x0000040000afed78 in giac::giac_yyparse (scanner=0x1008bdd0) at input_parser.yy:232
#6  0x00000400013d7784 in giac::try_parse (
    s=" restart;maple_mode(1);cas_setup(0,0,0,1,0,1e-10,10,[1,50,0,25],0,0,0); #radians,pas de cmplx, pas de  Sqrt\n/* astuces, a retenir: sous xcas on utilise unapply qui est en general plus sur\243que la metho"..., contextptr=0xffff075a590) at gen.cc:11074
#7  0x00000400013d9284 in giac::protected_giac_yyparse (
    chaine=" restart;maple_mode(1);cas_setup(0,0,0,1,0,1e-10,10,[1,50,0,25],0,0,0); #radians,pas de cmplx, pas de  Sqrt\n/* astuces, a retenir: sous xcas on utilise unapply qui est en general plus sur\243que la metho"..., parse_result=..., contextptr=0xffff075a590) at gen.cc:11237
#8  0x00000400013d95d0 in giac::gen::gen (this=0xffff0759f58, 
    s=" restart;maple_mode(1);cas_setup(0,0,0,1,0,1e-10,10,[1,50,0,25],0,0,0); #radians,pas de cmplx, pas de  Sqrt\n/* astuces, a retenir: sous xcas on utilise unapply qui est en general plus sur\243que la metho"..., contextptr=0xffff075a590) at gen.cc:11267
#9  0x000004000076788c in giac::readargs_from_stream (inf=..., args=..., contextptr=0xffff075a590) at sym2poly.cc:3869
#10 0x0000040000767cf8 in giac::readargs (ARGC=2, ARGV=0xffff075b5e8, args=..., contextptr=0xffff075a590) at sym2poly.cc:3920
#11 0x0000000010011b60 in main (ARGC=2, ARGV=0xffff075b5e8) at icas.cc:1615

I also noticed this warning during the build, nothing bad happens because of it on x86_64 but who knows

usual.cc: In function 'giac::complex_long_double giac::lngamma(giac::complex_long_double)':
usual.cc:7138:30: note: the ABI of passing aggregates with 16-byte alignment has changed in GCC 5
   static complex_long_double lngamma(complex_long_double x){
                              ^

comment:29 Changed 3 years ago by frederichan

I guess that g.sommet.ptr()->printsommet try to acces to the string representation of a usual symbol. so it looks similar to what I got. May be the less confusing example is to just type: e in icas, it should crash also for you when trying to obtain the exp string while d should return d because it is not a reserved keyword. Could it be an loader ordering problem?

comment:30 Changed 3 years ago by fbissey

Typing e in icas segfault and that's what I get from the core dump

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000040000b28538 in __gnu_cxx::new_allocator<char const*>::construct<char const*, char const* const&> (this=0x1007fc00, __p=0x40054000940)
    at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/ext/new_allocator.h:120
120             { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
[Current thread is 1 (Thread 0x4005228f080 (LWP 40544))]
(gdb) bt
#0  0x0000040000b28538 in __gnu_cxx::new_allocator<char const*>::construct<char const*, char const* const&> (this=0x1007fc00, __p=0x40054000940)
    at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/ext/new_allocator.h:120
#1  0x0000040000b274fc in std::allocator_traits<std::allocator<char const*> >::construct<char const*, char const* const&> (__a=..., __p=0x40054000940)
    at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/alloc_traits.h:530
#2  0x0000040000b275cc in std::vector<char const*, std::allocator<char const*> >::_M_emplace_back_aux<char const* const&> (this=0x1007fc00)
    at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/vector.tcc:416
#3  0x0000040000b263c4 in std::vector<char const*, std::allocator<char const*> >::push_back (this=0x1007fc00, __x=<error reading variable>)
    at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/stl_vector.h:923
#4  0x0000040000b21ca4 in giac::symbolic::eval (this=0x1013a1a8, level=25, contextptr=0xfffc02556f0) at symbolic.cc:1371
#5  0x0000040001368ccc in giac::gen::in_eval (this=0x4005228e5c8, level=25, evaled=..., contextptr=0xfffc02556f0) at gen.cc:2113
#6  0x0000040001366268 in giac::gen::eval (this=0x4005228e5c8, level=25, contextptr=0xfffc02556f0) at gen.cc:1899
#7  0x000004000106fd7c in giac::protecteval (g=..., level=25, contextptr=0xfffc02556f0) at prog.cc:6881
#8  0x0000040000e4e50c in giac::in_thread_eval (arg=0x1007ff28) at global.cc:3463
#9  0x000004000265bb10 in .start_thread () from /shared/work_no_backup/ppc64-prefix/lib64/libpthread.so.0
#10 0x0000040002d6b268 in .__clone () from /shared/work_no_backup/ppc64-prefix/lib64/libc.so.6

comment:31 Changed 3 years ago by frederichan

So you have the same debug as what I had with gcc4.9 in comment 26 where I put a break in symbolic.cc.

But for me, if after the built I rebuilt icas with .libs/libgiac.a instead of .libs/libgiac.so by doing in the src/ directory:

fred@debianppc64:~/giac-1.2.3-gcc49/src$ g++ -g -fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS -o .libs/icas icas.o  ./.libs/libxcas.a /home/fred/giac-1.2.3-gcc49/src/.libs/libgiac.a -lreadline -ltermcap -lrt -lpthread -ldl -lm -lmpfr -lgmp

then I can run .libs/icas without problems.

comment:32 Changed 3 years ago by jpflori

Indeed, if I configure giac with disable-shared, I can ask e in icas without sefgault.

comment:33 Changed 3 years ago by jpflori

But I still have similar failures:

0>> maple_mode(0);
[New Thread 0x3fffaf10f1a0 (LWP 31223)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffaf10f1a0 (LWP 31223)]
0x000000001034c1a0 in __gnu_cxx::new_allocator<char const*>::construct (
    this=0x1107a830, __p=0x3fffa8000940, 
    __val=@0xffffe3b0: <error reading variable>)
    at /usr/include/c++/4.8.3/ext/new_allocator.h:130
130           { ::new((void *)__p) _Tp(__val); }
Missing separate debuginfos, use: debuginfo-install glibc-2.18-16.fc20.ppc64p7 libgcc-4.8.3-7.fc20.ppc64 libgfortran-4.8.3-7.fc20.ppc64 libstdc++-4.8.3-7.fc20.ppc64
(gdb) bt
#0  0x000000001034c1a0 in __gnu_cxx::new_allocator<char const*>::construct (
    this=0x1107a830, __p=0x3fffa8000940, 
    __val=@0xffffe3b0: <error reading variable>)
    at /usr/include/c++/4.8.3/ext/new_allocator.h:130
#1  0x000000001034ae74 in __gnu_cxx::__alloc_traits<std::allocator<char const*> >::construct<char const*> (__a=..., __p=0x3fffa8000940, 
    __arg=@0xffffe3b0: <error reading variable>)
    at /usr/include/c++/4.8.3/ext/alloc_traits.h:216
#2  0x000000001034b024 in std::vector<char const*, std::allocator<char const*> >::_M_insert_aux (this=0x1107a830, 
    __position=<error reading variable: Cannot access memory at address 0x0>, 
    __x=@0xffffe3b0: <error reading variable>)
    at /usr/include/c++/4.8.3/bits/vector.tcc:353
#3  0x000000001034942c in std::vector<char const*, std::allocator<char const*> >::push_back (this=0x1107a830, __x=@0xffffe3b0: <error reading variable>)
    at /usr/include/c++/4.8.3/bits/stl_vector.h:913
#4  0x0000000010344af4 in giac::symbolic::eval (this=0x1119df98, level=25, 
    contextptr=0x3fffffffde10) at symbolic.cc:1372
#5  0x0000000010b7f04c in giac::gen::in_eval (this=0x3fffaf10e6f8, level=25, 
    evaled=..., contextptr=0x3fffffffde10) at gen.cc:2109
#6  0x0000000010b7c7f8 in giac::gen::eval (this=0x3fffaf10e6f8, level=25, 
    contextptr=0x3fffffffde10) at gen.cc:1893
#7  0x0000000010887b2c in giac::protecteval (g=..., level=25, 
    contextptr=0x3fffffffde10) at prog.cc:7001
#8  0x000000001068bb08 in giac::in_thread_eval (arg=0x1107aad8)
    at global.cc:3467
#9  0x00003fffb703c328 in .start_thread () from /lib64/libpthread.so.0
#10 0x00003fffb6abdc70 in .__clone () from /lib64/libc.so.6

comment:34 Changed 3 years ago by jpflori

A shorter one:

0>> maple_mode
[New Thread 0x3fffaf10f1a0 (LWP 35528)]
[Thread 0x3fffaf10f1a0 (LWP 35528) exited]

Program received signal SIGSEGV, Segmentation fault.
0x0000000010bfc680 in giac::gen::print (this=0x3fffffffdb50, 
    contextptr=0x3fffffffde10) at gen.cc:12961
12961         if (rpn_mode(contextptr) || _FUNCptr->ptr()->printsommet==&printastifunction || subtype==0) 
(gdb) bt
#0  0x0000000010bfc680 in giac::gen::print (this=0x3fffffffdb50, 
    contextptr=0x3fffffffde10) at gen.cc:12961
#1  0x00000000100174cc in main (ARGC=1, ARGV=0x3fffffffe398) at icas.cc:1536
(gdb) 

comment:35 Changed 3 years ago by jpflori

This looks bad:

(gdb) p this->ref_FUNCptr()->ptr()
$8 = (giac::unary_function_abstract *) 0xffffe3a8

Address has been cut.

comment:36 Changed 3 years ago by jpflori

One can circumvent that by setting __x86_64__ but this automatically sets SMARTPTR64 which might be broken on ppc64 because of endianness (vould work on ppc64le) and _I386_ which includes assembly code.

I'm now trying with proper 64 bits pointers but without "smart" pointers.

comment:37 Changed 3 years ago by jpflori

Oh yeah and on 64 bits systems, not using SMARTPTR64 is doomed to fail because C(++) types of different lengths are used to access the _FUNC_ part of a gen.

comment:38 Changed 3 years ago by jpflori

And double storage trick fails because of byte order and is fixed when passing -DDOUBLEVAL.

comment:39 Changed 3 years ago by jpflori

Everything seems fine now, patches on their way.

comment:40 Changed 3 years ago by jpflori

  • Authors set to Jean-Pierre Flori
  • Branch set to public/giac
  • Commit set to f5e35f22f55f56921aa3314689aa8a3c84db64b6

Here you go. Please report any success/failure with this branch.


New commits:

f5e35f2Make giac behave correctly on 64 bits or big endian systems.

comment:41 Changed 3 years ago by jpflori

  • Report Upstream changed from N/A to Not yet reported upstream; Will do shortly.
  • Status changed from new to needs_review

And let's even say it's needs_review...

comment:42 Changed 3 years ago by jpflori

I've been in contact with Bernard (Parisse = upstream) and made some efforts have been made towards more portability but according to my experiments not enough at the moment. See:

comment:43 Changed 3 years ago by jpflori

  • Report Upstream changed from Not yet reported upstream; Will do shortly. to Reported upstream. No feedback yet.

comment:44 follow-up: Changed 3 years ago by tmonteil

Did you suggest the fix for libpng/lpng1x too (suggested on this comment)?

comment:45 follow-up: Changed 3 years ago by fbissey

Which version is your starting point? I am trying with 1.2.3-25 at the moment (because I have it handy on ppc64 right now) and while it is an improvement there are still failures, and I seem to be hanging at chk_morley_demo and a few others.

comment:46 in reply to: ↑ 44 ; follow-up: Changed 3 years ago by jpflori

Replying to tmonteil:

Did you suggest the fix for libpng/lpng1x too (suggested on this comment)?

Nope, I did not...

comment:47 in reply to: ↑ 45 Changed 3 years ago by jpflori

Replying to fbissey:

Which version is your starting point? I am trying with 1.2.3-25 at the moment (because I have it handy on ppc64 right now) and while it is an improvement there are still failures, and I seem to be hanging at chk_morley_demo and a few others.

Hum, the one pointed in this ticket.

The latest "unstable" (which might have become stable) tarball should have equivalent fixes. See:

I guess you still have to pass -Dx86_64 into C[XX|PP]FLAGS to make sure addresses are not cut at 32 bits.

comment:48 Changed 3 years ago by jpflori

Note that using static or shared libraries makes no difference, both work well.

comment:49 Changed 3 years ago by jpflori

Thanks to Bernard and debian folk work the latest stable version seems ok. Pass -Dx86_64 into CPPFLAGS.

comment:50 Changed 3 years ago by jpflori

  • Description modified (diff)

comment:51 Changed 3 years ago by git

  • Commit changed from f5e35f22f55f56921aa3314689aa8a3c84db64b6 to 8dc4c88c3f7a0f9a8710f54d839cacc0936fd959

Branch pushed to git repo; I updated commit sha1. New commits:

8dc4c88Update to 1.2.3-47.

comment:52 Changed 3 years ago by jpflori

  • Description modified (diff)

If you want to add arm64 support, please do so. But I think this is ready to go now.

comment:53 Changed 3 years ago by jpflori

  • Report Upstream changed from Reported upstream. No feedback yet. to Fixed upstream, in a later stable release.

Feel free to send this to the bots!

comment:54 Changed 3 years ago by jpflori

  • Cc vbraun added

comment:55 Changed 3 years ago by fbissey

I am sorry I haven't had time to test this fully yet. I will try to give it another go over the weekend.

comment:56 Changed 3 years ago by fbissey

make[3]: Entering directory '/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/check'
*** stack smashing detected ***: /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/icas terminated
======= Backtrace: =========
/shared/work_no_backup/ppc64-prefix/lib64/libc.so.6(+0xa3ba8)[0x400016e3ba8]
/shared/work_no_backup/ppc64-prefix/lib64/libc.so.6(__fortify_fail-0x89548)[0x40001782480]
/shared/work_no_backup/ppc64-prefix/lib64/libc.so.6(__stack_chk_fail-0x89598)[0x40001782418]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZN4giac5substERKNS_3genERKNS_15dbgprint_vectorIS0_EES6_bPKNS_7contextE-0x836be0)[0x400007770d8]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(+0x6dbcc0)[0x4000074bcc0]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(+0x1ca518)[0x4000023a518]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(+0x6e0834)[0x40000750834]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZN4giac5limitERKNS_3genERKNS_14identificateurES2_iPKNS_7contextE-0x85b8e8)[0x40000751590]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZN4giac11quotedlimitERKNS_3genERKNS_14identificateurES2_iPKNS_7contextE-0x85b498)[0x400007519f8]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZN4giac6_limitERKNS_3genEPKNS_7contextE-0x85ab14)[0x40000752394]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZNK4giac19unary_function_evalclERKNS_3genEPKNS_7contextE-0x3aa814)[0x40000c165b4]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZNK4giac18unary_function_ptrclERKNS_3genEPKNS_7contextE-0x3b940c)[0x40000c07c5c]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZNK4giac8symbolic4evalEiPKNS_7contextE-0xa07dd8)[0x4000059f9b8]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZNK4giac3gen7in_evalEiRS0_PKNS_7contextE-0x2c80d0)[0x40000cfdc30]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZNK4giac3gen4evalEiPKNS_7contextE-0x2c70d8)[0x40000cfec58]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(_ZN4giac11protectevalERKNS_3genEiPKNS_7contextE-0x54a214)[0x40000a6fe34]
/dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0(+0x81b894)[0x4000088b894]
/shared/work_no_backup/ppc64-prefix/lib64/libpthread.so.0(+0xbb10)[0x40002c1bb10]
/shared/work_no_backup/ppc64-prefix/lib64/libc.so.6(clone-0x9e5b8)[0x4000176b268]
======= Memory map: ========
10000000-10020000 r-xp 00000000 00:10 13112212                           /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/icas
10020000-10030000 r--p 00010000 00:10 13112212                           /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/icas
10030000-10040000 rw-p 00020000 00:10 13112212                           /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/icas
10040000-100d0000 rw-p 00000000 00:00 0                                  [heap]
40000000000-40000030000 r-xp 00000000 00:16 41936355                     /shared/work_no_backup/ppc64-prefix/lib64/ld-2.23.so
40000030000-40000040000 r--p 00020000 00:16 41936355                     /shared/work_no_backup/ppc64-prefix/lib64/ld-2.23.so
40000040000-40000050000 rw-p 00030000 00:16 41936355                     /shared/work_no_backup/ppc64-prefix/lib64/ld-2.23.so
40000050000-40000070000 r-xp 00000000 00:00 0                            [vdso]
40000070000-40000f60000 r-xp 00000000 00:10 13111890                     /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0.0.0
40000f60000-40000f70000 ---p 00ef0000 00:10 13111890                     /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0.0.0
40000f70000-40000fd0000 r--p 00ef0000 00:10 13111890                     /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0.0.0
40000fd0000-40000ff0000 rw-p 00f50000 00:10 13111890                     /dev/shm/portage/sci-mathematics/giac-1.2.3.47/work/giac-1.2.3/src/.libs/libgiac.so.0.0.0
40000ff0000-40001020000 rw-p 00000000 00:00 0 
40001020000-40001080000 r-xp 00000000 00:16 14674565                     /shared/work_no_backup/ppc64-prefix/usr/lib64/libreadline.so.7.0
40001080000-40001090000 r--p 00050000 00:16 14674565                     /shared/work_no_backup/ppc64-prefix/usr/lib64/libreadline.so.7.0
40001090000-400010a0000 rw-p 00060000 00:16 14674565                     /shared/work_no_backup/ppc64-prefix/usr/lib64/libreadline.so.7.0
400010a0000-40001340000 r-xp 00000000 00:16 16553231                     /shared/work_no_backup/ppc64-prefix/usr/lib64/libgsl.so.19.3.0
40001340000-40001370000 r--p 00290000 00:16 16553231                     /shared/work_no_backup/ppc64-prefix/usr/lib64/libgsl.so.19.3.0
40001370000-40001390000 rw-p 002c0000 00:16 16553231                     /shared/work_no_backup/ppc64-prefix/usr/lib64/libgsl.so.19.3.0
40001390000-400013a0000 rw-p 00000000 00:00 0 
400013b0000-400015c0000 r-xp 00000000 00:16 15211125                     /shared/work_no_backup/ppc64-prefix/usr/lib64/gcc/powerpc64-unknown-linux-gnu/5.4.0/libstdc++.so.6.0.21
400015c0000-400015f0000 r--p 00200000 00:16 15211125                     /shared/work_no_backup/ppc64-prefix/usr/lib64/gcc/powerpc64-unknown-linux-gnu/5.4.0/libstdc++.so.6.0.21
400015f0000-40001600000 rw-p 00230000 00:16 15211125                     /shared/work_no_backup/ppc64-prefix/usr/lib64/gcc/powerpc64-unknown-linux-gnu/5.4.0/libstdc++.so.6.0.21
40001600000-40001620000 r-xp 00000000 00:16 15211117                     /shared/work_no_backup/ppc64-prefix/usr/lib64/gcc/powerpc64-unknown-linux-gnu/5.4.0/libgcc_s.so.1
40001620000-40001630000 r--p 00010000 00:16 15211117                     /shared/work_no_backup/ppc64-prefix/usr/lib64/gcc/powerpc64-unknown-linux-gnu/5.4.0/libgcc_s.so.1
40001630000-40001640000 rw-p 00020000 00:16 15211117                     /shared/work_no_backup/ppc64-prefix/usr/lib64/gcc/powerpc64-unknown-linux-gnu/5.4.0/libgcc_s.so.1FAIL: chk_limit
PASS: chk_partfrac
FAIL: chk_fhan15
PASS: chk_fhan13
PASS: chk_factor
PASS: chk_geo
FAIL: chk_fhan0
PASS: chk_fhan21
PASS: chk_integrate
FAIL: chk_fhan2
FAIL: chk_cas
PASS: chk_xavier
FAIL: chk_fhan1
PASS: chk_normalize
FAIL: chk_morley_demo
FAIL: chk_fhan18
FAIL: chk_fhan12
FAIL: chk_fhan7
FAIL: chk_fhan20
FAIL: chk_fhan16
FAIL: chk_fhan9
FAIL: chk_fhan17
FAIL: chk_fhan8
FAIL: chk_fhan5
FAIL: chk_fhan3
FAIL: chk_fhan4
FAIL: chk_fhan6
FAIL: chk_fhan19
FAIL: chk_fhan14
FAIL: chk_fhan11
============================================================================
Testsuite summary for giac 1.2.3
============================================================================
# TOTAL: 30
# PASS:  8
# SKIP:  0
# XFAIL: 0
# FAIL:  22
# XPASS: 0
# ERROR: 0

I am starting to think my g++ is at fault :(

comment:57 Changed 3 years ago by fbissey

@ Jean-Pierre, what version of gcc did you test this with?

comment:58 follow-up: Changed 3 years ago by jpflori

An old one:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.3/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/cloog-install --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)

I did not run giac testsuite though.

comment:59 in reply to: ↑ 58 Changed 3 years ago by fbissey

Replying to jpflori:

An old one:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.3/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/cloog-install --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)

I did not run giac testsuite though.

Ah, I never had trouble building it. Just running/testing it. It will be some work to get things to build with gcc 4.8.x, will have to find all the C++ dependencies before building.

comment:60 Changed 3 years ago by jpflori

Most tests seem to pass on my machine except for some numerical noise and some very long or looping tests I killed.

comment:61 in reply to: ↑ 46 ; follow-up: Changed 3 years ago by tmonteil

Replying to jpflori:

Replying to tmonteil:

Did you suggest the fix for libpng/lpng1x too (suggested on this comment)?

Nope, I did not...

Could you please give me some hints on how to achieve this (which file to modify, and how) ?

(sorry for not being able to help on the review, i do not have any ppc machine, my intel 32bit VM is trying it right now, just in case)

comment:62 Changed 3 years ago by jpflori

Just patch the Makefile to use -lpng16 rather than -lpng.

comment:63 Changed 3 years ago by fbissey

Currently giac configure png with

CONFIG_PNG="yes"
AC_ARG_ENABLE(png,
        [AS_HELP_STRING([--enable-png], [Enable PNG library])],
        [ if test "x$enableval" = "xno"; then CONFIG_PNG="no"; fi], [])
  
if test "x$CONFIG_PNG" = "xyes"; then
   AC_CHECK_HEADERS(png.h, AC_CHECK_LIB(png,main))
fi

in configure.in. An option is to use AC_CHECK_LIBS(main,[png16,png14,png12,png]) instead of AC_CHECK_LIB. For Jean-Pierre suggestion you have to do the replacement after configure is run. Because AC_CHECK_LIB is used -lpng is added to LIBS by configure.

comment:64 in reply to: ↑ 61 Changed 3 years ago by tmonteil

Replying to tmonteil:

(sorry for not being able to help on the review, i do not have any ppc machine, my intel 32bit VM is trying it right now, just in case)

For what it worth, giac-1.2.3.47 from this ticket compiles and pass self-tests on both my 64bit laptop and 32bit VM (both running Debian GNU/Linux jessie).

comment:65 Changed 3 years ago by tmonteil

Ragarding building giac with png support, thanks Jean-Pierre and François for your hints, i opened #23262.

comment:66 Changed 3 years ago by fbissey

Unfortunately, I still have no luck on ppc64 with gcc-5.4.0. It is better than before in that some tests are now succeeding. But things seems to get stuck in a C++ allocator for a number of them.

comment:67 Changed 3 years ago by jpflori

Is giac itself functional? That is: is it only failing its testsuite or is it completely broken as well?

comment:68 Changed 3 years ago by fbissey

Fair question. "1+1" works, the fact that some tests work means that it is working up to a point. I haven't tried to run the sage testsuite with it. Any tests I should run?

Last edited 3 years ago by fbissey (previous) (diff)

comment:69 Changed 3 years ago by jpflori

Maybe sage -t src/sage/interfaces/giac.py and rings and symbolic would tell you if it looks functional or not.

On my side, giac also fails a lot of its own testsuite, inlcuding bunch of numerical noise, but also more worrying stuff i did not investigate, but running tests as above seems to indicate it is good enough for sage.

comment:70 Changed 3 years ago by fbissey

  • Reviewers set to Thierry Monteil, Jean-Pierre Flori, François Bissey
  • Status changed from needs_review to positive_review

OK, I did run those tests and the few failures I have are unrelated to giac (I'll have to investigate some of them more deeply but they are definitely not giac). I guess we can go ahead with this.

comment:71 Changed 3 years ago by vbraun

  • Branch changed from public/giac to 8dc4c88c3f7a0f9a8710f54d839cacc0936fd959
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:72 Changed 3 years ago by infinity0

  • Commit 8dc4c88c3f7a0f9a8710f54d839cacc0936fd959 deleted

Do you guys know why the -Dx86_64 is needed on ppc64? That is still a bug that should be fixed upstream. In theory upstream should now be detecting 64-bit in a cross-platform way so I'm confused why it fails on ppc64.

comment:73 Changed 3 years ago by infinity0

(sorry, I have no idea why my comment there deleted the commit field)

(I can't seem to fix it either, even by Modifying the ticket with that commit)

Last edited 3 years ago by infinity0 (previous) (diff)

comment:74 Changed 3 years ago by infinity0

All tests pass for me for 1.2.3-51 on arm64 on Debian without further changes or extra flags, btw.

comment:75 Changed 3 years ago by fbissey

I'll have to try 1.2.3-51 on ppc64 without extra flags then. 1.2.3-47 builds but a lot of tests fail for me. We may want to consider a further upgrade.

The removal of the commit when you comment further is a "feature" of track. It is annoying but not harmfull.

comment:76 Changed 3 years ago by fbissey

Well, you probably don't have that problem but I allow compilation without gui, and sage itself doesn't depend on fltk

  bool has_graph3d(Fl_Widget * widget){
#ifdef HAVE_LIBFLTK
    Fl_Group * g=dynamic_cast<Fl_Group *>(widget);

Oooops! in src/Xcas.cc (line 3360) there goes your compilation failure if you don't have fltk.

comment:77 Changed 3 years ago by infinity0

I have found that annoying too, in Debian I am forced to ship the non-GUI icas program (which is what Sage actually wants) together with the GUI xcas program, and it even links against X libraries. I've filed a bug about it upstream, hopefully they can fix it.

comment:78 Changed 3 years ago by fbissey

Well, I pilled up some more in http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1814 because your request, I felt, was much broader than mine (but yes something should be done about all that X stuff).

comment:79 Changed 3 years ago by infinity0

Unfortunately giac fails to compile for me on a arm64 (aarch64) 4.9 Linux kernel:

http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?p=8941#p8941

It succeeded on a 3.16 Linux kernel though, as I reported above. Could someone reproduce this and if so re-open this ticket or open another one?

comment:80 Changed 3 years ago by infinity0

A potential solution to this has been suggested on the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855078#29

I'll try to test it next week, in the meantime feel free to jump in ahead.

Note: See TracTickets for help on using tickets.