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@winehq.org Reporter: gyebro69@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
http://bugs.winehq.org/show_bug.cgi?id=35127
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #1 from Béla Gyebrószki gyebro69@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
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #2 from Nikolay Sivov bunglehead@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #3 from Béla Gyebrószki gyebro69@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
https://bugs.winehq.org/show_bug.cgi?id=35127
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com, | |super_man@post.com
--- Comment #4 from super_man@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
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #5 from Bruno Jesus 00cpxxx@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #6 from winetest@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #7 from Bruno Jesus 00cpxxx@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #8 from winetest@luukku.com --- I quess the correct way to fix is something like this
https://source.winehq.org/patches/data/128795
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #9 from Nikolay Sivov bunglehead@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #10 from Béla Gyebrószki gyebro69@gmail.com --- Still present in wine-2.0-rc4-55-g083b35e.
gamehallsetup1110600.exe sha1: 134aa0a452ee849a967db8e0a01dc076d33dce55
https://bugs.winehq.org/show_bug.cgi?id=35127
Zhiyi Zhang yi.gd.cn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yi.gd.cn@gmail.com
--- Comment #11 from Zhiyi Zhang yi.gd.cn@gmail.com --- Created attachment 60233 --> https://bugs.winehq.org/attachment.cgi?id=60233 wine3.0-rc5-crashlog
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #12 from Zhiyi Zhang yi.gd.cn@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #13 from Zhiyi Zhang yi.gd.cn@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
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #14 from Zhiyi Zhang yi.gd.cn@gmail.com --- Created attachment 60234 --> https://bugs.winehq.org/attachment.cgi?id=60234 wine3.0-rc5-crash-at-TREEVIEW_ComputeTextWidth
https://bugs.winehq.org/show_bug.cgi?id=35127
Zhiyi Zhang yi.gd.cn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #60233|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=35127
Jactry Zeng jactry92@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@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #15 from Zhiyi Zhang yi.gd.cn@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #16 from Zhiyi Zhang yi.gd.cn@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
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #17 from Zhiyi Zhang yi.gd.cn@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)
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #18 from Zhiyi Zhang yi.gd.cn@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #19 from Zhiyi Zhang yi.gd.cn@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #20 from Zhiyi Zhang yi.gd.cn@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)
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #21 from Zhiyi Zhang yi.gd.cn@gmail.com --- Created attachment 60281 --> https://bugs.winehq.org/attachment.cgi?id=60281 Propose patch
https://bugs.winehq.org/show_bug.cgi?id=35127
Zhiyi Zhang yi.gd.cn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #60281|0 |1 is obsolete| |
--- Comment #22 from Zhiyi Zhang yi.gd.cn@gmail.com --- Created attachment 60295 --> https://bugs.winehq.org/attachment.cgi?id=60295 Proposed patch
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #23 from Zhiyi Zhang yi.gd.cn@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #24 from Nikolay Sivov bunglehead@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.
https://bugs.winehq.org/show_bug.cgi?id=35127
--- Comment #25 from Nikolay Sivov bunglehead@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).
https://bugs.winehq.org/show_bug.cgi?id=35127
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #26 from joaopa jeremielapuree@yahoo.fr --- Unable to test by myself. Does the bug still occur with wine-7.0-rc2?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla