- Wine-Devel - list.winehq.org

GDB remote debugging for wine
by Ove Kaaven April 21, 2001

April 21, 2001

As we all know, gdb isn't very compatible with wine, since gdb makes so many assumptions about the operating environment that isn't true in wine. But lately it occurred to me that perhaps it's possible to use gdb's remote debugging features to solve these issues. So recently, I've been secretly experimenting with writing gdb-server code in the wineserver. It goes something like this... ./configure --enable-remote-gdb [...blah...] $ wine stuff gdb socket ready at: target remote localhost:1234 $ gdb wine (gdb) target remote localhost:1234 and you're currently able to look at registers, backtrace, list all the threads, change thread, and read process memory... neato. But its usefulness might be quite limited since gdb doesn't know about the dynamically-loaded dlls so it doesn't automatically load their symbols... does anyone have ideas on how to solve that? It doesn't appear that the standard remote protocol have a command to tell gdb, and I don't know how gdb ordinarily does it. I've pondered making wine generate a file full of "add-symbol-file" commands or something that could be executed by gdb, but I don't know how to do that cleanly... preferably hacks for loading symbols should be transparent to the developer, and new symbols loaded automatically after new dlls are loaded. Hmm...

2 1

Crash due to some fixme messages in CreateProcessA
by Lionel Ulmer April 20, 2001

April 20, 2001

Hi all, While running a program, I got a crash in the CreateProcessA, in the following debug TRACE line : if (lpStartupInfo->lpDesktop) FIXME("(%s,...): lpStartupInfo->lpDesktop %s ignored\n", name, lpStartupInfo->lpDesktop); By running the debugger, I got this : Wine-dbg>print *lpStartupInfo print *lpStartupInfo {cb=83886080, lpReserved=*** Invalid address 0x4c000000 (_end+0xb823758) , lpDesktop=*** Invalid address 0x4c403416 (_end+0xbc26b6e) , lpTitle=*** Invalid address 0x70403416 (_end+0x2fc26b6e) , dwX=1883255830, dwY=406860822, dwXSize=1107296256, dwYSize=-1795162040, dwXCountChars=1849690049, dwYCountChars=1819042932, dwFillAttribute=1819042862, dwFlags=791899392, wShowWindow=26988, cbReserved2=14946, lpReserved2=*** Invalid address 0x7273752f (_end+0x31f5ac87) , hStdInput=409955375, hStdOutput=1107296256, hStdError=-285212600} It means that we are seeing a very broken application where these fields (lpDesktop and lpTitle) do not seem to be filled in propery... Now I never tried running this application on Windows to test if it even works, but I suppose it should work (otherwise it would not be burned on the CD :-) ). So what should we do ? Suppress the '%s' and replace it with a '%p' ? Add a check on the pointer to see if it's valid ? Lionel PS: BTW, why is this application that is on a win95 filesystem get run as : Call kernel32.CreateFileA(00405070 "~inst.exe",40000000,00000000,00000000,00000002,00000080,00000000) ret=00401391 tid=080678a0 Thus leading to a "~inst.exe" not found... -- Lionel Ulmer - http://www.bbrox.org/

2 2

FONT 8 requested, but 6x12 choosen: Wrong setup?
by Uwe Bonnes April 20, 2001

April 20, 2001

