http://bugs.winehq.org/show_bug.cgi?id=33839
Bug #: 33839 Summary: YY crash with builtin msvcr90 when 'my setting' is clicked Product: Wine Version: 1.6-rc2 Platform: x86 URL: http://yydl.duowan.com/4/setup/YYSetup-6.1.0.2-zh-CN.e xe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: fracting@gmail.com Classification: Unclassified
Created attachment 44876 --> http://bugs.winehq.org/attachment.cgi?id=44876 Log: +tid,+msvcrt,+msvcp,+seh
1. Download YY installer from http://yydl.duowan.com/4/setup/YYSetup-6.1.0.2-zh-CN.exe
2. Install and start YY.exe
3. login
4. click 'My setting', will attach screenshot
The app will crash.
Interesting, the backtrace start from msvcp90, however, native msvcr90 helps.
I'm attach a +tid,+msvcrt,+msvcp,+seh log, the full log is too long, I upload the part contains seh logs, please let me know if anything else is interested.
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #1 from Qian Hong fracting@gmail.com 2013-06-19 11:17:27 CDT --- Created attachment 44877 --> http://bugs.winehq.org/attachment.cgi?id=44877 Log: start YY with winedbg, print backtrace at crashing
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #2 from Qian Hong fracting@gmail.com 2013-06-19 11:22:11 CDT --- Created attachment 44878 --> http://bugs.winehq.org/attachment.cgi?id=44878 Screenshot: step 1 - active the menu in the left bottom corner of YY main panel.
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #3 from Qian Hong fracting@gmail.com 2013-06-19 11:23:10 CDT --- Created attachment 44879 --> http://bugs.winehq.org/attachment.cgi?id=44879 Screenshot: step2 - click the 'my setting' (我的设置) menu entry
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #4 from Qian Hong fracting@gmail.com 2013-06-19 11:34:59 CDT --- Here is a testing account for YY:
Login name: winetesting
Login number(optional): 742988215
password: testwine
http://bugs.winehq.org/show_bug.cgi?id=33839
lizhenbo litimetal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |litimetal@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=33839
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com Component|-unknown |msvcrt
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #5 from Piotr Caban piotr.caban@gmail.com 2013-10-23 06:55:18 CDT --- I've tried to reproduce the issue but the application updates itself to version 6.11. There's no crash when entering "my settings" dialog.
Is this still not working for you?
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #6 from Qian Hong fracting@gmail.com 2013-10-23 07:46:32 CDT --- Created attachment 46387 --> http://bugs.winehq.org/attachment.cgi?id=46387 Screenshot: step 3 - select the 'audio setting' tab in the left bar
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #7 from Qian Hong fracting@gmail.com 2013-10-23 07:47:29 CDT --- Created attachment 46388 --> http://bugs.winehq.org/attachment.cgi?id=46388 Screenshot: step 5 - click the 'ok' button
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #8 from Qian Hong fracting@gmail.com 2013-10-23 07:51:16 CDT --- (In reply to comment #5)
I've tried to reproduce the issue but the application updates itself to version 6.11. There's no crash when entering "my settings" dialog.
Is this still not working for you?
Hi Piotr, thanks for looking on it!
I can't reproduce the crash with the old steps after upgrading YY to 6.11 as well, however, I found a new way to reproduce the old bug.
Step 1 and Step 2 is exactly the same as before, however, Step 3 to Step 5 is needed now:
Step 3: select the “audio setting” (音频设置) tab in the left bar, just like my Screenshot shows.
Step 4: change any setting you like in the "audio setting" tab. (No screenshot for this one)
Step 5: Click the "ok"(确定) button, like my screenshot shows.
The backtrace is exactly the same as before.
Please let me know if there is anything else I can help, thanks!
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #9 from Piotr Caban piotr.caban@gmail.com 2013-10-23 08:02:22 CDT --- It doesn't crash here. Does native msvcr90 or msvcp90 still works around this bug? Could you please attach a tid,msvcrt,msvcp,seh,relay log (if it's to big for bugzilla can you upload it somewhere else (it may be to big to upload it anywhere)?
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #10 from Qian Hong fracting@gmail.com 2013-10-23 08:41:15 CDT --- (In reply to comment #9)
It doesn't crash here. Does native msvcr90 or msvcp90 still works around this bug? Could you please attach a tid,msvcrt,msvcp,seh,relay log (if it's to big for bugzilla can you upload it somewhere else (it may be to big to upload it anywhere)?
Bad luck, I can't reproduce the bug with +relay trace enabled, it takes a long time to run with +relay, I fail to reproduce 4 times in 4 tests.
Without +relay, I can reproduce it frequently, but not every time yet.
Any ideas?
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #11 from Piotr Caban piotr.caban@gmail.com 2013-10-24 06:01:25 CDT --- (In reply to comment #10)
Any ideas?
The application is accessing uninitialized memory. It calls: - operator new(136) - assigns this memory to MIXERCONTROLDETAILS->paDetails - calls mixerGetControlDetailsW - calls MSVCP_basic_string_wchar_ctor_cstr((wchar_t*)MIXERCONTROLDETAILS->paDetails+4)
The last call causes crash in some cases (I was not able to reproduce the crash on my computer). You can check that theory by calling: memset(paDetails, 0, cbDetails) in mixerGetControlDetailsW.
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #12 from Piotr Caban piotr.caban@gmail.com 2013-10-24 06:02:41 CDT --- There's also another failing call in the log: 0027:Call winmm.mixerGetLineControlsW(00008000,00ffe6a8,00000002) ret=30222e22 0027:Ret winmm.mixerGetLineControlsW() retval=0000000b ret=30222e22 but I don't know if it's related. Anyway I guess it's a bug in winmm.
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #13 from Qian Hong fracting@gmail.com 2013-10-24 13:46:23 CDT --- (In reply to comment #12)
There's also another failing call in the log: 0027:Call winmm.mixerGetLineControlsW(00008000,00ffe6a8,00000002) ret=30222e22 0027:Ret winmm.mixerGetLineControlsW() retval=0000000b ret=30222e22 but I don't know if it's related. Anyway I guess it's a bug in winmm.
Hello, thanks for the hints, I found the below logs interesting: (I added a trace for paDeatils and cbDetails in winmm)
BTW, I forgot to answer your question about native dlls: yes, winetricks vcrun2008 works around the bug for me, that's a bit strange, isn't it...
Note: the log is not exactly the same with the one I upload at 2013-06-19, there was no MSVCRT_operator_new (-1) call at that time. I don't understand why someone pass -1 to MSVCRT_operator_new...
0027:trace:msvcrt:MSVCRT_operator_delete (0x39ffba0) 0027:trace:winmm:mixerGetLineControlsW (0x8009, 0xffe734, 00000002) 0027:trace:winmm:mixerGetLineControlsW dwLineID: 4294901760 0027:trace:winmm:mixerGetLineControlsW dwControl: 70010001 0027:trace:winmm:mixerGetLineControlsW cControls: 1 0027:trace:msvcrt:_lock (9) 0027:trace:msvcrt:_unlock (9) 0027:trace:msvcrt:MSVCRT_operator_new (-1) out of memory 0027:trace:winmm:mixerGetControlDetailsW (0x8009, 0xffe8ac, 80000001) 0027:trace:winmm:mixerGetControlDetailsW paDeatils (nil), cbDetails 136 0027:trace:winmm:mixerGetControlDetailsW dwControlID: 0 0027:trace:msvcrt:_lock (9) 0027:trace:msvcrt:_unlock (9) 0027:trace:msvcrt:MSVCRT_operator_new (-1) out of memory 0027:trace:winmm:mixerGetControlDetailsW (0x8009, 0xffe8ac, 80000000) 0027:trace:winmm:mixerGetControlDetailsW paDeatils (nil), cbDetails 4 0027:trace:winmm:mixerGetControlDetailsW dwControlID: 0 0027:trace:msvcp:MSVCP_basic_string_wchar_ctor_cstr 0xffe5a8 L"Master Volume" 0027:trace:msvcp:MSVCP_basic_string_wchar_assign_cstr_len 0xffe5a8 L"Master Volume" 13 0027:trace:msvcrt:MSVCRT_operator_new (32) returning 0x3c87748 0027:trace:msvcp:MSVCP_basic_string_wchar_ctor_cstr 0xffe58c #0008 0027:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e45966a ip=7e45966a tid=0027 0027:trace:seh:raise_exception info[0]=00000000 0027:trace:seh:raise_exception info[1]=00000008 0027:trace:seh:raise_exception eax=00000008 ebx=7e592ff4 ecx=00000000 edx=00000000 esi=03888c18 edi=03d05a84 0027:trace:seh:raise_exception ebp=00ffe474 esp=00ffe464 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010202
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #14 from Qian Hong fracting@gmail.com 2013-10-24 15:55:28 CDT --- Created attachment 46407 --> http://bugs.winehq.org/attachment.cgi?id=46407 Patch: Fix NULL paDetails
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #15 from Qian Hong fracting@gmail.com 2013-10-24 15:59:58 CDT --- (In reply to comment #12)
There's also another failing call in the log: 0027:Call winmm.mixerGetLineControlsW(00008000,00ffe6a8,00000002) ret=30222e22 0027:Ret winmm.mixerGetLineControlsW() retval=0000000b ret=30222e22 but I don't know if it's related. Anyway I guess it's a bug in winmm.
Hi Piotr, thanks for your hint!
The attached winmm patch reliable fixed the crashing for me as far as test I done (10/10).
With this patch I can see such logs: 0027:trace:msvcrt:MSVCRT_operator_new (-1) out of memory 0027:trace:winmm:mixerGetControlDetailsW (0x8008, 0xffe8ac, 80000001) 0027:trace:winmm:mixerGetControlDetailsW paDeatils (nil), cbDetails 136 0027:trace:msvcrt:MSVCRT_operator_delete ((nil))
I'll submit the patch soon.
I leave one question for you: Do you think it is still worth to investigate the buitin msvcrt/msvcp problem, since winetricks vcrun2008 works around this bug?
If it is not interest to you anymore, I'll set the component to winmm, and resolve it as fixed once the winmm patch is committed.
Great thanks, as always :)
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #16 from Piotr Caban piotr.caban@gmail.com 2013-10-24 16:19:39 CDT --- Native operator new will throw an exception in case of -1 allocation. I guess this may cause the difference in application behavior. You can try to check if new(-1) is called when native msvcr90 is used (it should be visible with seh or snoop debug channel).
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #17 from Qian Hong fracting@gmail.com 2013-10-24 19:04:03 CDT --- (In reply to comment #16)
Native operator new will throw an exception in case of -1 allocation. I guess this may cause the difference in application behavior. You can try to check if new(-1) is called when native msvcr90 is used (it should be visible with seh or snoop debug channel).
Thanks for the hint, however I failed to follow this approach. With +snoop, the app crashes, I don't know any way to workaround a +snoop crash, is there one?
With only +seh, I don't have evidence to proof that some one tried to call new(-1) when I was testing native msvcr90. (The app randomly call new(-1)).
http://bugs.winehq.org/show_bug.cgi?id=33839
--- Comment #18 from lizhenbo litimetal@gmail.com --- Well, as it comes to memory behavior, I remained Bug 34698. Maybe we should mark then as 'See also'?
http://bugs.winehq.org/show_bug.cgi?id=33839
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #19 from hanska2@luukku.com --- This is a bit hard to test, because cant understand the dialogues. I logged in and it wanted to update itself, I canceled.
@ qian did your patches got merged?
Is this still an issue?
https://bugs.winehq.org/show_bug.cgi?id=33839
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |78b2fd8399dc05ec8ff5dbf90aa | |be687c35b423d Status|NEW |RESOLVED Component|msvcrt |winmm&mci Resolution|--- |FIXED
--- Comment #20 from Piotr Caban piotr.caban@gmail.com --- Marking as fixed.
https://bugs.winehq.org/show_bug.cgi?id=33839
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.26.