#281 losts assocs

closed-fixed
nobody
pythonwin (176)
8
2008-06-18
2006-05-07
kxroberto
No

build 208
PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.

Get occasionally a trace in the Pythonwin interactive
pane - like this one recently when pressing Ctrl-F
(find tool):

Traceback (most recent call last):
File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of
<pywin.scintilla.find.FindDialog instance at
0x0157FA30>>) raised an exception

I'm noticing this ["win32ui: Internal error - existing
object has type 'PyCWinThread', but 'PyC...' was
requested."] occasionally in very random situations.
Also in other standalone win32ui apps.

This problem may relate to #1475467 (win32ui: Internal
error-existing object is not of same type?). a
"->GetGoodRet()" issue or similar problem?

Discussion

  • kxroberto

    kxroberto - 2006-05-07

    Logged In: YES
    user_id=972995

    trace again (as initial posting removes whitespace):

    Traceback (most recent call last):
    File
    "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
    line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
    win32ui: Internal error - existing object has type
    'PyCWinThread', but 'PyCButton' was requested.
    win32ui: OnInitDialog() virtual handler (<bound method
    FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog
    instance at 0x0157FA30>>) raised an exception

     
  • kxroberto

    kxroberto - 2006-06-06

    Logged In: YES
    user_id=972995

    Think, I found some of the sources for theses kind of bugs.

    I got many other such bugs reported. e.g.:

    File "app.pyo", line 2033, in WmSize\\n\', "win32ui: Internal
    error - existing object has type \'PyCWnd\', but
    \'PyCTabCtrl\' was requested.\\n"]

    I have these strong guesses for bugs:

    * CPythonWinThread::ExitInstance
    the MFC destroys the this pointer, but the assoc is not
    deleted! ==> junk items are pickup ==> bug in OP (see
    skipLookup problem below)

    * ui_propsheet_get_tab_ctrl:
    permanent ui_assoc_object::make is called on temporary pTab
    = pPS->GetTabControl() !!
    (MFC uses FromHandle !)
    PyCWnd::make should be used or something similar to make it
    permanent as required for a Python-Object

    * (for example!): PyCWinThread::create, PyCFormView::create,
    PyCEditView::create, ... (and in most ::create functions)
    ui_assoc_object::make( PyCWinThread::type, pThread ) is
    called with default skipLookup=FALSE
    even if the C object was created brandnew (with 'new' -
    which is in done in 95% of cases) !
    ==> Those map lookups are very likely to pick up undeleted
    junk objects in the map !
    ==> when Objects are created new, skipLookup=TRUE should be
    used - or FALSE the default and TRUE only for GetXXX things
    - or best a new ui_assoc_object::makenew should be used.
    Think this is very important and I attribute many other
    strange win32ui - Internal errors to this risky map management.

    * ui_assoc_object::GetGoodRet
    DODECREF better to be done after DOINCREF !?

    -robert

     
  • kxroberto

    kxroberto - 2006-06-06
    • priority: 5 --> 8
     
  • kxroberto

    kxroberto - 2006-11-18

    Logged In: YES
    user_id=972995
    Originator: YES

    bugs as far as concretely visible are solved now with patch of bug #1590399

    The comment regarding the danger of typical ui_assoc_object::make usage "map lookups are very likely to pick up undeleted
    junk objects in the map" still could be interesting to avoid latent bugs in future.

     
  • kxroberto

    kxroberto - 2006-11-18
    • status: open --> closed
     
  • kxroberto

    kxroberto - 2006-11-21

    Logged In: YES
    user_id=972995
    Originator: YES

    I'm reopening this bug. Just got this with build 210 (patch of GIL bug 1590399 already in):

    >>> Traceback (most recent call last):
    File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 430, in OnCmdEditFind
    find.ShowFindDialog()
    File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 36, in ShowFindDialog
    _ShowDialog(FindDialog)
    File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 50, in _ShowDialog
    curDialog = dlgClass()
    File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 162, in __init__
    dialog.Dialog.__init__(self,self._GetDialogTemplate())
    File "C:\Python23\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 32, in __init__
    dlg=win32ui.CreateDialogIndirect(id)
    win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCDialog' was requested.
    win32ui: Error in Command Message handler for command ID 57636, Code 0

    Most probable its either still the unaddressed problem with CPythonWinThread::ExitInstance (destructor not cleaning up its assoc) problem as described below. Or its another lost object found randomly by ui_assoc_object::make (within win32ui.CreateDialogIndirect; as most of the ::make calls are not forcing to create objects anew but are likely to pick up on random sticky assocs to dead objects, which have not cleaned their assoc accidentally. (Thus big problems arises as consequence of "small" bug)

    -robert

     
  • kxroberto

    kxroberto - 2006-11-21
    • status: closed --> open
     
  • kxroberto

    kxroberto - 2006-11-21
    • summary: Occasionally strange object mixup with GetDlgItem() --> losts assocs
     
  • Roger Upole

    Roger Upole - 2008-02-14

    Logged In: YES
    user_id=771074
    Originator: NO

    I've added skipLookup=TRUE to several places where I've seen this
    most often. However, when trying to address the underlying issue
    with the assocs, it seems as if PyCWinThread's destructor is
    not getting called. Circular references may keep it alive, but I
    haven't dug into it that far yet.

    There is also another problem with CPythonWinThread::ExitInstance.
    virtual int ExitInstance() {
    CVirtualHelper helper("ExitInstance", this);
    if (helper.HaveHandler() && helper.call()) {
    int ret;
    helper.retval(ret);
    return ret;
    } else
    return CWinThread::ExitInstance();
    }

    If there is a python method defined, the base class
    ExitInstance is not called. According to this:

    http://msdn2.microsoft.com/en-us/library/1afc1fkh.aspx

    CWinThread::ExitInstance should alway be called even
    when it is overridden, since this is what actually
    deletes the class.

     
  • Roger Upole

    Roger Upole - 2008-06-18

    Logged In: YES
    user_id=771074
    Originator: NO

    This should finally be fixed in build 211.

     
  • Roger Upole

    Roger Upole - 2008-06-18
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks