#281 losts assocs

[kxroberto]

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?

[kxroberto]

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]

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]

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]

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

[Roger Upole]

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]

Logged In: YES
user_id=771074
Originator: NO

This should finally be fixed in build 211.