[Bug 39147] New: Reaper 5.0 crashes at start

List overview All Threads

newer

older

[Bug 42006] New: Kurlewin Windows...

[Bug 34704] New: Duel of the...

wine-bugs＠winehq.org

24 Aug 2015 24 Aug '15

4:17 p.m.

https://bugs.winehq.org/show_bug.cgi?id=39147

Bug ID: 39147 Summary: Reaper 5.0 crashes at start Product: Wine Version: 1.6.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: bameylan@bluewin.ch Distribution: ---

Created attachment 52172 --> https://bugs.winehq.org/attachment.cgi?id=52172 .txt file generated by Wine

When I start with Reaper 5.0, he crashed every time.

-- 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.

Show replies by date

wine-bugs＠winehq.org

24 Aug 24 Aug

4:29 p.m.

New subject: [Bug 39147] Reaper 5.0 crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

super_man@post.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com

--- Comment #1 from super_man@post.com --- Bugs should be opened against development version of wine so all the fixes would land into next stable release. We are currently using 1.7.50. Your wine is so outdated that it doesnt give a clear picture of wine abilities. You should upgrade your wine and try again.

-- 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.

wine-bugs＠winehq.org

5:08 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

Rosanne DiMesio dimesio@earthlink.net changed:

--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net --- I can reproduce this in 1.7.50.

-- 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.

wine-bugs＠winehq.org

5:14 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

Rosanne DiMesio dimesio@earthlink.net changed:

--- Comment #3 from Rosanne DiMesio dimesio@earthlink.net --- Created attachment 52173 --> https://bugs.winehq.org/attachment.cgi?id=52173 Backtrace, 1.7.50

Attaching backtrace. Console output prior to that consists of:

fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:heap:RtlSetHeapInformation 0x350000 0 0x23fcd0 4 stub

with the second fixme repeated several times.

-- 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.

wine-bugs＠winehq.org

5:34 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

--- Comment #4 from Bernard Meylan bameylan@bluewin.ch --- Created attachment 52174 --> https://bugs.winehq.org/attachment.cgi?id=52174 generated by 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.

wine-bugs＠winehq.org

5:36 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

--- Comment #5 from Bernard Meylan bameylan@bluewin.ch --- After installing Wine 1.7.44, same result: Reaper crashed at start (see attachment 52174)

-- 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.

wine-bugs＠winehq.org

5:55 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

--- Comment #6 from Rosanne DiMesio dimesio@earthlink.net --- I did a bit more testing, and the behavior is inconsistent. I now have one wineprefix where it crashes on start every time, and one where it has never crashed (at least so far). They were both clean installs in 1.7.50.

-- 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.

wine-bugs＠winehq.org

25 Aug 25 Aug

7:28 a.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

Anastasius Focht focht@gmx.net changed:

--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello folks,

I can't confirm this, the app works fine for me in 64-bit prefix.

$ sha1sum reaper50_x64-install.exe d182c3143aed5ff97c963300cbba3c694b84859a reaper50_x64-install.exe

$ du -sh reaper50_x64-install.exe 10M reaper50_x64-install.exe

$ wine --version wine-1.7.50

Regards

-- 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.

wine-bugs＠winehq.org

12:20 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start

https://bugs.winehq.org/show_bug.cgi?id=39147

--- Comment #8 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Anastasius Focht from comment #7)

...

I can't confirm this, the app works fine for me in 64-bit prefix.

One thing I did notice is that the app does not crash when the installer starts it at the end of the install, even in wineprefixes where it crashes consistently afterwards when you start the installed app directly. My working wineprefix is still working, and my crashing one is still crashing; no idea why.

-- 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.

wine-bugs＠winehq.org

5:54 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start when WaveOut is selected as the audio device

https://bugs.winehq.org/show_bug.cgi?id=39147

Rosanne DiMesio dimesio@earthlink.net changed:

--- Comment #9 from Rosanne DiMesio dimesio@earthlink.net --- I think I found the difference. The first time Reaper is run, it prompts users to select their audio hardware. The dialog has WaveOut selected by default. If I accept that, it crashes on subsequent runs, but if I change it to anything else, it doesn't.

The values are saved in the audioconfig section of the REAPER.ini file. WaveOut corresponds to MODE=2. I fixed my crashing wineprefix by manually editing the file to set MODE=1 (which is DirectSound). Deleting the REAPER.ini file altogether also fixes it, as Reaper will then show the audio hardware selection dialog again the next time it is started.

-- 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.

wine-bugs＠winehq.org

29 Dec 29 Dec

3:15 p.m.

New subject: [Bug 39147] Reaper 5.0 (x64) crashes at start when WaveOut is selected as the audio device ( winmm.waveInAddBuffer needs stricter header flags validation)

https://bugs.winehq.org/show_bug.cgi?id=39147

Anastasius Focht focht@gmx.net changed:

--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello folks,

I've spent some hours on this and came to conclusion this is an application bug. It most likely just works on native by chance due to stricter parameter validation.

Thread 0x2c (main):

--- snip --- $ pwd /home/focht/wineprefix64/drive_c/Program Files/REAPER (x64)

