- Wine-Devel - list.winehq.org

DC lock in CreateDIBitmap
by Uwe Bonnes Aug. 16, 2001

Aug. 16, 2001

Hallo, with the new GDI_CheckNotLock() stuff, some application (gcprevue 9) fails with > err:win32:_CheckNotSysLevel Holding lock 0x4079b9e8 level 3 Backtrace is: Backtrace: =>0 0x400e21d1 (_CheckNotSysLevel+0x51(lock=0x4079b9e8) [syslevel.c:152] in libntdll.so) (ebp=405c6090) 1 0x4078261c (GDI_CheckNotLock+0x1c [gdiobj.c:510] in libgdi32.so) (ebp=405c60a0) 2 0x4077823d (CreateDCA+0x1d(driver=0x407909d3, device=0x0, output=0x0, initData=0x0, s=0x0, s=0x0, s=0x407909d3) [dc.c:558] in libgdi32.so) (ebp=405c61e8) 3 0x4077bbc6 (CreateDIBitmap+0x166(hdc=0xdec, header=0x41eadb50, init=0x0, bits=0x0, data=0x41eadb50, coloruse=0x0) [dib.c:881] in libgdi32.so) (ebp=405c6218) 4 0x409f9479 (X11DRV_DIB_CreateDIBSection+0x359(dc=0x404225f4, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:3914] in libx11drv.so) (ebp=405c62a0) 5 0x4077bd75 (DIB_CreateDIBSection+0x65(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:944] in libgdi32.so) (ebp=405c62d4) 6 0x4077bdd1 (CreateDIBSection+0x31(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0) [dib.c:961] in libgdi32.so) (ebp=405c6304) 7 0x00401fba (gcprevue.exe..text+0xfba in D:\cae\gcp9.0.0.8\gcprevue.exe) (ebp=ffffffff) CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause is true, CreateDCA() checks that the lock is not hold. A laymans approach to release hdc before CreateDCA() and reopen it afterwards resulted in this report asr startup, with no visual output: fixme:win32:PE_CreateModule Security directory ignored err:win32:_LeaveSysLevel (0x4079ba08, level 3): Invalid state: count 0 mutex (nil). err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=030f err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=031f err:ntdll:RtlpWaitForCriticalSection section 0x4079ba08 "gdiobj.c: GDI_level" wait timed out, retrying (60 sec) fs=008f How to cure this problem? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Stupid Winedbg question
by Bobby Bingham Aug. 16, 2001

Aug. 16, 2001

Ok, I feel like an idiot for having to ask this, but it's my first time realing using the debugger. When wine starts the debugger on an exception, it opens it up in another xterm. Is there an easy way to copy it's output? The usual select and middle-click isn't working because it doesn't let me select the text to begin with. Thanks in advance for your patience. Bobby Bingham

3 2

Re: Extra space at bottom of toolbar
by Guy L. Albertelli Aug. 16, 2001

Aug. 16, 2001

