Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Symbolic computation: ECLS internal error: No such file or directory #348

Closed
Thrasymachos opened this issue Apr 25, 2015 · 34 comments
Closed

Comments

@Thrasymachos
Copy link

Whenever I try something with symbolic manipulation in Sage, ECL throws an error:

var('x')
simplify(x^3)
Internal or unrecoverable error in:
Got signal before environment was installed on our thread
  [2: No such file or directory]

;;; ECL C Backtrace
;;; /usr/lib64/libecl.so.13.5(si_dump_c_backtrace+0x31) [0x7f30c79e45f1]
;;; /usr/lib64/libecl.so.13.5(ecl_internal_error+0x44) [0x7f30c79cd5c4]
;;; /usr/lib64/libecl.so.13.5(+0x1b8578) [0x7f30c79fa578]
;;; /lib64/libpthread.so.0(+0xfeb0) [0x7f3105cc5eb0]
;;; /usr/lib64/libgc.so.1(+0x8bcd) [0x7f30f2130bcd]
;;; /usr/lib64/libgc.so.1(+0x68eb) [0x7f30f212e8eb]
;;; /usr/lib64/libgc.so.1(+0x6c4e) [0x7f30f212ec4e]
;;; /usr/lib64/libgc.so.1(+0x13a94) [0x7f30f213ba94]
;;; /usr/lib64/libgc.so.1(+0x87d3) [0x7f30f21307d3]
;;; /usr/lib64/libgc.so.1(+0xd659) [0x7f30f2135659]
;;; /usr/lib64/libgc.so.1(GC_generic_malloc+0x47) [0x7f30f2135757]
;;; /usr/lib64/libgc.so.1(+0xdada) [0x7f30f2135ada]
;;; /usr/lib64/libecl.so.13.5(ecl_alloc_object+0x9b) [0x7f30c7a10f7b]
;;; /usr/lib64/libecl.so.13.5(init_threads+0x42) [0x7f30c7a0e172]
;;; /usr/lib64/libecl.so.13.5(cl_boot+0x87) [0x7f30c78dd377]
;;; /usr/lib64/python2.7/site-packages/sage/libs/ecl.so(+0x6c6c) [0x7f30c7d6dc6c]
;;; /usr/lib64/python2.7/site-packages/sage/libs/ecl.so(+0x6f98) [0x7f30c7d6df98]
;;; /usr/lib64/python2.7/site-packages/sage/libs/ecl.so(initecl+0x1781) [0x7f30c7d79961]
;;; /usr/lib64/libpython2.7.so.1.0(_PyImport_LoadDynamicModule+0x99) [0x7f3105fc4a39]
;;; /usr/lib64/libpython2.7.so.1.0(+0xefc29) [0x7f3105fc2c29]
;;; /usr/lib64/libpython2.7.so.1.0(+0xefe6d) [0x7f3105fc2e6d]
;;; /usr/lib64/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x188) [0x7f3105fc37d8]
;;; /usr/lib64/libpython2.7.so.1.0(+0xd792f) [0x7f3105faa92f]
;;; /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7f3105f1d593]
;;; /usr/lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7f3105fac477]
;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0xf05) [0x7f3105fad965]
;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7dd) [0x7f3105fb251d]
;;; /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x32) [0x7f3105fb2622]
;;; /usr/lib64/libpython2.7.so.1.0(PyImport_ExecCodeModuleEx+0x8c) [0x7f3105fc1d9c]
;;; /usr/lib64/libpython2.7.so.1.0(+0xef005) [0x7f3105fc2005]
;;; /usr/lib64/libpython2.7.so.1.0(+0xefc29) [0x7f3105fc2c29]
;;; /usr/lib64/libpython2.7.so.1.0(+0xefe6d) [0x7f3105fc2e6d]
Aborted

I'm running Sage 6.6

version()
'SageMath Version 6.6, Release Date: 2015-04-14'

I tried reinstalling every related package (sage, maxima, ecls) several times, removing and reenabling threads support, even remerging my whole system, without success. Recently I created a sandbox and installed everything from scratch there - same error.
Symbolic computation in Maxima itself is just fine, though.

Does anyone have an idea what could cause this problem? Or what is even meant by the error? What file or directory isn't found?

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 25, 2015

First port of call, is to check what's happening on a "vanilla" build but that look serious enough that it would have been seen there before.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 25, 2015

OK not getting it here

fbissey@QCD-nzi3 ~ $ sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath Version 6.7.beta2, Release Date: 2015-04-21               │
│ Type "notebook()" for the browser-based notebook interface.        │
│ Type "help()" for help.                                            │
└────────────────────────────────────────────────────────────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable.     ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
sage: var('x')
x
sage: simplify(x^3)
x^3

output of eix -I ecls and eix -I maxima please.

