I would like to draw attention to bug #6439 (http://bugs.winehq.org/show_bug.cgi?id=6439) in which Enterprise Architect 6.5 (trial version at http://www.sparxsystems.com.au/bin/easetup.exe) crashes with a debug assertion on _CheckNotSysLevel, as detailed in the bug report. From the winedbg trace, the inmediate cause of this debug assertion is the call of GDI_CheckNotLock() at the very start of CreateCompatibleDC(), when the stack of callers in the same thread have already taken references to GDI objects via GDI_GetObjPtr(). The basic question is: why is _CheckNotSysLevel required at CreateCompatibleDC()? What kind of damage might be caused by the removal of the check (in CreateCompatibleDC() and DeleteDC())? On Enterprise Architect, the removal of the assertions allow the app to load the sample file (EAExample.eap) correctly without crashing, and everything appears to work normally.
Alex Villacís Lasso wrote:
I would like to draw attention to bug #6439
Why that bug in particular? Can we pick any other? You seems to really like to copy list of all of your bugs. Hell that's turn this list into another Bugzilla!
You know, I wanted to look at this bug when I get home. And now after reading your email ... I just added you to my list of bug submitters to ignore bugs from.
Vitaliy
At 19:09 18.10.2006 -0600, you wrote:
Alex Villacís Lasso wrote:
I would like to draw attention to bug #6439
Why that bug in particular? Can we pick any other? You seems to really like to copy list of all of your bugs. Hell that's turn this list into another Bugzilla!
You know, I wanted to look at this bug when I get home. And now after reading your email ... I just added you to my list of bug submitters to ignore bugs from.
I'm not an active wine-developer, so you can put my comment wherever you like. But if you don't pay attention you might end up on such a list as well. He has a problem with a program, he has a bug report and he didn't say "Please fix this bug". He intends to do it himself and just asked for some help in understanding the code. That's already a lot more than most other people do posting a problem here. So please stop spreading such an unfriendly mood.
bye Fabi
Vitaliy Margolen escribió:
Alex Villacís Lasso wrote:
I would like to draw attention to bug #6439
Why that bug in particular? Can we pick any other?
Yes, you can:
http://bugs.winehq.org/buglist.cgi?query_format=&short_desc_type=allword...
This search lists 11 (unfixed) bugs that mention _CheckNotSysLevel.
Sorry if I sounded like a newbie, but the question was made in order to avoid sending a patch that would be immediately rejected with "your fix is incorrect, this should be fixed in xyz way at foo.c ..." The only users of _CheckNotSysLevel in the Wine tree are dlls/user and dll/gdi . In dlls/user the pattern seems to be to use USER_Lock() and USER_Unlock() in strict pairs to protect blocks of code and not call any other functions that use USER_CheckNotLock(). In dlls/gdi the lock is taken once every time a reference to a GDI object is requested, but the rule about not calling other functions that check GDI_CheckNotLock() can be violated (at least in my bug) on the rendering of a metafile, as shown by the sequence:
(App tries to draw an icon into a metafile) DrawIconEx calls into StretchBlt (dlls/gdi/bitblt.c:140) StretchBlt calls DC_GetDCUpdate, then DC_GetDCPtr . Both of these functions increment the GDI lock, so it ends up with a lock count of (at least) 2. (dlls/gdi/bitblt.c:148) With lock held, StretchBlt calls into dcDst->funcs->pStretchBlt. Since this is a metafile, it calls into EMFDRV_StretchBlt (dlls/gdi/enhmfdrv/bitblt.c:186) EMFDRV_StretchBlt delegates to EMFDRV_BitBlockTransfer (dlls/gdi/enhmfdrv/bitblt.c:163) EMFDRV_BitBlockTransfer calls into GetDIBits <-- possible source of bug? (dlls/gdi/dib.c:556) GetDIBits calls CreateCompatibleDC with the source HDC (dlls/gdi/dc.c:728) CreateCompatibleDC() calls into GDI_CheckNotLock unconditionally. But StretchBlt already raised the lock count --> debug assertion.
So, when metafiles are involved, this sequence of calls triggers the debug assertion in CreateCompatibleDC(). Since I don't really see the point of having the assertion in CreateCompatibleDC(), I was planning to send a patch to simply remove the assertion. However, the assertion must be there for a reason (debug a deadlock, maybe), so I thought I would check with others with more experience in GDI. If this assertion has to stay, then the metafile functions should be reworked to remove calls to GetDIBits or any other GDI calls that check the assertion. In fact, any GDI call that uses CreateDC[AW], CreateCompatibleDC or DeleteDC must not be called with the GDI lock held, because of the debug assertion.
Alex Villacís Lasso a_villacis@palosanto.com writes:
So, when metafiles are involved, this sequence of calls triggers the debug assertion in CreateCompatibleDC(). Since I don't really see the point of having the assertion in CreateCompatibleDC(), I was planning to send a patch to simply remove the assertion. However, the assertion must be there for a reason (debug a deadlock, maybe), so I thought I would check with others with more experience in GDI. If this assertion has to stay, then the metafile functions should be reworked to remove calls to GetDIBits or any other GDI calls that check the assertion. In fact, any GDI call that uses CreateDC[AW], CreateCompatibleDC or DeleteDC must not be called with the GDI lock held, because of the debug assertion.
Yes, and the assertion should remain there. The real bug is that GetDIBits creates a new DC, it shouldn't need to do that.
-
Alex Villacís Lasso -
Alexandre Julliard -
Fabian Cenedese -
Vitaliy Margolen