http://bugs.winehq.org/show_bug.cgi?id=14161
Summary: quartz regression - crash in PullPin_Thread_Process Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: quartz AssignedTo: wine-bugs@winehq.org ReportedBy: alexd4@inbox.lv CC: m.b.lankhorst@gmail.com Blocks: 12722
New quartz crash started occuring since commit 6aabf5d39e1a5bd13d95a9ad7a9b318f775c95fd (quartz: Create thread after connection is made.). I get this with a game Thief The Dark Project where I'm trying to fix another bug. Unfortunately, to even get far enough to see the crash some hacks and semi-ready patches that I've in my tree are necessary, e.g. hack for querying IFilterMapper from IFilterGraph (see http://bugs.winehq.org/show_bug.cgi?id=12722). Also as of today's git reverting 6ad6ff0198df385706e53d246d0ca9b023dd758d and d54c53a4b64223cb5744571b9f56064543e385c0 (different regressions that cause program to go blow up earlier) is necessary to get to this crash. I don't have much quartz test cases so I don't know what else may be affected. I'll attach a +quartz log and I'll be around if any other info or patch testing is required.
So far I found out that it crashes in PullPin_Thread_Process(), because This->fnCustomRequest is NULL, hope that helps.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #1 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-28 09:22:53 --- Created an attachment (id=14424) --> (http://bugs.winehq.org/attachment.cgi?id=14424) +quartz,+tid log
This is +quartz,+tid log generated by starting Thief and trying to play intro video, that causes unhandled exception crash.
33884dfef182e70943688aa249fc066d7fbbe1cd and 69d4881be9757a0be363f5cb435d7ce1f59b39e7 are reverted and out of tree hack to query IFilterMapper in FilterGraph applied.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #2 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-28 10:54:54 --- Oh, sorry, the above posts contain wrong commit hashes. Correct hashes for two other commits causing issues are
d54c53a4b64223cb5744571b9f56064543e385c0 quartz: Fix Render and RenderFile. b157969d49bd81d23b542b19d55a8c1f8bd004d8 quartz: Only enumerate renderers if bRender is set in filtermapper.
Regarding d54c53a4b64223cb5744571b9f56064543e385c0 - I'm checking what happens and I think that commit is wrong because now for some reason it's trying to connect the game's custom renderer during RenderFile("intro.avi") call. But the game's custom renderer ("LG Video Renderer") appears to have MERIT_UNLIKELY, while standart "Video Renderer" has higher merit MERIT_PREFERRED (as far as i can tell).
Before, RenderFile was connecting "Video Renderer" there, which seems more correct to me as "Video Renderer" should be preferred(?). So before it was RenderFile(), then EnumMatchingFilters(), then game finds "LG Video Renderer", disconnects standart video renderer from the graph and connects its own. With d54c53a4b64223cb5744571b9f56064543e385c0 it crashes during RenderFile in some pin's method in its custom renderer DLL. Can't tell for sure from the assembly, but I guess when doing RenderFile the game hasn't yet properly initialized the custom renderer or something along those lines and it isn't ready for connection.
http://bugs.winehq.org/show_bug.cgi?id=14161
Alexander Dorofeyev alexd4@inbox.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|quartz regression - crash in|quartz regressions - crash |PullPin_Thread_Process |in PullPin_Thread_Process & | |more
--- Comment #3 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-28 11:16:14 --- b157969d49bd81d23b542b19d55a8c1f8bd004d8 quartz: Only enumerate renderers if bRender is set in filtermapper.
^ This one may also be wrong. It prevents game from finding its custom renderer with EnumMatchingFilters because it passes bRender = FALSE. Perhaps with bRender=TRUE it should only return renderers but with bRender=FALSE it shouldn't care, it's not very clear from msdn wording. Working on a conformance test to figure out precisely...
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #4 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-28 12:18:51 --- Created an attachment (id=14428) --> (http://bugs.winehq.org/attachment.cgi?id=14428) conformance test for bRender / EnumMatchingFilters
Test demonstrating native returns a renderer if bRender=FALSE, does not return non-renderer if bRender=TRUE.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #5 from Maarten Lankhorst m.b.lankhorst@gmail.com 2008-06-28 13:44:37 --- I have submitted a patch that rewrites the avi splitter, if you apply that the avi splitter should work again. Or you can revert the breaking commit for now.
Could you send the enummatchingfilters patch to wine-patches?
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #6 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-28 15:42:35 --- (In reply to comment #5)
I have submitted a patch that rewrites the avi splitter, if you apply that the avi splitter should work again. Or you can revert the breaking commit for now.
Ok I'll try to test with that patch.
Could you send the enummatchingfilters patch to wine-patches?
I'm currently working on some other misc fixes in quartz, hope to submit it tomorrow. BTW, by enummatchingfilters do you mean the test or the test + revert of commit that broke it (changed bRender logic)?
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #7 from Maarten Lankhorst m.b.lankhorst@gmail.com 2008-06-28 16:45:11 --- Test + revert commit that broke. :-)
http://bugs.winehq.org/show_bug.cgi?id=14161
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #8 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 08:53:17 --- Ok, some updates on this. I sent test, revert and some other fixes to wine-patches.
Experience with your avi splitter rewrite: yes it seems to fix the PullPin_Thread_Process crash. Also it seems to introduce noticeable improvements here and there. For example, several videos previously had a problem that sound would only start playing after video has finished. Now this seems to be fixed (at least in the intro video that had this problem). Also, the credits video that was previously crashing immediately when activated now seems to be playing right. Nice to see these problems gone, yay! :) New issue noticed though: Assertion `((HRESULT)(hr)>=0)' when shutting down (when video plays till the end or is aborted by pressing ESC. Previously it was hanging on stop, but in some yet earlier git versions (like few weeks ago) it was stopping without problems, unfortunately this part regressed. I'll try to attach the log from such a session.
There is one more still standing regression though, from the quartz: Fix Render and RenderFile patch. It still crashes the game because a custom MERIT_UNLIKELY renderer is connected instead of MERIT_PREFERRED standart renderer (looks wrong to me although I didn't deeply research or test this so far). Any idea about this? I can add logs for this if you are interested.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #9 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 09:01:30 --- Created an attachment (id=14444) --> (http://bugs.winehq.org/attachment.cgi?id=14444) +quartz,+tid log with new avisplitter, failed assert
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #10 from Maarten Lankhorst m.b.lankhorst@gmail.com 2008-06-29 17:16:49 --- You can take out the asserts that are tripping, I'm working on a real fix.
Also, could it be that the Render regression might be because the renderer is added manually by the application?
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #11 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 17:34:06 --- (In reply to comment #10)
You can take out the asserts that are tripping, I'm working on a real fix.
Also, could it be that the Render regression might be because the renderer is added manually by the application?
I think not. I checked the quartz log again, I see no AddFilter calls preceding the RenderFile call. It seems to be pretty much filtergraph creation stuff and RenderFile right after, and as far as I can tell it crashes within this RenderFile. I'll attach a log.
The game does manually add a renderer if all goes well, but normally that happens after this first RenderFile successfully returns.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #12 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-29 17:35:39 --- Created an attachment (id=14462) --> (http://bugs.winehq.org/attachment.cgi?id=14462) +quartz,+tid log, crash in RenderFile
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #13 from Alexander Dorofeyev alexd4@inbox.lv 2008-07-04 17:29:57 --- I've found out that the problems with Render/RenderFile patch come from the fact that it always calls EnumMatchingFilters with bRender=TRUE on first pass (because !final is TRUE). This prevents EnumMatchingFilters from returning Indeo video decompressor filter (since it's not a renderer) at the point when it should be connecting this filter to Avi Splitter's video pin. So Render cycles through some filters, none of which of course accepts IV50, then it gets to "LG Video Renderer" filter that has been returned from EnumMatchingFilters because it has major type Video and subtype NULL and is a renderer. Render tries to establish connection with LG Video Renderer, which crashes, probably because this is something unexpected for the app.
Not sure what exactly is wrong there. It may be wrong that a filter with MERIT_UNLIKELY - "LG Video Renderer" - was used instead of filter with MERIT_NORMAL - "Indeo video decompressor". It may also make sense to look for a more "perfect" match first, to avoid the kind of situation when it tries to connect MEDIATYPE_Video / IV50 pin to MEDIATYPE_Video / NULL pin of a renderer. Maarten, what do you think? I of course realize that ideally instead of guessing this should be tested, but I don't know how... writing and registering a simple filter implementation for tests is, perhaps, doable, but then it would need a com server dll afaik.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #14 from Alexander Dorofeyev alexd4@inbox.lv 2008-07-08 16:02:54 --- I've submitted a test for native trying a non-renderer with higher merit first, even if there is a renderer with lower merit, and a corresponding fix to FilterGraph2_Render. If it will be accepted, then the only remaining part to fix problems will be the avi splitter rewrite.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #15 from Alexander Dorofeyev alexd4@inbox.lv 2008-07-08 16:06:25 --- BTW, the new version of avi splitter (the one last submitted to wine-patches) works better, does not trigger asserts etc. It's a bit noisy on the console though, lots of fixmes and even errs appear, even though everything seems to be working. I wonder if some normal conditions are possibly interpreted as errors. Logs can be provided if needed.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #16 from Maarten Lankhorst m.b.lankhorst@gmail.com 2008-07-08 16:08:38 --- It's a bit noisy, but that was done so I can find bottlenecks easily. You don't have to pay much attention to it, it is merely so I know what is going on when for example sound suddenly stops playing.
http://bugs.winehq.org/show_bug.cgi?id=14161
--- Comment #17 from Alexander Dorofeyev alexd4@inbox.lv 2008-07-08 16:16:14 --- I mean stuff like this:
err:quartz:AVISplitter_next_request END OF STREAM ON 0 fixme:quartz:AVISplitter_done_process Waiting for 0 to terminate fixme:quartz:AVISplitter_thread_reader Receiving error: 80040227 fixme:quartz:AVISplitter_thread_reader Thread 0 terminated with hr 80040227! fixme:quartz:AVISplitter_done_process Waiting for 1 to terminate err:quartz:AVISplitter_next_request ... 80040211? err:quartz:AVISplitter_next_request ... 80040211? fixme:quartz:AVISplitter_first_request Created stream 0 thread 0x00000025 fixme:quartz:AVISplitter_first_request Created stream 1 thread 0x00000026 err:quartz:AVISplitter_first_request Horsemen of the apocalypse came to bring error 0x80040211
It appears that harmless (?) end of stream condition is generating a serious sequence of scary looking errors down the road.
http://bugs.winehq.org/show_bug.cgi?id=14161
Alexander Dorofeyev alexd4@inbox.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #18 from Alexander Dorofeyev alexd4@inbox.lv 2008-07-09 11:21:37 --- all regression crashes now fixed in current git, marking fixed.
http://bugs.winehq.org/show_bug.cgi?id=14161
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2008-07-11 11:10:48 --- Closing bugs fixed in 1.1.1.
http://bugs.winehq.org/show_bug.cgi?id=14161
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
-
wine-bugs＠winehq.org