Changes between Version 2 and Version 3 of Ticket #13447, comment 13


Ignore:
Timestamp:
09/15/12 05:43:30 (7 years ago)
Author:
nbruin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #13447, comment 13

    v2 v3  
    162162The evidence points absolutely to `currRingHdl.data.uring` pointing to unallocated (probably freed) memory. The access then of course can have all kinds of effects. At this point it is probably doable for a `LibSingular` expert to reason about the code whether `uring` should always be valid at this point (I suspect not).
    163163
    164 Keep in mind that in principle, singular code can get executed in rather awkward moments, possibly as part of clean-ups of circular garbage and call-backs on weakref cleanup, where equality might be tested of objects that are soon to be deallocated themselves.
     164It looks suspicious to me that `sage.libs.singular.ring.singular_ring_delete` does do a careful dance to zero out the `currRing` variable but doesn't seem to care about `currRngHdl`. I also find it worrying that there apparently is a refcount system right on the ring structures (as you can see above) and yet in `singular_ring_delete` a separate refcounting dict is used. One would think the same refcounting system should be borrowed by `singular_ring_new` and `singular_ring_delete`. It looks to me the code above thinks that by increasing `...uring.ref` the reference is protected, but `singular_ring_delete` doesn't seem to take into account this refcount. It could well be that I'm misinterpreting the code and that this is all perfectly safe, though.
     165
     166Libsingular specialists: Keep in mind that in principle, singular code can get executed in rather awkward moments, possibly as part of clean-ups of circular garbage and call-backs on weakref cleanup, where equality might be tested of objects that are soon to be deallocated themselves.
    165167
    166168The fickleness of the bug is consistent with this condition arising during a cyclic garbage collection with just the right amount of junk around. That would make the occurrence of the bug depend on just about everything in memory. Or at least if you depend on the corruption leading to a segfault, it depends on which location exactly gets corrupted.