March 2020 - Wine-Bugs - list.winehq.org

[Bug 15462] New: Wine blocking on exit when stdout and stderr are piped
by wine-bugs＠winehq.org May 18, 2021

May 18, 2021

http://bugs.winehq.org/show_bug.cgi?id=15462 Summary: Wine blocking on exit when stdout and stderr are piped Product: Wine Version: 1.0.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: chris(a)neko.net.nz Created an attachment (id=16357) --> (http://bugs.winehq.org/attachment.cgi?id=16357) Output of two simultaneous runs of described script The issue occurs when concurrently running shell scripts which call Wine processes whose standard out and standard error are both piped to another program. When two instances of a script such as the following are run concurrently, the first child wine processes started by each of then run together, but in one of the scripts that child doesn't fully exit until the _other_ script has completely run and exited. (The Wine process terminates, but the pipeline doesn't complete and so the script doesn't continue.) A bash test-case to show this behaviour is as follows: for iter in first second ; do echo "[$$] running $iter child wine" `date`; wine sleep-long.exe 2>&1 | tee /dev/null; done; echo "[$$] done " `date` The problem doesn't occur if either the redirection or pipe is removed, if I run the scripts in separate Wine environments using $WINEPREFIX, or if I have another long-lived Wine process which stays running throughout the entire operation. An example run with timing is attached. The test Wine program used above, 'sleep-long', is the following tiny C program (tested with Microsoft cl and Cygwin GCC with mingw): #include <stdio.h> #include <windows.h> int main(){ printf("Started fake compiler, sleeping 8000ms\n"); Sleep(8000); printf("Exiting fake compiler\n"); exit(0); } I've been able to reproduce this problem on several systems and Wine versions (Debian Lenny with distro-packaged Wine 1.0.0-1, Debian Etch with Wine 1.0-rc1-1~bpo40+1 from Debian backports, Ubuntu Dapper with distro-packaged Wine 0.9.9-0ubuntu2) but not on one other (Debian Etch with distro-packaged Wine 0.9.25-2.1) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 15

[Bug 15906] New: EnumFonts returns each font multiple times
by wine-bugs＠winehq.org May 18, 2021

May 18, 2021

http://bugs.winehq.org/show_bug.cgi?id=15906 Summary: EnumFonts returns each font multiple times Product: Wine Version: 1.1.5 Platform: PC-x86-64 URL: http://msdn.microsoft.com/en- us/library/ms533964(VS.85).aspx OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: goeran(a)uddeborg.se Created an attachment (id=17078) --> (http://bugs.winehq.org/attachment.cgi?id=17078) Test program executing EnumFonts() According to the documentation (see URL) the EnumFonts function returns one (random) font of each available typeface. The Wine implementation returns each typeface many times. As a test case I installed the typeface "Signet Roundhand" and ran the attached test program. Under indows it returns "Signet Roundhand" once. Under wine it returns it three times, with different values for lfCharSet and tmCharSet. I also copied the Arial font files from Windows (arial.ttf, ariali.ttf, arialbd.ttf, and arialbi.ttf) to my $HOME/.fonts directory. Under Windows, Arial is returned once with the test program. Under Wine it is returned ten(!) times. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 17

[Bug 14350] New: SetClassLongW() to subclass window EDIT control Problem
by wine-bugs＠winehq.org May 18, 2021

May 18, 2021

