April 2001 - Wine-Devel - list.winehq.org

Re: fault handling - oof

by lawson_whitney＠juno.com

On Tue, 24 Apr 2001, eric pouech wrote: > don't want to be sarcastic at your fingers, but I don't see how a fix > in the debugger could change the way an app work when the debugger is > not > launched... > did you try to run the app with the debugger started before the crash > to see where you get the first fault ? > > A+ > -- > --------------- > Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) > "The future will be better tomorrow", Vice President Dan Quayle > I don't either, but that is what seems to be happening. Do you mean start the debugger by itself and attach the app before it faults, or run the app with the debugger? I applied the patch by itself. Of installable things, that changes only the debugger, but I installed whatever make install sees fit to install. The app won't start. I restored only the debugger from a local.tar, since only it changed. The app still won't start. I restored all of local to the state before the patch and it will. This makes so little sense I am embarassed to write about it. I am going to go out and get some fresh air and see if it can clear my head. Okay, it started raining, so I only did 8km on the push-bike instead of 16, but it seems to have helped. If you get this, it comes by wine with the debugger patch in. It seems I was getting HD errors which were causing wine to hang and otherwise misbehave. Load a library, and when you are done there is nothing there, so when the init code gets called, it faults. reverting moved the files to sectors that happened to work. I should have known when the same version of wine worked on one box and not on the other for the same app (shared by nfs) but at the time it only made my head hurt. e2fsck -c has fixed it for now, but sterner measures may become necessary. Sorry for the noise, and thanks for insisting on common sense. There was nothing wrong with any of those patches after all. Lawson It is impossible to make anything foolproof because fools are so ingenious. ---cut here ________________________________________________________________ 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.

April 25, 2001

AVI resource in shell32.dll

by Stefan Leichter

Hi all, during debugging an installer (of Wiso Homebanking Try&Buy Version from Buhl Data) i found that native shell32.dll contains at least one AVI resource (the magnifier that is spinning in front of a computer) that is not implemented in the buildin shell32.dll. I have looked around in the source tree of wine but i did not find any resource from typ AVI. Now my questions: Is someone working on an implementation of avi resources into the buildin dlls? If not, what needs to be done to start implementing avi resources into the dlls? Bye Stefan

April 24, 2001

Re: GDI syslevel held during psdrv init ... bad

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Now the reason is, that pCreateDC is always called with the GDI syslevel (3) > held, so _any_ call to relaying here will dump. > > How do we fix this? We could probably get rid of the check. Syslevel locking is reasonably stable now, and dll separation will cause more and more false alarms here. -- Alexandre Julliard julliard(a)winehq.com

April 24, 2001

Re: fault handling - oof

by eric pouech

> I have got the first 2 back in again and it seems still to work, so I > guess you are exculpated. That leaves only the debugger patch or my own > fat fingers. don't want to be sarcastic at your fingers, but I don't see how a fix in the debugger could change the way an app work when the debugger is not launched... did you try to run the app with the debugger started before the crash to see where you get the first fault ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

April 24, 2001

Re: fault handling - oof

by lawson_whitney＠juno.com

On 24 Apr 2001, Alexandre Julliard wrote: > A fixup_imports crash sounds a bit like what other people reported > seeing with the shared sections fix. Did you run two instances of the > application by any chance? > > -- > Alexandre Julliard > julliard(a)winehq.com > It does, doesn't it? No, or only by accident would I have had 2 instances. I wish I had been thinking clearly while I had the debugger on it. Maybe next time. Lawson ---cut here ________________________________________________________________ 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.

April 24, 2001

Re: fault handling - oof

by lawson_whitney＠juno.com

On Tue, 24 Apr 2001, Francois Gouget wrote: > If you're using native msvcrt then the first two should have no > impact. If you meant that the crash only occurs when you try using the > builtin msvcrt then maybe it's the patch to time.c. But I would still > don't see why... quite the opposite. > Let us know if you find out more about this. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > {free} || die ""; > I have got the first 2 back in again and it seems still to work, so I guess you are exculpated. That leaves only the debugger patch or my own fat fingers. Lawson It is impossible to make anything foolproof because fools are so ingenious. ---cut here ________________________________________________________________ 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.

April 24, 2001

Re: fault handling - oof

by Alexandre Julliard

lawson_whitney(a)juno.com writes: > I got what looked like a recursive page fault somewhere in > startup/fixup_imports until I reverted all 3. A fixup_imports crash sounds a bit like what other people reported seeing with the shared sections fix. Did you run two instances of the application by any chance? -- Alexandre Julliard julliard(a)winehq.com

April 24, 2001

GDI syslevel held during psdrv init ... bad

by Marcus Meissner

Hi, While trying to debug something I come across this problem: Call gdi32.CreateICA(405b59eb "WINEPS",405b59d4 "Wine PostScript Driver",405b59f 2 "LPT1:",00000000) ret=007a6674 tid=08063338 trace:relay:PE_InitDLL CallTo32(entryproc=0x4bef3270,module=4beeb000,type=1,res= (nil)) err:psdrv:PSDRV_AFMGetCharMetrics missing ;, failed. [C 0 ; WX 600 ; N null] fixme:psdrv:PSDRV_FindPrinterInfo 'Wine PostScript Driver' Call kernel32.MultiByteToWideChar(00000000,00000000,4c057534 "Wine PostScript Dr iver",ffffffff,00000000,00000000) ret=40953fd4 tid=08063338 err:win32:SYSLEVEL_CheckNotLevel (2): Holding lock of level 3! Now the reason is, that pCreateDC is always called with the GDI syslevel (3) held, so _any_ call to relaying here will dump. How do we fix this? Ciao, Marcus

April 24, 2001

Re: fault handling - oof

by Francois Gouget

On Tue, 24 Apr 2001 lawson_whitney(a)juno.com wrote: > > On Tue, 24 Apr 2001, Francois Gouget wrote: > > > > > If you're using native msvcrt then the first two should have no > > impact. If you meant that the crash only occurs when you try using the > > builtin msvcrt then maybe it's the patch to time.c. But I would still > > don't see why... quite the opposite. > > Let us know if you find out more about this. > > I thought I saw that wine itself is now using the msvcrt headers, so > maybe a macro... no, I can't see that it is. Only the sources of the msvcrt dll use the msvcrt headers. This helps find bugs and make sure things are coherent. Normally the other libraries don't use the msvcrt headers (I don't think there would be any reason for them to). So all problems should be restricted to the msvcrt library. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

April 24, 2001

Re: fault handling - oof

by lawson_whitney＠juno.com

On Tue, 24 Apr 2001, Francois Gouget wrote: > > If you're using native msvcrt then the first two should have no > impact. If you meant that the crash only occurs when you try using the > builtin msvcrt then maybe it's the patch to time.c. But I would still > don't see why... quite the opposite. > Let us know if you find out more about this. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > {free} || die ""; > I thought I saw that wine itself is now using the msvcrt headers, so maybe a macro... no, I can't see that it is. crtdll defaults to builtin: [DllOverrides] "*" = "builtin, so, native" [AppDefaults\\juno.exe\\DllOverrides] "msvcrt" = "native" "riched32" = "native" but AFAIK, the app doesn't use crtdll. No, if I'd had builtin msvcrt working and a patch made it crash, I would just debug that, I think. It may take a while, but I will worry at it until I find it. Thanks Lawson ---cut here ________________________________________________________________ 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.

April 24, 2001