wine-devel

wine-devel@winehq.org

84463 discussions

Race condition?
by lawson_whitney＠juno.com 01 Sep '01

01 Sep '01

Good day! My app just crashed, after I logged in and dismissed its modal nuisance ad. Normally it doesn't, so I guess this might be some kind of race condition? Here is a backtrace, in case it might be useful. If not, sorry for the noise. Oh, load order is: [DllOverrides] "*" = "builtin, so, native" [AppDefaults\\juno.exe\\DllOverrides] "msvcrt" = "native" "riched32" = "native" Haven't seen anything on wine-cvs since 29 August, but the local wine is up to that. No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42LOC.DLL' (0x76020000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RICHED32.DLL' (0x6c000000) Unhandled exception: page fault on read access to 0x2e6873f4 in 32-bit code (0x5f404eca). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x5f404eca (MFC42.DLL.2028+0xf in C:\AWAY\BIN\MFC42.DLL): cmpl $1,0xfffffff4(%eax) Wine-dbg>bt Backtrace: =>0 0x5f404eca (MFC42.DLL.2028+0xf in C:\AWAY\BIN\MFC42.DLL) (ebp=405b5b88) 1 0x15030f38 (JSESSION.DLL.2914+0x30d8 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5ca0) 2 0x150257a3 (JSESSION.DLL.2141+0xad3 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5cb4) 3 0x1502c816 (JSESSION.DLL.2606+0x766 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5e54) 4 0x1502d27a (JSESSION.DLL.2606+0x11ca in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5edc) 5 0x150249f9 (JSESSION.DLL.2039+0x699 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5f7c) 6 0x15049088 (JSESSION.DLL.3948+0x988 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b6088) 7 0x1502d45a (JSESSION.DLL.2707+0x5a in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b61ac) 8 0x150241e8 (JSESSION.DLL.2035+0x88 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b61f4) 9 0x0042aff0 (juno.exe..text+0x29ff0 in C:\away\bin\juno.exe) (ebp=405b623c) 10 0x5f4019f0 (MFC42.DLL.5163+0x31c in C:\AWAY\BIN\MFC42.DLL) (ebp=405b62bc) 11 0x5f4016b2 (MFC42.DLL.6374+0x22 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b62dc) 12 0x5f40163b (MFC42.DLL.1109+0x71 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b633c) 13 0x5f4015c6 (MFC42.DLL.1578+0x2a in C:\AWAY\BIN\MFC42.DLL) (ebp=405b6358) 14 0x5f40157d (MFC42.DLL.1579+0x39 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b6384) 15 0x40665a07 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b63a8) 16 0x40665a8d (WINPROC_CallWndProc+0x7d(proc=0x5f401544, hwnd=0x6005d, msg=0x403, wParam=0x0, lParam=0x0) [winproc.c:172] in libuser32.so) (ebp=405b63d8) 17 0x4066b417 (CallWindowProcA+0x93(func=0x40d31c44, hwnd=0x6005d, msg=0x403, wParam=0x0, lParam=0x0) [winproc.c:2639] in libuser32.so) (ebp=405b6400) 18 0x4064e822 (DispatchMessageA+0xd6(msg=0x4920dc) [message.c:922] in libuser32.so) (ebp=405b6444) 19 0x5f401226 (MFC42.DLL.5307+0x3a in C:\AWAY\BIN\MFC42.DLL) (ebp=004920dc) 20 0x00000403 (ebp=0006005d) Wine-dbg>info local MFC42.DLL.2028: Wine-dbg>up 15 Wine-dbg>info local WINPROC_wrapper: Wine-dbg>up 172 retvalue = WINPROC_wrapper( proc, hwnd, msg, wParam, lParam ); Wine-dbg>info local WINPROC_CallWndProc: long int(*none)()* proc == 0x5f401544 unsigned int hwnd == 0x0006005d unsigned int msg == 0x00000403 unsigned int wParam == 0x00000000 long int lParam == 0x00000000 unsigned int hwnd (optimized into register $edi) == 0x00000003 long int retvalue == 0x00000000 int iWndsLocks (optimized into register $esi) == 0x410f84ac long unsigned int ret (optimized into register $eax) == 0x2e687400 long unsigned int ret (optimized into register $eax) == 0x2e687400 Wine-dbg>up 2639 return WINPROC_CallWndProc( proc->thunk.t_from16.proc, Wine-dbg>info local CallWindowProcA: long int(*none)()* func == 0x40d31c44 unsigned int hwnd == 0x0006005d unsigned int msg == 0x00000403 unsigned int wParam == 0x00000000 long int lParam == 0x00000000 unsigned int wParam (optimized into register $edi) == 0x00000003 long int lParam (optimized into register $esi) == 0x410f84ac struct tagWINDOWPROC* proc (optimized into register $eax) == 0x2e687400 Wine-dbg>up 922 retval = CallWindowProcA( (WNDPROC)wndPtr->winproc, Wine-dbg>info local DispatchMessageA: struct tagMSG* msg == 0x004920dc struct tagMSG* msg (optimized into register $edi) == 0x00000003 struct tagWND* wndPtr (optimized into register $esi) == 0x410f84ac long int retval == 0x004920a8 int painting == 0x00000000 Wine-dbg> Regards, Lawson ---oof---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.

1 0

Re: wine-devel digest, Vol 1 #445 - 9 msgs
by Robert Lunnon 30 Aug '01

30 Aug '01

Attempt 2 :-) I am trying to get winsock to work under Solaris and need a little help. When connecting, the call to connect doesn't generate a syn packet as expected, The problem appears to be WSOCK32_socket, where the type of socket is passed as type 1 for a tcp service, as it turns out the Solaris header file defines SOCK_STREAM as 2 and SOCK_DGRAM as 1 which makes the subsequent call to connect succeed without establishing a connection because a UDP endpoint was created instead of a tcp one. Now to find out where SOCK_STREAM is getting defined as 1 :-/ I probably need to check the standard function calls between a solaris binary and a windows one so does someone have a simple test program and a unix source (IE windows binary with unix compatible source code) that I can use to compare behaviours between the two environments ? Thanks Bob

2 1

Re: [PATCH] DestroyWindow16
by eric pouech 30 Aug '01

30 Aug '01

Gerard Patel wrote: > > As DestroyWindow does a lot of handle comparaisons, it is necessary > to give it a real 32 bit handle. This avoids a systematic crash when > ForteFreeAgent 16 bit exits. I have not looked for other places where > this can be necessary - but it would not be surprising that this happens. perhaps as an extension of the relay code ? (it would mean typing correctly windows handles in spec files though) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Problems with WM_PAINT and threads
by Ove Kaaven 30 Aug '01

30 Aug '01

After trying to merge Wine 20010824 into WineX, I've encountered a threading issue. A window is created in an app thread: 0806d1f0:Call user32.CreateWindowExA(00000000, 403cb0d4 "Afx:400000:3",0055b674 "3DMark - Display Window", 80000000,00000000,00000000,00000280,000001e0,00000000, 00000000,00400000,00000000) ret=5f40c486 trace:win:WIN_CreateWindowEx "3DMark - Display Window" "Afx:400000:3" 00000000 80000000 0,0 640x480 0000 0000 00400000 (nil) trace:win:WIN_CreateWindowEx winproc type is 2 (WIN_PROC_32A) ... This works fine, until our ddraw update thread somehow decides to send it a message after syncing its own window 31bc: 08107170:Ret x11drv.CreateWindow() retval=00000001 ret=407f542f trace:win:WIN_CreateWindowEx created window 31bc 08107170:Call x11drv.SetWindowPos(44a12e88) ret=407fb159 trace:x11drv:X11DRV_SetWindowPos hwnd 31bc, swp (0,0)-(0,0) flags 0000255b trace:x11drv:X11DRV_SetWindowPos current (0,0)-(800,600), style 84000000 warn:x11drv:SWP_DoOwnedPopups (31bc) hInsertAfter = 0000 trace:x11drv:X11DRV_sync_whole_window_position setting win 3200001 pos 0,0,800x600 after 8081268 changes=40 trace:x11drv:X11DRV_SetWindowPos mapping win 31bc trace:x11drv:X11DRV_SetWindowPos status flags = 1843 08107170:Ret x11drv.SetWindowPos() retval=00000001 ret=407fb159 trace:win:RedrawWindow 31bc (0000) NULL 0,0-0,0 0000 flags=0180 trace:win:RDW_UpdateRgns hwnd 31bc [0000] -> hrgn [0000], flags [0180] trace:win:RDW_Paint hwnd 31bc [0000] -> hrgn [0000], flags [0180] 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000002,44a12da4,ffffffff,000000ff,00000000) ret=407e4237 trace:x11drv:X11DRV_Expose win 31bc (3200002) 0,0 800x600 trace:win:RedrawWindow 31bc (0000) rect 0,0-800,600 0000 flags=0005 trace:win:RDW_UpdateRgns hwnd 31bc [174a] -> hrgn [0000], flags [0005] trace:win:RDW_Paint hwnd 31bc [174a] -> hrgn [0000], flags [0005] 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000002 ret=407e4237 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=407a1ca4 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=407a1ca4 trace:msg:MSG_peek_message got type 5 msg f hwnd 0 wp 0 lp 0 trace:win:WIN_FindWinToRepaint found 3124 trace:win:RedrawWindow 3124 (1746) NULL 0,0-0,0 0000 flags=0050 trace:win:RDW_UpdateRgns hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:win:RDW_Paint hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:message:SPY_EnterMessage (00003124) "3DMark - D..." message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 08107170:Call window proc 0x5f4019fa (hwnd=00003124,msg=WM_PAINT,wp=00000000,lp=00000000) ^^^^^^^^ ^^^^^^^^ After Wine dispatches this WM_PAINT message from the wrong thread, 3DMark2000 fails to locate its thread-local data, gets confused, and crashes. Maybe Alexandre did a mistake somewhere in his restructures?

1 0

Re: BUG with wine/dlls/ntdll/string.c:_ultoa() ???!!??
by Uwe Bonnes 30 Aug '01

30 Aug '01

>>>>> "Johann" == Johann Messner <johann.messner(a)zid.uni-linz.ac.at> writes: Johann> Hi there, First: thanks & compliments for your impressive Johann> project!!! Johann> please check wine/dlls/ntdll/string.c:_ultoa() ... I think there Johann> is a bug in it ... There are for sure more bug... Johann> hans Johann> ==> this is the path to it in the web cvs: ... Johann> ==> this is the source snippet with the patch as suggested ... Did you test? As no win function is uses, you can easily write a test programm wrapper, like static char *_ultoa(... void main() { char buffer[32]; printf(" x %d, radix %d, result %s\n",1000,10,_ultoa(1000,buffer,10)); printf("... } The loop decrements p after use, so p needs to be corrected and I would think that the original version is right. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Mouse Events
by Brad Campbell 30 Aug '01

30 Aug '01

G'day all, Maiden post. Please be gentle.. I had a problem using wine with a touchscreen under XFree 4.0.2. With the help of Gerard Patel and Ove Kaaven I have come up with a patch that solves my problem, and does not appear to disrupt any of the other machines and programs I use. I have looked at several ways of achieving this, and this seems to be the least messy. This has been tested with both the touchscreen and also ps/2 mouse and works well with both. I'm not a C programmer at all, and have little experience with the WINE code. All comments both positive and negative appreciated.. Thanks.. To be applied to windows/input.c --- input.c Wed Aug 29 21:00:42 2001 +++ input.c.new Wed Aug 29 20:59:01 2001 @@ -195,43 +195,43 @@ if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTDOWN : MOUSEEVENTF_RIGHTDOWN)) { MouseButtonsStates[0] = AsyncMouseButtonsStates[0] = TRUE; - queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTUP : MOUSEEVENTF_RIGHTUP)) { MouseButtonsStates[0] = FALSE; - queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTDOWN : MOUSEEVENTF_LEFTDOWN)) { MouseButtonsStates[2] = AsyncMouseButtonsStates[2] = TRUE; - queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTUP : MOUSEEVENTF_LEFTUP)) { MouseButtonsStates[2] = FALSE; - queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEDOWN) { MouseButtonsStates[1] = AsyncMouseButtonsStates[1] = TRUE; - queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEUP) { MouseButtonsStates[1] = FALSE; - queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_WHEEL) { queue_raw_hardware_message( WM_MOUSEWHEEL, MAKELONG( keystate, mi->mouseData), 0, - PosX, PosY, mi->time, mi->dwExtraInfo ); + mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } } -- Brad Campbell /"\ Save the Forests \ / ASCII RIBBON CAMPAIGN Burn a Greenie. X AGAINST HTML MAIL / \

