http://bugs.winehq.org/show_bug.cgi?id=19854
Summary: Oblivion crashes constantly if music is enabled Product: Wine Version: 1.1.28 Platform: All OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz AssignedTo: wine-bugs@winehq.org ReportedBy: billy65bob@gmail.com
Created an attachment (id=23274) --> (http://bugs.winehq.org/attachment.cgi?id=23274) checks for failure earlier, and prevents null pointers beiong passed to IMediaSample_SetTime()
I can even confirm this regression using versions as old as 1.1.1. so I'm quite surprised no one has reported this earlier.
When playing Oblivion with music enabled, chances are you'll constantly be switching between the area's main theme and the battle theme, which currently in wine results in a brief slowdown (bug 14186 was filed regarding the slowdowns), during this transition quartz quite often crashes, when *sample == 0x00000000, is passed to IMediaSample_SetTime().
I'm including a patch with this bug report (to which I have no doubt is incorrect), which at least nullifies the crashes, and from oblivion's viewpoint, doesn't remove any functionality.
just in case it's relevant
Sound card: HDA Intel Sound System: ALSA
Wine settings
Driver: ALSA Accel: Full DEfault Frequenzy: 48000 Default bps: 16
http://bugs.winehq.org/show_bug.cgi?id=19854
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other OS/Version|All |other
http://bugs.winehq.org/show_bug.cgi?id=19854
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2009-08-27 10:41:09 --- The second hunk in your patch: - if (FAILED(hr)) - FIXME("o_Ox%08x\n", hr); + is unnecessary, and in fact won't do anything, right? Since if hr failed, you would already have returned.
I don't think this is the best approach, but it has some merit.
The question is, why is IMemAllocator_GetBuffer failing? And where's the accompanying release of the returned sample?
http://bugs.winehq.org/show_bug.cgi?id=19854
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #23274|0 |1 is obsolete| |
--- Comment #2 from Juan Lang juan_lang@yahoo.com 2009-08-27 10:42:35 --- Created an attachment (id=23275) --> (http://bugs.winehq.org/attachment.cgi?id=23275) Patch: Don't crash if sample allocation fails
Here's one that I think is stylistically better, though it doesn't resolve the question of when the sample is freed. Does it work for you?
http://bugs.winehq.org/show_bug.cgi?id=19854
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=19854
--- Comment #3 from Kevin Meyer billy65bob@gmail.com 2009-08-27 18:02:02 --- (In reply to comment #2)
Created an attachment (id=23275)
--> (http://bugs.winehq.org/attachment.cgi?id=23275) [details]
Patch: Don't crash if sample allocation fails
Here's one that I think is stylistically better, though it doesn't resolve the question of when the sample is freed. Does it work for you?
Thanks for that, it does the trick nicely and judging by newer debug messages, prevented at least 8 NULLs being passed to the functions. (of which 1 message was that for the original fixme)
On the other hand, this 'bug' seems to be the sort that occurs when processes are multithreaded. ( as in, another thread is modifying the buffer for this thread, while this thread is busy working with it) does this mean there's simply a lack of relevant thread safety (mainly with (un)locking mutexes) within the processing functions? or is something else at work here?
http://bugs.winehq.org/show_bug.cgi?id=19854
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2009-08-27 18:06:14 --- (In reply to comment #3)
On the other hand, this 'bug' seems to be the sort that occurs when processes are multithreaded. ( as in, another thread is modifying the buffer for this thread, while this thread is busy working with it) does this mean there's simply a lack of relevant thread safety (mainly with (un)locking mutexes) within the processing functions? or is something else at work here?
That's a good question, and I don't know the answer. I'm not at all familiar with this part of the code.
Someone sent some other changes to quartz, starting here: http://www.winehq.org/pipermail/wine-patches/2009-August/077769.html
I have no reason for believing they'll help, but I don't have any reason to believe they won't, either ;-) You might give them a go.
Back to this bug: I'll send my patch in, if you don't mind.
http://bugs.winehq.org/show_bug.cgi?id=19854
Kevin Meyer billy65bob@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #5 from Kevin Meyer billy65bob@gmail.com 2009-08-28 10:36:21 --- I saw your patch got accepted; commit e73f31a6ef0e9ee92d9d2c9776e5e5ebe6eebe6c; congrats :)
I guess that means this half of the oblivion sound problems can be marked as fixed, which in itself is music to my ears ;)
http://bugs.winehq.org/show_bug.cgi?id=19854
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2009-09-02 14:31:58 --- Closing bugs fixed in 1.1.29.
-
wine-bugs＠winehq.org