[Bug 60501] New: Picross for a Cause crashes after a song is played again (mf session requests a sample from a NULL source stream)

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
  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.