Hi,
I have an interesting bug (maybe?) for you. I don't know what's the best
way to explain so I will just retrace how I found out what's happening.
I was investigating Bug 58216 (completely unrelated, but this is how I
encountered this problem). When I started the game, it just hangs with a
black screen. It didn't crash but it didn't start either. Nothing stood out
in the logs, so I attached winedbg. It showed a thread stuck in
mmdevapi.dll::DriverProc, handling a DRV_FREE. The notify_thread wasn't
stopping, clearly the midi_release call isn't causing the midi_notify_wait
to return.
So I added debug logging to alsamidi.c, and they weren't being hit. Turning
on +mmdevapi debug channel shows winealsa.drv was being loaded as the MIDI
driver. What is going on? I was perplexed. Single stepping into the unix
call to midi_release showed it somehow called into pulse_not_implemented.
Turning on +module and I found this:
0024:trace:module:load_native_dll found
L"C:\\windows\\system32\\winepulse.drv" for
L"\\??\\C:\\windows\\system32\\winealsa.drv"
This is bizarre. Reading the code I saw a few server calls for memory
mapping stuff, so I turned on +server. And I saw a create_mapping call made
with a file handle for winealsa.drv, but a later get_mapping_info call on
that mapping returned winepulse.drv. Okay, I was reading wineserver code
now. In the create_mapping function we have:
mapping->fd = get_fd_object_for_mapping( ... )
And get_fd_object_for_mapping can replace the given fd with another fd of
the same underlying inode#. Ah ha! I look at the inode of winealsa.drv and
winepulse.drv, and yeah they are identical.
* * *
But how? I run NixOS. On NixOS all installed software packages come out of
the "nix store", and nix store has an "optimise" feature which replaces
identical files in the nix store with hardlinks. winealsa.drv and
winepulse.drv are empty dlls only there for loading their corresponding .so
unixlibs, that's why they are identical, and were replaced by hardlinks.
Question: what's the right thing to do here? Considering hardlinked files
indistinguishable for mapping purposes seems reasonable, and I won't be
surprised if there are testcases testing specifically this. But adding
unixlibs to the mix and things change. Now the path from which a module is
accessed becomes significant too, because it will be used to find the .so.
In this case the result was the wrong unixlib being used.
Help? Thanks.
--
Regards
Yuxuan Shui