http://bugs.winehq.org/show_bug.cgi?id=14350 Summary: SetClassLongW() to subclass window EDIT control Problem Product: Wine Version: 1.0.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: hongbo(a)njstar.com CC: hongbo(a)njstar.com Created an attachment (id=14649) --> (http://bugs.winehq.org/attachment.cgi?id=14649) MSVC6 MFC test project with exe in debug dir Summary: SetClassLongW(hEditWnd, GCL_WNDPROC, (DWORD)EditWndProc) behave different on WINE 1.0 from Windows. Any EDIT window created after will be ANSI window on Windows, but Unicode Windows on Wine. How To Repeat: In the attached VC6 MFC ANSI App project, SetClassLongW is called in ------------------------------------------------------------------- static WNDPROC lpfnOldEditWndProc=NULL; LONG FAR PASCAL EditWndProc(HWND hWnd, WORD Message, WORD wParam, LONG lParam) { return CallWindowProcW((WNDPROC)lpfnOldEditWndProc, hWnd, Message, wParam,lParam); } int CDialogTestView::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CView::OnCreate(lpCreateStruct) == -1) return -1; HWND hEditWnd1 = CreateWindowEx(0,"EDIT", "E1",WS_POPUP,0, 0, 1, 1,NULL,NULL,NULL,NULL); lpfnOldEditWndProc =(WNDPROC)SetClassLongW(hEditWnd1, GCL_WNDPROC, (DWORD)EditWndProc); // TODO: Add your specialized creation code here return 0; } ------------------------------------------------------------------- There is a EDIT control on the About dialogbox, when click 'OK' on window the program report the Edit Box is NOT unicode Window. But Under Wine 1.0, It says 'the Edit Box IS unicode Window'. To Test: run the EXE in debug folder, Help - About DialogTest - click 'OK'. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 18

[Bug 12891] New: ntdll: exception.ok test fails in PC-BSD but not Linux
by wine-bugs＠winehq.org May 18, 2021

May 18, 2021

http://bugs.winehq.org/show_bug.cgi?id=12891 Summary: ntdll: exception.ok test fails in PC-BSD but not Linux Product: Wine Version: 0.9.60 Platform: PC OS/Version: FreeBSD Status: NEW Keywords: testcase Severity: minor Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=12597) --> (http://bugs.winehq.org/attachment.cgi?id=12597) +relay,+seh,+ntdll in git exception.c:602: Test failed: expected 4 exceptions, got 0 fixme:seh:fpe_handler untested SIMD exception: 0. Might not work correctly *** Error code 1 +relay,+seh,+ntdll log attached -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 10

[Bug 36282] New: valgrind shows an unitialized write in ieframe/tests/ie.c
by wine-bugs＠winehq.org May 16, 2021

May 16, 2021