@Thrasymachos
Copy link
Author

I'm also not getting it on other machines (e.g. at work). Here are the outputs of eix:

eix -I ecls
[I] dev-lisp/ecls
     Available versions:  9.12.3 ~10.4.1 ~11.1.1-r1 ~12.2.1 ~12.7.1 ~12.12.1 ~12.12.1-r5(0/12.12.1)^m ~12.12.1-r6(0/12.12.1)^m[1] ~13.5.1(0/13.5.1) 13.5.1-r1(0/13.5.1)^t ~15.3.7(0/15.3.7)^t {X debug doc emacs gengc +libatomic precisegc (+)threads +unicode CPU_FLAGS_X86="sse"}
     Installed versions:  13.5.1-r1^t(11:43:09 PM 04/25/2015)(emacs threads unicode -X -debug -gengc -precisegc CPU_FLAGS_X86="sse")
     Homepage:            http://ecls.sourceforge.net/
     Description:         ECL is an embeddable Common Lisp implementation

[1] "sage-on-gentoo" /var/lib/layman/sage-on-gentoo
eix -I maxima
[I] sci-mathematics/maxima
     Available versions:  5.18.1 ~5.29.1-r3[1] ~5.33.0-r2[1] 5.34.1 ~5.34.1-r2[1] (~)5.35.1-r2[1] ~5.36.0 {X clisp clozurecl cmucl ecls emacs gcl latex nls sbcl tk unicode xemacs LINGUAS="es pt pt_BR"}
     Installed versions:  5.35.1-r2[1](11:47:55 PM 04/25/2015)(ecls emacs latex nls unicode -X -clisp -clozurecl -cmucl -gcl -sbcl -tk -xemacs LINGUAS="-es -pt -pt_BR")
     Homepage:            http://maxima.sourceforge.net/
     Description:         Free computer algebra environment based on Macsyma

[1] "sage-on-gentoo" /var/lib/layman/sage-on-gentoo

The problem has been around for me for a longer time (since Sage 6.2? I don't remember so well). Also, no one else on the web seems to have had this problem. I tried up- and downgrading sage, maxima and ecls, haven't had any luck though.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 25, 2015

Looking at the backtrace we may want to go back to boehm-gc so eix for that as well, please.

@Thrasymachos
Copy link
Author

Sure.

eix -I boehm-gc
[I] dev-libs/boehm-gc
     Available versions:  6.8 7.1-r1 7.2d 7.2d-r1 7.2e ~7.4.0 7.4.2 {cxx static-libs threads}
     Installed versions:  7.4.2(08:17:05 PM 02/12/2015)(cxx threads -static-libs)
     Homepage:            http://www.hboehm.info/gc/
     Description:         The Boehm-Demers-Weiser conservative garbage collector

@Thrasymachos
Copy link
Author

I just figured out

┌────────────────────────────────────────────────────────────────────┐
│ SageMath Version 6.6, Release Date: 2015-04-14                     │
│ Type "notebook()" for the browser-based notebook interface.        │
│ Type "help()" for help.                                            │
└────────────────────────────────────────────────────────────────────┘
sage: import sage.interfaces.maxima_lib

Internal or unrecoverable error in:
Got signal before environment was installed on our thread
  [2: No such file or directory]
...

already produces the exact same error.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 25, 2015

Feels like something is fundamentally broken with threads there. emerge --info please.

@Thrasymachos
Copy link
Author

Here you are:

Portage 2.2.18 (python 3.3.5-final-0, default/linux/amd64/13.0, gcc-4.8.4, glibc-2.20-r2, 3.17.7-gentoo x86_64)
=================================================================
System uname: Linux-3.17.7-gentoo-x86_64-Intel-R-_Core-TM-_i5-4200U_CPU_@_1.60GHz-with-gentoo-2.2
KiB Mem:    12006976 total,   7627864 free
KiB Swap:   16505876 total,  16505876 free
Timestamp of repository gentoo: Sat, 25 Apr 2015 12:45:02 +0000
sh bash 4.2_p53
ld GNU ld (Gentoo 2.24 p1.4) 2.24
app-shells/bash:          4.2_p53::gentoo
dev-java/java-config:     2.1.12-r1::gentoo
dev-lang/perl:            5.20.2::gentoo
dev-lang/python:          2.7.9-r1::gentoo, 3.3.5-r1::gentoo, 3.4.1::gentoo
dev-util/cmake:           2.8.12.2-r1::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.13.11::gentoo
sys-apps/sandbox:         2.6-r1::gentoo
sys-devel/autoconf:       2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.13.4::gentoo
sys-devel/binutils:       2.24-r3::gentoo
sys-devel/gcc:            4.8.4::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers)
sys-libs/glibc:           2.20-r2::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.de.gentoo.org/gentoo-portage
    priority: -1000

