May 2018 - Wine-Bugs - list.winehq.org

[Bug 44329] New: Listview custom draw in report mode uses wrong state of LV_ITEM using LVIS_STATEIMAGEMASK
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44329 Bug ID: 44329 Summary: Listview custom draw in report mode uses wrong state of LV_ITEM using LVIS_STATEIMAGEMASK Product: Wine Version: 3.0-rc5 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: lisitski.segrey(a)gmail.com Created attachment 60193 --> https://bugs.winehq.org/attachment.cgi?id=60193 Wrong result in WINE I'm trying to create my own Listview in report mode, using custom draw. When I try to check does Item have a state image using LVIS_STATEIMAGEMASK, WINE says that subItem has state image too(See attached screenshot) By MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/bb774760(v=vs.85).… Bits 12 through 15 of this member specify the state image index. The state image is displayed next to an item's icon to indicate an application-defined state. If these bits are zero, the item has no state image. To isolate these bits, use the LVIS_STATEIMAGEMASK mask. To set the state image index, use the INDEXTOSTATEIMAGEMASK macro. The state image index specifies the index of the image in the state image list that should be drawn. The state image list is specified with the LVM_SETIMAGELIST message. Source code: https://drive.google.com/open?id=1FlwWEIn2r_CJfw_OWLJmq2Cb8N_ciruw Executables: https://drive.google.com/open?id=1QdnYBvDQiSOEmHMWLQpYDDGLRI6ZnTTl -- 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.

1 28

[Bug 42789] New: Qemu 2.9.0-rc3 crashes before displaying anything
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=42789 Bug ID: 42789 Summary: Qemu 2.9.0-rc3 crashes before displaying anything Product: Wine Version: 2.5 Hardware: x86-64 URL: https://qemu.weilnetz.de/w32/qemu-w32-setup-20170405.e xe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 00cpxxx(a)gmail.com Distribution: --- Created attachment 57816 --> https://bugs.winehq.org/attachment.cgi?id=57816 log + backtrace To reproduce just install qemu and run qemu-system-i386 with no additional parameters. Backtrace seems pretty clean on where the problem is. File Info: 666798c903472b4cb44b37544d5764cf2acb6c0f qemu-w32-setup-20170405.exe 37Mb -- 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.

1 9

[Bug 44492] New: winedbg reports unknown mode, fails to backtrace etc. in protected-mode
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44492 Bug ID: 44492 Summary: winedbg reports unknown mode, fails to backtrace etc. in protected-mode Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Distribution: --- While trying to debug bug #42554 I found that winedbg persistently refused to give backtraces, both in the crash dialog and when started via `wine winedbg MSBSOLAR.EXE`. The following output is given: ------ Unhandled exception: page fault on read access to 0x00004540 bad address. In (null) mode. Register dump: CS:12af SS:11d7 DS:12c7 ES:1237 FS:0063 GS:006bBad segment (4567) Stack dump: 000c: sel=0067 base=00000000 limit=00000000 32-bit rw- Backtrace: =>0 Unknown mode ffffffff (Unknown mode ffffffff ) Unknown mode ffffffff: -- no code accessible -- ------ Tracing this back to its source, I find that ptrace seems to be returning incorrect output: 0039: get_selector_entry( handle=002c, entry=597 ) 0030: *signal* signal=19 0039: get_selector_entry() = 0 { base=00000000, limit=00000000, flags=52 } Obviously the base should not be NULL, nor the limit 0, and the flags should be 9b (WINE_LDT_FLAGS_ALLOCATED|WINE_LDT_FLAGS_CODE). If I add traces to libs/wine/ldt.c, nothing is modifying the entry past the point at which it is set, so it seems like the fault lies in ptrace... an audacious claim to be sure. I'm almost sure this used to work correctly, but I can't figure out when. I checked wine-2.10 and 3.0, and it was still broken then. I also checked on Arch (well, Manjaro) just in case this was another Ubuntu-related ptrace breakage, but it shows the same behaviour there. -- 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.

1 6