https://bugs.winehq.org/show_bug.cgi?id=36282 Bug ID: 36282 Summary: valgrind shows an unitialized write in ieframe/tests/ie.c Product: Wine Version: 1.3.13 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: ieframe Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==16468== Thread 6: ==16468== Syscall param write(buf) points to uninitialised byte(s) ==16468== at 0x4EA8262B: ??? (in /usr/lib/libpthread-2.18.so) ==16468== by 0x7BC46BB8: NtWriteFile (file.c:1073) ==16468== by 0x7B83E0AA: WriteFile (file.c:563) ==16468== by 0x5A01BB8: rpcrt4_conn_np_write (rpc_transport.c:444) ==16468== by 0x59F6B27: rpcrt4_conn_write (rpc_binding.h:189) ==16468== by 0x59F8AA9: RPCRT4_SendWithAuth (rpc_message.c:849) ==16468== by 0x59F9BA0: RPCRT4_Send (rpc_message.c:1245) ==16468== by 0x59FCD02: process_request_packet (rpc_server.c:464) ==16468== by 0x59FCF82: RPCRT4_process_packet (rpc_server.c:519) ==16468== by 0x59FD115: RPCRT4_worker_thread (rpc_server.c:541) ==16468== by 0x7BC909EA: worker_thread_proc (threadpool.c:110) ==16468== by 0x7BC87087: ??? (signal_i386.c:2571) ==16468== by 0x7BC870D0: call_thread_func (signal_i386.c:2630) ==16468== by 0x7BC87065: ??? (signal_i386.c:2571) ==16468== by 0x7BC8E4B0: start_thread (thread.c:428) ==16468== by 0x4EA7BD89: start_thread (in /usr/lib/libpthread-2.18.so) ==16468== by 0x4E95CA0D: clone (in /usr/lib/libc-2.18.so) ==16468== Address 0x47f9cf4 is 44 bytes inside a recently re-allocated block of size 92 alloc'd ==16468== at 0x7BC4C735: notify_alloc (heap.c:255) ==16468== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==16468== by 0x59F88E9: RPCRT4_SendWithAuth (rpc_message.c:808) ==16468== by 0x59F9BA0: RPCRT4_Send (rpc_message.c:1245) ==16468== by 0x59FCD02: process_request_packet (rpc_server.c:464) ==16468== by 0x59FCF82: RPCRT4_process_packet (rpc_server.c:519) ==16468== by 0x59FD115: RPCRT4_worker_thread (rpc_server.c:541) ==16468== by 0x7BC909EA: worker_thread_proc (threadpool.c:110) ==16468== by 0x7BC87087: ??? (signal_i386.c:2571) ==16468== by 0x7BC870D0: call_thread_func (signal_i386.c:2630) ==16468== by 0x7BC87065: ??? (signal_i386.c:2571) ==16468== by 0x7BC8E4B0: start_thread (thread.c:428) ==16468== by 0x4EA7BD89: start_thread (in /usr/lib/libpthread-2.18.so) ==16468== by 0x4E95CA0D: clone (in /usr/lib/libc-2.18.so) ==16468== Uninitialised value was created by a client request ==16468== at 0x7BC4C52C: mark_block_uninitialized (heap.c:209) ==16468== by 0x7BC4C697: initialize_block (heap.c:240) ==16468== by 0x7BC50FA3: RtlAllocateHeap (heap.c:1717) ==16468== by 0x501E635: IMalloc_fnAlloc (ifs.c:186) ==16468== by 0x501EF50: CoTaskMemAlloc (objidl.h:1236) ==16468== by 0x505C935: RemUnknown_RemQueryInterface (stubmanager.c:690) ==16468== by 0x50661C6: IRemUnknown_RemQueryInterface_Stub (dcom_p.c:369) ==16468== by 0x59CA5BF: CStdStubBuffer_Invoke (cstub.c:477) ==16468== by 0x503D280: RPC_ExecuteCall (objidl.h:9086) ==16468== by 0x4FFC1ED: apartment_wndproc (compobj.c:1460) ==16468== by 0x548C509: ??? (winproc.c:173) ==16468== by 0x548C67E: call_window_proc (winproc.c:244) ==16468== by 0x548E817: WINPROC_call_window (winproc.c:900) ==16468== by 0x544FBE4: DispatchMessageW (message.c:4019) ==16468== by 0x4793F60: IEWinMain (iexplore.c:1061) ==16468== by 0x472CA34: wWinMain (main.c:84) ==16468== by 0x472CD21: wmain (exe_wmain.c:51) ==16468== by 0x472CBFC: __wine_spec_exe_wentry (exe_wentry.c:36) ==16468== by 0x7B864247: ??? (process.c:1045) ==16468== by 0x7B864394: start_process (process.c:1097) ==16468== -- 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.

2 3

[Bug 28831] New: secur32/tests/schannel.ok: occasional uninitialised memory read in _gnutls_recv_int() in test_communication()?
by wine-bugs＠winehq.org May 16, 2021

May 16, 2021

http://bugs.winehq.org/show_bug.cgi?id=28831 Bug #: 28831 Summary: secur32/tests/schannel.ok: occasional uninitialised memory read in _gnutls_recv_int() in test_communication()? Product: Wine Version: 1.3.30 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: secur32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified I don't see this on every run, but sometimes Valgrind complains: Conditional jump or move depends on uninitialised value(s) at _gnutls_recv_int (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by schan_InitializeSecurityContextW (schannel.c:728) by schan_InitializeSecurityContextA (schannel.c:775) by InitializeSecurityContextA (wrapper.c:282) by test_communication (schannel.c:644) by func_schannel (schannel.c:773) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a client request by mark_block_uninitialized (heap.c:208) by initialize_block (heap.c:239) by RtlAllocateHeap (heap.c:1703) by init_buffers (schannel.c:496) by test_communication (schannel.c:633) by func_schannel (schannel.c:773) by run_test (test.h:556) by main (test.h:624) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 4

[Bug 37849] New: Wine causing color temperature setting(redshift) not working for a short time
by wine-bugs＠winehq.org May 14, 2021

May 14, 2021

