http://bugs.winehq.org/show_bug.cgi?id=9916
Summary: "make test" usually fails Product: Wine Version: 0.9.46. Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: wine-misc AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
"make test" should usually run well. Right now, it usually fails badly.
Right now, on my machine, it: put up a modal dialog once (requiring a mouse click), hung once (requiring a 'wineserver -k'), dropped me into the debugger once (requiring a 'wineserver -k'), screwed up my screen resolution once, and had 22 package failures and 169 individual test failures.
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Target Milestone|--- |1.0.0
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|"make test" usually fails |test.winehq.org
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|test.winehq.org |"make test" usually fails
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #1 from Dan Kegel dank@kegel.com 2007-10-06 07:38:58 --- You can get an overview of the problem by looking at the data at http://test.winehq.org/data/
http://bugs.winehq.org/show_bug.cgi?id=9916
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|wine-misc |test
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #2 from Jan Zerebecki jan.wine@zerebecki.de 2007-10-07 09:12:02 --- Should this bug depend on more specific bug reports about test failures? Though I guess just mentioning them in comments is sufficient... Like bug 9922 , bug 8086 , bug 8112 .
http://bugs.winehq.org/show_bug.cgi?id=9916
Marcus Meissner marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@jet.franken.de
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #3 from Dan Kegel dank@kegel.com 2007-10-11 08:10:59 --- So, after the great 'make test' bugsquish at wineconf, "make test" only has seven module failures for me instead of 22: d3d9: visual ddraw: visual kernel32: comm msi: db msvcrt: heap user32: msg, win and I no longer have to click "OK" once, but I still have to do "wineserver -k" twice to unstick it.
(This is on a different machine, so maybe I'm picking up some new failures, too.)
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #4 from Dan Kegel dank@kegel.com 2007-10-17 00:02:34 --- On my main development laptop, "make -k test" now fails for me in just five modules:
gdi32: bitmap, palette (new failures?) msi: db (same old failure) user32: msg, win (same old failure)
And "make -k test" still hangs (on wininet/ftp), but that's an improvement, it used to hang twice.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #5 from Marcus Meissner marcus@jet.franken.de 2007-10-17 01:17:34 --- i remailed the msi/db.c fix alexandre did at wineconf to wine-patches, but he did not apply it for some reason.
http://article.gmane.org/gmane.comp.emulators.wine.patches/42611
http://bugs.winehq.org/show_bug.cgi?id=9916
Hans Leidekker hans@it.vu.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@it.vu.nl
--- Comment #6 from Hans Leidekker hans@it.vu.nl 2007-10-17 03:04:48 --- Marcus, I remember Alexandre saying at Wineconf that he didn't believe the fix was correct and that perhaps James could have a look at it.
Dan, does this patch have any effect on the wininet/ftp hang? http://www.winehq.org/pipermail/wine-patches/2007-October/044948.html
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #7 from Dan Kegel dank@kegel.com 2007-10-18 16:18:24 --- Doesn't help, it seems.
The right thing to do is code up a small win32 ftp server library and include it in the wine test tree; conformance tests should not fail if the internet is unavailable, IMHO.
Possible inspirations with LGPL-compatible source include http://www.freebsd.org/cgi/cvsweb.cgi/src/libexec/ftpd/ http://www.whitsoftdev.com/slimftpd/ but we'd probably want to write one from scratch.
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|test |wine-misc
--- Comment #8 from Dan Kegel dank@kegel.com 2007-10-18 19:10:09 --- Maarten points out that doing MAKEDEBUG=warn+heap turns on a memset that poisons freed memory: if (TRACE_ON(heap) || WARN_ON(heap)) memset( ptr, ARENA_FREE_FILLER, size ); It seems to help find a few more problems that would otherwise lurk undetected (until it was maximally inconvenient).
Here's the full list on my dual cpu Feisty system with that setting:
crypt32: cert msg store str d3d9: device gdi32: font itss: protocol kernel32: comm msi: automation db install msvcrt: heap user32: dde msg wininet: ftp
Changing category to 'misc' to reflect fact that this exposes bugs in all sorts of areas (not a bug in our test code).
http://bugs.winehq.org/show_bug.cgi?id=9916
Maarten Lankhorst M.B.Lankhorst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |M.B.Lankhorst@gmail.com
--- Comment #9 from Maarten Lankhorst M.B.Lankhorst@gmail.com 2007-10-18 19:30:23 --- It not just destroys free memory, also just allocated memory will have a value (just different). This allows for easier debugging, unitialized/freed pointer dereferences are almost certainly caught by those 2.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #10 from Juan Lang juan_lang@yahoo.com 2007-10-18 20:44:00 --- Youch. That's a good tool. I've fixed up one double-free in crypt32/chain.c that this didn't show. I believe the store.c problem is another instance of the msg.c one, but there may be more than one.
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |10109
http://bugs.winehq.org/show_bug.cgi?id=9916
Bug 9916 depends on bug 10109, which changed state.
Bug 10109 Summary: "make test" fails in itss/tests/protocol.c http://bugs.winehq.org/show_bug.cgi?id=10109
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #11 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 03:33:56 --- Created an attachment (id=8859) --> (http://bugs.winehq.org/attachment.cgi?id=8859) Trace of wininet ftp test without WINEDEBUG=warn+heap
http://bugs.winehq.org/show_bug.cgi?id=9916
Lionel Debroux lionel_debroux@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lionel_debroux@yahoo.fr
--- Comment #12 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 03:34:59 --- The wininet ftp test fails on my dual core SimplyMEPIS 7 Beta system as well, and it fails differently when using WINEDEBUG="warn+heap" and when not using it.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #13 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 03:35:48 --- Created an attachment (id=8860) --> (http://bugs.winehq.org/attachment.cgi?id=8860) Trace of wininet ftp test with WINEDEBUG="warn+heap"
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #14 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 03:39:54 --- Created an attachment (id=8861) --> (http://bugs.winehq.org/attachment.cgi?id=8861) Trace of user32 dde test with WINEDEBUG="warn+heap"
The page fault and stack trace don't show without WINEDEBUG="warn+heap".
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #15 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 03:46:18 --- Created an attachment (id=8862) --> (http://bugs.winehq.org/attachment.cgi?id=8862) Trace of user32 input test without WINEDEBUG="warn+heap"
These errors don't show up if the test is run *WITH* WINEDEBUG="warn+heap".
I don't think it matters in this test, but I did rm -Rf ~/.wine; make testclean between the execution of the test without WINEDEBUG="warn+heap" and the execution of the test with it.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #16 from Hans Leidekker hans@it.vu.nl 2007-10-30 04:29:56 --- Lionel, please attach a WINEDEBUG="warn+heap,trace+wininet" trace for the ftp test.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #17 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 04:46:06 --- Created an attachment (id=8863) --> (http://bugs.winehq.org/attachment.cgi?id=8863) Trace of wininet ftp test with WINEDEBUG="warn+heap,trace+wininet"
IMPORTANT (I should have written this later, stupid me...): all network interfaces other than loopback (eth0 Ethernet, eth1 WiFi) were down when I ran `make test` this morning, because I was in a place where I don't have an Internet connection.
http://bugs.winehq.org/show_bug.cgi?id=9916
Lionel Debroux lionel_debroux@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #8860 is|0 |1 obsolete| |
--- Comment #18 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 04:50:38 --- Created an attachment (id=8864) --> (http://bugs.winehq.org/attachment.cgi?id=8864) Trace of wininet http test with WINEDEBUG="warn+heap,trace+wininet"
I noticed errors in the http test as well, and I'm not 100% sure that all of them (especially "Test failed: expected status ...") are due to the network interfaces being down.
Also obsoleting attachment #8860, I forgot to do that when creating the previous attachment.
http://bugs.winehq.org/show_bug.cgi?id=9916
Lionel Debroux lionel_debroux@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #8861 is|0 |1 obsolete| |
--- Comment #19 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 08:38:07 --- Created an attachment (id=8870) --> (http://bugs.winehq.org/attachment.cgi?id=8870) Trace of user32 dde test with WINEDEBUG="warn+heap,trace+ddeml,trace+msg"
Trace of user32 dde test with WINEDEBUG="warn+heap,trace+ddeml,trace+msg".
A trace about fifty lines before the crash caught my attention: trace:msg:PostMessageW hwnd 0xaaaaaaaa msg 3e1 (WM_DDE_TERMINATE) wp aaaaaaaa lp 0
This time, the Ethernet interface was up when running the tests, but it shouldn't matter, and the stack backtrace is the same anyway.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #20 from Lionel Debroux lionel_debroux@yahoo.fr 2007-10-30 12:01:36 --- Created an attachment (id=8872) --> (http://bugs.winehq.org/attachment.cgi?id=8872) Trace of user32 tests with WINEDEBUG="warn+heap,trace+edit"
With WINEDEBUG="warn+heap", the user32 tests print dozens of of warn:heap:GlobalUnlock 0xnnnnnnnn not locked Since the one that generates most such warnings is the edit test, I ran the user32 tests with trace+edit. The result is the attached trace. WARNING: the uncompressed trace is ~42 MB.
All "GlobalUnlock not locked" (in edit test and others) warnings seem to be emitted when handling a WM_DESTROY. trace:edit:EditWndProc_common hwnd=0x1a002a msg=2 (WM_DESTROY) wparam=0 lparam=0 warn:heap:GlobalUnlock 0x1204aa not locked trace:edit:EditWndProc_common hwnd=0x1a002a msg=2 (WM_DESTROY) -- 0x00000000
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #21 from Hans Leidekker hans@it.vu.nl 2007-10-30 14:19:29 --- The ftp crash is fixed in git now.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #22 from Dan Kegel dank@kegel.com 2007-10-31 02:02:31 --- I've been submitting patches to fix valgrind warnings lately, e.g. http://www.winehq.org/pipermail/wine-patches/2007-October/046005.html http://www.winehq.org/pipermail/wine-patches/2007-October/046006.html http://www.winehq.org/pipermail/wine-patches/2007-October/046007.html
To reproduce my results, apply http://wiki.winehq.org/Wine_and_Valgrind?action=AttachFile&do=get&ta... to a fresh valgrind-3.2.3 tree and install it, then apply http://wiki.winehq.org/Wine_and_Valgrind?action=AttachFile&do=get&ta... to your wine tree and build it, then run the tests under valgrind with RUNTESTS_USE_VALGRIND=1 make -k test > log 2>&1 A full run takes half the day, so run on just one subdirectory for starters. You probably want to look at the log after a couple minutes. If you see lots of spurious errors (e.g. in ld.so or Xlib) just copy the suppressions from the log file into tools/valgrind-suppressions and rerun. (If that helped, please email me your new suppressions file and I'll update the patch.)
I find it easier to analyse the results with the perl script included in the wine patch above, perl tools/valgrind-split.pl log but maybe that's just me.
Now that I've cleared out the first few easy errors, some interesting ones are starting to emerge. Give it a try!
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #23 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-01 08:17:04 --- Created an attachment (id=8910) --> (http://bugs.winehq.org/attachment.cgi?id=8910) Partial run of Valgrind (as described in comment #22)
So I did as Dan wrote in comment #22: patched and compiled Valgrind 3.2.3, patched Wine, and run the Wine tests through Valgrind.
Here's the first part of the run. One of the tests seemed to hang, so I killed it - but instead of killing the faulty process (child of Valgrind and make) through top, I CTRL+C the whole execution of Valgrind. Stupid me. So I restarted the tests, and will post the second part in a subsquent attachment.
In the second run, I haven't been able to suppress the spurious warnings in a different version of libGL, despite adding { bogus_addr4_libgl_101001419 Memcheck:Addr4 obj:/usr/lib/libGL.so.100.14.19 } to tools/valgrind-suppressions. I must have done something wrong somewhere. To remove those spurious errors, I tried to cook multiple | grep -v "..." one-liners, and a more complicated Perl script. In the end, I managed to do nothing such that I'm convinced it will never remove useful lines... so I'm giving up and attaching the unedited logs...
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #24 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-01 08:25:49 --- Created an attachment (id=8911) --> (http://bugs.winehq.org/attachment.cgi?id=8911) Second run of Valgrind (as described in comment #22 and #23)
Several interesting errors indeed surface, let's mention: * in a number of tests, wine_cp_wcstombs seems to use uninitialized values of size 4; * various functions use uninitialized memory for conditional jumps or moves; * various functions seem to pass uninitialized areas to syscalls (?);
This time, the wininet FTP & HTTP tests were run when the Ethernet interface was up, and they both went smoothly. With Hans' patch, the FTP test now goes smoothly when the network interfaces are down, but as I posted above with trace+wininet output, the HTTP test generates "unexpected status" errors.
I've just fetched & rebased from the git repository, so I'm currently rebuilding, and I'll run the tests again with Valgrind. This time, I will make sure that the suppressions file is actually taken into account...
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #25 from Dan Kegel dank@kegel.com 2007-11-01 09:18:52 --- Thanks for trying it out! Don't jump too quickly to the conclusion that valgrind warnings are real problems in wine; a lot of third-party libraries (like libasound) have known problems, so we just have to add suppressions up the wazoo.
Send me the suppressions you find you need on your machine, and I'll collect them all into one big suppressions file to post on the wiki.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #26 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-01 10:04:07 --- I've seen the bugs in asound indeed :) I'm of course not meaning that everything is wine's fault (hence the two "seem" in my previous comment ;) ); however, in some of the tests, some backtraces show only functions belonging to Wine .exe/.dll.so files: * advpack: cabinet.dll.so; * cabinet: cabinet.dll.so; * comctl32: comctl32.dll.so, user32.dll.so, gdi32.dll.so, winex11.drv.so; * crypt32: crypt32.dll.so * dsound: dsound.dll.so * gdi32: gdi32.dll.so etc. (the computer is currently playing the kernel32 tests)
These look more suspicious to me than those which also show functions belonging to say, ld.so or X11 ;)
http://bugs.winehq.org/show_bug.cgi?id=9916
Lionel Debroux lionel_debroux@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #8910 is|0 |1 obsolete| | Attachment #8911 is|0 |1 obsolete| |
--- Comment #27 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-01 11:46:25 --- Created an attachment (id=8917) --> (http://bugs.winehq.org/attachment.cgi?id=8917) Fresh results of valgrind on wine-0.9.48-112-gab07d61
I killed three tests (by sending SIGTERM to the process): * joystick in dinput: my Microsoft Digital Media Pro keyboard (USB ID 045e:00b0) is detected as a joystick with 7 buttons and 37 axes (!). I know because PlanetPenguinRacer and Nexuiz detect it as such, and try to use it as a joystick... which makes both of them completely unusable. * marshal in ole32. * dde in user32. Hence the traces after make finishes.
Before launching the test, I added { bogus_addr4_libgl_101001419 Memcheck:Addr4 obj:/usr/lib/libGL.so.100.14.19 } to silence warnings in libGL. That reduced the number of error logs (as created by valgrind-split) by ~70. There's certainly something to do on some warnings involving libX11 and/or write, but I didn't do anything for now, since multiple backtraces involve libX11.
Running the test suite requires about 2 hours on this computer.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #28 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-02 03:09:21 --- In tools/valgrind-split.pl, what about adding Warning to the return /uninitialised|Unhandled exception:|Invalid read/; match in sub is_error ? I'm asking because I've seen that the FTP tests generate warnings such as: ==20485== Warning: invalid file descriptor 1162170950 in syscall close()
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #29 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-02 03:19:40 --- Err, no, it's a bad idea, since there are lots of preloader: Warning: failed to reserve range 00000000-60000000 ==18576== Warning: set address range perms: large range 1038614528 (defined) warnings.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #30 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-05 13:16:11 --- After the changes in the past few days, only two tests now crash on my computer (down from about seven and later five), and the advapi32 & crypt32 tests (between others) generate less warnings. Good job everyone :-) These tests are: kernel32/debugger (but maybe it's intended to crash and start the debugger, I didn't have a look at the code ?) msvcrt/cpp
Three tests generate lots of warn+heap warnings: * dsound, capture test: "Invalid in-use arena magic for ..." * user32, dde test: this one used to crash. * user32, edit test: "GlobalUnlock: not locked" reported in comment #20. From the trace+edit output, all those warnings occur right when handling a WM_DESTROY message.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #31 from Dan Kegel dank@kegel.com 2007-11-05 14:02:53 --- Yeah, things are looking up. Today, without warn+heap, the following tests fail on my main office workstation: d3d9: device.ok kernel32: comm.ok msi: install.ok msvcrt: heap.ok ole32: marshal.ok user32: msg.ok win.ok winmm: mixer.ok I no longer have to do "wineserver -k" at all for normal test runs, and none of them crash at all (except debugger, which is supposed to). That's really good compared to this time last month.
We still have some work to do before "make test" actually passes, though!
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #32 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-12 10:04:08 --- Created an attachment (id=9126) --> (http://bugs.winehq.org/attachment.cgi?id=9126) Trace of tests on wine-0.9.49-59-g2a2e303 with warn+heap
Two tests (other than the debugger test) crash, one up from last week :'(
Test that still crashes: ../../../tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p msvcrt_test.exe.so cpp.c && touch cpp.ok wine: Unhandled page fault on write access to 0x00000000 at address 0x606cdd6e (thread 0043), starting debugger... Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x606cdd6e).
Test that didn't crash last week: ../../../tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p msvcrt_test.exe.so heap.c && touch heap.ok warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic for 0x1138e0 wine: Unhandled page fault on write access to 0x55555559 at address 0x602d03d9 (thread 0019), starting debugger... Unhandled exception: page fault on write access to 0x55555559 in 32-bit code (0x602d03d9). Looks like an access to an incorrect memory area, all the more the test doesn't crash without warn+heap.
Another note: the wininet FTP and HTTP tests in the attached log were run with the Ethernet network interface down and the WiFi interface up (although I don't know if it could really reach the Internet). I ran the tests again with both interfaces down: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so ftp.c && touch ftp.ok ftp.c:706: Tests skipped: No ftp connection could be made to ftp.winehq.org
../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok http.c:115: Test failed: unexpected status 70 (INTERNET_STATUS_HANDLE_CLOSING) http.c:461: Test failed: expected status 70 (INTERNET_STATUS_HANDLE_CLOSING) 1 times, received 2 times http.c:266: Test failed: expected status 60 (INTERNET_STATUS_HANDLE_CREATED) 1 times, received 2 times http.c:115: Test failed: unexpected status 70 (INTERNET_STATUS_HANDLE_CLOSING) http.c:461: Test failed: expected status 70 (INTERNET_STATUS_HANDLE_CLOSING) 1 times, received 2 times http.c:507: Test failed: expected status 60 (INTERNET_STATUS_HANDLE_CREATED) 1 times, received 2 times http.c:115: Test failed: unexpected status 70 (INTERNET_STATUS_HANDLE_CLOSING) http.c:724: Test failed: expected status 70 (INTERNET_STATUS_HANDLE_CLOSING) 1 times, received 2 times fixme:wininet:InternetSetOptionW Option 43 STUB fixme:wininet:InternetSetOptionW Option 44 STUB make[2]: *** [http.ok] Erreur 8
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #33 from Lionel Debroux lionel_debroux@yahoo.fr 2007-11-18 10:44:14 --- Created an attachment (id=9237) --> (http://bugs.winehq.org/attachment.cgi?id=9237) Traces of dinput device test on wine-0.9.49-199-ga529ef4
This is the dinput device test crashing when the "joystick" (actually a keyboard) I mentioned in comment #27 is connected. I made two runs with different WINEDEBUG options. In both runs, the program dies due to a read access to 0x55555555, i.e. it somehow dereferenced uninitialized "in-use" memory.
In the first run, the backtrace when compiling with -g3 reveals that a parameter to JoystickAImpl_GetObjectInfo is wrong: 3 0x606d8e69 JoystickAImpl_GetObjectInfo+0x40(iface=0x11f880, pdidoi=0x34f7d4, dwObj=0x55555555, dwHow=0x2) [/home/Lionel_Debroux/wine/dlls/dinput/joystick_linux.c:989] in dinput (0x0034f7a8) 4 0x606ccb92 IDirectInputDevice2AImpl_EnumObjects+0x1ae(iface=0x11f880, lpCallback=0x60683160, lpvRef=0x34f95c, dwFlags=0x0) [/home/Lionel_Debroux/wine/dlls/dinput/device.c:860] in dinput (0x0034f938)
In the second run, a parameter to _dump_dinput_GUID is invalid: =>1 0x7eb9e8f8 _dump_dinput_GUID+0x52(guid=0x55555555) [/home/Lionel_Debroux/wine/dlls/dinput/device.c:181] in dinput (0x0034f758) 2 0x7eb9ee17 _dump_DIDATAFORMAT+0x4de(df=0x11fb68) [/home/Lionel_Debroux/wine/dlls/dinput/device.c:212] in dinput (0x0034f828)
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #34 from Dan Kegel dank@kegel.com 2008-01-13 17:12:58 --- As of today, the following tests fail 10 out of 10 times on my main test machine (compaq presario r3000 running Feisty):
dsound: propset gdi32: bitmap palette msi: install user32: msg winmm: mixer
Half of those are new since comment #31 in November; the other half were also failing back then.
I'll attach the log, fwiw.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #35 from Dan Kegel dank@kegel.com 2008-01-13 17:14:02 --- Created an attachment (id=10227) --> (http://bugs.winehq.org/attachment.cgi?id=10227) Log of running just the tests that always fail
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #36 from Dan Kegel dank@kegel.com 2008-01-13 17:14:42 --- Created an attachment (id=10228) --> (http://bugs.winehq.org/attachment.cgi?id=10228) Script to reproduce the problem
Here's a script that runs the tests that always fail for me.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #37 from Dan Kegel dank@kegel.com 2008-02-02 03:41:12 --- I just ran the tests with wine-0.9.54, on a different machine ('planet', an Athlon XP 2100 system running Ubuntu Gutsy with an nVidia NV11 [GeForce2 MX/MX 400] card), Six tests failed. Here's a script to run just those tests:
try() { cd dlls/$1/tests; make $2.ok; cd ../../.. } try dsound propset # flaky, hangs on exit sometimes try d3d8 visual try d3d9 visual try ddraw visual try gdi32 font try kernel32 comm try urlmon url # flaky, passes sometimes try user32 msg
The dsound propset hang on exit seems to happen just after it unloads winealsa.drv on exit; the main thread deadlocks with a wineboot service thread? The visual failures might be a result of the crappy old graphics card on this machine.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #38 from Dan Kegel dank@kegel.com 2008-02-02 03:51:47 --- Created an attachment (id=10571) --> (http://bugs.winehq.org/attachment.cgi?id=10571) Log of running just the tests that failed
I should say, six tests always fail; another (dsound propset) hangs on exit sometimes, and another one (urlmon url) fails sometimes. Here's the log of all eight failing.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #39 from Dan Kegel dank@kegel.com 2008-02-02 04:29:29 --- Filed bug 11441 for dsound proptest hang.
http://bugs.winehq.org/show_bug.cgi?id=9916
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #40 from joaopa jeremielapuree@yahoo.fr 2008-02-02 07:05:14 --- For me, make test fails in msi. I added the console output
Joaopa
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #41 from joaopa jeremielapuree@yahoo.fr 2008-02-02 07:05:46 --- Created an attachment (id=10573) --> (http://bugs.winehq.org/attachment.cgi?id=10573) console output
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #42 from joaopa jeremielapuree@yahoo.fr 2008-02-02 07:07:32 --- err:msi:ready_media Cabinet not found: L"C:\windows\temp\test3.cab" err:msi:ACTION_InstallFiles Failed to ready media err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603 fixme:advapi:LookupAccountNameW (null) L"david" (nil) 0x33f31c (nil) 0x33f320 0x33f314 - stub fixme:advapi:LookupAccountNameW (null) L"david" 0x134098 0x33f31c 0x133308 0x33f320 0x33f314 - stub fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well make: *** [install.ok] Erreur 2
Joaopa
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #43 from Austin English austinenglish@gmail.com 2008-02-06 14:20:15 --- (In reply to comment #42)
err:msi:ready_media Cabinet not found: L"C:\windows\temp\test3.cab" err:msi:ACTION_InstallFiles Failed to ready media err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603 fixme:advapi:LookupAccountNameW (null) L"david" (nil) 0x33f31c (nil) 0x33f320 0x33f314 - stub fixme:advapi:LookupAccountNameW (null) L"david" 0x134098 0x33f31c 0x133308 0x33f320 0x33f314 - stub fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well make: *** [install.ok] Erreur 2
Joaopa
What distribution are you using?
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #44 from James Hawkins truiken@gmail.com 2008-02-06 14:24:42 --- (In reply to comment #43)
(In reply to comment #42)
err:msi:ready_media Cabinet not found: L"C:\windows\temp\test3.cab" err:msi:ACTION_InstallFiles Failed to ready media err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603 fixme:advapi:LookupAccountNameW (null) L"david" (nil) 0x33f31c (nil) 0x33f320 0x33f314 - stub fixme:advapi:LookupAccountNameW (null) L"david" 0x134098 0x33f31c 0x133308 0x33f320 0x33f314 - stub fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well make: *** [install.ok] Erreur 2
Joaopa
What distribution are you using?
This is a known problem. The tests relies on the files being iterated in a certain order (which happens on Windows, but Wine does not emulate).
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #45 from Austin English austinenglish@gmail.com 2008-02-06 14:57:20 ---
This is a known problem. The tests relies on the files being iterated in a certain order (which happens on Windows, but Wine does not emulate).
I was asking because Joaopa had another msi error that neither I nor you could reproduce...
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #46 from James Hawkins truiken@gmail.com 2008-02-06 15:14:00 --- (In reply to comment #45)
This is a known problem. The tests relies on the files being iterated in a certain order (which happens on Windows, but Wine does not emulate).
I was asking because Joaopa had another msi error that neither I nor you could reproduce...
Right. Just because we can't reproduce it doesn't mean it's not a known problem. Many others have reproduced it and with the same distribution and version I'm using (Ubuntu Gutsy).
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #47 from Steven Edwards winehacker@gmail.com 2008-02-13 04:16:41 --- Created an attachment (id=10744) --> (http://bugs.winehq.org/attachment.cgi?id=10744) dsurface failure with git 20080213
Feisty running OpenMotif with the Nvidia binary drivers
http://bugs.winehq.org/show_bug.cgi?id=9916
Steven Edwards winehacker@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehacker@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #48 from Austin English austinenglish@gmail.com 2008-02-13 15:28:10 --- Filed bug 11580 for winmm hanging for me on exit.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #49 from Steven Edwards winehacker@gmail.com 2008-02-18 05:23:38 --- The dsurface bug does not happen in a desktop window or on fvwm2. It seems to be a gnome issue.
http://bugs.winehq.org/show_bug.cgi?id=9916
Mike mozilla_bugs@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mozilla_bugs@mail.ru
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #50 from Austin English austinenglish@gmail.com 2008-02-27 15:01:52 --- I'm down to 8 test failing:
visual.c:887: Test failed: SRCALPHA on texture returned color 00800040, expected bar visual.c:894: Test failed: DSTALPHA on texture returned color 00808000, expected foo exception.c:573: Test failed: expected 4 exceptions, got 0 msg.c:9307: Test failed: 48: ShowWindow(SW_SHOWMAXIMIZED): the msg 0x0047 was expected, but got msg 0x0005 instead msg.c:9307: Test failed: 48: ShowWindow(SW_SHOWMAXIMIZED): the msg 0x0003 was expected, but got msg 0x0009 instead msg.c:9307: Test failed: 48: ShowWindow(SW_SHOWMAXIMIZED): the msg 0x0005 was expected, but got msg 0x0047 instead msg.c:9307: Test failed: 48: ShowWindow(SW_SHOWMAXIMIZED): the msg sequence is not complete: expected 0000 - actual 0003 msg.c:9307: Test failed: 52: ShowWindow(SW_HIDE): in msg 0x0046 expecting wParam 0x83 got 0x93 msg.c:9307: Test failed: 52: ShowWindow(SW_HIDE): in msg 0x0047 expecting wParam 0x1883 got 0x1893
As well as winmm still hanging on exit.
And this is on a VM. I haven't had a chance to test my real hardware...We're making great progress!
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #51 from Austin English austinenglish@gmail.com 2008-03-01 19:44:00 --- In today's git, on my main machine (kubuntu gutsy), I'm down to 6 failures:
msg.c:9307: Test failed: 30: ShowWindow(SW_RESTORE): in msg 0x0047 expecting wParam 0x8160 got 0x8162 msg.c:8895: Test failed: WmMouseHoverSeq: the msg sequence is not complete: expected 0118 - actual 0000 msg.c:8897: Test failed: wrong tme.dwFlags 00000001, expected 00000000 msg.c:8897: Test failed: wrong tme.hwndTrack 0x230096, expected (nil) msg.c:8897: Test failed: wrong tme.dwHoverTime 400, expected 0 wave.c:765: Test failed: The sound played for 1630 ms instead of 1000 ms
I'll test the feisty VM tomorrow.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #52 from Austin English austinenglish@gmail.com 2008-03-02 19:40:24 --- WINEDEBUG=+heap is pretty interesting as well:
input.c:270: Test failed: message count is wrong: got 0 expected: 4 input.c:270: Test failed: message count is wrong: got 0 expected: 6 msg.c:9307: Test failed: 30: ShowWindow(SW_RESTORE): in msg 0x0047 expecting wParam 0x8160 got 0x8162 msg.c:4034: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: the msg 0x0047 was expected, but got msg 0x0005 instead msg.c:4034: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: the msg 0x0005 was expected, but got msg 0x030f instead msg.c:4034: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: the msg sequence is not complete: expected 0000 - actual 001c msg.c:5273: Test failed: WmParentPaintNc: the msg 0x000f was expected, but got msg 0x0046 instead msg.c:5273: Test failed: WmParentPaintNc: the msg 0x000f was expected, but got msg 0x0024 instead msg.c:5273: Test failed: WmParentPaintNc: the msg 0x0085 was expected, but got msg 0x0021 instead msg.c:5273: Test failed: WmParentPaintNc: the msg 0x0014 was expected, but got msg 0x000f instead msg.c:5273: Test failed: WmParentPaintNc: the msg sequence is not complete: expected 0000 - actual 0014 msg.c:7780: Test failed: WmDispatchPaint: the msg 0x0085 was expected, but got msg 0x0014 instead msg.c:7780: Test failed: WmDispatchPaint: the msg sequence is not complete: expected 0014 - actual 0000
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #53 from Dan Kegel dank@kegel.com 2008-03-04 07:54:14 --- I'm still seeing lots more failures than you. $ grep 'make.*Error' test.log make[2]: *** [bitmap.ok] Error 2 make[2]: *** [font.ok] Error 2 make[2]: *** [palette.ok] Error 3 make[1]: *** [gdi32/tests/__test__] Error 2 make[2]: *** [stream.ok] Error 10 make[1]: *** [urlmon/tests/__test__] Error 2 make[2]: *** [msg.ok] Error 24 make[1]: *** [user32/tests/__test__] Error 2
And if I set wine to run in a virtual desktop, user32/tests/win also fails.
But three DLLs failing their tests is a whole lot better than where we were four or five months ago!
There's only one urlmon failure, I bet we can get that fixed easier than the gdi32 or user32 ones. Then we'd be down to just two bad DLLs.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #54 from Austin English austinenglish@gmail.com 2008-03-04 11:48:51 --- (In reply to comment #51)
In today's git, on my main machine (kubuntu gutsy), I'm down to 6 failures:
msg.c:9307: Test failed: 30: ShowWindow(SW_RESTORE): in msg 0x0047 expecting wParam 0x8160 got 0x8162 msg.c:8895: Test failed: WmMouseHoverSeq: the msg sequence is not complete: expected 0118 - actual 0000 msg.c:8897: Test failed: wrong tme.dwFlags 00000001, expected 00000000 msg.c:8897: Test failed: wrong tme.hwndTrack 0x230096, expected (nil) msg.c:8897: Test failed: wrong tme.dwHoverTime 400, expected 0 wave.c:765: Test failed: The sound played for 1630 ms instead of 1000 ms
I'll test the feisty VM tomorrow.
In today's git (wine-0.9.56-337-gb0269c9) I'm still seeing a few in: visual.c exception.c msg.c I'm attaching the full log in a moment.
To the D3D guys, it was skipping those visual tests a few days ago, so I'm guessing your recent patches aren't detecting the crappy VM video card and then failing. Care to take a look/add a skip to them?
The exception.c failure is new...looks like: http://source.winehq.org/git/wine.git/?a=commitdiff;h=198a00bc9eeb2d2fcf5122... could be to blame. I'm reverting/recompiling now to test that.
Winmm is no longer hanging though, yay!
I'll test my real hardware this evening.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #55 from Austin English austinenglish@gmail.com 2008-03-04 11:50:59 --- Created an attachment (id=11109) --> (http://bugs.winehq.org/attachment.cgi?id=11109) List of failing tests in todays git
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #56 from Austin English austinenglish@gmail.com 2008-03-04 12:06:34 --- Created an attachment (id=11110) --> (http://bugs.winehq.org/attachment.cgi?id=11110) +ntdll log of exception.c failing
The exception.c failure is new...looks like: http://source.winehq.org/git/wine.git/?a=commitdiff;h=198a00bc9eeb2d2fcf5122... could be to blame. I'm reverting/recompiling now to test that.
Hmm...reverting didn't help, still fails. Attaching an ntdll log.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #57 from Austin English austinenglish@gmail.com 2008-03-04 21:02:21 --- On real hardware, in today's git:
job.c:228: Test failed: GetProgress failed: 0x80004001 msg.c:9413: Test failed: 30: ShowWindow(SW_RESTORE): in msg 0x0047 expecting wParam 0x8160 got 0x8162 msg.c:9413: Test failed: 34: ShowWindow(SW_NORMALNA): the msg sequence is not complete: expected 0000 - actual 0018 msg.c:9413: Test failed: 35: ShowWindow(SW_NORMALNA): the msg sequence is not complete: expected 0000 - actual 0018 resource.c:123: Test failed: LoadStringA did not return -1 when called with buflen = 0, got 24, err 0
adding +heap: win.c:3269: Test failed: pixel should be black, color is 00c8d73f win.c:3273: Test failed: pixel should be black, color is 00c8d73f win.c:3300: Test failed: pixel should be black, color is 00c8d73f
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #58 from Austin English austinenglish@gmail.com 2008-03-05 16:58:15 --- Got some regressions in today's git :-(
austin@zelda:~/wine-git$ grep -i 'Test failed' wine-0.9.56-420-g22f146f.txt visual.c:1741: Test failed: double texbem failed: Got color 0x00ff00ff, expected 0x00ffff00. systray.c:89: Test failed: ret 0x1 which is not a window systray.c:90: Test failed: hWnd overwritten msg.c:9415: Test failed: 30: ShowWindow(SW_RESTORE): in msg 0x0047 expecting wParam 0x8160 got 0x8162 msg.c:9415: Test failed: 50: ShowWindow(SW_SHOWNORMAL): the msg 0x0047 was expected, but got msg 0x0005 instead msg.c:9415: Test failed: 50: ShowWindow(SW_SHOWNORMAL): the msg 0x0003 was expected, but got msg 0x0009 instead msg.c:9415: Test failed: 50: ShowWindow(SW_SHOWNORMAL): the msg 0x0005 was expected, but got msg 0x0047 instead msg.c:9415: Test failed: 50: ShowWindow(SW_SHOWNORMAL): the msg sequence is not complete: expected 0000 - actual 0003 msg.c:9415: Test failed: 56: ShowWindow(SW_SHOWNOACTIVATE): in msg 0x0047 expecting wParam 0x8170 got 0x8172 win.c:3271: Test failed: pixel should be black, color is 00205860 win.c:3275: Test failed: pixel should be black, color is 00205860 win.c:3302: Test failed: pixel should be black, color is 00205860
+heap adds: job.c:250: Test failed: GetState failed: 0x80004001 job.c:266: Test failed: Resume failed to return BG_E_EMPTY error: 0x80004001 input.c:470: Test failed: 01: 12 from 81 -> 01 unexpected input.c:470: Test failed: 01: a4 from 81 -> 01 unexpected input.c:461: Test failed: 03: 12 from 00 -> 00 instead of 80 -> 00 input.c:461: Test failed: 03: a4 from 00 -> 00 instead of 80 -> 00 input.c:538: Test failed: not enough messages found; looking for 0
Do we still want all these under one bug, or separate bugs for each test failure?
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #59 from Dan Kegel dank@kegel.com 2008-03-05 17:01:02 --- This bug report's getting too big, so new bugs, perhaps. But when you have a recent regression like that, if you can narrow it down to a likely culprit, try emailing the culprit directly (and cc wine-devel) instead of filing a bug. Often that does the job with less fuss.
http://bugs.winehq.org/show_bug.cgi?id=9916
Lionel Debroux lionel_debroux@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9126 is|0 |1 obsolete| | Attachment #9237 is|0 |1 obsolete| |
--- Comment #60 from Lionel Debroux lionel_debroux@yahoo.fr 2008-03-08 03:31:27 --- Created an attachment (id=11195) --> (http://bugs.winehq.org/attachment.cgi?id=11195) Trace of tests on wine 0.9.57 with warn+heap
I hadn't run a make test with WINEDEBUG=warn+heap since several days before the 0.9.56 release. With the Wine 0.9.57 release, I'm seeing *two* crashes I didn't see last time :-((
* d3d9 stateblock test accesses the memory at 0xaaaaaaaa (freed memory !); * qedit mediadet test accesses the memory at 0x0;
The two other crashes are dinput tests, due to accesses to 0x55555555. I opened bug #11644 for them, but so far, nobody replied there, and I don't have the knowledge required to help debugging the problem further...
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #61 from Dan Kegel dank@kegel.com 2008-03-08 09:01:07 --- The qedit crash is probably because http://winehq.org/pipermail/wine-patches/2008-February/050478.html hasn't been committed yet. Clean out your .wine directory and try again.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #62 from Dan Kegel dank@kegel.com 2008-04-24 23:49:06 --- user32/tests/msg is still failing for me, and depending on display mode, so does either d3d9/tests/visual *or* gdi32/tests/bitmap and gdi32/tests/palette:
24 bit display: make[2]: *** [visual.ok] Error 12 make[1]: *** [d3d9/tests/__test__] Error 2 make[2]: *** [msg.ok] Error 14 make[1]: *** [user32/tests/__test__] Error 2 make: *** [dlls/__test__] Error 2
16 bit display: make[2]: *** [bitmap.ok] Error 2 make[2]: *** [palette.ok] Error 3 make[1]: *** [gdi32/tests/__test__] Error 2 make[2]: *** [msg.ok] Error 14 make[1]: *** [user32/tests/__test__] Error 2 make: *** [dlls/__test__] Error 2
msg may be too hard to fix, but how about the other three?
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #63 from Austin English austinenglish@gmail.com 2008-04-25 13:01:09 --- (In reply to comment #62)
16 bit display: make[2]: *** [bitmap.ok] Error 2 make[2]: *** [palette.ok] Error 3 make[1]: *** [gdi32/tests/__test__] Error 2 make[2]: *** [msg.ok] Error 14 make[1]: *** [user32/tests/__test__] Error 2 make: *** [dlls/__test__] Error 2
msg may be too hard to fix, but how about the other three?
This is bug 12730
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #64 from Austin English austinenglish@gmail.com 2008-04-25 14:31:59 --- (In reply to comment #62)
msg may be too hard to fix, but how about the other three?
Seems to fail for most people. Does anyone know what window manager Alexandre is testing on? Perhaps we should file bugs with Gnome/KDE/etc. to fix any issues on their end that prevent this from working on all/most desktops...
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #65 from Steven Edwards winehacker@gmail.com 2008-04-25 16:06:29 --- (In reply to comment #64)
(In reply to comment #62)
msg may be too hard to fix, but how about the other three?
Seems to fail for most people. Does anyone know what window manager Alexandre is testing on? Perhaps we should file bugs with Gnome/KDE/etc. to fix any issues on their end that prevent this from working on all/most desktops...
fvwm2/95 from what I understand. Also the version in CVS or SVN seems to have some fixes from what I hear so even stock fvwm will still fail a few tests.
Thanks Steven
http://bugs.winehq.org/show_bug.cgi?id=9916
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com
--- Comment #66 from François Gouget fgouget@codeweavers.com 2008-04-25 16:38:22 --- (In reply to comment #65) [...]
fvwm2/95 from what I understand. Also the version in CVS or SVN seems to have some fixes from what I hear so even stock fvwm will still fail a few tests.
He's using fvwm2. I'm the one who used to run fvwm95 but I have since switched to fvwm2 (with an fvwm95 theme).
16 bit display: make[2]: *** [bitmap.ok] Error 2
As far as I know there are two possible failures for bitmap.c.
One is in the black and white tests and can happen in any screen depth. Nothing is known about that failure mode.
The other specifically happens when the screen is in 16bpp and the patch below should fix it. The problem is I ran out of time just before submitting it and I haven't had time to pick it up since.
http://www.winehq.org/pipermail/wine-patches/2007-November/046504.html
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #67 from Alexandre Julliard julliard@winehq.org 2008-04-26 03:52:54 --- (In reply to comment #64)
Seems to fail for most people. Does anyone know what window manager Alexandre is testing on? Perhaps we should file bugs with Gnome/KDE/etc. to fix any issues on their end that prevent this from working on all/most desktops...
The test passes for me with fvwm and metacity, both built from CVS (the released versions have various bugs).
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #68 from Austin English austinenglish@gmail.com 2008-04-26 19:42:33 --- (In reply to comment #67)
(In reply to comment #64)
Seems to fail for most people. Does anyone know what window manager Alexandre is testing on? Perhaps we should file bugs with Gnome/KDE/etc. to fix any issues on their end that prevent this from working on all/most desktops...
The test passes for me with fvwm and metacity, both built from CVS (the released versions have various bugs).
Good to know. I think we should aim at getting the tests passing in Kwin/Metacity, due to their widespread popularity...
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #69 from Dan Kegel dank@kegel.com 2008-04-26 22:12:36 --- fwiw, in Gutsy, to build recent metacity, do
sudo apt-get install libgtk2.0-dev libgconf2-dev wget http://ftp.acc.umu.se/pub/gnome/sources/metacity/2.23/metacity-2.23.8.tar.bz... tar -xjvf metacity-2.23.8.tar.bz2 cd metacity-2.23.8 ./configure --prefix=/usr/local/metacity make
Haven't figured out how to use it yet, though... maybe just kill the existing one and start the new one?
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #70 from Dan Kegel dank@kegel.com 2008-04-26 22:50:03 --- To run metacity out of the source directory and override your default window manager temporarily, do src/metacity --replace
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #71 from Dan Kegel dank@kegel.com 2008-04-26 23:34:09 --- Using that metacity does make the msg tests pass! Golly!
http://bugs.winehq.org/show_bug.cgi?id=9916
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #72 from Austin English austinenglish@gmail.com 2008-04-27 22:08:34 --- (In reply to comment #71)
Using that metacity does make the msg tests pass! Golly!
I also needed gettext.
Still fails for me in hardy:
--snip-- msg.c:9565: Test failed: 29: expected style 20000000, got 00000000 msg.c:9568: Test failed: 30: ShowWindow(SW_RESTORE): the msg 0x0001 was expected, but got msg 0x0018 instead msg.c:9568: Test failed: 30: ShowWindow(SW_RESTORE): in msg 0x0046 expecting wParam 0x8160 got 0x43 msg.c:9568: Test failed: 30: ShowWindow(SW_RESTORE): in msg 0x0047 expecting wParam 0x8160 got 0x1843 msg.c:9568: Test failed: 30: ShowWindow(SW_RESTORE): the msg sequence is not complete: expected 0003 - actual 0000 msg.c:7841: Test failed: ScrollWindow: the msg sequence is not complete: expected 0000 - actual 000f msg.c:4161: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: in msg 0x0047 expecting wParam 0x1002 got 0x0 msg.c:4161: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: the msg 0x0005 was expected, but got msg 0x0003 instead make: *** [msg.ok] Error 28 --snip--
In the terminal that metacity was running from, there's quite a few: Window manager warning: Window 0x2200039 (Test popup) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #73 from Dan Kegel dank@kegel.com 2008-04-27 22:37:54 --- Yes, I got a lot of those "doesn't make sense" warnings from metacity, too. (Who knows, maybe those are expected?!)
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #74 from Dan Kegel dank@kegel.com 2008-05-09 05:46:53 --- I ran 'make -k test' while using a web browser, and got a failure on comctl32/tooltips.ok, user32/msg.ok, and winmm/wave.ok. Rerunning those three tests succeeded.
Amusingly, I also got sock.c:1833: Test failed: gethostbyname("someweirdandbogusname") succeeded. but that's because my @!#@!$()$~!! ISP now returns success for *any* dns lookup: $ host someweirdandbogusname someweirdandbogusname has address 24.28.193.9 Host someweirdandbogusname not found: 3(NXDOMAIN)
I also got failures in d3d8 in visual and volume, and in d3d9 in query, shader, and volume, but that might be par for the course with my old graphics card [GeForce2 MX/MX 400].
Perhaps we should have a whitelist of known supported cards for the d3d tests? Then we could close this bug, maybe...
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #75 from Austin English austinenglish@gmail.com 2008-05-11 17:46:01 --- (In reply to comment #74)
I also got failures in d3d8 in visual and volume, and in d3d9 in query, shader, and volume, but that might be par for the course with my old graphics card [GeForce2 MX/MX 400].
Perhaps we should have a whitelist of known supported cards for the d3d tests? Then we could close this bug, maybe...
Agreed. I test on quite a few machines with different graphics cards/drivers, and can test on several various win2k/xp machines with differing setups. Without the information on what should pass, however, I feel it's a waste.
Roderick/Stephen, mind throwing out some knowledge of what cards/drivers these should pass on?
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
--- Comment #76 from Dan Kegel dank@kegel.com 2008-05-12 16:33:08 --- I posted a patch, http://winehq.org/pipermail/wine-patches/2008-May/054828.html to fix six of the d3d9/visual failures (the test was too strict).
After that, and with the fresh version of metacity, the only errors left on my machine are these four in d3d9/visual:
fixme:d3d:tex_alphaop Attempt to enable unsupported stage! visual.c:8694: Test failed: TSSARGTEMP test returned color 0x00ff0000, expected 0x00FFFF00 fixme:d3d:tex_colorop >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glActiveTextureARB @ state.c / 1833 visual.c:9074: Test failed: stretchrect: Pixel 160,360 has color 0x00000000, expected 0x00ff0000 visual.c:9076: Test failed: stretchrect: Pixel 480,360 has color 0x00000000, expected 0x0000ff00 visual.c:9078: Test failed: stretchrect: Pixel 480,120 has color 0x00000000, expected 0x000000ff
Could some d3d person take a look?
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #77 from Dan Kegel dank@kegel.com 2008-05-13 10:42:32 --- d3d9/visual problems are the subject of bug 10221, copying my last comment there.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #78 from Dan Kegel dank@kegel.com 2008-05-13 14:00:15 --- Maarten says "On my test linux computer I got 26 failures in the d3d9:visual tests, rand(0,12) in the user32:input tests, and rand(0,1) in the user32:msg tests. Which really makes it only the d3d9 test consistently failing and the rest only failing some of the time. Test pc is debian etch."
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #79 from Dan Kegel dank@kegel.com 2008-05-13 14:30:08 --- On an old dapper system with some updates, a nVidia Corporation NV41GL [Quadro FX 1400] (rev a2), with two large screens, and no new metacity,
user32/input and user32/msg fail in a message sequence test, but I chalk that up to not having a new metacity.
ddraw/dsurface fails reliably: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so dsurface.c dsurface.c:1373: Test failed: Attaching an offscreen plain surface to a front buffer returned 8876000a ...
ddraw/visual tests are skipped because it can't find a matching video mode: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c fixme:win:EnumDisplayDevicesW ((null),0,0x32f0e8,0x00000000), stub! err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 640x480x32 @0! (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 640x480x24 @0! (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1920x1200x32 @0! (XRandR) visual.c:2612: Tests skipped: Cannot initialize DirectDraw and Direct3D, skipping
xrandr says: SZ: Pixels Physical Refresh *0 3840 x 1200 (1048mm x 331mm ) *50 1 3200 x 1200 ( 873mm x 331mm ) 51 2 2560 x 1024 ( 699mm x 282mm ) 52
so it seems ddraw/visual isn't expecting a two-monitor system.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #80 from Austin English austinenglish@gmail.com 2008-05-13 16:07:58 --- For me in today's git/feisty VM: austin@austin-desktop:~/wine-git$ grep -i 'make.*Error' wine-1.0-rc1-88-gc72f318.txt make[2]: *** [visual.ok] Error 2 make[2]: Target `test' not remade because of errors. make[1]: *** [d3d8/tests/__test__] Error 2 make[2]: *** [visual.ok] Error 205 make[2]: Target `test' not remade because of errors. make[1]: *** [d3d9/tests/__test__] Error 2 make[2]: *** [exception.ok] Error 1 make[2]: Target `test' not remade because of errors. make[1]: *** [ntdll/tests/__test__] Error 2 make[2]: *** [shlexec.ok] Error 16 make[2]: Target `test' not remade because of errors. make[1]: *** [shell32/tests/__test__] Error 2 make[2]: *** [msg.ok] Error 14 make[2]: Target `test' not remade because of errors. make[1]: *** [user32/tests/__test__] Error 2 make[2]: *** [wave.ok] Error 1 make[2]: Target `test' not remade because of errors. make[1]: *** [winmm/tests/__test__] Error 2 make[1]: Target `test' not remade because of errors. make: *** [dlls/__test__] Error 2 make: Target `test' not remade because of errors.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #81 from Dan Kegel dank@kegel.com 2008-05-16 22:21:32 --- See http://wiki.winehq.org/MakeTestFailures for how we're tracking this now. Please run the dotests script so your system's results get logged...
http://bugs.winehq.org/show_bug.cgi?id=9916
shakaran shakaran@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shakaran@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=9916
Jeremy White jwhite@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jwhite@codeweavers.com
--- Comment #82 from Jeremy White jwhite@codeweavers.com 2008-05-27 18:11:45 --- Hmm. Metacity 2.23.21 was not a magic bullet for me; I still get a fair number of message and user errors:
http://test.winehq.org/data/914cb228685b8878be72148330a1b2e8e10d521d/wine_xp...
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.0.0 |1.2.0
--- Comment #83 from Dan Kegel dank@kegel.com 2008-06-09 10:12:55 --- I think this is fixed sufficiently for wine-1.0.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #84 from Lionel Debroux lionel_debroux@yahoo.fr 2008-10-07 04:17:32 --- Created an attachment (id=16519) --> (http://bugs.winehq.org/attachment.cgi?id=16519) Trace of tests on wine-1.1.5-450-ga113178 with warn+heap
I hadn't run the Wine tests since about six months. Yesterday evening, I gave it a try, on the same computer as in March: Asus F3Jv-AS022P with Core 2 Duo @ 2 GHz, 2 GB RAM, Nvidia GeForce 7600 Go, running NVidia proprietary drivers v.100.14.19 under SimplyMEPIS 7 (KDE 3.5.x).
Wine is compiled with -O0 to save on compilation time and generated debug info size. I was in a place without Internet access, so I took the occasion to force wired and WiFi network interfaces down and /etc/resolv.conf empty, like I had done at times since last October.
On the positive side: * there are more successful resolution changes of DirectDraw/Direct3D tests than back in march.
On the negative side: 19 tests failures (though this number doesn't mean too much because some of the failures, e.g. url, are consequences of no network connectivity), 5 crashes, 1 hang: * gdiplus graphics and region tests: both try to read 0xaaaaaaaa, which means they're accessing memory after it was freed. * user32 dde test: read access to 0x00130000. * wininet http test: read access to 0x00000000. * winmm mci test: read access to 0x00130000. * winmm wave test: repeatably hangs for several minutes for me, both with and without warn+heap.
The wininet http test is the only test that crashes both with and without warn+heap.
I hadn't time to do it yesterday evening, it was late, but tonight, I'll focus on providing more detailed traces (trace+wininet; trace+ddeml,trace+msg; etc. ) for the tests that crash.
http://bugs.winehq.org/show_bug.cgi?id=9916
Lionel Debroux lionel_debroux@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #8864 is|0 |1 obsolete| | Attachment #8870 is|0 |1 obsolete| | Attachment #16519|0 |1 is obsolete| |
--- Comment #85 from Lionel Debroux lionel_debroux@yahoo.fr 2008-10-08 02:18:09 --- Created an attachment (id=16533) --> (http://bugs.winehq.org/attachment.cgi?id=16533) Multiple traces of tests on wine-1.1.5-507-ge20ef50
Here are the more detailed runs I promised yesterday, generated with the following series of commands:
make testclean && WINEDEBUG="warn+heap" make -k test &> ~/wine/test_20081007_warnheap.txt cd dlls/gdiplus/tests/ WINEDEBUG="trace+gdiplus,+relay,warn+heap" ../../../tools/runtest -q -P wine -M gdiplus.dll -T ../../.. -p gdiplus_test.exe.so graphics.c &> ~/wine/gdiplus_graphics_20081007_wh.txt WINEDEBUG="trace+gdiplus,+relay,warn+heap" ../../../tools/runtest -q -P wine -M gdiplus.dll -T ../../.. -p gdiplus_test.exe.so region.c &> ~/wine/gdiplus_region_20081007_wh.txt cd ../../user32/tests/ WINEDEBUG="trace+ddeml,+relay,warn+heap" ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so dde.c &> ~/wine/user32_dde_20081007_wh.txt cd ../../wininet/tests/ WINEDEBUG="trace+wininet,+relay,warn+heap" ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c &> ~/wine/wininet_http_20081007_wh.txt cd ../../winmm/tests/ WINEDEBUG="trace+winmm,trace+mci,+relay,warn+heap" ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c &> ~/wine/winmm_mci_20081007_wh.txt cd ../../wldap32/tests/ WINEDEBUG="trace+wldap32,+relay,warn+heap" ../../../tools/runtest -q -P wine -M wldap32.dll -T ../../.. -p wldap32_test.exe.so parse.c &> ~/wine/wldap32_parse_20081007_wh.txt cd ../../winmm/tests/ WINEDEBUG="trace+winmm,+relay,warn+heap" ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c &> ~/wine/winmm_wave_20081007_wh.txt & cd ../../..
There's a fresh new crash since yesterday: wldap32 parse. wldap32 was modified yesterday by 927e9e08921fb14397f397f4ce1d424ec6737d31 and b9813873838af3ec880ae0c68a7932afdf9e616b.
winmm wave test seems to have an infinite loop of InterlockedExchange, I killed it.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #86 from Maarten Lankhorst m.b.lankhorst@gmail.com 2008-10-08 04:42:52 --- winmm:wave is not really in winmm since it mostly forwards to the drivers, +wave is more useful.
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #87 from Lionel Debroux lionel_debroux@yahoo.fr 2008-10-08 05:33:07 --- Created an attachment (id=16536) --> (http://bugs.winehq.org/attachment.cgi?id=16536) winmm wave test with WINEDEBUG="+wave,+relay,warn+heap"
OK, here's a +wave trace :)
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-d3d |testcases
--- Comment #88 from Dan Kegel dank@kegel.com 2008-11-08 08:16:58 --- Changing component to "testcases" since this is really a metabug about all testcases.
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |15958
--- Comment #89 from Dan Kegel dank@kegel.com 2008-11-08 08:54:40 --- filed bug 15958 for winmm/tests/wave.c hang.
http://bugs.winehq.org/show_bug.cgi?id=9916
chris ahrendt celticht32@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |celticht32@aol.com
http://bugs.winehq.org/show_bug.cgi?id=9916
Bug 9916 depends on bug 15958, which changed state.
Bug 15958 Summary: "make test" hangs in winmm/wave.c in wave_out_test_device http://bugs.winehq.org/show_bug.cgi?id=15958
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=9916
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|jeremielapuree@yahoo.fr |
http://bugs.winehq.org/show_bug.cgi?id=9916
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on|10109, 15958 |12925, 14078, 17414, 17518, | |19183
--- Comment #90 from Dan Kegel dank@kegel.com 2009-07-04 10:37:47 --- For me, this is down to bug 12925, bug 14078, bug 17414, bug 17518, and bug 19183, at least on my main computer.
http://bugs.winehq.org/show_bug.cgi?id=9916
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #91 from André H. nerv@dawncrow.de 2009-08-29 12:30:13 --- (In reply to comment #79) ...
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1920x1200x32 @0! (XRandR) visual.c:2612: Tests skipped: Cannot initialize DirectDraw and Direct3D, skipping
xrandr says: SZ: Pixels Physical Refresh *0 3840 x 1200 (1048mm x 331mm ) *50 1 3200 x 1200 ( 873mm x 331mm ) 51 2 2560 x 1024 ( 699mm x 282mm ) 52
so it seems ddraw/visual isn't expecting a two-monitor system.
I got the same error but i only have one monitor, so i guess it sometimes has problems getting the refreshrate
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1600x1200x24 @0! (XRandR)
http://bugs.winehq.org/show_bug.cgi?id=9916
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #8859|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=9916
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #8862|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=9916
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.2.0 |---
--- Comment #92 from Alexandre Julliard julliard@winehq.org 2010-05-25 04:49:56 --- Metabugs don't belong on a release milestone.
http://bugs.winehq.org/show_bug.cgi?id=9916
Bug 9916 depends on bug 12925, which changed state.
Bug 12925 Summary: D3D8: Visual test fails http://bugs.winehq.org/show_bug.cgi?id=12925
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=9916
Bug 9916 depends on bug 17518, which changed state.
Bug 17518 Summary: winmm/mci tests fail with +heap enabled http://bugs.winehq.org/show_bug.cgi?id=17518
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=9916
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |infyquest@gmail.com
--- Comment #93 from Vijay Kamuju infyquest@gmail.com 2011-08-31 16:29:28 CDT --- can we close this, since it is working for latest git
http://bugs.winehq.org/show_bug.cgi?id=9916
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #94 from Frédéric Delanoy frederic.delanoy@gmail.com 2011-08-31 16:53:53 CDT --- (In reply to comment #93)
can we close this, since it is working for latest git
Maybe for you, but that doesn't mean it works for everybody.
See http://test.winehq.org/data/
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #95 from Dan Kegel dank@kegel.com 2011-09-08 11:27:31 CDT --- Wine's tests are in a lot better shape than when this bug was filed, but still, odds are that "make test" will fail on the average machine.
I've been collecting a blacklist of bad and/or flaky tests. Here's one way to use it to measure how unreliable the flaky tests are on a particular system:
wget -c http://winezeug.googlecode.com/svn/trunk/buildbot/dotests.sh wget -c http://winezeug.googlecode.com/svn/trunk/buildbot/dotests_blacklist.txt rm -rf ~/.wine winetricks nocrashdialog while true do make testclean sh dotests.sh flakytests done
Out of 40 or so runs on one system, five dll/foo.ok files exhibited crashes or failures:
7 dlls/wininet/tests/urlcache.ok (bug 28038, workaround: clear cache between runs) 4 dlls/msctf/tests/inputprocessor.ok (bug 28288) 4 dlls/kernel32/tests/pipe.ok (bug 28257) 3 dlls/user32/tests/static.ok (bug 20149) 2 dlls/urlmon/tests/url.ok (bug 28108)
So about half of 40 runs of "make test" would probably fail because of flaky tests on this machine without manual workarounds.
Your mileage may vary. Other systems tickle other bugs.
That blacklist and script can also look for tests that have failed on any of my systems repeatably. Running 'sh dotests.sh badtests' twice on that same (64 bit) system, I got
2 dlls/ieframe/tests/ie.ok FAILED; blacklist says BAD64 , see bug 26768 . 2 dlls/kernel32/tests/process.ok FAILED; blacklist says NOTTY , see bug 28220 . 2 dlls/oleaut32/tests/tmarshal.ok FAILED; blacklist says BAD64 , see bug 26768 . 1 dlls/user32/tests/msg.ok FAILED; blacklist says SYS , see bug 12053 . 2 programs/wscript/tests/run.ok FAILED; blacklist says BAD64 , see bug 28285 .
so "make test" will always fail on this system because of msg tests (probable workaround: run a blessed window manager) and because win64 isn't finished. And a kernel test will always fail because I tend to redirect the output of "make test".
http://bugs.winehq.org/show_bug.cgi?id=9916
--- Comment #96 from Dan Kegel dank@kegel.com 2011-09-08 14:45:21 CDT --- Letting 'dotests.sh flakytests' run for two hours on three different machines, I got five failures that hit multiple systems: kernel32/tests/pipe.ok; bug 28257 msctf/tests/inputprocessor.ok; bug 28288 urlmon/tests/url.ok; bug 28108 wininet/tests/urlcache.ok; bug 28038 ws2_32/tests/sock.ok; bug 28102 and one that happened often on a single system (and has been reported elsewhere). user32/tests/static.ok; bug 20149
http://bugs.winehq.org/show_bug.cgi?id=9916
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #97 from Austin English austinenglish@gmail.com 2011-11-05 14:34:50 CDT --- Make test now passes on a few machines (mine, Francois's, Jacek's).
Individual bugs should be filed for any other failures, metabugs are bad.
http://bugs.winehq.org/show_bug.cgi?id=9916
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #98 from Alexandre Julliard julliard@winehq.org 2011-11-18 13:04:38 CST --- Closing bugs fixed in 1.3.33.
https://bugs.winehq.org/show_bug.cgi?id=9916 Bug 9916 depends on bug 14078, which changed state.
Bug 14078 Summary: Rewrite typelib marshaller on top of NDR functions https://bugs.winehq.org/show_bug.cgi?id=14078
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=9916 Bug 9916 depends on bug 19183, which changed state.
Bug 19183 Summary: "make test" still fails on d3d9/tests/visual.c https://bugs.winehq.org/show_bug.cgi?id=19183
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=9916 Bug 9916 depends on bug 17414, which changed state.
Bug 17414 Summary: user32/dde test crashes if +heap enabled https://bugs.winehq.org/show_bug.cgi?id=17414
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
-
wine-bugs＠winehq.org -
WineHQ Bugzilla