$ WINEDEBUG=+tid,+seh,+relay,+winmm,+dsound wine ./reaper.exe >>log.txt 2>&1 ... 002c:Ret winmm.waveInOpen() retval=00000000 ret=14002c583 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e15770 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e157a0 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e157a0,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe157a0, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe157a0) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e17750 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e18700 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e18730 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e18730,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe18730, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe18730) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e1a6e0 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e1a710 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e1a710,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe1a710, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe1a710) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e1c6c0 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e1c6f0 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e1c6f0,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe1c6f0, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe1c6f0) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e1e6a0 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e1e6d0 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e1e6d0,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe1e6d0, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe1e6d0) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e20680 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e206b0 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e206b0,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe206b0, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe206b0) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e22660 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e22690 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e22690,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe22690, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe22690) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e24640 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00e24670 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00e24670,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xe24670, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xe24670) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 ... --- snip ---

The 0x18 byte buffer allocation preceding each 'winmm.waveInPrepareHeader()' call is an app internal data structure which contains pointers to corresponding WAVEHDR along with other state data. The second one is the WAVEHDR plus the actual buffer in one chunk.

Thread 0x34 (app audio thread):

--- snip --- ... 0034:Call winmm.waveInStart(0000bf00) ret=14002ad08 0034:trace:winmm:waveInStart (0xbf00) 0034:trace:winmm:WINMM_BeginPlaying (0xbf00) 0034:Ret winmm.waveInStart() retval=00000000 ret=14002ad08 0034:Call winmm.waveInAddBuffer(0000bf00,00e15770,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe15770, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000000 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00e18700,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe18700, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000000 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00e1a6e0,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe1a6e0, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000000 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00e1c6c0,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe1c6c0, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00e1e6a0,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe1e6a0, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00e20680,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe20680, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000000 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00e22660,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe22660, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00e24640,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xe24640, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:trace:seh:raise_exception code=c0000005 flags=0 addr=0x14002ac4f ip=14002ac4f tid=0034 0034:trace:seh:raise_exception info[0]=0000000000000000 0034:trace:seh:raise_exception info[1]=0000000000000018 0034:trace:seh:raise_exception rax=0000000000000000 rbx=0000000000e464a0 rcx=0000000000000000 rdx=0000000000e15770 0034:trace:seh:raise_exception rsi=0000000000e155b8 rdi=0000000000e15470 rbp=0000000000e37500 rsp=0000000004e7e400 0034:trace:seh:raise_exception r8=0000000000000009 r9=000000014002ad4f r10=0000000000000000 r11=0000000000000000 0034:trace:seh:raise_exception r12=0000000000e37580 r13=0000000000001000 r14=0000000000000000 r15=0000000000000010 --- snip ---

The app passes by mistake not the actual pointers to the WAVEHDR structures that ought to be prepared earlier but pointers to internal data items. Not all members of the internal data structure are initialized after heap allocation.

Due to Wine not fully validating WAVEHDR flags some 'winmm.waveInAddBuffer()' calls actually succeed (WHDR_PREPARED incorrectly "inherited" from prior heap usage) which messes up the internal buffer counting/state machine.

I added a validation of supported flags (WHDR_DONE|WHDR_PREPARED|WHDR_BEGINLOOP|WHDR_ENDLOOP|WHDR_INQUEUE) to 'winmm.waveInAddBuffer()', returning MMSYSERR_INVALPARAM in error case. It prevents the crash.

New output:

--- snip --- ... 002c:Ret winmm.waveInOpen() retval=00000000 ret=14002c583 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00000018) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00fff460 ret=1406c7487 002c:Call ntdll.RtlAllocateHeap(00350000,00000000,00001fa0) ret=1406c7487 002c:Ret ntdll.RtlAllocateHeap() retval=00fff490 ret=1406c7487 002c:Call winmm.waveInPrepareHeader(0000bf00,00fff490,00000030) ret=14002c6d7 002c:trace:winmm:waveInPrepareHeader (0xbf00, 0xfff490, 48) 002c:trace:winmm:WINMM_PrepareHeader (0xbf00, 0xfff490) 002c:Ret winmm.waveInPrepareHeader() retval=00000000 ret=14002c6d7 ... 0034:Call winmm.waveInStart(0000bf00) ret=14002ad08 0034:trace:winmm:waveInStart (0xbf00) 0034:trace:winmm:WINMM_BeginPlaying (0xbf00) 0034:Ret winmm.waveInStart() retval=00000000 ret=14002ad08 0034:Call winmm.waveInAddBuffer(0000bf00,00fff460,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xfff460, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,010023f0,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0x10023f0, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,010043d0,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0x10043d0, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,010063b0,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0x10063b0, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,01008390,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0x1008390, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,0100a370,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0x100a370, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,0100c350,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0x100c350, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000022 ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,0100e330,00000030) ret=14002ad4f 0034:trace:winmm:waveInAddBuffer (0xbf00, 0x100e330, 48) 0034:Ret winmm.waveInAddBuffer() retval=0000000b ret=14002ad4f 0034:Call winmm.waveInAddBuffer(0000bf00,00fff490,00000030) ret=14002acbf 0034:trace:winmm:waveInAddBuffer (0xbf00, 0xfff490, 48) 0034:Ret winmm.waveInAddBuffer() retval=00000000 ret=14002acbf 0034:Call KERNEL32.Sleep(00000001) ret=14002b433 ... --- snip ---

Not completely fool-proof since a seemingly valid flags pattern in a garbage WAVEHDR could still appear by chance but it helps the app here.

$ sha1sum reaper50_x64-install.exe d182c3143aed5ff97c963300cbba3c694b84859a reaper50_x64-install.exe

$ wine --version wine-2.0-rc3

Regards

-- 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.

2942

Age (days ago)

3435

Last active (days ago)

wine-bugs@winehq.org

10 comments

1 participants

tags (0)

participants (1)

wine-bugs＠winehq.org