https://bugs.winehq.org/show_bug.cgi?id=37849 Bug ID: 37849 Summary: Wine causing color temperature setting(redshift) not working for a short time Product: Wine Version: 1.7.32 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: anonymous_temp_mail(a)yahoo.co.jp Distribution: --- [Bug] While using redshift(a display color temperature) and entered the sunset time, if then use wine to start a GUI program, the current display color temperature will be reset for several seconds and return back. [Reproducer] 1. Start redshift and ensure it entered sunset color. Better use -l LAT:LON to fake that you are in somewhere sun is already set. Default redshift will use randr backend to reset the color temp, so no extra setting is needed to reproduce. And default redshift will use 5500K for daytime and 3500K for nighttime, so the color temp change will be quite obvious. 2. Start wine GUI program I'm using Startcraft2 an galgame called "月に寄り添う乙女の作法2", both of them cause the display color temperature reset for several seconds. [Version] wine: 1.7.33 redshift: 1.9.1 -- 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.

2 14

[Bug 48842] New: Ghostmouse 3.2.3: Can't record the mouse
by WineHQ Bugzilla May 13, 2021

May 13, 2021

https://bugs.winehq.org/show_bug.cgi?id=48842 Bug ID: 48842 Summary: Ghostmouse 3.2.3: Can't record the mouse Product: Wine Version: 5.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cryptonotev7(a)protonmail.com Distribution: --- Ghostmouse is a program that can record and replay mouse movements, but when doing that on Wine it doesn't seem to move the mouse to your wanted location or perform any clicks. Download link to Ghostmouse: http://down.ghost-mouse.com/GhostMouse-Setup.exe SHA-1: e42a23484708cfa84fc0d6ba63a8e6eb6e8c3e84 -- 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 48843] New: Ghostmouse 3.2.3: UI elements are crooked
by WineHQ Bugzilla May 13, 2021

May 13, 2021

https://bugs.winehq.org/show_bug.cgi?id=48843 Bug ID: 48843 Summary: Ghostmouse 3.2.3: UI elements are crooked Product: Wine Version: 5.5 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cryptonotev7(a)protonmail.com Distribution: --- Created attachment 66760 --> https://bugs.winehq.org/attachment.cgi?id=66760 complete terminal output After installing Ghostmouse, running the app shows broken looking UI elements: https://i.imgur.com/gmKdN5f.png Download link to Ghostmouse, a mouse recorder application: http://down.ghost-mouse.com/GhostMouse-Setup.exe SHA-1: e42a23484708cfa84fc0d6ba63a8e6eb6e8c3e84 -- 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 33031] New: Microsoft Windows Driver Development Kit (win7 ddk/wdk) fails
by wine-bugs＠winehq.org May 13, 2021

May 13, 2021

http://bugs.winehq.org/show_bug.cgi?id=33031 Bug #: 33031 Summary: Microsoft Windows Driver Development Kit (win7 ddk/wdk) fails Product: Wine Version: 1.3.28 Platform: x86 URL: https://www.microsoft.com/en-us/download/details.aspx? id=11800 OS/Version: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Classification: Unclassified Prerequisite: winetricks mfc42 Mount the iso, run kitsetup.exe. I chose to install 'Build Environments' (a subset of 'Full Development Environment'). This fails: wine: Unhandled page fault on read access to 0x84d5c3a5 at address 0x100228d (thread 0027), starting debugger... ... Backtrace: =>0 0x0100228d in eula (+0x228d) (0x0033f708) 1 0x0100236b in eula (+0x236a) (0x0033f790) 2 0x5f8019d1 in mfc42u (+0x19d0) (0x0033f7b0) 3 0x5f80195a in mfc42u (+0x1959) (0x0033f810) 4 0x5f8018e2 in mfc42u (+0x18e1) (0x0033f82c) 5 0x5f8018a1 in mfc42u (+0x18a0) (0x0033f858) the backtrace makes me suspect riched20, trying native gives: wine: Call from 0x7b83f2a9 to unimplemented function msls31.dll.LssbFDonePresSubline, aborting which may be a future problem, but belongs in a separate bug. austin(a)aw25 ~ $ sha1sum GRMWDK_EN_7600_1.ISO du -hde6abdb8eb4e08942add4aa270c763ed4e3d8242 GRMWDK_EN_7600_1.ISO austin(a)aw25 ~ $ du -h GRMWDK_EN_7600_1.ISO 620M GRMWDK_EN_7600_1.ISO austin(a)aw25 ~ $ wine --version wine-1.5.24-74-g5069ad7 luckily, I only wanted the headers, and running: $ msiexec /i wdk/headers.msi installs the headers fine. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 9