http://bugs.winehq.org/show_bug.cgi?id=23230
Summary: After playing awhile MIDI freezes Product: Wine Version: 1.2-rc3 Platform: x86 URL: http://www.mozart.co.uk/programs/mzsetup.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs@winehq.org ReportedBy: let02do@earthlink.net CC: m.b.lankhorst@gmail.com
Created an attachment (id=28911) --> (http://bugs.winehq.org/attachment.cgi?id=28911) A music file which on two playbacks shows the bug
Mozart10 is a music notation and notation editing program. Being able to hear a MIDI output from entered notes, and the ability to play a notated section or whole piece is a *very* important feature of the program.
This bug causes the midi playback to freeze on a note, making the program largely useless. The bug occurs after the program plays a piece to completion, and then re-plays the piece.
This MIDI bug is a regression. The most recent WINE without the bug is wine-1.1.44
After playing a long enough piece through and then attempting to re-play it, the piece will play only part way through, and midi will hang, requiring the program to be closed. When it hangs the console displays:
err:mmtime:TIME_MMTimeStart Cannot create pipe: Too many open files wine client error:c: pipe: Too many open files
At this point the program cannot be normally closed, and must be killed.
Using wine-1.2-rc3 checked out with git for regression testing I have this result:
00eaa9294559bb75cf5cbf7f1b61c3e239d08d62 is first bad commit commit 00eaa9294559bb75cf5cbf7f1b61c3e239d08d62 Author: Maarten Lankhorst m.b.lankhorst@gmail.com Date: Mon May 17 19:58:28 2010 +0200
winmm: Make timer keep a ref on winmm while it's running.
:040000 040000 818c00e328e36daa9473a76362d9b96b6071f7fc 551895b70e1730eb0b1c19a5f2c1b0e179c6f78c M dlls
I have attached one of my Mozart files which can be used demonstrate the bug. (Note that your system must be able to play MIDI)
http://bugs.winehq.org/show_bug.cgi?id=23230
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression CC| |wylda@volny.cz
http://bugs.winehq.org/show_bug.cgi?id=23230
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|After playing awhile MIDI |Mozart10: midi playback |freezes |freezes after awhile
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #1 from Maarten Lankhorst m.b.lankhorst@gmail.com 2010-06-18 07:07:13 --- Does reverting that commit help?
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #2 from Lawrence E Toal let02do@earthlink.net 2010-06-18 12:59:09 --- (In reply to comment #1)
Does reverting that commit help?
I seem to have run into a difficulty doing that. After resetting the bisect with:
git bisect reset
This yielded:
Checking out files: 100% (676/676), done. Previous HEAD position was cc784e2... shdocvw: Added IDataObject stub implementation. Switched to branch 'master'
Then for the patch:
git show 00eaa9294559bb75cf5cbf7f1b61c3e239d08d62 | patch -p1 -R
gave this:
patching file dlls/winmm/time.c Hunk #8 FAILED at 368. 1 out of 8 hunks FAILED -- saving rejects to file dlls/winmm/time.c.rej
I'll upload the file: time.c.re
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #3 from Lawrence E Toal let02do@earthlink.net 2010-06-18 13:03:07 --- Created an attachment (id=28936) --> (http://bugs.winehq.org/attachment.cgi?id=28936) The rejects file from trying to revert the comit
the commit was:
00eaa9294559bb75cf5cbf7f1b61c3e239d08d62
http://bugs.winehq.org/show_bug.cgi?id=23230
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #28936|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #4 from Lawrence E Toal let02do@earthlink.net 2010-06-18 13:48:43 --- After reverting the commit that bisect gave as "last bad," upon re-compiling the bug has slightly changed. Previously, when playing the Mozart file I uploaded, it would play through fully once, then have a midi freeze about halfway through a second play. Now, after a first play through, the freeze happens almost immediately when a second play is tried. I.E., the bug happens more quickly now.
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #5 from Lawrence E Toal let02do@earthlink.net 2010-06-20 02:18:41 --- Just an update--the bug is still present with release candidate wine-1.2-rc4
http://bugs.winehq.org/show_bug.cgi?id=23230
Maarten Lankhorst m.b.lankhorst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #6 from Maarten Lankhorst m.b.lankhorst@gmail.com 2010-06-20 13:44:38 --- Can you paste a WINEDEBUG=+module,+mmtime,+tid ?
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #7 from Lawrence E Toal let02do@earthlink.net 2010-06-20 17:19:44 --- (In reply to comment #6)
Can you paste a WINEDEBUG=+module,+mmtime,+tid ?
OK I've been in the habit of compiling without debug enabled to save time...it took me a while to remember to edit the build script to be able to do this... You might have had a giggle watching me try to run debug without having it compiled in :-) I was getting quite creative in console commands :-)
Anyway, after re-building and running:
WINEDEBUG=+module,+mmtime,+tid wine "C:\Program Files\Mozart10\Mozart32.exe" &>DBmzLog
The output was piped to"DBmzLog" --It's a fairly long file, so I'll upload it.
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #8 from Lawrence E Toal let02do@earthlink.net 2010-06-20 17:40:17 --- (In reply to comment #6)
Can you paste a WINEDEBUG=+module,+mmtime,+tid ?
Oops, the file was too long to upload here (2.77MB) so I put it at this URL:
http://www.mathblade.com/Mozart-Files/DBmzLog
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2010-06-20 19:31:12 --- (In reply to comment #8)
Oops, the file was too long to upload here (2.77MB) so I put it at this URL:
Compress it, e.g. with bzip2, and attach that here.
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #10 from Lawrence E Toal let02do@earthlink.net 2010-06-20 20:04:41 --- Created an attachment (id=29044) --> (http://bugs.winehq.org/attachment.cgi?id=29044) WINEDEBUG=+module,+mmtime,+tid <output using Mozart with -rc4>
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #11 from Lawrence E Toal let02do@earthlink.net 2010-06-27 16:02:06 --- Another update--the bug is still present with release candidate wine-1.2-rc5. Recapping:
Mozart's MIDI playback freezes on a single note, and upon stopping the playback, the wine console message is:
"wine client error:24: pipe: Too many open files"
At this point the program is unusable and must be killed. The most recent WINE without the bug is wine-1.1.44
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #12 from Lawrence E Toal let02do@earthlink.net 2010-07-20 00:45:28 --- I was not happy with the bisect results I posted here. With the new stable wine-1.2 released, I decided to re-try the bisect using version 1.2 and wine-1.1.44 as the last good version. Perhaps it was the practice, or maybe I just didn't screw it up this time, but the process and these results seem more like what I expected. Here they are:
let01@arc:~/wine-git$ git bisect bad 00eaa9294559bb75cf5cbf7f1b61c3e239d08d62 is first bad commit commit 00eaa9294559bb75cf5cbf7f1b61c3e239d08d62 Author: Maarten Lankhorst m.b.lankhorst@gmail.com Date: Mon May 17 19:58:28 2010 +0200
winmm: Make timer keep a ref on winmm while it's running.
:040000 040000 818c00e328e36daa9473a76362d9b96b6071f7fc 551895b70e1730eb0b1c19a5f2c1b0e179c6f78c M dlls
Reverting the patch gives :
let01@arc:~/wine-git$ git bisect reset Checking out files: 100% (1146/1146), done. Previous HEAD position was 00eaa92... winmm: Make timer keep a ref on winmm while it's running. Switched to branch 'master' let01@arc:~/wine-git$ git show 00eaa9294559bb75cf5cbf7f1b61c3e239d08d62 | patch -p1 -R patching file dlls/winmm/time.c Hunk #8 FAILED at 368. 1 out of 8 hunks FAILED -- saving rejects to file dlls/winmm/time.c.rej
And after a re-compile and re-test, the bug is gone.
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #13 from Lawrence E Toal let02do@earthlink.net 2010-08-05 13:16:48 --- The bug is still present on wine 1.3.0
http://bugs.winehq.org/show_bug.cgi?id=23230
--- Comment #14 from Lawrence E Toal let02do@earthlink.net 2010-08-24 20:06:49 --- I just tested the newest development release wine-1.3.1 for the MIDI bug.
The MIDI bug present in each release since 1.1.44 is no longer present--very nice... But I am curious, was this fixed by the memory leak patch?
Well, whatever the fix was, thanks for the work you all do on WINE. I can happily report to my fellow WINE/MOZART users that this current release runs MOZART without the MIDI problem. Sadly, Ubuntu users seem stuck back with the stable release 1.2. Perhaps they'll have some fun learning to build WINE.
--Lawrence
http://bugs.winehq.org/show_bug.cgi?id=23230
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #15 from Jeff Zaroyko jeffz@jeffz.name 2010-08-25 03:03:13 --- (In reply to comment #14)
I just tested the newest development release wine-1.3.1 for the MIDI bug.
The MIDI bug present in each release since 1.1.44 is no longer present--very nice... But I am curious, was this fixed by the memory leak patch?
If you want a definite answer, a reverse regression test would tell you which commit fixed it.
You can point Ubuntu users to this page: http://www.winehq.org/download/deb to get the latest testing release of Wine as a binary package.
Marking fixed.
http://bugs.winehq.org/show_bug.cgi?id=23230
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org 2010-09-03 14:05:30 CDT --- Closing bugs fixed in 1.3.2.