http://bugs.winehq.org/show_bug.cgi?id=29472
Bug #: 29472 Summary: Regen: locks up/crashes on audio output Product: Wine Version: 1.3.35 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs@winehq.org ReportedBy: marzojr@yahoo.com Classification: Unclassified
Created attachment 38154 --> http://bugs.winehq.org/attachment.cgi?id=38154 The end result of regression testing with git bisect.
Whenever a game is loaded, Regen locks up if audio output is required.A partial work-around involves starting my USB sound card via another process; but there are other issues that come up after this (but they are irrelevant).
This was working on earlier version of Wine (1.3.34), so I performed regression testing; the git bisect log is attached.
Regen is a Sega Genesis emulator; I have been using version 0.972D available at http://aamirm.hacking-cult.org/www/regen.html
http://bugs.winehq.org/show_bug.cgi?id=29472
marzojr@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t Regression SHA1| |62017964bead565a1da427faaf0 | |83e5103c27440
http://bugs.winehq.org/show_bug.cgi?id=29472
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-30 09:36:45 CST --- [in the attachment:] commit 62017964bead565a1da427faaf083e5103c27440 Author: Jörg Höhle Joerg-Cyril.Hoehle@t-systems.com Date: Fri Dec 9 17:12:54 2011 +0100 winealsa: Implement IAudioClock::GetPosition() using snd_pcm_delay.
Could you please apply the latest patch to dlls/mdevapi/tests/render.c from bug #27937 cd dlls/mmdevapi/tests; git apply myfile.patch; make; and attach here the output of WINETEST_DEBUG=2 wine mmdevapi_test.exe.so render
What if you change the sleep(350); slept+=350; within the patch to use 750ms instead?
Perhaps your sound card does not provide correct/sensible data from snd_pcm_delay. Do you have other sound cards that behave correctly? What if you change winealsa/mmdevdrv.c from "default" to defname="hw:0"; or whatever ALSA calls your sound card(s)?
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #2 from marzojr@yahoo.com 2011-12-30 10:32:12 CST --- Created attachment 38181 --> http://bugs.winehq.org/attachment.cgi?id=38181 Output of test using patch - 350ms
Attached is what you asked; I ran the following command:
WINETEST_DEBUG=2 ../../../wine mmdevapi_test.exe.so render &> test.log
I don't have another working sound card at the moment; the whole reason for my USB sound card is that my laptop's sound card isn't being detected.
Changing defname to "hw:1,0" (what ALSA calls my soundcard) raised the number of failures to 106, which I really wasn't expecting because it is routed through PulseAudio anyway.
I will attach the test with 750ms after this post.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #3 from marzojr@yahoo.com 2011-12-30 10:32:37 CST --- Created attachment 38182 --> http://bugs.winehq.org/attachment.cgi?id=38182 Output of test using patch - 750ms
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-30 14:36:22 CST --- The test results look ok (GetPosition grows too fast initially, but I've already seen that elsewhere (recent PulseAudio?...). What's important is that the end position is reached and it doesn't hang. Please attach 2 compressed app logs like the wiki sound page asks, except you also add +timestamp. One prior to the patch (git checkout 20179...440^; make), one with it (git checkout without the trailing ^). Or one where you use the latest wine-1.3.36 and one with git-revert 20179...
Changing defname to "hw:1,0" raised the number of failures to 106
What sort of failures? That should work too, if $ speaker-test -D hw:1,0 works (may need to adjust -c #channels and format). Can you manage to disable PulseAudio on your system to try and locate the fault? Normally PA should detect the direct access to hw:* and get out of the way. Except some panel or desktop apps may cling to it.
sound card isn't being detected
By Wine or by Linux?
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #5 from marzojr@yahoo.com 2011-12-30 17:29:31 CST --- Created attachment 38187 --> http://bugs.winehq.org/attachment.cgi?id=38187 Log for pre-62017964bead565a1da427faaf083e5103c27440 with +tid,+mmdevapi,+winmm,+midi,+dsound,+dmusic,+mci,+oss,+alsa,+coreaudio,+timestamp
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #6 from marzojr@yahoo.com 2011-12-30 17:30:00 CST --- Created attachment 38188 --> http://bugs.winehq.org/attachment.cgi?id=38188 Log for post-62017964bead565a1da427faaf083e5103c27440 with +tid,+mmdevapi,+winmm,+midi,+dsound,+dmusic,+mci,+oss,+alsa,+coreaudio,+timestamp
(In reply to comment #4)
Please attach 2 compressed app logs like the wiki sound page asks, except you also add +timestamp. One prior to the patch (git checkout 20179...440^; make), one with it (git checkout without the trailing ^). Or one where you use the latest wine-1.3.36 and one with git-revert 20179...
The logs are attached. Should the last 2000 lines suggested in the wiki be too few to help, I have kept the whole logs. In both cases, I opened the emulator, selected the ROM and waited a few seconds -- post-patch, this was enough to hang.
Changing defname to "hw:1,0" raised the number of failures to 106
What sort of failures? That should work too, if $ speaker-test -D hw:1,0 works (may need to adjust -c #channels and format).
It works only with -c 2. The test application lists 106 additional test failures; maybe because of this?
sound card isn't being detected
By Wine or by Linux?
Sorry, I should have been more explicit: by Linux. So there is no cause for worry in this case.
http://bugs.winehq.org/show_bug.cgi?id=29472
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://aamirm.hacking-cult. | |org/www/regen.html CC| |aeikum@codeweavers.com Component|winealsa.drv |directx-dsound
--- Comment #7 from Jörg Höhle hoehle@users.sourceforge.net 2011-12-31 08:41:51 CST --- One bug appears to be in DSound. Its mixer has no business using IAudioClient_GetPosition in DSOUND_PerformMix. What it wants is Padding, i.e. how much buffer space is available. CC'ing Andrew Eikum who is currently working on the mixer.
There are some strange things in the logs, e.g. thread 0009 calls GetCurrentPadding 43 times per millisecond!
8.515:AudioClock_GetPosition frames written: 65024, held: 0, avail: 522751, delay: 4533 state 3, pos: 60491 8.525:AudioClock_GetPosition frames written: 65024, held: 0, avail: 522751, delay: 4533 state 3, pos: 60491 Identical values may indicate that ALSA/PA stalled (the underrun bug?), however there are not enough log lines to tell. 10ms of log is not enough to be sure. Regarding underruns (not seen in your short log snippet), you may apply http://www.winehq.org/pipermail/wine-patches/2011-December/110025.html manually (the conflict is easy to solve).
Some log lines are cut off or missing. Please use the >> trick from bug #19125, comment #2 when generating logs next time.
BTW, what is your OS?
106 additional test failures
What sort of failures?
Whenever a game is loaded
You pointed to a download but is it enough? Where can we find a game to load?
http://bugs.winehq.org/show_bug.cgi?id=29472
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.4.0
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #8 from Andrew Eikum aeikum@codeweavers.com 2012-01-03 09:06:52 CST --- (In reply to comment #7)
One bug appears to be in DSound. Its mixer has no business using IAudioClient_GetPosition in DSOUND_PerformMix. What it wants is Padding, i.e. how much buffer space is available. CC'ing Andrew Eikum who is currently working on the mixer.
Can you explain what's wrong with GetPosition()? It's how dsound has worked since before the move to mmdevapi, and seems to make sense to me.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #9 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-03 12:18:06 CST ---
It's how dsound has worked since before [...]
Yet another instance of a double bug that makes it so hard to change something in the fragile equilibrium that Wine's audio was/is. In the past, position was locked to buffer avail so the bug was not noticeable.
See how mmdevapi's periodic filler operates with GetCurrentPadding only. DSound should do exactly the same. It wants to fill a buffer, not perform lip synch'ing. Look up the DONTS about avail_update and delay in Poettering's blog: http://0pointer.de/blog/projects/guide-to-sound-apis.html
In my vision, when DSound is called by mmdevapi's periodic event, it should - query GetCurrentPadding to see how much it can mix; - mix that much data and Release it. Perhaps it also wants to perform rate limiting such that apps can still add a secondary buffer that plays almost immediately, without DSound playing "I've already queued 2s of data, your request will have to wait until after that".
GetPosition does not qualify as a play position for DSound because it could be that late that it doesn't even fit into DSound's tiny buffer; we don't control it; for the sake of bug #28723 we introduced latency, mmdevapi's and ALSA's buffer all add up. Instead, I believe we should treat DSound + mmdevapi + ALSA as what it really is: a chain of filters, adding up their latency, each with their own buffering constraints. DSound's primary buffer contents should be fed to mmdevapi piece by piece. IOW, DSound's read pointer follows mmdevapi's write pointer. Perhaps we could add GetStreamLatency to come a little closer to the actual speaker position.
OTOH you may argue that dsound:GetCurrentPosition appears to be the only function that apps can use for synchronisation purposes (requiring GetPosition & snd_pcm_delay). Alas it is expressed in terms of buffer positions, which is not that surprising given that D means Direct, i.e. a HW buffer model. Hence Wine must find a consistent way to map speaker positions onto the buffer(s). Clearly, here mmdevapi has the better separation of concerns.
MS seems to realize this, see DSBCAPS_TRUEPLAYPOSITION http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sd...
The dilemma is: For the sake of bug #28723, we've increased latency in mmdevapi, still having GetPosition return a true speaker position for the purpose of lip synchronization, while DSound's buffer model and following lack of distinction between frontmost buffer position and true speaker position does not fit well with mmdevapi's streaming. DSound is much like ALSA's hw:0: there, snd_pcm_delay + avail_update == buffer_size, i.e. what leaves the buffer is immediately heard, according to ALSA, there's no other latency.
So Wine's DSound jobs are: a) Have GetCurrentPosition provide values suitable for lip-sync'ing -- see MSDN about DSBCAPS_GETCURRENTPOSITION2 b) Have buffers large enough that a) can work; c) Have buffers small enough that the illusion of direct HW access can be maintained; d) Have latency as small as possible (fast audio feedback); Great fun!
What I don't know is: does DSound's primary buffer "materialize" (via a data pointer) when using secondary buffers, or is it then inaccessible to apps? In the latter case, mmdevapi's buffer could serve as primary (mixing like described above), eliminating a bit of latency for the sake of Wine gamers that want short audio response times. When the app requests WRITEPRIMARY, this shortcut is not possible, and primary's contents must be copied into mmdevapi, because the two buffer behaviours are incompatible on paper (one is fixed circular, the other dynamic). It is conceivable that native avoids that by having a fixed mmdevapi buffer with only rare auxiliary ones in case of wrap-around (like winealsa, unlike winecoreaudio), the output of my tests seems to back this up, but it's undocumented. I wonder whether/when we'll hit the first bug like DSound bug #28748, comment #1, that some apps touches mmdevapi's buffer outside of the Get/ReleaseBuffer pair. That might crash winecoreaudio.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #10 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-03 16:53:04 CST --- http://forums.create.msdn.com/forums/t/9214.aspx explains DSBCAPS_*POSITION "by default DSound reports play cursors that increase in regular 10ms jumps." That's what GetCurrentPadding does, not GetPosition. TRUEPLAYPOSITION: increase more smoothly, for backwards compatibility When I read this I'm always tempted to implement the old behaviour by default...
Also interesting: http://www.lysator.liu.se/snes9x/1.42/changes.txt - Added yet another sound buffer option to the Windows port - this time the block size of sound data to mix. Some DirectSound sound card drivers only report the play position moving in steps rather than continuous amounts and Snes9x's default mix block size turned out to be smaller than this step value on several cards. Snes9x couldn't work out out where the true play position was accurately enough resulting in broken, noisy sound output.
Presumably positions reported modulo buffer size cause problems when you don't query them often enough to follow with pos += buffer_size.
We really need somebody to write the equivalent of my mmdevapi GetPosition render tests for DSound!
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #11 from marzojr@yahoo.com 2012-01-09 18:41:12 CST --- (In reply to comment #7)
Some log lines are cut off or missing. Please use the >> trick from bug #19125, comment #2 when generating logs next time.
I will get around to it this weekend.
BTW, what is your OS?
Ubuntu Oneiric Ocelot x64, using Gnome 3 fallback.
106 additional test failures
What sort of failures?
It failed 106 tests more; the log wasn't specific about which ones failed. I will generate the log and attach it this weekend.
You pointed to a download but is it enough? Where can we find a game to load?
The download I gave was for the emulator; for a game, I can reliably get an error with just about any game, including the "Lawn Boy" homebrew game linked to at http://www.squidoo.com/sega-genesis-homebrew (the two after it require hardware not emulated by this particular emulator).
FYI, I get similar problems on other Windows programs requiring audio, but it is far more reliably triggered by this particular program.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #12 from Jörg Höhle hoehle@users.sourceforge.net 2012-01-23 08:07:30 CST --- Update on TRUEPLAYPOSITION. The author of a program named BASS noted: http://www.bass.radio42.com/help/html/3490e2bc-7f3a-9135-3d24-ee519029f737.h... http://www.un4seen.com/forum/?PHPSESSID=k4r85j2pfbitrajp29996jq6f0&topic... "... the use of DirectSound's new DSBCAPS_TRUEPLAYPOSITION option by BASS 2.4.3, [...] improves the precision of position reporting on Vista (it's only within 10ms otherwise). But after some further testing, it also appears to increase latency by around 20ms."
When I read this, I'm tempted to conclude that TRUEPLAYPOSITION uses mmdevapi's GetPosition, reporting speaker positions closer to the DAC, whereas GETCURRENTPOSITION[2] expresses speaker position as seen in DSound's buffer, completely ignoring that mmdevapi now sits beneath it, adding its 30-40ms (not 20ms AFAICT) share to latency.
IOW, old useage of DSound without that Vista-era flag does not report speaker positions in modern systems built with "advanced" audio servers. That's the legacy of its low-level HW ("Direct") approach. It's no more hitting the copper since Vista.
In practice, native's mmdevapi does not introduce too much latency for this to become perceptible: http://www.tesoga.com/articles/crossplat5.html "most people are not good at perceiving sound latency if it is kept down to 100-150 milliseconds."
Therefore, lip-sync based on GetCurrentPosition still appears to work. Furthermore, its 30ms is small enough to fit DSound's buffer such that the play+write pointer pair abstraction can still be made to work.
But Wine's mmdevapi is different. As you can verify by running my mmdevapi render GetPosition tests, winealsa is currently around 80ms with ALSA/dmix. Add DSound's own buffering and you get close to that 100ms limit. Add PulseAudio's typical delay and you get to values where you start wondering why bugzilla is not already flooded with complaints about late explosion noise.
Even worse, Wine useage scenarios comprise running with remote desktops, networked audio, PulseAudio and the like. There, true speaker position can be so far away from data still in DSound's typical 100ms buffer that it'll break the play+write pointer abstraction. Roughly, I'd say that if latency > half that buffer size (50ms), the abstraction will break down because there will be too little room for the app to write data or because it may not wake up often enough to write data at all.
My recommendation: 0. Observe how native behaves with high-latency equipment/environments. A. Have GETCURRENTPOSITION[2] yield DSound's buffer position, ignoring the following mmdevapi and host latency. B. Have TRUEPLAYPOSITION (when it'll be implemented) take mmdevapi's GetPosition into account, but cap it if it's too large for DSound's buffer.
Possible improvements: 0. Consider increasing DSound's primary buffer. A. Add mmdevapi's GetCurrentPadding -- again, if not too large. B. Have DSound bypass mmdevapi??
I'm unsure whether faking positions using a clock may help work-around pre-buffering such as PA does, but also some native equipment. I've received logs where some native sound card too initially consumed a lot of frames, then stabilized. That's why padding is not a good indicator of speaker positions. A distinct clock may cause issues when running for hours.
http://bugs.winehq.org/show_bug.cgi?id=29472
Rafal Stanilewicz washuu@eastnews.com.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |washuu@eastnews.com.pl
--- Comment #13 from Rafal Stanilewicz washuu@eastnews.com.pl 2012-02-20 03:48:26 CST --- I use wine-1.4-rc4, Ubuntu 11.10, winealsa.drv and Intel sound card.
On my system LawnBoy is completely silent, but several other commercial games run OK with audible, normal sound.
Please, let someone else confirms before mark as fixed.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #14 from marzojr@yahoo.com 2012-02-20 06:18:58 CST --- I have been able to trigger the crash in the latest release, but not on latest Git; so I think it is safe to say that it is fixed in latest Git.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #15 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-20 11:26:36 CST ---
the latest release, but not on latest Git
Currently, latest release (1.4-rc4) and latest git are identical. It's only this evening that you'll see new commits. What did you use?
able to trigger the crash
What crash? You mentioned a lock-up until now.
BTW, the recently added registry key http://wiki.winehq.org/UsefulRegistryKeys may allow you to bypass PulseAudio without killing it.
In comment #11, you promised a log. You never showed the nature of the 106 test failures. I'd be interested in a log from: cd dlls/mmdevapi/tests; rm /tmp/render.log WINETEST_INTERACTIVE=1 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi wine mmdevapi_test.exe.so render >>/tmp/render.log 2>&1 with winecfg or the registry configured to use your working device (if not "default"). Do you hear the test sound with your USB device?
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #16 from marzojr@yahoo.com 2012-02-20 12:46:52 CST --- Created attachment 38990 --> http://bugs.winehq.org/attachment.cgi?id=38990 Log for current git with WINETEST_INTERACTIVE=1 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi
Currently, latest release (1.4-rc4) and latest git are identical. It's only this evening that you'll see new commits. What did you use?
I still had wine-1.4-rc2 installed; I now see that 1.4-rc4 is available on the updater.
able to trigger the crash
What crash? You mentioned a lock-up until now.
That is what I meant, sorry. And now that the problem seems to be fixed, I have another bug report to open due to another issue on Regen that was hidden by the lock-up.
In comment #11, you promised a log. You never showed the nature of the 106 test failures.
I should have mentioned sooner that I have been needing to use my computer to compile code and run simulations to meet a deadline, which is why I never posted the log; the deadline is gone now, so I can test this again. Having done the test (using the same revision I used for the earlier tests), I can summarize the log as follows: a diff of the test with the attachments for the 350ms and 750ms logs show that all but the very last line are nearly identical; the last line reports reports 106 failures instead. So the log is useless, as it does not say what failed.
Should I redo it with latest git?
I'd be interested in a log from: cd dlls/mmdevapi/tests; rm /tmp/render.log WINETEST_INTERACTIVE=1 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi wine mmdevapi_test.exe.so render >>/tmp/render.log 2>&1 with winecfg or the registry configured to use your working device (if not "default"). Do you hear the test sound with your USB device?
In winecfg, I can hear the test sound; in this test, I can't (but I can hear the USB sound card turning on, it gives off a very faint white noise when it is on). I attached the full log, just in case.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #17 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-20 16:14:06 CST --- Well, you are the original reporter. If you find the bug fixed you should change the status and mark the bug fixed. Regardless of that, Wine must rethink DSound's GetCurrentPosition. I'm simply surprised because I'm not aware of a recent change in the GetPosition area. If you have time to kill, perform a reverse regression test to see which commit fixed the issue.
So the log is useless, as it does not say what failed.
I don't understand. A typical log shows what failed. Your latest log mentions exactly 1 failure, not 106: render.c:866: Test failed: Activation failed with 8889000a render.c:868: Tests skipped: Unable to open the same device twice. Skipping session tests render: 610 tests executed (0 marked as todo, 1 failure), 2 skipped.
I can't [hear the test sound]
The audible test was not present in 1.4-rc2. You don't need bug #27937 anymore, all of my tests are in git now.
http://bugs.winehq.org/show_bug.cgi?id=29472
--- Comment #18 from marzojr@yahoo.com 2012-02-20 18:33:12 CST --- (In reply to comment #17)
Well, you are the original reporter. If you find the bug fixed you should change the status and mark the bug fixed. Regardless of that, Wine must rethink DSound's GetCurrentPosition. I'm simply surprised because I'm not aware of a recent change in the GetPosition area. If you have time to kill, perform a reverse regression test to see which commit fixed the issue.
To be fair, wine-1.4-rc2 was already better: the programs still hanged, but only sometimes; when I tested earlier, I 'lucked out' and got the hangs in wine-1.4-rc2, but I haven't gotten one since. It may be that there were several factors in the hang that were fixed
I can't be sure exactly when it stated to improve because I have been either disabling sound in programs (due to the bug) or using programs that don't have audio, and I have been using Regen very infrequently because of the bug and of the aforementioned deadline. I haven't experienced any hangs in wine-1.4-rc4 so far. I will keep the bug open until I perform the reverse regression.
I don't understand. A typical log shows what failed. Your latest log mentions exactly 1 failure, not 106:
The log I posted was for latest git. But you are right, it has a lot less failures than the other logs had.
http://bugs.winehq.org/show_bug.cgi?id=29472
marzojr@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38990|0 |1 is obsolete| |
--- Comment #19 from marzojr@yahoo.com 2012-02-21 17:40:23 CST --- Created attachment 39015 --> http://bugs.winehq.org/attachment.cgi?id=39015 Log for current git with WINETEST_INTERACTIVE=1 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi
I re-did the last test because I had forgotten that my automated build script disables building the tests, so it was from an older version. With the newest test, I can hear the sounds perfectly.
Also, as I told Höhle over e-mail, I finished the reverse regression test and found out that nothing that was nothing in Wine since I first reported the bug was responsible for the fix; I tested versions as far back as those for which the bug reliably caused Regen to lock-up, and all of the versions worked without lock-ups; this is at direct odds with my earlier regression testing. Even my tests earlier with wine-1.4-rc2 were unrepresentative -- I seem to have 'lucked out' and gotten a hang before, which I could not reproduce since.
My best guess is that the change I first identified through regression testing did not play nice with the kernel/pulseaudio/alsa version I had back then, but that one of the more recent updates mitigates the issue; maybe there is even a newer/better driver for the USB sound card I am using, who knows.
I would still like to see the changes Höhle proposes, but I can't justify keeping open this bug report, since I can't reproduce the problem even with the versions of Wine for which it happened.
Now to wait for the next kernel update to break things again...
http://bugs.winehq.org/show_bug.cgi?id=29472
marzojr@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WORKSFORME
--- Comment #20 from marzojr@yahoo.com 2012-02-21 17:42:50 CST --- Setting it to 'works for me' since (a) it no longer locks-up, but (b) it wasn't fixed due to anything done in the Wine side.
http://bugs.winehq.org/show_bug.cgi?id=29472
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |adys.wh@gmail.com Resolution|WORKSFORME |INVALID
--- Comment #21 from Jerome Leclanche adys.wh@gmail.com 2012-02-24 05:46:44 CST --- Invalid is the correct resolution. Closing
-
wine-bugs＠winehq.org