sage-on-gentoo
    location: /var/lib/layman/sage-on-gentoo
    masters: gentoo
    priority: 0

belak
    location: /var/lib/layman/belak
    masters: gentoo
    priority: 1

science
    location: /var/lib/layman/science
    masters: gentoo
    priority: 2

sunrise
    location: /var/lib/layman/sunrise
    masters: gentoo
    priority: 3

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core-avx-i -mavx2 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=core-avx-i -mavx2 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://de-mirror.org/gentoo/"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
USE="acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dbus dri emacs fortran gdbm iconv ipv6 latex mmx mmxext modules multilib ncurses nls nptl openmp pam pcre pulseaudio readline session sse sse2 ssl startup-notification tcpd unicode vim-syntax zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx sse sse2 sse3 ssse3 sse4_1 sse4_2 mmxext avx fma" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="intel i915 v4l i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 25, 2015

Strange flags, I don't really know they are the root cause of your problem but I think you should change your C{XX}FLAGS instead of core-avx-i I would just use native and I would drop the -mavx2, native and CPU_FLAGS_X86 should take care of the rest. Over-optimization is sometimes a problem.

@Thrasymachos
Copy link
Author

Thank you. I will run emerge -e sage overnight and return back here with the results.

@Thrasymachos
Copy link
Author

Sadly, that didn't do any good. I actually ran emerge -e world and re-emerged everything with the "new" compiler and glibc a second time. The problem persists...
Could the CPU feature flags like sse2 etc. have anything to do with it?

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 27, 2015

Doubtful, I have similar settings if not similar cpu. Could you enable debugging in ecls and boehm-gc. With FEATURE=split-debug and adding -g -ggdb to your C{XX}FLAGS we could have some more meaningful backtrace and pinpoint something.

@Thrasymachos
Copy link
Author

Okay, I enabled the debug USE flag for ecls and sage and compiled boehm-gc, ecls, sage with the -g -ggdb flags. The output didn't change and gdb doesn't like to debug the sage scripts. Sorry, I have little experience debugging things.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

Can you tell me what kind of problem you had running gdb? What did you try and what happened - with paste from your terminal, please.

@Thrasymachos
Copy link
Author

First I tried to run gdb sage but gdb wasn't happy with me trying to debug a bash script. Now I found out that I can just run sage -gdb crash.sage where crash.sage is a file just containing

from sage.interfaces.maxima_lib import MaximaLib

Then:

(gdb) run
Starting program: /usr/bin/python2.7 /usr//bin/sage-ipython crash.sage -i
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff125a700 (LWP 5893)]
[New Thread 0x7fffcd674700 (LWP 5898)]
[New Thread 0x7fffcce73700 (LWP 5899)]
[New Thread 0x7fffcc672700 (LWP 5900)]

Program received signal SIGSEGV, Segmentation fault.
0x00007fffdb138bcd in GC_is_black_listed (h=h@entry=0x1390000, len=len@entry=4096) at blacklst.c:235
235 blacklst.c: No such file or directory.

The corresponding function from blacklst.c in the boehm-gc package is:

/*                                                                                                                                                                                                                  
 * Is the block starting at h of size len bytes black listed?   If so,                                                                                                                                              
 * return the address of the next plausible r such that (r, len) might not                                                                                                                                          
 * be black listed.  (R may not actually be in the heap.  We guarantee only                                                                                                                                         
 * that every smaller value of r after h is also black listed.)                                                                                                                                                     
 * If (h,len) is not black listed, return 0.                                                                                                                                                                        
 * Knows about the structure of the black list hash tables.                                                                                                                                                         
 */
struct hblk * GC_is_black_listed(struct hblk *h, word len)
{
    word index = PHT_HASH((word)h);
    word i;
    word nblocks;

    if (!GC_all_interior_pointers
        && (get_pht_entry_from_index(GC_old_normal_bl, index)
            || get_pht_entry_from_index(GC_incomplete_normal_bl, index))) {
      return (h+1);
    }

    nblocks = divHBLKSZ(len);
    for (i = 0;;) {
        if (GC_old_stack_bl[divWORDSZ(index)] == 0
            && GC_incomplete_stack_bl[divWORDSZ(index)] == 0) {
            /* An easy case */
          i += WORDSZ - modWORDSZ(index);
        } else {
          if (get_pht_entry_from_index(GC_old_stack_bl, index)
              || get_pht_entry_from_index(GC_incomplete_stack_bl, index)) {
            return(h+i+1);
      }
          i++;
        }
        if (i >= nblocks) break;
        index = PHT_HASH((word)(h+i));
    }
    return(0);
}

