[pywin32-bugs] [ pywin32-Bugs-1483482 ] losts assocs

[SourceForge.net <no...@so...>]

Bugs item #1483482, was opened at 2006-05-07 14:31
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 8
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: losts assocs

Initial Comment:
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?



----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2008-06-18 16:43

Message:
Logged In: YES 
user_id=771074
Originator: NO

This should finally be fixed in build 211.

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-02-14 14:31

Message:
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.


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-11-21 06:40

Message:
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

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-11-18 06:42

Message:
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.

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-06-06 12:10

Message:
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


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-05-07 14:32

Message:
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018