[Bug 44255] New: Wolf RPG Editor: Game.exe zombifies upon quit
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44255 Bug ID: 44255 Summary: Wolf RPG Editor: Game.exe zombifies upon quit Product: Wine Version: 2.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- Pretty much every single title using Wolf Rpg Editor as the engine zombifies upon engine shutdown. That is, the application window closes properly, but the app itself goes into an infinite cycle of "err:ntdll:RtlpWaitForCriticalSection section 0x7bcea9e0 "/mnt/buildbox/builds/portage/app-emulation/wine-2.22/work/wine-2.22/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0577, blocked by 060a, retrying (60 sec)'. This is an old problem, that was present with Wolf 2.10 and still present with 2.21. Needs to be killed via task mgr. The warning itself is an annoyance: in my personal experience, in less than 20% of the cases it's not a deadlock and if it is, once it pops up, it blocks Ctrl-C from terminating such hung app. -- 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.

1 16

[Bug 44512] New: Royale Noir theme - Various: fixme:uxtheme: DrawThemeTextEx unsupported flags
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44512 Bug ID: 44512 Summary: Royale Noir theme - Various: fixme:uxtheme:DrawThemeTextEx unsupported flags Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs(a)winehq.org Reporter: stu.axon(a)gmail.com Distribution: --- Using the freely available Royale Noir theme triggers various unsupported flags WineCFG: Opening winecfg 0053:fixme:uxtheme:DrawThemeTextEx unsupported flags 0x7e5094ae 0053:fixme:uxtheme:DrawThemeTextEx unsupported flags 0x00126430 The ae fixme triggers every time a tab is clicked 0053:fixme:uxtheme:DrawThemeTextEx unsupported flags 0x7e5094ae Triggered in the drives tab 0058:fixme:uxtheme:DrawThemeTextEx unsupported flags 0x000c0170 wine explorer: Opening wine explorer: 0062:fixme:uxtheme:DrawThemeTextEx unsupported flags 0x00120144 -- 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.

1 6

[Bug 44270] New: Exception when organizing favorites in Windows Media Player 6.4 ( unimplemented function shdocvw.dll.DoOrganizeFavDlg)
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44270 Bug ID: 44270 Summary: Exception when organizing favorites in Windows Media Player 6.4 (unimplemented function shdocvw.dll.DoOrganizeFavDlg) Product: Wine Version: 3.0-rc4 Hardware: x86 URL: http://download.microsoft.com/download/winmediaplayer/ Update/6.4/W9XNT4/EN-US/mpfull.exe OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shdocvw Assignee: wine-bugs(a)winehq.org Reporter: jhansonxi(a)gmail.com Distribution: Ubuntu Created attachment 60082 --> https://bugs.winehq.org/attachment.cgi?id=60082 Backtrace from Organize Favorites error Exception in Windows Media Player 6.4 when attempting to organize favorites (Favorites > Organize Favorites). Tested on two systems. Xubuntu 16.04.3 x86_64, AMD Phenom 9550, GeForce GTX 750Ti with Nvidia 384.90 driver. wine-devel 3.0~rc4~xenial from dl.winehq.org Xubuntu 17.04 x86, Intel Pentium D 3.46GHz, GeForce 8600 GT with Nvidia 340.102 driver. wine-devel 3.0~rc4~zesty from dl.winehq.org -- 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.

1 10

[Bug 44626] New: AvP Classic 2000 (Steam) launcher crashes when attempting to start the game
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44626 Bug ID: 44626 Summary: AvP Classic 2000 (Steam) launcher crashes when attempting to start the game Product: Wine Version: 3.0-rc1 Hardware: x86 URL: http://store.steampowered.com/app/3730/Aliens_versus_P redator_Classic_2000/ OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: jacek(a)codeweavers.com Regression SHA1: 49abeb63cb88ea2efa6ad599047745bd8794f03c Distribution: ArchLinux Created attachment 60615 --> https://bugs.winehq.org/attachment.cgi?id=60615 terminal output "Aliens versus Predator 2000 Classic" launcher initializes correctly but crashes when I click on the red or green button to start the game. No demo version available on Steam. The result of the regression test: There are only 'skip'ped commits left to test. The first bad commit could be any of: 8600c2a57394b4d71e465e192b3621154b07c5ce -> Wine build fails e150f96a3e2134d99e17417adae8982c4398d9ff -> Wine build fails 49abeb63cb88ea2efa6ad599047745bd8794f03c -> the launcher crashes Prior to 8600c2a57394b4d71e465e192b3621154b07c5ce the game starts properly. Tested and reproduced with wine-3.2-206-g9ae8b8c00f. -- 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.