Hallo, the entry dialog of the Encarta 99 setup (from Computer Bild) looks wrong on my system: The box is to small and graphics and text overlap. This is caused by CreateDialogIndirect requesting an Font with width 8, but wine choosing a font with width 6. Manually correcting the return value of DIALOG_GetCharSizeFromDC to 8 gets the visula impression right. Is this caused by me setting up something wrong? Any hints how to setup right? Call USER.219: CREATEDIALOGINDIRECT(0x02fe,058f:0008,0x0390,0x02ef7778) ret=02ef:76b5 ds=02ff trace:dialog:DIALOG_ParseTemplate16 DIALOG 0, 0, 293, 214 trace:dialog:DIALOG_ParseTemplate16 STYLE 50000040 trace:dialog:DIALOG_ParseTemplate16 CAPTION '' trace:dialog:DIALOG_ParseTemplate16 FONT 8,'Helv' trace:font:X11DRV_FONT_SelectObject hfont=ffed trace:font:XFONT_RealizeFont physfont 1 trace:font:CreateFontIndirectW (-10 0 0 0) 'L"Helv"' => 09f6 trace:font:XFONT_UnAlias found alias 'Helv'->Helvetica' trace:font:X11DRV_FONT_SelectObject hfont=09f6 trace:font:XFONT_MatchDeviceFont (1) 'Helvetica' h=-10 weight=0 trace:font:XFONT_MatchDeviceFont found facename 'Helvetica' trace:font:XFONT_Match [ 10pt h=12 w=6 Bold Italic] trace:font:XFONT_Match returning 518 ... trace:font:XFONT_Match [ 12pt h=18 w=10 Normal ] trace:font:XFONT_Match returning 560 trace:font:XFONT_Match [ 13pt h=20 w=11 Normal ] trace:font:XFONT_Match returning 576 trace:font:XFONT_Match [ 17pt h=27 w=14 Normal ] trace:font:XFONT_Match returning 624 trace:font:XFONT_Match [ 23pt h=35 w=19 Normal ] trace:font:XFONT_Match returning 688 trace:font:LFD_ComposeLFD LFD(uRelax=0): -adobe-helvetica-medium-r-normal-*-11-*-100-100-p-*-iso8859-1 trace:font:XFONT_RealizeFont physfont 3 trace:font:GetTextMetricsW text metrics: Weight = 400 FirstChar = 32 AveCharWidth = 6 Italic = 0 LastChar = 255 MaxCharWidth = 11 UnderLined = 0 DefaultChar = 32 Overhang = 0 StruckOut = 0 BreakChar = 32 CharSet = 0 PitchAndFamily = 21 -------------------- InternalLeading = 2 Ascent = 10 Descent = 2 Height = 12 trace:font:GetTextExtentPointA not bug compatible. trace:font:GetTextExtentPoint32A (00000088 "abcd"... 4 0x407c6c8c): returning 22 x 12 trace:dialog:DIALOG_GetCharSizeFromDC Using tm: 6x12 (dlg: 6 x 12) (variable) Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Re: Strange crash
by gerard patel April 20, 2001

April 20, 2001

At 10:30 AM 20/04/2001 +0200, you wrote: <snip> >The lower 6 bits are the new floating point exception masks. Mine are >all set and yours are cleared, therefore the crash. > >Why that is the case, I haven't got a clue. I'm not sure I followed everything, but it could come from a problem that occurred a lot of time before, no? The bits could be already cleared on entry of the subroutine. If the exception handling bits are cleared and the app don't do anything with floating point, nothing will break, AFAICT. If this is the case a way could be to patch the code to print the mask with every +relay operation. BTW, I wonder if Dmitry has done some classic tricks like - getting a fresh tree from Winehq - compiling everything with -O0 - trying the same app on another computer with a (as much as possible) different configuration. Gerard

2 1

problem with native dll's.
by Rein Klazes April 20, 2001

April 20, 2001