1 1

Comment from IBM developer re FS register corruption
by Jeremy White 30 Aug '01

30 Aug '01

At LinuxWorld today, a couple of developers from IBM stopped by and mentioned a patch that they recently sent to Linus (which he accepted with dismay at such a long standing bug, and apparently committed to the 2.4.8 tree). Sadly, I have forgotten the woman's name, but she indicated that there was a race condition that could sometimes cause the fs register to become corrupt, and that this problem had existing in all versions of Linux, as far as they could tell. She indicated that the patch had a fairly innocuous description, but it might be worth understanding this problem better (although from her description, it didn't sound like a good workaround was available). Cheers, Jeremy p.s. Wine was a finalist for best open source project, but lost out to KDE. Next time, the crystal plaque is ours. I can feel it.

1 0

Powerdvd running under linux
by Robert Lowery 30 Aug '01

30 Aug '01

Hi I have a graphics card with an SIS6326 chipset. Under Windows 98 (using PowerDVD), I get fantastic performance on my Pention 233MMX as it supports YUV->RGB, Motion Compensation and iDCT in hardware. This chipset is not currently supported under Linux. What do you think the chances are of PowerDVD working with hardware acceleration under WINE/WINEX? What sort of performance should I expect? Please cc replies to my email, as I am not subscribed Thank-you for your help -Robert

