Underlying C/C++ object has been deleted in PurgeDialog

Issue #2386 resolved
Anonymous created an issue
** Mercurial version (2.4+6-35ba170c0f82).  TortoiseHg version (2.6)
** Command: 
** CWD: C:\Windows\system32
** Encoding: cp1252
** Extensions loaded: graphlog, purge
** Python version: 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
** Windows version: sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1')
** Processor architecture: x64
** Qt-4.8.0 PyQt-4.9.1
Traceback (most recent call last):
  File "tortoisehg\hgqt\purge.pyo", line 176, in completed
  File "tortoisehg\hgqt\purge.pyo", line 149, in reject
RuntimeError: underlying C/C++ object has been deleted

Comments (5)

  1. Steve Borho

    FWIW: I've seen this recently from the commit tool as well

    These errors are harmless (the dialog is closing), perhaps we should catch these in our exception handler and not show a bug report for them, at least until we come up with a comprehensive solution for this particular race hazard.

  2. Yuya Nishihara

    I'm -1 for hiding this error globally, because there may be unknown case. What about capturing only known cases?

    I guess this kind of error is due to deleteLater(). If I understand it, deleteLater() first deletes C++ object, and later, GC collects Python object if no reference exists.

    Instead, using setParent(None) seems much safer, which just leaves it to Python GC. (But some objects are not GC-able without deleteLater(), and will cause memleak.)

  3. Yuya Nishihara

    purge: move completed() handlers to instance to avoid GC issue (fixes #2386)

    Accessing self from dynamic function increases refcount, and it may cause "C/C++ object deleted" error in conjunction with deleteLater().

    Also marked them as pyqtSlot() to reduce risk of stale signal-slot connection.

    → <<cset c45ec4695f4f>>

  4. Log in to comment