#11752: ecl.pyx should not touch SIGPWR neither SIGXCPU when initializing ecl
--------------------------+-------------------------------------------------
Reporter: pcpa | Owner: was
Type: defect | Status: new
Priority: major | Milestone: sage-4.7.2
Component: interfaces | Keywords:
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
--------------------------+-------------------------------------------------
Comment(by nbruin):
Some observations:
- the fact that you land in ECL's break-loop is indeed a sign something
is broken, because we run the equivalent of a "try ... expect" in
ecl_eval, so the interrupt should be caught and propagated up. I suspect
this breaks because you are running it in a thread-enabled ECL. Perhaps
the ctrl-C arrives at a different thread that is not running under such
protection? There has to be a thread-aware option in ECL to change the
handling of SIGINT, though. We could adjust that
- You should exit ECL's break-loop with ":q", not "(quit)". The latter
terminates the ECL session, but because ECL is not running its top-level
(it's embedded), it cannot really do this and hence leaves the system in
an inconsistent state. So the memory corruption you are observing is
probably not due to erroneous signal handling.
Thank you for testing this! It looks like for now we should really advise
people against running ECL in thread-enabled mode inside Sage.
Unfortunately, it seems enabling/disabling threads is something done at
configure time, not at ECL run time.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11752#comment:6>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.