http://bugs.winehq.org/show_bug.cgi?id=60501 Bug ID: 60501 Summary: Picross for a Cause crashes after a song is played again (mf session requests a sample from a NULL source stream) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs@list.winehq.org Reporter: marepetru2015@gmail.com Target Milestone: --- Distribution: --- Created attachment 82359 --> http://bugs.winehq.org/attachment.cgi?id=82359 it's the test program, its source, three 2-second test songs, and a README with how to run it and the results on Windows and Wine. Product: Wine Picross for a Cause (free on Steam, MonoGame 3.7.1 WindowsDX build) crashes after 10 minutes or more of play. ProtonDB has reports of this with every Proton version. I hit it with GE-Proton11-7 and reproduced it on upstream Wine (wine-11.19-226-ga312fc87a5) with the attached test program. The game picks a random song (5 WMA files, 1:49 to 3:24 long) whenever the previous one ends. The crash happens when a song that already played comes back after a different one. Backtrace on upstream Wine (from the attached test program): Unhandled exception: page fault on read access to 0x00000000 in wow64 32-bit code =>0 IMFMediaStream_RequestSample [include/mfidl.h:5785] in mf 1 session_request_sample_from_node+0xf3 [dlls/mf/session.c:4149] in mf 2 transform_node_deliver_samples+0x301 [dlls/mf/session.c:4072] in mf 3 session_request_sample_from_node+0x227 [dlls/mf/session.c:4177] in mf 4 session_request_sample+0x5e [dlls/mf/session.c:4214] in mf 5 session_events_callback_Invoke+0x808 [dlls/mf/session.c:4589] in mf 6 standard_queue_worker+0x2d [dlls/rtworkq/queue.c:393] in rtworkq In the game on GE-Proton11-7 it is the same call: "wine: Unhandled page fault on read access to 00000000 at address ... (mf +0x21b13)", right after the next song starts ("wmadec:transform_ProcessMessage Ignoring message 0x10000000"). How MonoGame plays music (MediaPlayer.WMS.cs / Song.WMS.cs in 3.7.1): - one IMFMediaSession for the whole game; - for each song, one topology (source node + output node holding an MFCreateAudioRendererActivate activate), created once and reused for every play; - a different song: SetTopology(MFSESSION_SETTOPOLOGY_IMMEDIATE, song topology) + Start; - when a song ends: Start(position 0) then Stop. What goes wrong: 1. A song's topology is used again, so its audio renderer is the same object as in its earlier presentation (the session doesn't shut down sinks of replaced topologies since 5d255e85, which matches Windows). The session's events_callback subscription on that stream sink from the earlier presentation is still pending. 2. While the topology is resolved, the renderer's SetCurrentMediaType queues MEStreamSinkFormatInvalidated and, through audio_renderer_preroll(), two MEStreamSinkRequestSample. 3. The session gets these through the old subscription before the new source has been started, so before MENewStream has set source_stream on the new presentation's source node. session_request_sample() then ends in IMFMediaStream_RequestSample(NULL) (session.c:4149). f34dda8a ("mf: Fix crash when stream is null during sample request") made the session subscribe to sinks only once the sources have started, but a sink that is still subscribed from an earlier presentation gets around that. On Windows 10 22H2 the attached program runs the same sequence (30 plays, 19 topology switches, songs played again after other songs) without any problem, and an early sample request is served once the sources have started. A direction that worked for me in a local build: while the presentation's sinks aren't subscribed yet (SESSION_FLAG_SINKS_SUBSCRIBED not set), count a sink's sample requests on its output node instead of passing them upstream, and serve the counted ones in session_subscribe_sinks(). With that, the test program runs all 30 plays (together with the fix from the related renderer bug, see below). Related: when the same sink is used by two topologies, session shutdown calls IMFMediaSink_Shutdown on it once per topology; on Windows it is shut down once. Related bug (filed separately): the music stops for good when the same song is played again right after it ended (the renderer requests a sample after OnClockStop). Note: I'm not a developer. This analysis and the test program were made with the help of an AI assistant (Claude). Because of Wine's policy on LLM-generated code I'm not attaching a patch. I'm happy to test patches. To reproduce: unpack mfrepro.zip and run "wine mfrepro.exe 30 2 s1.wma s2.wma s3.wma" in its folder (crashes on the 3rd play). README.txt in the zip describes the sequence and the results on Windows and Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.