3 2

./configure file in cvs
by Gioele Barabucci 29 Aug '01

29 Aug '01

Hello everyone, why is there a ./configure file in your cvs? configure was meant to be created for endusers, not for developers. Many projects based on auto* tools create a ./autogen.sh or ./bootstrap script. The fact is that the configure supplied (and all the auto* files) creates lot of confusion and some errors sometime. simple as: #!/bin/sh # rm -f configure ltmain.sh config.guess config.sub echo "Running libtoolize..." libtoolize --force --copy >/dev/null echo "Running aclocal..." aclocal $ACLOCAL_FLAGS echo "Running autoheader..." $use_autoheader echo "Running autoconf..." $use_autoconf echo "Running automake..." automake --add-missing --copy --foreign -- Gioele Barabucci (Gb]) <gioeleb(a)tiscalinet.it>

3 2

Re:Call for Volunteers (Re: Newbie work?)
by Eric Pouech 29 Aug '01

29 Aug '01

> Also I'm thinking about starting an additional section for > 'hard(er)' projects that would significantly improve Wine. > Maybe it > could also list projects that are already underway and for which help > would be appreciated (DCOM?, STRICT handles?). I think that when folks start working on a rather large chunk they should talk about it a bit more (that they started, post some ideas on how it should be done, call for contributions...). All developpers are rather terse on this matter. > Easy: > Medium (I expect these would take longer or be a bit harder) > * Provide a pedump utility > #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 > I know there's sample code that does that already floating around so > it should be relatively simple. > Eric Pouech seems to be working on this. I did not check if his > pedump dump the imports/exports but it probably does. yes, but it's missing delayed imports and resource. disass could be provided to. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel