[Bug 35127] New: Gamehall (Chinese game client) crashes in comctl32
http://bugs.winehq.org/show_bug.cgi?id=35127 Bug ID: 35127 Summary: Gamehall (Chinese game client) crashes in comctl32 Product: Wine Version: 1.7.8 Hardware: x86 URL: http://fcg.uc108.com/gamehall/down.aspx?downid=113 OS: Linux Status: NEW Keywords: download Severity: minor Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com Classification: Unclassified Created attachment 46857 --> http://bugs.winehq.org/attachment.cgi?id=46857 terminal output I came across this bug when looking at bug #35125. The application is (probably) a game client for playing card games. Everything in the installer and in the application is displayed in Chinese so I don't understand a word of it, but here are the steps to reproduce the crash: 1. download the client from the above url and launch it. Installation should be straightforward even though everything is displayed in Chinese. 2. start the application with GameHall.exe. There are 3 green buttons at the bottom, click on the leftmost one. Some files are being downloaded(?) and Wine crashes in comctl32 before the application interface is loaded. 'winetricks comctl32' is a workaround to the crash. gamehallsetup.exe md5sum: b091c46d56680a7376853460dc8510ce wine-1.7.8-88-gfb75292 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=35127 Qian Hong <fracting(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting(a)gmail.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.
http://bugs.winehq.org/show_bug.cgi?id=35127 --- Comment #1 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Still present in Wine 1.7.24 and native comctl32 is still a workaround. The downloadable executable has changed since the original post: gamehallsetup.exe md5sum: 6cf2df096be4e861b573706bc37672c4 -- 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=35127 --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- Bela, could you retest with current Wine? I'm getting win_data_section deadlock and full cpu load on all cores when running GameHall.exe. Can you confirm? If it's still crashes same way for you, please rebuild comctl32 with -O0 and attach +treeview,+tid. -- 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=35127 --- Comment #3 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Created attachment 51113 --> https://bugs.winehq.org/attachment.cgi?id=51113 +tid,+treeview log Tested in wine-1.7.39-75-g3c2d0b9. Crashes in the same way as before. gamehallsetup.exe md5sum: f2240d36a75979a74db258ad183bf66f -- 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=35127 super_man(a)post.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com, | |super_man(a)post.com --- Comment #4 from super_man(a)post.com --- It still crashes similar way I think I have seen this bug somewhere else also. It for some reason seem to get NULL/0 value that it doesnt like. wine 1.7.53 -- 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=35127 --- Comment #5 from Bruno Jesus <00cpxxx(a)gmail.com> --- Created attachment 52633 --> https://bugs.winehq.org/attachment.cgi?id=52633 ugly hack It took the app around 15 runs to skip the deadlock from comment 2. The attached awful hack makes the program start for me. It looks like the text pointer is not valid so strlenW 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=35127 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest(a)luukku.com --- Comment #6 from winetest(a)luukku.com --- (In reply to Bruno Jesus from comment #5)
Created attachment 52633 [details] ugly hack
It took the app around 15 runs to skip the deadlock from comment 2. The attached awful hack makes the program start for me. It looks like the text pointer is not valid so strlenW crashes.
Do you think bug 10347 is worked around similar way the patch it includes. -- 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=35127 --- Comment #7 from Bruno Jesus <00cpxxx(a)gmail.com> --- (In reply to winetest from comment #6)
(In reply to Bruno Jesus from comment #5)
Created attachment 52633 [details] ugly hack
It took the app around 15 runs to skip the deadlock from comment 2. The attached awful hack makes the program start for me. It looks like the text pointer is not valid so strlenW crashes.
Do you think bug 10347 is worked around similar way the patch it includes.
Unfortunately no, I just tested and the patch there does not have the same effect from my hack. My hack still works in 1.9.18. -- 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=35127 --- Comment #8 from winetest(a)luukku.com --- I quess the correct way to fix is something like this https://source.winehq.org/patches/data/128795 -- 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=35127 --- Comment #9 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to winetest from comment #8)
I quess the correct way to fix is something like this
Please don't link unrelated things together, this is not helpful. -- 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=35127 --- Comment #10 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Still present in wine-2.0-rc4-55-g083b35e. gamehallsetup1110600.exe sha1: 134aa0a452ee849a967db8e0a01dc076d33dce55 -- 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=35127 Zhiyi Zhang <yi.gd.cn(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yi.gd.cn(a)gmail.com --- Comment #11 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Created attachment 60233 --> https://bugs.winehq.org/attachment.cgi?id=60233 wine3.0-rc5-crashlog -- 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=35127 --- Comment #12 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Still present in wine-3.0-rc5-52-g5dbf2726fe. gamehallsetup1110600.exe sha1: 134aa0a452ee849a967db8e0a01dc076d33dce55 However it's worth noting that it doesn't crash with Chinese locale. #LANG=zh_CN.UTF-8 wine ./gamehallsetup1110600.exe and clicking the big rightmost button works. -- 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=35127 --- Comment #13 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Oh, it still crashes. With Chinese locale set, it just crashed not so early. It now crashes when the application interface is loading at TREEVIEW_ComputeTextWidth -- 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=35127 --- Comment #14 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Created attachment 60234 --> https://bugs.winehq.org/attachment.cgi?id=60234 wine3.0-rc5-crash-at-TREEVIEW_ComputeTextWidth -- 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=35127 Zhiyi Zhang <yi.gd.cn(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60233|0 |1 is obsolete| | -- 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=35127 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://fcg.uc108.com/gameha |http://zhejiang.uc8848.com/ |ll/down.aspx?downid=113 |download/uc108.com_15536134 | |9/gamehallsetup155361349.ex | |e CC| |jactry92(a)gmail.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=35127 --- Comment #15 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- This is due to the application try to write to internal structure. $ winedbg winedbg>break TREEVIEW_SendCustomDrawItemNotify winedbg>c winedbg>watch * (value of item + 0x18) winedbg>c watchpoint should now be triggered Using 'info reg',you should see that ESI points to item，and the instruction tried to write to $item+0x1a. Wine-dbg>disas 0x004f1040,0x004f1080 disas 0x004f1040,0x004f1080 0x004f1040: jl 0x004f1066 0x004f1042: orb %dl,0xffffff8b(%edi) 0x004f1045: pushl %ecx 0x004f1046: clc 0x004f1047: pushl %edx 0x004f1048: movl 0x8(%eax),%edx 0x004f104b: pushl %ecx 0x004f104c: pushl %edx 0x004f104d: call *0x6b3234 -> 0x7eaed64c GetTextExtentPoint32A [/home/eric/source/wine/wine/dlls/gdi32/font.c:1140] in gdi32 0x004f1053: movl 0x8(%esp),%eax <- 0x8(%esp) is 0x0000004e 0x004f1057: leal 0x24(%esp),%ecx 0x004f105b: addl $4,%eax <- +4, then %eax is the written value 0x004f105e: movl $0xffffffff,0x18(%esp) 0x004f1066: movw %ax,0x1a(%esi) <- corrupts item->pszText，accordding to calling GetTextExtentPoint32A，the application is trying to write to item->textWidth directly. You can also verify this by print out value of textWidth and written value. They should be off by 4. 0x004f106a: andl $0xffff,%eax 0x004f106f: movl %eax,%esi 0x004f1071: call 0x00687e76 0x004f1076: movl 0x10(%esp),%ecx 0x004f107a: movl %esi,%eax 0x004f107c: popl %edi 0x004f107d: popl %esi 0x004f107e: movl %ecx,%fs:0x00000000 Wine-dbg>x 0x0033e268 0x8(%esp) x 0x0033e268 0000004e However in comctl32/treeview.c#L139 struct _TREEITEM. In struct _TREEITEM, $item+0x1a points to none of the members, because they are all 4 bytes aligned. By writing to $item+0x1a, item->pszText gets corrupted. By adding a 2 bytes padding before item->pszText to workground this. The application runs. Since the application expect textWidth to be at $item+0x1a and textWidth to be 2 bytes long, try move the position of textWidth also works. However, textWidth now is 4 bytes.Moving textWidth also make it corrupted. But it seems that the application still runs. -- 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=35127 --- Comment #16 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- forgot to mention. I used $ LANG=zh_CN.UTF-8 WINEDEBUG=+treeview ./wine ~/.wine/drive_c/Program\ Files/GameChannel/GameHall.exe to launch the debugger -- 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=35127 --- Comment #17 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- When watchpoint trigger, backtrace showed that the offending code is in the application itself Stopped on watchpoint 2 at 0x004f106a new value 52004e Wine-dbg>bt bt Backtrace: =>0 0x004f106a in gamehall (+0xf106a) (0x00c5ee00) 1 0x00000001 (0x006b96e4) 2 0x0046be70 in gamehall (+0x6be6f) (0x004efa20) -- 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=35127 --- Comment #18 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Further experiment on Windows by calling related api and dumping the memory pointed by HTREEITEM, $HTREEITEM+0x1a is the textWidth member. And since the content 2 bytes before and after $HTREEITEM+0x1a is not zero, and don't change with the text of the item. It's reasonable to believe that textWidth is not a LONG but a WORD. -- 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=35127 --- Comment #19 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- (In reply to Zhiyi Zhang from comment #18)
Further experiment on Windows by calling related api and dumping the memory pointed by HTREEITEM, $HTREEITEM+0x1a is the textWidth member. And since the content 2 bytes before and after $HTREEITEM+0x1a is not zero, and don't change with the text of the item. It's reasonable to believe that textWidth is not a LONG but a WORD.
Sorry, I was wrong. 2 bytes after $HTREEITEM+0x1a is zero. So it's possible that textWidth is a LONG member but aligned to 2 bytes boundary, which means there is WORD before textWidth. -- 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=35127 --- Comment #20 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- (In reply to Zhiyi Zhang from comment #19)
(In reply to Zhiyi Zhang from comment #18)
Further experiment on Windows by calling related api and dumping the memory pointed by HTREEITEM, $HTREEITEM+0x1a is the textWidth member. And since the content 2 bytes before and after $HTREEITEM+0x1a is not zero, and don't change with the text of the item. It's reasonable to believe that textWidth is not a LONG but a WORD.
Sorry, I was wrong. 2 bytes after $HTREEITEM+0x1a is zero. So it's possible that textWidth is a LONG member but aligned to 2 bytes boundary, which means there is WORD before textWidth.
But since $HTREEITEM+0x1a is aligned to 2 bytes boundary, I am putting my money on textWidth is WORD and there is a another WORD before it. Unless struct __TREEITEM used packed(2) -- 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=35127 --- Comment #21 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Created attachment 60281 --> https://bugs.winehq.org/attachment.cgi?id=60281 Propose patch -- 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=35127 Zhiyi Zhang <yi.gd.cn(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60281|0 |1 is obsolete| | --- Comment #22 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Created attachment 60295 --> https://bugs.winehq.org/attachment.cgi?id=60295 Proposed patch -- 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=35127 --- Comment #23 from Zhiyi Zhang <yi.gd.cn(a)gmail.com> --- Tests show that there are times the content 2 bytes before and after $HTREEITEM+0x1a is not zero(Once there are 0x1 at lower 2 bytes). You can dump the memory of HTREEITEM pointed to to check it. And since MSDN says the pszText max displayed text will be 260 characters, I am pretty sure textWidth is a WORD. -- 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=35127 --- Comment #24 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to Zhiyi Zhang from comment #23)
Tests show that there are times the content 2 bytes before and after $HTREEITEM+0x1a is not zero(Once there are 0x1 at lower 2 bytes). You can dump the memory of HTREEITEM pointed to to check it. And since MSDN says the pszText max displayed text will be 260 characters, I am pretty sure textWidth is a WORD.
Number of allowed characters does not limit measured width, in this case 260 char limit can't possibly guarantee that pixel width will fit in 2 bytes. -- 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=35127 --- Comment #25 from Nikolay Sivov <bunglehead(a)gmail.com> --- Apparently similar test fails on WinXP/2k3 for version 6 case, so it's not that stable. We can probably get away by adding enough unused fields so application does not corrupt anything useful (don't even have to use their custom set width). -- 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=35127 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #26 from joaopa <jeremielapuree(a)yahoo.fr> --- Unable to test by myself. Does the bug still occur with wine-7.0-rc2? -- 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