http://bugs.winehq.com/show_bug.cgi?id=970
Summary: Intermittent regression tests freeze, possibly due to
thread race condition.
Product: Wine
Version: CVS
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.com
ReportedBy: paulm(a)astro.gla.ac.uk
[Comments made about CVS just after Tue, 13 Aug 2002 19:44:01 +01:00 (BST) updates]
Whilst conducting the regression tests (as part of the rolling CVS regression
testing) I discovered a problem. With the version set to "win20", the process
froze at one of the wininet DLL tests. This has happened before (see [1]), but
it only occurs when emulating one of the 16-bit version of Windows (ie "win20",
"win30" or "win31") and never for other versions.
Sylvain has reported [2] problems with the wininet regression tests. The
symptoms are the same, but for me the problem is only intermittent. Once I found
an example of the problem, I haven't been able to reproduce it - even with
identical CVS trees.
When the problem occurred, I attached gdb to the process and got the following info:
[...]
Loaded symbols for /lib/libresolv.so.2
0x402e7744 in __libc_close () at __libc_close:-1
-1 __libc_close: No such file or directory.
in __libc_close
(gdb) bt
#0 0x402e7744 in __libc_close () at __libc_close:-1
#1 0x400ec9a4 in __DTOR_END__ ()
from /home/paulm/WINE-cvs/wine/dlls/libntdll.dll.so
#2 0x400b3df5 in WaitForMultipleObjectsEx (count=0, handles=0x0,
wait_all=0, timeout=100, alertable=0) at
../../scheduler/synchro.c:257
#3 0x400b3b88 in Sleep (timeout=100) at ../../scheduler/synchro.c:178
#4 0x40358747 in winapi_test (flags=268435456) at tests/http.c:121
#5 0x40358b36 in func_http () at tests/http.c:184
#6 0x40358f9d in run_test (name=0xbffffc63 "http.c") at wtmain.c:244
#7 0x40357037 in __wine_exe_main () at wininet_test.exe.spec.c:133
#8 0x400aff84 in start_process () at ../../scheduler/process.c:528
#9 0x400b3f3f in call_on_thread_stack (func=0x400afd2c)
at ../../scheduler/sysdeps.c:108
So, to summarise (with some extra bits of information):
The problem occurs when wininet/tests/http.c is testing asynchronous
HttpSendRequest() (so flags > 0). The problem is triggered at line 121 of
http.c, i.e.:
120 while ((flags)&&(!goon))
121 Sleep(100);
Sleep(), in turn, just calls WaitForMultipleObjectsEx(). From
scheduler/synchro.c:
176 VOID WINAPI Sleep( DWORD timeout )
177 {
178 WaitForMultipleObjectsEx( 0, NULL, FALSE, timeout, FALSE );
179 }
WaitForMultipleObjectsEx() has problems when it gets to 257:
256 SERVER_END_REQ;
257 if (ret == STATUS_PENDING) ret = wait_reply( &cookie );
258 if (ret != STATUS_USER_APC) break;
In this case, ret is 1079729528, btw.
AFAIK, __DTOR_END__ (see near bottom of stack) is the destructor for a
function call in ntdll. I'm probably missing something obvious, but I
don't see the connection between scheduler/synchro.c:257 and ntdll. The
closest is wait_reply() (in scheduler/client.c) calls wait_reply_data (in
same file), which calls NtCurrentTeb(), which is commented as an NTDLL
function. But there doesn't seem to be an implementation of NtCurrentTeb
in ntdll.
HTH
Paul.
[1] http://www.winehq.com/hypermail/wine-devel/2002/08/0006.html
[2] http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=970>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=821
------- Additional Comments From johane(a)lysator.liu.se 2002-08-16 06:56 -------
Try again with latest CVS, since there has been changes to this area.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=821>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=167
------- Additional Comments From lionel.ulmer(a)free.fr 2002-08-16 06:48 -------
Note that if you use DGA2, 'Ctrl Alt Backspace' still works to kill the X server
and return to normal.
By the way, DGA2 is severely broken in other ways (like no mouse event
handling), so do not use it :-)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=167>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=167
------- Additional Comments From johane(a)lysator.liu.se 2002-08-16 06:47 -------
And what Wine are you using?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=167>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=167
johane(a)lysator.liu.se changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
------- Additional Comments From johane(a)lysator.liu.se 2002-08-16 06:42 -------
Is this with any particular game or with all games?
Which game is it, if any particular?
Does pressing Alt+F1 work to get you a console screen when things have gone wrong?
Alt+F7 or something should in that case bring you back to X after killing wine.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=167>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=167
------- Additional Comments From mcbridematt(a)hotmail.com 2002-08-16 06:34 -------
Using Same X version, Nvidia drivers 1.0-2960, 2.2.16-22 Kernel for i686
(NVdriver does not work for athlon based kernels).
Same for me.
Run a game, need reboot to return to normal use
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=167>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=90
This bug depends on bug 506, which changed state:
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=90>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=965
tony_lambregts(a)telusplanet.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|wine-gui |wine-gdi
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-08-15 21:14 -------
This is what Microsofts documentation has to say about MaskBlt
Windows GDI
MaskBlt
The MaskBlt function combines the color data for the source and destination
bitmaps using the specified mask and raster operation.
BOOL MaskBlt(
HDC hdcDest, // handle to destination DC
int nXDest, // x-coord of destination upper-left corner
int nYDest, // y-coord of destination upper-left corner
int nWidth, // width of source and destination
int nHeight, // height of source and destination
HDC hdcSrc, // handle to source DC
int nXSrc, // x-coord of upper-left corner of source
int nYSrc, // y-coord of upper-left corner of source
HBITMAP hbmMask, // handle to monochrome bit mask
int xMask, // horizontal offset into mask bitmap
int yMask, // vertical offset into mask bitmap
DWORD dwRop // raster operation code
);
Parameters
hdcDest
[in] Handle to the destination device context. nXDest
[in] Specifies the x-coordinate, in logical units, of the upper-left corner of
the destination rectangle. nYDest
[in] Specifies the y-coordinate, in logical units, of the upper-left corner of
the destination rectangle. nWidth
[in] Specifies the width, in logical units, of the destination rectangle and
source bitmap. nHeight
[in] Specifies the height, in logical units, of the destination rectangle and
source bitmap. hdcSrc
[in] Handle to the device context from which the bitmap is to be copied. It must
be zero if the dwRop parameter specifies a raster operation that does not
include a source. nXSrc
[in] Specifies the x-coordinate, in logical units, of the upper-left corner of
the source bitmap. nYSrc
[in] Specifies the y-coordinate, in logical units, of the upper-left corner of
the source bitmap. hbmMask
[in] Handle to the monochrome mask bitmap combined with the color bitmap in the
source device context. xMask
[in] Specifies the horizontal pixel offset for the mask bitmap specified by the
hbmMask parameter. yMask
[in] Specifies the vertical pixel offset for the mask bitmap specified by the
hbmMask parameter. dwRop
[in] Specifies both foreground and background ternary raster operation codes
that the function uses to control the combination of source and destination
data. The background raster operation code is stored in the high-order byte of
the high-order word of this value; the foreground raster operation code is
stored in the low-order byte of the high-order word of this value; the low-order
word of this value is ignored, and should be zero. The macro MAKEROP4 creates
such combinations of foreground and background raster operation codes.
For a discussion of foreground and background in the context of this
function, see the following Remarks section.
For a list of common raster operation codes, see the BitBlt function.
Return Values
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero.
Windows NT/2000/XP: To get extended error information, call GetLastError.
Remarks
The MaskBlt function uses device-dependent bitmaps.
A value of 1 in the mask specified by hbmMask indicates that the foreground
raster operation code specified by dwRop should be applied at that location. A
value of 0 in the mask indicates that the background raster operation code
specified by dwRop should be applied at that location.
If the raster operations require a source, the mask rectangle must cover the
source rectangle. If it does not, the function will fail. If the raster
operations do not require a source, the mask rectangle must cover the
destination rectangle. If it does not, the function will fail.
If a rotation or shear transformation is in effect for the source device context
when this function is called, an error occurs. However, other types of
transformation are allowed.
If the color formats of the source, pattern, and destination bitmaps differ,
this function converts the pattern or source format, or both, to match the
destination format.
If the mask bitmap is not a monochrome bitmap, an error occurs.
When an enhanced metafile is being recorded, an error occurs (and the function
returns FALSE) if the source device context identifies an enhanced-metafile
device context.
Not all devices support the MaskBlt function. An application should call the
GetDeviceCaps function to determine whether a device supports this function.
If no mask bitmap is supplied, this function behaves exactly like BitBlt, using
the foreground raster operation code.
ICM: No color management is performed when blits occur.
Windows 2000/XP: When used in a multiple monitor system, both hdcSrc and hdcDest
must refer to the same device or the function will fail. To transfer data
between DCs for different devices, convert the memory bitmap (compatible bitmap,
or DDB) to a DIB by calling GetDIBits. To display the DIB to the second device,
call SetDIBits or StretchDIBits.
Requirements
Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Unsupported.
Header: Declared in Wingdi.h; include Windows.h.
Library: Use Gdi32.lib.
See Also
Bitmaps Overview, Bitmap Functions, BitBlt, GetDeviceCaps, GetDIBits, PlgBlt,
SetDIBits, StretchBlt, StretchDIBits
I do not have any confidence that I can handle this but I will take a look to see.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=965>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=763
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-08-15 20:55 -------
Regressions should have their own bug report. The way to find the patch that
broke the app (worse than it already is) is described here
http://www.winehq.org/Docs/wine-devel/cvs-regression.shtml
I know that you have some trepidation about compiling from source but it is very
easy. Also once you have it set up as CVS it is a snap to keep up to date with
wine. the following link explains how to set up wine via CVS.
http://www.winehq.org/development/index.php?devstart
If you run into problems with this then you can drop me a line and I will try to
be helpfull.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=763>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=965
------- Additional Comments From apa3a(a)yahoo.com 2002-08-15 20:42 -------
Yes, the picture has a few placeholders for counters.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=965>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.