-----Original Message----- From: Bobby Bingham <uhmmmm(a)ameritech.net> To: Wine Devel <wine-devel(a)winehq.com> Date: Thursday, August 16, 2001 12:28 AM Subject: Extra space at bottom of toolbar >Has anyone else seen this... In WinZip 8.0 (I don't know about other >versions/software), there are about 6 extra pixels at the bottom of the >toolbar below the buttons. Does anyone know what's causing this? I can look >into it if I get some time, but I was wondering if anybody knew. > >Bobby Bingham > > The current CVS shows the following differences between the builtin control and the native one: 1. Button top-left corner is 2 pixels too high. 2. Button is 2 pixels too short. 3. Background bar is 2 pixels too wide. This gives the 6 pixels you noticed. Items 1 & 2 are definitely within the toolbar.c. Item 3 may be in either toolbar or rebar. I need to work on moving screenshots from Win to Linux for comparison. Guy

1 0

Re: Protocol for adding FIXMEs
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

"Bill Medland" <medbi01(a)accpac.com> writes: > However I am occasionally frustrated by the number of times I see the same > FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also > recognise from posts that these disconcert newbies whereas after a couple > of weeks one gets used to them. > > So maybe it is better to use FIXME comments where one knows that something > is wrong but it doesn't seem to matter. FIXME macros should be used in cases where we know something is wrong but we don't expect this part of the code to ever get used. This way if some app triggers the wrong code we can hear about it. It doesn't make sense to add FIXME output to parts of the code we know are going to be called, it just generates noise; a comment is much better in this case. > (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and > if it is TRUE then the lParam no longer points to a simple rectangle but to > a structure whose first element is a rectangle. Very little if any code > handles that case explicitly.) I don't think this specific case is a FIXME at all. Apps are allowed to ignore the extra information if they don't have any use for it. -- Alexandre Julliard julliard(a)winehq.com

1 0

_CheckNotSysLevel (was: patch.py?id=997918367324549717828631)
by lawson_whitney＠juno.com Aug. 16, 2001

Aug. 16, 2001

On Thu, 16 Aug 2001 whit(a)giftie.alien.org wrote: > Good day! > > I can't remember that I've ever seen the fixme that was here before, > but I'll check again when I send this. > Is that a new fixme? I reversed just this patch and there are more of this fixme than any other. Hope the backtrace I sent before is useful. Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: _CheckNotSysLevel Patch
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > winedbg winzip32 > ... > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > Stopped on breakpoint 1 at 0x004677fa (WINZIP32.EXE.EntryPoint in C:\Program > Files\WinZip\WINZIP32.EXE) If you run under winedbg directly the CheckNotSysLevel breakpoints are ignored, and it only stops at the program entry point; and the backtrace there is useless. Please run it under wine and let it start the debugger by itself when encountering the first CheckNotSysLevel, then you should get a proper backtrace. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: _CheckNotSysLevel Patch
by Alexandre Julliard Aug. 16, 2001

Aug. 16, 2001

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) > Read the Wine Developers Guide on how to set up winedbg or another debugger > > if the debugger is set up, I can continue, and and it works just fine. Before the continue, could you please do a backtrace and mail it to me? Thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Protocol for adding FIXMEs
by Bill Medland Aug. 16, 2001

Aug. 16, 2001

What do people think? I seem to have a knack for finding things that are probably going to need fixing at some point but for which I do not have time or knowledge currently. My first temptation is to add a FIXME macro in the code directly. However I am occasionally frustrated by the number of times I see the same FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also recognise from posts that these disconcert newbies whereas after a couple of weeks one gets used to them. So maybe it is better to use FIXME comments where one knows that something is wrong but it doesn't seem to matter. (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and if it is TRUE then the lParam no longer points to a simple rectangle but to a structure whose first element is a rectangle. Very little if any code handles that case explicitly.) I know that the manual (wine-devel 8.0) says to add FIXMEs I am concerned that this could lead to ridiculously large traces that hide the important stuff (to say nothing of upsetting timing) Any other views? Bill

1 0

RE: Toolbar background error
by Medland, Bill Aug. 16, 2001

Aug. 16, 2001

I'll handle it. I have this horrible feeling its the compiler again (2.96-85; RedHat 7.1). (It seems to be a side-effect of DPtoLP!!??) Bill > -----Original Message----- > From: Guy L. Albertelli [SMTP:galberte(a)neo.lrun.com] > Sent: Wednesday, August 15, 2001 7:30 PM > To: Bill Medland > Cc: Wine Devel > Subject: Re: Toolbar background error > > > -----Original Message----- > From: Bill Medland <medbi01(a)accpac.com> > To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> > Date: Wednesday, August 15, 2001 4:39 PM > Subject: Re: Toolbar background error > > > >> > >> > >In case you haven't found it yet it is in windows/defwnd.c; the change > made > >between 1.57 and 1.58. Are you going to handle it? > > > >Bill > > > > > Bill, > > Great job in tracking it down. I probably won't get to having time till > Friday evening. If you see the problem and know the fix, by all means go > and > fix it. Otherwise I will look into this Friday. > > Thanks again, > Guy

3 2

patch.py?id=997918367324549717828631
by lawson_whitney＠juno.com Aug. 16, 2001

Aug. 16, 2001

Good day! I guess native riched32.dll does something nasty to provoke the new DbgBreakPoint in _CheckNotSysLevel. Builtin riched32 doesn't, of course, but then the app won't start. I can't remember that I've ever seen the fixme that was here before, but I'll check again when I send this. I've attached a backtrace. I'd appreciate some guidance on what else might be useful, or maybe a pointer to some doco on critical sections in Wine, even it is in .sgml, .c or .h in case I have to debug it myself. Regards, Lawson

1 0