1 11

[Bug 43520] New: WIC does not decode some JPEG images correctly
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=43520 Bug ID: 43520 Summary: WIC does not decode some JPEG images correctly Product: Wine Version: 2.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: windowscodecs Assignee: wine-bugs(a)winehq.org Reporter: theli.ua(a)gmail.com Distribution: --- Created attachment 58915 --> https://bugs.winehq.org/attachment.cgi?id=58915 sample image example image attached -- 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.

1 18

[Bug 44553] New: Kerberos support added in Wine 3.1 is broking build on some old Linux distributions
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44553 Bug ID: 44553 Summary: Kerberos support added in Wine 3.1 is broking build on some old Linux distributions Product: Wine Version: 3.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Zenitur(a)yandex.ru Distribution: --- Created attachment 60518 --> https://bugs.winehq.org/attachment.cgi?id=60518 Build error log.txt Example: krb5_ap.c:103:14: error: 'krb5_is_config_principal' undeclared here (not in a function) MAKE_FUNCPTR(krb5_is_config_principal); ^ Full error log attached. SLES 11 SP4. KRB5 version is 1.6.3. Full build log: https://build.opensuse.org/build/home:linux4humans:wine-staging/SLE_11_SP4/… In openSUSE 11.4 (KRB5 version is 1.8.3) it builds fine: https://build.opensuse.org/build/home:linux4humans:wine-staging/openSUSE_Ev… I'd retest with 3.2 and it's also failed: https://build.opensuse.org/build/home:linux4humans:temp/SLE_11_SP2/i586/win… -- 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.

1 13

[Bug 44819] New: kernel32.OutputDebugString/ ntdll.DbgPrint should throw DBG_PRINTEXCEPTION_C a second time if attached debugger didn 't consume it
by wine-bugs＠winehq.org May 14, 2018

May 14, 2018

https://bugs.winehq.org/show_bug.cgi?id=44819 Bug ID: 44819 Summary: kernel32.OutputDebugString/ntdll.DbgPrint should throw DBG_PRINTEXCEPTION_C a second time if attached debugger didn't consume it Product: Wine Version: 3.4 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, to track https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-Exce… Unfortunately there is no further information/details on this. My guess would be that Sebastian observed this behaviour while debugging some application under native Windows. I've found some interesting/related remarks about this behaviour here: https://www.virusbulletin.com/virusbulletin/2009/01/anti-unpacker-tricks-pa… The observed behaviour is described in 'ntdll.DbgPrint' remark: --- quote --- Similarly, despite the fact that the ntdll DbgPrint() function raises the DBG_PRINTEXCEPTION_C (0x40010006) exception, a registered Structured Exception Handler will not see it. Once again, the reason is that Windows registers its own Structured Exception Handler internally, which consumes the exception if a debugger does not do so. As such, the presence of a debugger that consumes the exception cannot be inferred by the absence of it. However, as discussed previously, in Windows XP and later, any registered Vectored Exception Handler will run before the Structured Exception Handler that Windows registers and the presence of a debugger that consumes the exception can now be inferred by the absence of the exception. Further, a different exception is delivered to the Vectored Exception Handler if a debugger is present but has not consumed the exception, or if a debugger is not present. If a debugger is present but has not consumed the exception, then Windows will deliver the DBG_PRINTEXCEPTION_C (0x40010006) exception. If a debugger is not present, then Windows will deliver the EXCEPTION_ACCESS_VIOLATION (0xC0000005) exception. The presence of a debugger can now be inferred by either the absence of the exception, or by the value of the exception. --- quote --- remark for 'kernel32.OutputDebugString': --- quote --- Despite the fact that the kernel32 OutputDebugString() function raises the DBG_PRINTEXCEPTION_C (0x40010006) exception, a registered Structured Exception Handler will not see it. The reason is that Windows registers its own Structured Exception Handler internally, which consumes the exception if a debugger does not do so. As such, the presence of a debugger that consumes the exception cannot be inferred by the absence of the exception. However, in Windows XP and later, any registered Vectored Exception Handler will run before the Structured Exception Handler that Windows registers. This might be considered a bug in Windows. In this case the presence of a debugger that consumes the exception can be inferred by its absence. --- quote --- $ wine --version wine-3.4 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.

1 2