February 2007 - Wine-Devel - list.winehq.org

Re: help in debugging

by Damjan Jovanovic

On 2/5/07, Ioannis Nousias <s0238762(a)sms.ed.ac.uk> wrote: > Hello Wine developers, > > I've decided to see what causes floAt's Mobile Agent[1] to fail with wine > > I checked the wine developers' cheatsheet to help me debug the > application, but I'm lost. > > The application installs but with some error: > "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll > Unable to register the DLL/OCX: LoadLibrary failed; code 126 > Module not found." Can you try typing $ regsvr32 BramusICQ.dll manually? You'll have to do it from the directory it's in. > I click "ignore" and the installation continues. When I try to execute > the installed binary "MobileAgent.exe" it fails. > > I invoke it like this: > > WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe > > no error messages are produce by the app itself. > > on wine's debug log I see the following, just before winedbg starts: > > 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 > trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 > trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade > flags=1 > 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c > 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 > edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b > flags= > 00200246 > trace:seh:__regs_RtlUnwind code=eedfade flags=3 > trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade > flags=3 > trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 > 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c > 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 > edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b > flags= > 00200246 > trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 > trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade > flags=1 > trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 > trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade > flags=1 > 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc > wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 > (thread 0009), starting debugger... > trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" > > this is not the first "trace:seh". Relatively early in the call stack > there is this: > > 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b > trace:seh:raise_exception info[0]=00000000 > trace:seh:raise_exception info[1]=ffffffff > trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 > edx=0000ffff esi=00000000 edi=ffffffff > trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b > es=007b fs=0033 gs=003b flags=00010206 > trace:seh:call_stack_handlers calling handler at 0x602b5540 > code=c0000005 flags=0 > trace:seh:__regs_RtlUnwind code=c0000005 flags=2 > trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 > flags=2 > trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 > ffffffff (invalid)) ret=6033e95f > > which looks suspicious to me. > > Am I on the right track? Unfortunately I'm not familiar with windows API > or wine's underlying architecture. I need some guidance please :) I'm an > experienced C/C++ programmer. > > thanks > > -Ioannis > > > > > > > > > > > > [1] http://fma.sourceforge.net/index2.htm > > >

Feb. 5, 2007

help in debugging

by Ioannis Nousias

Hello Wine developers, I've decided to see what causes floAt's Mobile Agent[1] to fail with wine I checked the wine developers' cheatsheet to help me debug the application, but I'm lost. The application installs but with some error: "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll Unable to register the DLL/OCX: LoadLibrary failed; code 126 Module not found." I click "ignore" and the installation continues. When I try to execute the installed binary "MobileAgent.exe" it fails. I invoke it like this: WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe no error messages are produce by the app itself. on wine's debug log I see the following, just before winedbg starts: 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade flags=1 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:__regs_RtlUnwind code=eedfade flags=3 trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade flags=3 trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade flags=1 trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade flags=1 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 (thread 0009), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" this is not the first "trace:seh". Relatively early in the call stack there is this: 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=ffffffff trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 edx=0000ffff esi=00000000 edi=ffffffff trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010206 trace:seh:call_stack_handlers calling handler at 0x602b5540 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 ffffffff (invalid)) ret=6033e95f which looks suspicious to me. Am I on the right track? Unfortunately I'm not familiar with windows API or wine's underlying architecture. I need some guidance please :) I'm an experienced C/C++ programmer. thanks -Ioannis [1] http://fma.sourceforge.net/index2.htm

Feb. 5, 2007

Re: shell32: shlfileop tests: avoid buffer overflows for paths

by James Hawkins

