|
From: SourceForge.net <no...@so...> - 2006-11-18 11:43:56
|
Bugs item #1475467, was opened at 2006-04-24 13:47 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1475467&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: None Priority: 6 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: win32ui: Internal error-existing object is not of same type? Initial Comment: I get rare reports with this error: "win32ui: Internal error - existing object is not of same type as requested new object" (the last was on a Win XP Prof; build 208 or build205 - not sure) it traces to a bare: tt=win32ui.CreateToolTipCtrl();tt.CreateWindow(parent,0) I don't even find the above error string in the pywin32 sources. Only "Internal error - existing object has type..." in win32assoc.cpp What error is this "existing object is not of same type as requested new object"? Most probably it has to do with (win32tooltip.cpp): return ui_assoc_object::make( PyCToolTipCtrl::type, pTTC ); Many of such ::make's in the win32ui sources have a "->GetGoodRet()" on the line. Some have not. What is the criteria? Is such ->GetGoodRet() maybe necessary in that win32tooltip.cpp location? Can a misbehaviour on such ::make's also cause crashes? (I have occasional mem. access crash reports also; mainly on dual core's) -robert ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-11-18 12:43 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 "ui_assoc_object::make should by default NOT look up, but force-create/replace the assoc" still could be interesting in order to avoid latent bugs in future. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-06-07 13:52 Message: Logged In: YES user_id=972995 as explained in #1483482 this would also most probably be forced correct with ui_assoc_object::make(..., skipLookup=TRUE). The source of the error can be ANY stale temp/wrong/lost assoc in the map: any possible flaw in 1000's of assoc creations in the win32ui code - probably from PyCWinThread's (not cleaned up with ExitInstance). Yet the real problem are not some few (lost/bug) assoc's, but the fact that ANY lost assoc can make everthing instable and case OS-crashes. Meanwhile I'd say not even ui_assoc_object::makenew is the best solution for this (requires 1000's code locations to be changed), but maybe ui_assoc_object::make should by default NOT look up, but force-create/replace the assoc. There are only quite few locations in win32ui where maybe a ui_assoc_object::lookupmake has to be done (and if some are forgotten its not serious - only a new python object will be created at some cost - a DEBUG warning could tell that with time) So the change would be comparably simple: * set skipLookup=TRUE by default * put a mere DEBUG warning if a replaced assoc changes the type (==> indicates illegal use of temporary/lost C-assocs) * search those very very few locations in win32ui code where ui_assoc_object::make is used upon GetXXXX-functions which are really by guarantee not createing new C-objects, but (re-)provide permanent C-Objects. ( in most GetXXX-functions already PyCWnd::make is used correctly and not ui_assoc_object::make !) Think that would greatly improve the stability of win32ui regarding internal errors and random crashes. -robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1475467&group_id=78018 |
