On Sep 6, 1:48 pm, Simon King <simon.k...@uni-jena.de> wrote: > > We've seen before that invalidated expect interfaces can interact > > unexpectedly with weakreffed stuff in entirely unrelated places. > > Is it known how the interaction occurs? Is there a ticket or an example > explaining the relation?
The issue we ran into was where the deletion of a Gap key from a WeakValueDictionary lead to big problems because __eq__ got called on the gap element when the gap interface was already torn down, just to look up the key for deletion. You solved the symptom by putting a "gc.collect()" in sage.quit. see also http://trac.sagemath.org/sage_trac/ticket/13394 However, it doesn't seem that this particular issue is to blame. I can imagine that weaker references mean more things get deleted upon invalidation of the expect interfaces, which might just push execution times over the SIGALRM limit. I suspect that if you really stress the Parallel iterator's timeout feature together with lots of parallel processes, you might be able to triggrer the observed problem more reliably on bsd. This would corroborate the hypothesis that we're observing leaked SIGALRMs here. I'm no signal handling expert either, but I suspect that any python- level signal handling is going to be much more prone to racing conditions because there is much more time between setup/scheduling/ tearing down the handling of signals (and they don't get blocked in between!). Using sigaction might alleviate the problem. If you can localize the problem to flakey signal handling, I'm sure our local signal expert Jeroen will be quite willing to clean it up. > I also tried trace("...") I'd be wary of "trace" on these kinds of cross-fork problems. I'd go with the usual "print" options. Or actually, you might prefer looking the python logging module, because with all the stdout/stderr redirection involved in this forking, I wouldn't be so sure that a print message would make it to the screen. Also, don't forget to flush. There'll be a lot of processes writing to the log! I don't have access to a machine where I can reproduce the problem, so I'm limited to arm-chair debugging here. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
