[Bugs] #2064 UNSP: Sudden death while clicking around on the journal

[Sugar Labs Bugs]

#2064: Sudden death while clicking around on the journal
------------------------------------------+---------------------------------
    Reporter:  bernie                     |          Owner:  alsroot                    
        Type:  defect                     |         Status:  new                        
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
   Component:  journal                    |        Version:  0.88.x                     
    Severity:  Unspecified                |       Keywords:                             
Distribution:  Unspecified                |   Status_field:  Unconfirmed                
------------------------------------------+---------------------------------

Comment(by aa):

 This may be tough to debug without reproducing it in a gdb run. Here's
 what Python/Modules/gcmodule.c has to say about this:

 {{{
 update_refs(PyGC_Head *containers)
 {
     PyGC_Head *gc = containers->gc.gc_next;
     for (; gc != containers; gc = gc->gc.gc_next) {
         assert(gc->gc.gc_refs == GC_REACHABLE);
         gc->gc.gc_refs = Py_REFCNT(FROM_GC(gc));
         /* Python's cyclic gc should never see an incoming refcount
          * of 0:  if something decref'ed to 0, it should have been
          * deallocated immediately at that time.
          * Possible cause (if the assert triggers):  a tp_dealloc
          * routine left a gc-aware object tracked during its teardown
          * phase, and did something-- or allowed something to happen --
          * that called back into Python.  gc can trigger then, and may
          * see the still-tracked dying object.  Before this assert
          * was added, such mistakes went on to allow gc to try to
          * delete the object again.  In a debug build, that caused
          * a mysterious segfault, when _Py_ForgetReference tried
          * to remove the object from the doubly-linked list of all
          * objects a second time.  In a release build, an actual
          * double deallocation occurred, which leads to corruption
          * of the allocator's internal bookkeeping pointers.  That's
          * so serious that maybe this should be a release-build
          * check instead of an assert?
          */
         assert(gc->gc.gc_refs != 0);
     }
 }
 }}}

 I couldn't find any destructors in our C extensions, so this may not be
 our bug.

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/2064#comment:1>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system