-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
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. |
OK not getting it here
output of |
I'm also not getting it on other machines (e.g. at work). Here are the outputs of eix:
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. |
Looking at the backtrace we may want to go back to |
Sure.
|
I just figured out
already produces the exact same error. |
Feels like something is fundamentally broken with threads there. |
Here you are:
|
Strange flags, I don't really know they are the root cause of your problem but I think you should change your |
Thank you. I will run |
Sadly, that didn't do any good. I actually ran |
Doubtful, I have similar settings if not similar cpu. Could you enable debugging in ecls and boehm-gc. With |
Okay, I enabled the |
Can you tell me what kind of problem you had running |
First I tried to run
Then:
The corresponding function from
Line 235 is
Right now I am not really able to make head of this. |
Where there more lines afterwards in the gdb output? |
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 |
There is no further output from There is, however, the following statement at the startup of
I tried recompiling python2.7 with the 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. |
Indeed no such flag in maxima. It must simply rely on what's in lisp. |
Well that's weird. Even after removing threads support, the same error appears and the backtrace goes through |
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. |
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. |
And 7.2d is what upstream sage ships. |
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. |
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 |
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... |
It is interesting but that point to a deeper system issue that may be hard to track down. |
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. |
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. 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. |
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. |
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. |
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. |
We are now allowing building against |
Note to self. Vanilla sage compiled with icc displays the same error (although not on the original input). |
Whenever I try something with symbolic manipulation in Sage, ECL throws an error:
I'm running Sage 6.6
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?
The text was updated successfully, but these errors were encountered: