#715: Parents probably not reclaimed due to too much caching
-------------------------------------------------------------------+--------
Reporter: robertwb |
Owner: somebody
Type: defect |
Status: needs_review
Priority: major |
Milestone: sage-5.4
Component: coercion |
Resolution:
Keywords: weak cache coercion Cernay2012 | Work
issues:
Report Upstream: N/A |
Reviewers: Jean-Pierre Flori, Simon King, Nils Bruin
Authors: Simon King, Jean-Pierre Flori | Merged
in:
Dependencies: #9138, #11900, #11599, to be merged with #11521 |
Stopgaps:
-------------------------------------------------------------------+--------
Comment (by nbruin):
Replying to [comment:269 SimonKing]:
> Do I get SEGV? Is that a synonym of signal 11?
Ah, yes. SIGSEGV (a segmentation fault) gets communicated via a signal 11.
> Is it preventing it from happening? I thought we have found that some
signal problem is still present for sub-processes created with
p_iter_fork.
Right. But signal handlers and segfaults are only related to the extent
that a segmentation fault gets communicated via a signal. So being killed
because of a "signal 11" doesn't particularly indicate any problem with
stray signals or signal handlers. It's probably just a plain memory fault.
At this point I think there is little ground to assume the SIGABRT issues
observed are related to the segmentation fault. In particular because
#13437 fixes one and not the other.
Even if there is a connection, it doesn't seem that exploring a
hypothetical one is going to help much in tracing the problem. If
{{{
$ sage -sh
...
> python -t failing_test_under_gdb.py
}}}
is giving you a segfault, perhaps you can get that to dump core? (if I
send
`kill -11 [python process]` I get a core dumped if I unset the limit).
Alternatively, perhaps
{{{
> sage failing_test_under_gdb.py
}}}
is close enough that it still segfaults. Sage installs a more useful
SIGSEGV handler that at least gives you a traceback on stderr. Apparently
involving gdb changes things too much to still observe the error, so from
that point it's just tweaking the file and/or sage to see where the error
is originating.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/715#comment:270>
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.