Hi, Since the cvs commits early this week or the last (I could be more precise but that will take a while) I have noticed a problem with some native dlls. If I start one app that uses such a dll and then another using the same dll may crash. If this second app is started as the first process it runs fine. As an example eudora, using native commctrl/comctl32 crashes when it loads these dlls: | Unhandled exception: priviledged instruction | in 32-bit code (0x406e12b8). | In 32-bit mode. | 0x406e12b8 (GetTextColor+0x34 [dcvalues.c:177]): hlt | 177 DC_GET_VAL( COLORREF, GetTextColor, textColor ) | Wine-dbg>bt | Backtrace: | =>0 0x406e12b8 (GetTextColor+0x34(hdc=0x0) [dcvalues.c:177]) (ebp=405b6dc4) | 1 0xbfebbd8d (COMCTL32.DLL.341+0x74) (ebp=405b6dd8) | 2 0xbfebbceb (COMCTL32.DLL.EntryPoint+0x36) (ebp=405b6e04) | 3 0x4008abe3 (MODULE_InitDLL+0x97(wm=0x40383d84, type=0x1, lpReserved=0x1) [module.c:115]) (ebp=405b6e24) | 4 0x4008acf1 (MODULE_DllProcessAttach+0xd1(wm=0x40383d84, lpReserved=0x1) [module.c:182]) (ebp=405b6e48) | 5 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x403838f4, lpReserved=0x1) [module.c:177]) (ebp=405b6e68) | 6 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x4038302c, lpReserved=0x1) [module.c:177]) (ebp=405b6e88) | 7 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x403826f8, lpReserved=0x1) [module.c:177]) (ebp=405b6ea8) | 8 0x4008accd (MODULE_DllProcessAttach+0xad(wm=0x0, lpReserved=0x1) [module.c:177]) (ebp=405b6ec8) | 9 0x400d288f (start_process+0x133 [process.c:373]) (ebp=405b6f30) | 10 0x400d5f99 (SYSDEPS_DoCallOnStack+0x25(func=0x400d275c, arg=0x0) [sysdeps.c:173]) (ebp=405b6ff0) | 11 0x400d603f (SYSDEPS_CallOnStack+0x2f) (ebp=bffff8d4) | 12 0x400d60e2 (SYSDEPS_SwitchToThreadStack+0x8e(func=0x400d275c) [sysdeps.c:236]) (ebp=bffff908) | 13 0x400d2c5d (PROCESS_InitWine+0x1a1(argc=0x5, argv=0xbffff9a4, win16_exe_name=0x804d5c0, win16_exe_file=0x804d6c4) [process.c:524]) (ebp=bffff924) | 14 0x0804c164 (Letext [main.c]) (ebp=bffff93c) | 15 0x4028116b (NTDLL.DLL.sqrt+0x3bc6b) (ebp=bffff978) | 16 0x08049021 (_start+0x21) (ebp=00000000) The ip register is pointing to some instruction byte, making it an bogus opcode, "hlt" in this case: | Wine-dbg>disass $eip-12,$eip+10 | 0x406e129c (GetTextColor+0x18 [dcvalues.c:177]): call 0x406bf664 (_init+0x67c) | 0x406e12a1 (GetTextColor+0x1d [dcvalues.c:177]): addl $4,%esp | 0x406e12a4 (GetTextColor+0x20 [dcvalues.c:177]): testl %eax,%eax | 0x406e12a6 (GetTextColor+0x22 [dcvalues.c:177]): jz 0x406e12b4 (GetTextColor+0x30 [dcvalues.c:177]) | 0x406e12a8 (GetTextColor+0x24 [dcvalues.c:177]): movl 0x88(%eax),%edi | 0x406e12ae (GetTextColor+0x2a [dcvalues.c:177]): pushl %esi | 0x406e12af (GetTextColor+0x2b [dcvalues.c:177]): call 0x406bfee4 (_init+0xefc) | 0x406e12b4 (GetTextColor+0x30 [dcvalues.c:177]): movl %edi,%eax | 0x406e12b6 (GetTextColor+0x32 [dcvalues.c:177]): leal 0xfffffff4(%ebp),%esp | 0x406e12b9 (GetTextColor+0x35 [dcvalues.c:177]): popl %ebx | 0x406e12ba (GetTextColor+0x36 [dcvalues.c:177]): popl %esi | 0x406e12bb (GetTextColor+0x37 [dcvalues.c:177]): popl %edi | 0x406e12bc (GetTextColor+0x38 [dcvalues.c:177]): leave | 0x406e12bd (GetTextColor+0x39 [dcvalues.c:177]): ret $0x4 | 0x406e12c0 (GetViewportExt16 [dcvalues.c:182]): pushl %ebp Redoing the experiment (by starting and stopping all apps's) will give crashes at slightly different places. Has any one a suggestion? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: Strange crash
by Alexandre Julliard April 20, 2001

April 20, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Unhandled exception: c000008f > [...] > > Commenting lines 36-37 > physDev->pen.width = GDI_ROUND((FLOAT)pen->logpen.lopnWidth.x * > dc->xformWorld2Vport.eM11 * 0.5); > in X11DRV_PEN_SelectObject (graphics/x11drv/pen.c) cures the problem. > > Why call to floor() leads to crash? Exception c000008f is EXCEPTION_FLT_INEXACT_RESULT. Probably one of the floating point values is invalid, or something similar. -- Alexandre Julliard julliard(a)winehq.com

4 10

Regedit from Win2k
by Dominik Strasser April 19, 2001

April 19, 2001

Hi, trying to run regedit from Win2k I encounter the following problems: err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef Hmm, but those are implemented. When I try to add a loadorder for shlwapi to get the builtin one, this doesn't work. "shlwapi" = "builtin, native" Still the native version is used. If I change the overall DefaultLoadOrder, to "builtin, native" it works. After this, the tree items in the Treeview vanished but I don't care. I assume this is the cause: fixme:listview:LISTVIEW_Create ANSI notify format is NOT used Trying to save the registry I get a crash wich I tracked down to this line in filedlg95.c: 453: AllocInArgWtoA(ofn->lpTemplateName, lpTemplateName); But ofn->lpTemplateName is not a pointer but seems to be a handle: 0x00000064. If I wrap the call into a if(!IsBadReadPtr(ofn->lpTemplateName, 4)), the filedialog comes up. Any clues anybody ? Regards Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser(a)mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

1 0

Re: Store each glyph name only once in PS driver
by Alexandre Julliard April 18, 2001

April 18, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > Separating the string data from their indices will allow them to be > declared as const, so that should get them into the ".rodata" section of > the resulting assembly; the Adobe Glyph List vector is already there. > Is this what you mean by "read only memory"? Yes, exactly that; separating the strings and the indices seems the right thing to do. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Store each glyph name only once in PS driver
by Alexandre Julliard April 18, 2001

April 18, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > typedef struct { > + INT index; > + CHAR sz[0]; > +} GLYPHNAME; > + > +typedef struct { > + LONG UV; > + GLYPHNAME *name; > +} UNICODEGLYPH; > + > +typedef struct { > + INT size; > + UNICODEGLYPH glyphs[0]; > +} UNICODEVECTOR; Zero-size arrays are not portable, and the standard method of using a size of 1 doesn't work well with initialized data (lots of warnings). So you probably need to change your data structures a bit; also it would be nice to store all the preinitialized stuff, or at least the strings, in read-only memory to save a bit of swap space. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: SEH logging
by Alexandre Julliard April 17, 2001

April 17, 2001

Francois Gouget <fgouget(a)free.fr> writes: > In this implementation exception.c reuses format_exception_msg() > which is normally used to display the dialog box asking whether to debug > the exception or not. Since this is all in ntdll it works. Actually win32/except.c is part of kernel, it's only linked in ntdll now because separation is not finished. So you cannot call format_exception_msg from ntdll. And anyway this would print "unhandled xxx" for all exceptions, which is misleading since they might be handled later on. Also I don't think the core exception routines should know about specific exception codes like EXCEPTION_WINE_STUB. If you want a message on stubs, it should be done in the .spec.c file before the call to RtlRaiseException. -- Alexandre Julliard julliard(a)winehq.com

2 1