On 2/4/07, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > These buffers can contain multiple paths and set_curr_dir_path can make > the paths long resulting in a buffer overflow. > > From 36e05f3140e57bad2af790c56073799d23f7ef60 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= <mikolaj(a)zalewski.pl> > Date: Thu, 25 Jan 2007 12:17:11 +0100 > Subject: [PATCH] shell32: shlfileop tests: avoid buffer overflows for paths > > --- > dlls/shell32/tests/shlfileop.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index b363c5e..23aaeba 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > @@ -329,8 +329,8 @@ static void test_delete(void) > static void test_rename(void) > { > SHFILEOPSTRUCTA shfo, shfo2; > - CHAR from[MAX_PATH]; > - CHAR to[MAX_PATH]; > + CHAR from[5*MAX_PATH]; > + CHAR to[5*MAX_PATH]; > DWORD retval; > > shfo.hwnd = NULL; > This is really hacky. If this is fixed, it needs to be fixed properly. -- James Hawkins

Feb. 5, 2007

comctl32 kibitzers wanted

by Dan Kegel

I and Lei Zhang, with some help from James Hawkins, are leading a group of 13 UCLA students who are writing conformance tests for comctl32. Each student picked one control, and is now busily writing getter/setter tests. In the coming few weeks we'll also try more interesting tests, like verifying that the right messages are sent in the right order. If you're interested in helping the students in any way (reviewing code before it hits wine-patches, offering suggestions on how to test tricky bits, or whatever), please let me know and I can add you to the project's mailing list. Thanks, Dan

Feb. 5, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Damjan Jovanovic

On 2/3/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > > > In wine's struct _stati64, st_size has an offset of 20 bytes from the > > beginning of the struct, unlike mingw's and Window's 24. This breaks > > Java 1.4.x pretty badly, it dies on startup complaining about a > > truncated class file (#2953). Using #include <pshpack8.h> and #include > > <pshpop8.h> around the struct didn't help, so a padding field was used > > instead. > > Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to > align the Size field help? > > #include <pshpack8.h> > typedef struct _WIN32_STREAM_ID { > DWORD dwStreamId; > DWORD dwStreamAttributes; > LARGE_INTEGER DECLSPEC_ALIGN(8) Size; > DWORD dwStreamNameSize; > WCHAR cStreamName[ANYSIZE_ARRAY]; > } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; > #include <poppack.h> That doesn't help. I heard somewhere GCC up to version 4.1.12 or so didn't align some things properly (I'm using 4.0.3). Since mingw aligns it properly with the same declaration as wine and it uses GCC 3.4.4, maybe it's a GCC bug. > > +static void test_stat( void ) > > +{ > > + int offset = offsetof(struct _stati64, st_size); > > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > > +} > > This should be a part of auto generated header tests. Have a look at > dlls/*/tests/generated.c files. Thanks. > -- > Dmitry. Damjan

Feb. 5, 2007

Re: Detect screen resolution change errors

by Stefan Dösinger

Am Freitag 02 Februar 2007 16:24 schrieb Francois Gouget: > Is there some code that would show what cleaning the GL context entails? > I have looked at the other exit paths of CreateAdditionalSwapChain() > but the only relevant one only does stuff if object->frontBuffer != NULL > which cannot be the case there. I have patches in my tree which change the context creation, and they also clean up properly in the case of an error(hopefully). I'll send them when things get going again after Alexandre's return.

Feb. 5, 2007

Re: Detect screen resolution change errors

by Francois Gouget

H. Verbeet wrote: > On 30/01/07, Francois Gouget <fgouget(a)codeweavers.com> wrote: >> I have attached the relevant patches. Does this look ok to the DirectX >> gurus? >> > At least the wined3d part looks ok to me, although we should probably > be cleaning up the GL context as well, there and in the other places > where we return. Is there some code that would show what cleaning the GL context entails? I have looked at the other exit paths of CreateAdditionalSwapChain() but the only relevant one only does stuff if object->frontBuffer != NULL which cannot be the case there. -- Francois Gouget fgouget(a)codeweavers.com

Feb. 4, 2007

Re: Detect screen resolution change errors

by Francois Gouget

Stefan Dösinger wrote: > Am Mittwoch 31 Januar 2007 10:25 schrieb H. Verbeet: >> On 30/01/07, Francois Gouget <fgouget(a)codeweavers.com> wrote: >>> I have attached the relevant patches. Does this look ok to the DirectX >>> gurus? >> At least the wined3d part looks ok to me, although we should probably >> be cleaning up the GL context as well, there and in the other places >> where we return. > For some reason I didn't get the original patch, or I accidentally deleted > it(more likely). Yo can find it there: http://www.winehq.org/pipermail/wine-devel/2007-January/053725.html [...] > I do not know to what extend we want to catch screen res change failures. The > resolution? I'd say yes. Color depth? Propably no because we can't change it > anyway. Refresh rate? Don't think its important. There's already some code dealing with color depth issues: devmode.dmBitsPerPel = (bpp >= 24) ? 32 : bpp; /* Stupid XVidMode cannot change bpp */ But there's another place where we deal with these issues differently: if(devmode.dmBitsPerPel == 24) devmode.dmBitsPerPel = 32; [...] ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL, CDS_FULLSCREEN, NULL); if (ret != DISP_CHANGE_SUCCESSFUL) { if(devmode.dmDisplayFrequency != 0) { WARN("ChangeDisplaySettingsExW failed, trying without the refresh rate\n"); devmode.dmFields &= ~DM_DISPLAYFREQUENCY; devmode.dmDisplayFrequency = 0; ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL, CDS_FULLSCREEN, NULL) != DISP_CHANGE_SUCCESSFUL; } if(ret != DISP_CHANGE_SUCCESSFUL) { return DDERR_INVALIDMODE; } } -- Francois Gouget fgouget(a)codeweavers.com

Feb. 4, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Detlef Riekenberg

On Sa, 2007-02-03 at 13:00 -0800, Scott Ritchie wrote: > > The Sidenet - Script is still there. > > > I removed all traces of it from the wine wiki page I set up here, which > the download-deb page should link to now: > http://wiki.winehq.org/UbuntuAMD64 > I agree with you and Vitaly about this, by the way. Great. It's still there, but it's intresting, how fast it went away: https://help.ubuntu.com/community/WineForAMD64 > > Another Tip: > > "Next get the libxxf86dga1 package" > > > > Why that? > > DGA was dropped in July 2006: > The main problem is that I don't have a 64-bit machine and haven't > tested the instructions myself, I have also no 64-Bit machine here. > if Wine was compiled with DGA support (as the 32 bit package was) That is not possible since Aug. 2006. The Part of the Patch "Kill DGA support", that removed "-lXxf86dga": http://source.winehq.org/git/wine.git/?a=commitdiff;h=98179f06565b7f681d3cd… > But if it can be eliminated entirely that's really good news. You can remove the libXxf86dga-dev package and build wine again: The same "winex11.dev.so" is build. -- By by ... Detlef

Feb. 4, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Hans Leidekker

On Sunday 04 February 2007 06:58:58 Dmitry Timoshkov wrote: > To make sure that Wine headers are free of alignment bugs we have > dlls/*/tests/generated.c auto generated by tools/winapi. We just need > to add msvcrt types to tests.dat. Sure, that will help fixing Wine alignment bugs. But an MSVC source that makes assumptions about the alignment of __int64, when recompiled as a Winelib app with GCC could still prove to be very hard to debug. So it's important to find a way to make all 64 bit types align on 8 byte boundaries, like MinGW does as well. We have to do it selectively of course, because Unix libraries have different assumptions about the alignment of 64 bit types. -Hans

Feb. 4, 2007