Line 235 is

        && (get_pht_entry_from_index(GC_old_normal_bl, index)

Right now I am not really able to make head of this.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

Where there more lines afterwards in the gdb output?

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

It looks like it may be a subtle thread bug in ecls. There are a few bugs I can see when googling around that end up with that message from boehm-gc. The most comprehensive thread about this is https://lists.opendylan.org/pipermail/bdwgc/2011-March/004445.html
I am not sure what to do at this stage and it must be very subtle that it is only hit rarely. One thing to try, disable threads in boehm-gc, ecls and maxima - if you can.

@Thrasymachos
Copy link
Author

There is no further output from gdb, not without backtrace.

There is, however, the following statement at the startup of gdb:

Reading symbols from python...(no debugging symbols found)...done.
Python was not compiled with debug symbols (or it was stripped). Some functionality may not work (properly).

I tried recompiling python2.7 with the nostrip feature enabled, but that didn't change it.

About the threads problem, I will try to remove the USE flag from boehm-gc and ecls. Maxima doesn't seem to have a straightforward way to disable it.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

Indeed no such flag in maxima. It must simply rely on what's in lisp.

@Thrasymachos
Copy link
Author

Well that's weird. Even after removing threads support, the same error appears and the backtrace goes through libpthread.so.0. I will try it again...

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

That is actually possible but that may also show a problem in boehm-gc configuration. I will have a quick look but at least we know there is something fishy in the threading.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

Actually after looking a bit at history of when sage 6.2 made it to the overlay and when boehm-gc 7.4.2 has been made stable, a thing we can try is mask boehm-gc 7.4.0 and 7.4.2 to go back to boehm-gc 7.2e which would have been the one you had before, we may even want to go back to 7.2d if you messed your chronology a bit.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

And 7.2d is what upstream sage ships.

@Thrasymachos
Copy link
Author

I would rather not trust my memory on that issue. In fact I can't remember that it worked at one point and then didn't anymore. I think back then I didn't use sage for a long time period, while still updating everything regularly.
Anyway, I tried that already, going back to an earlier boehm-gc. I went down to 7.2d, without success. I tried 7.1 as well, which is technically the lowest version still supported by ecls-13.5.1, but the ecls code is messed up and doesn't actually support it (they seem to have some typos and wrong function declarations in the #ifdef blocks concerned with boehm-gc features).

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

OK that was a too nice idea to work I guess. Back to the thinking cap, I may have to dive in ecls and may be look at what's in 15.x

@Thrasymachos
Copy link
Author

Mh, if it is of interest, I tried going back to ecls-12.2.1 (and earlier sage versions) at some point, which also didn't fix the issue...
Ah, and I tried the current 15.x ebuild as well.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

It is interesting but that point to a deeper system issue that may be hard to track down.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 28, 2015

It is strange that it doesn't work with boehm-gc 7.1, ecls has its own copy of it along with a copy of 7.2alpha7 dubbed gc-unstable. You would think it works against their internal copy, unless they edited it. Anyway I am now curious to see if sage and maxima will work against the latest ecls, that's a bit of a last ditch effort there.

@Thrasymachos
Copy link
Author

Okay, I read the thread you linked to and compiled boehm-gc without -DALL_INTERIOR_POINTERS manually. I also added -DGC_NO_THREAD_REDIRECTS to ecls and maxima.
Now it works, actually. The symbolic computations are handled just fine. Sage segfaults on quit, though. There are probably memory leaks everywhere. I will investigate this further tomorrow.

I think I will also try to setup a from-scratch gentoo with minimal configuration on a second partition on my machine and see what happens. But this will have to wait at least until the weekend.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 29, 2015

Awesome. I actually want to thank you for the effort. Finding a bug you are the only one so far to see is a daunting task.

@Thrasymachos
Copy link
Author

And I was just about to add another comment thanking you. So, thank you for all your efforts, it was a great help and I learned a lot. Should I file anything of the above to the ecls project? Maybe they are interested in this strange behaviour.

@kiwifb
Copy link
Collaborator

kiwifb commented Apr 29, 2015

That would be nice. I am currently testing 15.3.7 with maxima and sage - it builds and it runs I am just running the whole tes suite to see if anything obvious is broken. It would be nice and appropriate to check if that version is also affected first.

@kiwifb
Copy link
Collaborator

kiwifb commented Oct 5, 2015

We are now allowing building against ecls-16.0.0 which should have a number of fix possibly including on its use of boehm-gc could you give it a go and let me know if that fixes the issue?

@kiwifb kiwifb mentioned this issue Oct 27, 2016
@kiwifb kiwifb closed this as completed Nov 13, 2016
@kiwifb
Copy link
Collaborator

kiwifb commented Jun 27, 2017

Note to self. Vanilla sage compiled with icc displays the same error (although not on the original input).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants