[Bug 40024] New: Prosound crashes with ntvdm
https://bugs.winehq.org/show_bug.cgi?id=40024 Bug ID: 40024 Summary: Prosound crashes with ntvdm Product: Wine Version: 1.9.1 Hardware: x86-64 URL: http://www.gaby.de/ftp/pub/win3x/prosound.zip OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sdoom4(a)gmail.com Created attachment 53473 --> https://bugs.winehq.org/attachment.cgi?id=53473 Backtrace of program crash Prosound is a midi sequencer that I have used in Windows 9x for many years. I attempted to run it on Wine, and got a crash upon loading. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Summary|Prosound crashes with ntvdm |Prosound crashes on start --- Comment #1 from Bruno Jesus <00cpxxx(a)gmail.com> --- The log says you configured wine as Windows 7, did you try with XP or older? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 --- Comment #2 from sdoom4(a)gmail.com --- Created attachment 53500 --> https://bugs.winehq.org/attachment.cgi?id=53500 XP backtrace -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 Andrew Eikum <aeikum(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum(a)codeweavers.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |STAGED CC| |dmitry(a)baikal.ru, | |erich.e.hoover(a)wine-staging | |.com, michael(a)fds-team.de, | |sebastian(a)fds-team.de Ever confirmed|0 |1 Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/mmsystem.dll16 | |-MIDIHDR_Refcount -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 --- Comment #3 from Andrew Eikum <aeikum(a)codeweavers.com> --- I don't think I agree with the approach taking by the staging patchset. Instead of refcounting to prevent access-after-free, we should just never access the MIDIHDR after sending MOM_DONE to the application. I'm not sure exactly how we can do this, but my approach would be to unmap the MODM_LONGDATA header just before invoking MOM_DONE. Maybe we can do this in mmsystem16.MMSYSTDRV_Callback3216. This would have the advantage of correctly copying the flags that are set in midimap.modLongData to the 16-bit header. The flags are currently not reaching the application in the MOM_DONE callback invoked by midimap.modLongData. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 --- Comment #4 from Andrew Eikum <aeikum(a)codeweavers.com> --- To elaborate a bit more, the application calls midiOutPrepareHeader, which allocates a 32-bit backing header. Then the application calls MODM_LONGDATA with that header, so mmsystem16 maps the header to the backing header and invokes 32-bit winmm. Eventually this calls the application's MOM_DONE callback with that header. The application calls midiOutUnprepareHeader during this callback, which frees the 32-bit backing header. After the callback is done, the LONGDATA call unmaps its 32-bit header, but this was deleted by the UnprepareHeader call, and the application crashes. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 --- Comment #5 from Andrew Eikum <aeikum(a)codeweavers.com> --- (In reply to Andrew Eikum from comment #3)
I'm not sure exactly how we can do this, but my approach would be to unmap the MODM_LONGDATA header just before invoking MOM_DONE. Maybe we can do this in mmsystem16.MMSYSTDRV_Callback3216. This would have the advantage of correctly copying the flags that are set in midimap.modLongData to the 16-bit header. The flags are currently not reaching the application in the MOM_DONE callback invoked by midimap.modLongData.
A complication here is that we don't touch every header that comes through. For example, headers coming in from midiStreamOut get passed straight through to winmm and eventually back out through the MOM_DONE callback. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/mmsystem.dll16 |er/patches/mmsystem.dll16-M |-MIDIHDR_Refcount |IDIHDR_Refcount CC| |nerv(a)dawncrow.de -- 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.
https://bugs.winehq.org/show_bug.cgi?id=40024 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #6 from joaopa <jeremielapuree(a)yahoo.fr> --- Bug still occurs with wine-5.3 -- 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.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla