December 2021 - Wine-bugs - list.winehq.org

[Bug 37891] New: Firefox 35.0 installer crashes ('INetFwAuthorizedApplication::IpVersion' property accessors are stubs)
by wine-bugs＠winehq.org 15 Dec '21

15 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=37891 Bug ID: 37891 Summary: Firefox 35.0 installer crashes ('INetFwAuthorizedApplication::IpVersion' property accessors are stubs) Product: Wine Version: 1.7.34 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, as the summary says. --- snip --- $ WINEDEBUG=+tid,+seh,+relay,+hnetcfg wine ./Firefox\ Setup\ 35.0.exe >>log.txt 2>&1 ... 0009:Call KERNEL32.CreateProcessA(00000000,00431680 ".\\setup.exe",00000000,00000000,00000000,00000000,00000000,00000000,0033fbec,0033fc3c) ret=00411784 ... 002b:Call KERNEL32.__wine_kernel_init() ret=7bc5a88d 0009:Ret KERNEL32.CreateProcessA() retval=00000001 ret=00411784 ... 002f:fixme:hnetcfg:fw_app_put_Name 0x1c39c0, L"Firefox (C:\\Program Files\\Mozilla Firefox)" ... 002f:fixme:hnetcfg:fw_app_put_Scope 0x1c39c0, 0 002f:fixme:hnetcfg:fw_app_put_IpVersion 0x1c39c0, 2 002f:trace:hnetcfg:fw_app_QueryInterface 0x1c39c0 {df0b3d60-548f-101b-8e65-08002b2bd119} 0x97e018 002f:fixme:hnetcfg:fw_app_QueryInterface interface {df0b3d60-548f-101b-8e65-08002b2bd119} not implemented 002f:Call msvcrt._CxxThrowException(0097dfe8,003e22f0) ret=003e1c55 002f:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0097df84) ret=7d575949 002f:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b83b39f ip=7b83b39f tid=002f 002f:trace:seh:raise_exception info[0]=19930520 002f:trace:seh:raise_exception info[1]=0097dfe8 002f:trace:seh:raise_exception info[2]=003e22f0 002f:trace:seh:raise_exception eax=7b827025 ebx=7b8bf000 ecx=19930520 edx=0097ded4 esi=0097df80 edi=0097df40 002f:trace:seh:raise_exception ebp=0097df18 esp=0097deb4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00200283 002f:trace:seh:call_stack_handlers calling handler at 0x3e1f1c code=e06d7363 flags=1 002f:trace:seh:cxx_frame_handler handling C++ exception rec 0x97dec0 frame 0x97e05c trylevel 2 descr 0x3e218c nested_frame (nil) 002f:trace:seh:dump_exception_type flags 0 destr 0x3e1cd0 handler (nil) type info 0x3e22e8 002f:trace:seh:dump_exception_type 0: flags 0 type 0x3e3010 {vtable=0x3e208c name=.?AV_com_error@@ ()} offsets 0,-1,0 size 16 copy ctor 0x3e1ca3 002f:trace:seh:dump_function_descr magic 19930520 002f:trace:seh:dump_function_descr unwind table: 0x3e2120 9 002f:trace:seh:dump_function_descr 0: prev -1 func (nil) 002f:trace:seh:dump_function_descr 1: prev 0 func 0x3e1ee4 002f:trace:seh:dump_function_descr 2: prev 1 func 0x3e1eec 002f:trace:seh:dump_function_descr 3: prev 2 func 0x3e1ef4 002f:trace:seh:dump_function_descr 4: prev 2 func 0x3e1efc 002f:trace:seh:dump_function_descr 5: prev 2 func 0x3e1f04 002f:trace:seh:dump_function_descr 6: prev 5 func 0x3e1f0c 002f:trace:seh:dump_function_descr 7: prev 6 func 0x3e1f14 002f:trace:seh:dump_function_descr 8: prev -1 func (nil) 002f:trace:seh:dump_function_descr try table: 0x3e2178 1 002f:trace:seh:dump_function_descr 0: start 0 end 7 catchlevel 8 catch 0x3e2168 1 002f:trace:seh:dump_function_descr 0: flags 8 offset -60 handler 0x3e1281 type 0x3e3010 {vtable=0x3e208c name=.?AV_com_error@@ ()} 002f:trace:seh:call_catch_block matched type 0x3e22c8 in tryblock 0 catchblock 0 002f:Call ntdll.RtlUnwind(0097e05c,00000000,0097dec0,00000000) ret=7d580125 ... 002f:trace:hnetcfg:fw_manager_Release destroying 0x1c6470 ... 002f:trace:seh:call_catch_block calling catch block 0x3e2168 addr 0x3e1281 ebp 0x97e068 002f:trace:seh:raise_exception code=c0000005 flags=0 addr=0xf7447e06 ip=f7447e06 tid=002f 002f:trace:seh:raise_exception info[0]=00000000 002f:trace:seh:raise_exception info[1]=80004001 002f:trace:seh:raise_exception eax=00000000 ebx=7d5f6000 ecx=00000001 edx=0097d6a8 esi=0097e068 edi=80004001 002f:trace:seh:raise_exception ebp=0097d618 esp=0097d5d4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210287 002f:trace:seh:call_stack_handlers calling handler at 0x7d57fb7f code=c0000005 flags=0 ... --- snip --- MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365266%28v=vs.85%… Source: http://source.winehq.org/git/wine.git/blob/ab7a707136997453de5a7ed87828899c… --- snip --- 253 static HRESULT WINAPI fw_app_get_IpVersion( 254 INetFwAuthorizedApplication *iface, 255 NET_FW_IP_VERSION *ipVersion ) 256 { 257 fw_app *This = impl_from_INetFwAuthorizedApplication( iface ); 258 259 FIXME("%p, %p\n", This, ipVersion); 260 return E_NOTIMPL; 261 } --- snip --- Bug 37624 is a similar problem domain: "Adobe CS4 installer fails ('INetFwOpenPort::Name' property accessors are stubs)" $ sha1sum Firefox\ Setup\ 35.0.exe e80a795d9a379a89296c087c97f0c1ca13157157 Firefox Setup 35.0.exe $ du -sh Firefox\ Setup\ 35.0.exe 38M Firefox Setup 35.0.exe $ wine --version wine-1.7.34-20-g6bad163 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.

2 6

[Bug 32845] New: Installing Cisco CSM 4.2 in Ubuntu x64 fails (32bit works)
by wine-bugs＠winehq.org 15 Dec '21

15 Dec '21

http://bugs.winehq.org/show_bug.cgi?id=32845 Bug #: 32845 Summary: Installing Cisco CSM 4.2 in Ubuntu x64 fails (32bit works) Product: Wine Version: 1.4.1 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lordmael(a)gmail.com Classification: Unclassified Created attachment 43377 --> http://bugs.winehq.org/attachment.cgi?id=43377 Backtrace from the wine error log. Installing Cisco Security Manager (CSM) 4.2 on ubuntu 64bit fails but when installing it in 32bit ubuntu it installs and runs fine. I followed the directions to install the replacement advpack.dll and update it in the wine libraries as well as installing java in the wine environment prior to installing CSM. Running ubuntu 12.10 x64 with wine 1.4.1 (perhaps I need to update) Willing to help out as much as needed :) -- 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 34648] New: J2SE Runtime Environment 5.0 Update 10 installer 'patchjre' tool crashes due to unbuffered io on redirected stdout pipe
by wine-bugs＠winehq.org 15 Dec '21

15 Dec '21

http://bugs.winehq.org/show_bug.cgi?id=34648 Bug #: 34648 Summary: J2SE Runtime Environment 5.0 Update 10 installer 'patchjre' tool crashes due to unbuffered io on redirected stdout pipe Product: Wine Version: 1.7.3 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello folks, as the summary says ... The first thing to notice is the installer seeming to hang without showing GUI. It actually tries to call home to 'jal.sun.com' which might take up to a minute until it times out. Not sure why they didn't remove the DNS entry if the host is dead/filtered/blocked anyway. --- snip --- 0009:trace:wininet:HTTP_HttpSendRequestW Request header -> L"HEAD /webapps/installstat/CountryLookup HTTP/1.1\r\nHost: jal.sun.com\r\nContent-Length: 0\r\nUser-Agent: jupdate\r\nCache-Control: no-cache\r\nConnection: Keep-Alive\r\n\r\n" 0009:trace:wininet:GetAddress L"jal.sun.com" 0009:trace:wininet:HTTP_ResolveName resolved L"jal.sun.com" to 192.18.97.143 0009:trace:wininet:open_http_connection connecting to L"jal.sun.com", proxy (null) --- snip --- (test with a browser) The crash itself can be reproduced by running the following command after failed install attempt: --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Common Files/Java/Update/Base Images/jre1.5.0.b64/patch-jre1.5.0_10.b03 $ wine ./patchjre.exe -s "C:\\Program Files\\Java\\jre1.5.0_10" --- snip --- Backtrace: --- snip --- Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0xf7527245). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:f7527245 ESP:0033c33c EBP:0033c398 EFLAGS:00010206( R- -- I - -P- ) EAX:00000001 EBX:f75a5000 ECX:00000022 EDX:00000000 ESI:7e5ea308 EDI:7b868ca6 Stack dump: 0x0033c33c: 00000001 00000000 00000004 0033c398 0x0033c34c: 00000000 00000000 0012fa10 00000000 0x0033c35c: 00000000 00000000 00000000 0033c340 0x0033c36c: 7e61e000 7e5ea308 7b868ca6 0033c398 0x0033c37c: 7e5ea32f 00000001 0040a32c 0033db40 0x0033c38c: 0040626c 00000000 00000000 0033db40 000c: sel=0067 base=00000000 limit=00000000 16-bit --x Backtrace: =>0 0xf7527245 __strstr_sse42+0x25() in libc.so.6 (0x0033c398) 1 0x7e5ea32f MSVCRT_strstr+0x26(haystack=*** invalid address 0x1 ***, needle=""") [/home/focht/projects/wine/wine-git/dlls/msvcrt/string.c:1725] in msvcrt (0x0033c398) 2 0x0040628f in patchjre (+0x628e) (0x0033db40) 3 0x00401155 in patchjre (+0x1154) (0x0033fd84) 4 0x00406daa in patchjre (+0x6da9) (0x0033fe20) 5 0x7b863cf0 call_process_entry+0xb() in kernel32 (0x0033fe38) --- snip --- The patcher creates pipes for child process stdio: --- snip --- 0025:Call KERNEL32.CreatePipe(0033db30,0033db24,0033db18,00000400) ret=0040616e 0025:Ret KERNEL32.CreatePipe() retval=00000001 ret=0040616e 0025:Call KERNEL32.CreatePipe(0033db34,0033db28,0033db18,00000400) ret=0040618b 0025:Ret KERNEL32.CreatePipe() retval=00000001 ret=0040618b 0025:Call KERNEL32.CreatePipe(0033db38,0033db2c,0033db18,00000400) ret=004061a2 0025:Ret KERNEL32.CreatePipe() retval=00000001 ret=004061a2 ... 0025:Call KERNEL32.SetHandleInformation(00000064,00000001,00000000) ret=00406205 0025:Ret KERNEL32.SetHandleInformation() retval=00000001 ret=00406205 0025:Call KERNEL32.SetHandleInformation(00000068,00000001,00000000) ret=0040620d 0025:Ret KERNEL32.SetHandleInformation() retval=00000001 ret=0040620d 0025:Call KERNEL32.SetHandleInformation(00000070,00000001,00000000) ret=00406215 0025:Ret KERNEL32.SetHandleInformation() retval=00000001 ret=00406215 --- snip --- The child process is started: --- snip --- ... 0025:Call KERNEL32.CreateProcessA(00000000,0033cbbc "C:\\Program Files\\Java\\jre1.5.0_10\\bin\\java.exe -fullversion",00000000,00000000,00000001,08000008,00000000,00000000,0033dabc,0033db00) ret=00406248 ... 0027:Call KERNEL32.__wine_kernel_init() ret=7bc594f9 0025:Ret KERNEL32.CreateProcessA() retval=00000001 ret=00406248 ... --- snip --- The parent (patcher) immediately issues a blocking read on child stdout pipe without waiting for anything. It blocks until the child writes something to other end of pipe: --- snip --- 0025:Call KERNEL32.ReadFile(00000070,0033d3bc,00000100,0033db48,00000000) ret=0040626c --- snip --- The child parses the command line and (f)prints out the version string to "stdout" pipe. I added more trace info to show 'MSVCRT_fwrite' and 'MSVCRT__write' calls + args. --- snip --- 0027:trace:msvcrt:MSVCRT__isatty :fd (2) handle (0x74) 0027:Call KERNEL32.GetFileType(00000074) ret=7ecacf3f 0027:Ret KERNEL32.GetFileType() retval=00000003 ret=7ecacf3f 0027:trace:msvcrt:pf_printf_a Format is: "%s full version \"%s\"\n" 0027:trace:msvcrt:_lock (30) 0027:trace:msvcrt:MSVCRT_fwrite :file (0x7ed22320) ptr (0x40809c) wrcnt (4) file->_cnt=0 0027:trace:msvcrt:MSVCRT__isatty :fd (2) handle (0x74) 0027:Call KERNEL32.GetFileType(00000074) ret=7ecacf3f 0027:Ret KERNEL32.GetFileType() retval=00000003 ret=7ecacf3f 0027:Call ntdll.RtlAllocateHeap(00110000,00000008,00000200) ret=7ecb8877 0027:Ret ntdll.RtlAllocateHeap() retval=00134f48 ret=7ecb8877 0027:trace:msvcrt:MSVCRT__write :fd (2) handle (116) buf (0x40809c) len (4) 0027:Call KERNEL32.WriteFile(00000074,0040809c,00000004,0033f7a4,00000000) ret=7ecb4157 0027:Ret KERNEL32.WriteFile() retval=00000001 ret=7ecb4157 0027:trace:msvcrt:_unlock (30) 0027:trace:msvcrt:_lock (30) --- snip --- Upon pipe write of client, the parent's blocking read returns and it starts parsing the output: --- snip --- 0025:Ret KERNEL32.ReadFile() retval=00000001 ret=0040626c Regards ... 0025:Call msvcrt.strstr(0033d3bc "java",0040a32c "\"") ret=00406280 ... 0025:Ret msvcrt.strstr() retval=00000000 ret=00406280 ... 0025:Call msvcrt.strstr(00000001,0040a32c "\"") ret=0040628f ... 0025:trace:seh:raise_exception code=c0000005 flags=0 addr=0xf747d245 ip=f747d245 tid=0025 --- snip --- Unfortunately the buffer of client fprintf() call was not written in one piece (buffered io) causing the parent to read only a partial string. Due to crappy coding it crashes (2x strstr for '"' won't work for partial data). As seen in trace the first 4 bytes were directly written to pipe without any buffering. The child process fprintf() call to stdout (pipe): --- snip --- ... 0040111F mov dword ptr [40AEB8h], 40809Ch ; offset "java" ... 00402007 push 4085DCh ; offset to "1.5.0-b64" 0040200C push dword ptr [40AEB8h] ; -> "java" 00402012 add eax, 40h 00402015 push 4085E8h ; offset to "%s full version \"%s\"\n" 0040201A push eax ; FILE * 0040201B call fprintf --- snip --- The first call to WriteFile() is actually the result of outputting first string argument after format string -> 40809Ch = "java" (len=4). Each vfprintf() argument handler -> pf_output_xxx will immediately trigger an unbuffered write to the pipe(s). Example session with winedbg showing use of buffered stdio when started from console (len = 0x1f): --- snip --- =>0 0x7b83db29 WriteFile(hFile=0x17, buffer=0x112110, bytesToWrite=0x1f, bytesWritten=0x33f9bc, overlapped=(nil)) [/home/focht/projects/wine/wine-git/dlls/kernel32/file.c:529] in kernel32 (0x0033fa38) 1 0x7ecace65 msvcrt_flush_buffer+0x54(file=0x7ed22320) [/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:565] in msvcrt (0x0033fa78) 2 0x7ecad0b8 remove_std_buffer+0x10(file=0x7ed22320) [/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:628] in msvcrt (0x0033fa98) 3 0x7ecb7630 MSVCRT_vfprintf+0x91(file=0x7ed22320, format="%s full version "%s" ", valist="") [/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:4491] in msvcrt (0x0033fae8) 4 0x7ecb7aca MSVCRT_fprintf+0x35(file=0x7ed22320, format="%s full version "%s" ") [/home/focht/projects/wine/wine-git/dlls/msvcrt/file.c:4612] in msvcrt (0x0033fb1c) 5 0x00402021 in java (+0x2020) (0x00111ff3) --- snip --- It seems to me that buffered io should be still done even if stdout is connected to a pipe. Regards -- 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 5

[Bug 48101] New: Metatester 5 exits silently
by WineHQ Bugzilla 14 Dec '21

14 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=48101 Bug ID: 48101 Summary: Metatester 5 exits silently Product: Wine Version: 4.19 Hardware: x86-64 URL: http://files.metaquotes.net/metaquotes.software.corp/m t5/mt5tester.setup.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: imwellcushtymelike(a)gmail.com Distribution: Ubuntu Metatester 5 exits silently after an unknown period of time. The agent starts a number of background services (that apparently install correctly), but when it exits, Wine kills off the background services along with everything else. To workaround that specific problem: 1. wineserver -p 2. wineboot 3. Anything else. (Bug 39030) Nonetheless if you let the agent, or Wine itself, start up the services the result is the same: the agent simply vanishes after an unknown amount of time. Usually less than an hour. Under Windows 8.1 and 10 it runs indefinitely. Entire log (wineserver and wineboot already run): 0190:fixme:heap:RtlSetHeapInformation 0x6a0000 0 0x22f3f0 4 stub 0190:fixme:font:get_outline_text_metrics failed to read full_nameW for font L"Ani"! 0190:fixme:nls:GetThreadPreferredUILanguages 00000038, 0x2263e4, 0x226400 0x2263e0 0190:fixme:nls:get_dummy_preferred_ui_language (0x38 0x2263e4 0x226400 0x2263e0) returning a dummy value (current locale) 0196:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA, 0000000000C5FD80 0190:fixme:ntdll:server_ioctl_file Unsupported ioctl 9003c (device=9 access=0 func=f method=0) 0190:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not implemented: 0x1 0190:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not implemented: 0x1 0190:fixme:shell:InitNetworkAddressControl stub 0198:fixme:secur32:schan_QueryContextAttributesW Unhandled attribute 0x64 0197:fixme:secur32:schan_QueryContextAttributesW Unhandled attribute 0x64 0190:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000022FCD0 No workarounds used. The app can be started again without issue. -- 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 3

[Bug 52185] New: IDA 7.6 irregular crashes when used in an IPC namespace
by WineHQ Bugzilla 14 Dec '21

14 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=52185 Bug ID: 52185 Summary: IDA 7.6 irregular crashes when used in an IPC namespace Product: Wine Version: 6.23 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: esteve.varela(a)gmail.com Distribution: --- When used within an environment that restricts the IPC Namespace, such as within a Docker container or a Firejail environment, IDA crashes irregularly when performing certain tasks. This can result in frustrating crashes and lost work. This is fairly simple to reproduce with just the help of the "unshare" utility: 1. Install IDA Free: wget https://out7.hex-rays.com/files/idafree76_windows.exe wine idafree76_windows.exe # Follow the installation, install to default location unshare -Ui wine 'C:\Program Files\IDA Freeware 7.6\ida64.exe' 2. Follow the prompts until you reach the main window which says "Drag a file here to disassemble it" 3. Unmaximize the window if maximized, grab a corner and keep resizing the window 4. Keep doing this for up to 10 seconds. The window will disappear and the following will be shown on the terminal: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 131 (MIT-SHM) Minor opcode of failed request: 3 (X_ShmPutImage) Value in failed request: 0x2e0 Serial number of failed request: 5854 Current serial number in output stream: 5858 This has been tested and verified on the following platforms: - Gentoo (WINE 6.20, 6.22) - Kubuntu 21.10 (WINE 6.0.2, 6.23) - Kubuntu 20.04 (WINE 6.0.2, 6.23) As well as the following desktop environments/window managers: - KDE - i3 Workarounds: On docker, you can use the `docker run --ipc=host` command to disable the IPC namespace. On firejail, you can use the `ignore ipc-namespace` setting to disable the IPC namespace. -- 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 7

[Bug 51828] New: Simucube 2: All applications using raw HID access to communicate with devices, stopped tracking steering axis movement
by WineHQ Bugzilla 13 Dec '21

13 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=51828 Bug ID: 51828 Summary: Simucube 2: All applications using raw HID access to communicate with devices, stopped tracking steering axis movement Product: Wine Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: d40d8d968658dca4a75afc97f9e48acda0654b0f Distribution: ArchLinux Created attachment 70716 --> https://bugs.winehq.org/attachment.cgi?id=70716 0001-hidclass.sys-Fix-input-reports-with-ReportID-being-d.patch Found out that the dropping of input packets with lengths different than desc->InputLength, which was introduced with the regression commit is causing this issue. Since the Simucube 2 is a HID PID device, it uses multiple HID reports (with defined ReportIDs), which are different lengths. For such devices desc->InputLength specifies the biggest possible buffer length, that would fit any of the input reports. If the most essential input report for tracking the steering axis movements is smaller than desc->InputLength, it'll be dropped by that check. Only the reports with the exact same size go through in non polled mode. In this case with Simucube 2 the biggest input report is of 61 bytes, and is vendor defined. All the other input reports are smaller sizes, and will get dropped. Attached a patch which fixes the issue. It also fixes possible memory access error with report->buffer while copying it to irp->AssociatedIrp.SystemBuffer, due to the internal buffer for hid_report being just report->length which could be less than or equal to desc->InputLength. The patch is based to the current master (aa629c4c7225166f4ee46476d98702df2e142711). -- 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 7

[Bug 51831] New: TrueDrive: On start shows an alert that the steering wheel is turned around too close to the bump stops, while the wheel is actually aligned on top center
by WineHQ Bugzilla 13 Dec '21

13 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=51831 Bug ID: 51831 Summary: TrueDrive: On start shows an alert that the steering wheel is turned around too close to the bump stops, while the wheel is actually aligned on top center Product: Wine Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: hid Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 8b434bdc7fe98e3bd97e180f31bc18d87161c05a Distribution: ArchLinux Created attachment 70718 --> https://bugs.winehq.org/attachment.cgi?id=70718 0001-winebus.sys-Fix-possible-memory-access-error-in-bus_.patch In addition to the summary, the in app steering wheel animation is indeed turned around usually on left, and the high torque mode of the Simucube 2 FFB wheel is also being disabled, as the alert warns. After closing the alert, the steering wheel animation resumes proper tracking of the real wheel. After some regression testing found out that in bus_event_queue_pop() (winebus.sys/unixlib.c) the size for the memcpy operation is calculated on base of the event->input_report.length, and when the event operand is passed for first time to this function, its input_report.length is uninitialized. The bus_event structure is being allocated once per bus thread. This could lead to either insufficient bytes being copied to the event struct, or memory access error for an out of bounds copy operation of the tmp struct. The consecutive calls of this function use the event->input_report.length again, which in this case is just the length of the input buffer from the previous operation. If the device uses multiple input reports with different ReportIDs and different lengths, this could lead to serious issues. Attached a patch which fixes the issue (based on the current master) -- 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 7

[Bug 51822] New: Simucube 2 TrueDrive: Doesn't recognize the steering wheel device
by WineHQ Bugzilla 13 Dec '21

13 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=51822 Bug ID: 51822 Summary: Simucube 2 TrueDrive: Doesn't recognize the steering wheel device Product: Wine Version: 6.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: hid Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 51560aabcb259cb89659d96654d8ad38edbb528d Distribution: ArchLinux Created attachment 70707 --> https://bugs.winehq.org/attachment.cgi?id=70707 0001-hidparse.sys-Preserve-the-original-state-items.repor.patch, wine_6.18.log, SC2_descr.txt Simucube 2 is FFB steering wheel device using the HID PID specification for FFB. Thus the support for it is included in the Linux kernel as part of the HID specification. It still needs some patching of the usbhid kernel module, but in general is entirely functional in Wine, as long as "DisableInput" and "Enable SDL" are disabled in the Wine registry, and for the HIDRAW device is granted rw user access. TrueDrive is an application for controlling and fine tuning various parameters of the steering wheel (using HidD/HidP calls), which also includes real time animation of the steering wheel movement, buttons pushed, etc. The application is not used/needed during gameplay. The TrueDrive version used is 2020.10. The application can be downloaded from the manufacturer site: https://granitedevices.com/wiki/Simucube_2_True_Drive_releases The mentioned regression commit is the earliest in which the problem occurs. I've investigated further, and found that state->items.report_count in the parse_new_value_caps() function (hidclass.sys/descriptor.c) is not preserved properly. While being used for building the alternate value array it's set to 1, and since "Report Count" is a global item, reset_local_items() at the end of the function preserves its state. Thus if there are subsequent main items (Input, Output, etc.) with more than one usages, and with no "Report Count" specified in between, the parser would calculate wrong bit sizes, report len, etc. The particular problem was at the end of the descriptor. Here is an excerpt: /* Usage Page (FF00h), */ /* Usage (01h), */ /* Collection (Application), */ /* Usage (01h), */ /* Report ID (107), */ /* Report Size (8), */ /* Report Count (60), */ /* Logical Minimum (0), */ /* Logical Maximum (255), */ /* Output, */ /* Usage (01h), */ /* Report ID (108), */ /* Input, */ /* End Collection, */ The Input report 108 follows immediately the Output report 107, without Report Count specified in between. In our case parse_new_value_caps() would set erroneously Report Count to 1, after being called on the Output main item. Thus the next Input report size would be calculated wrongly. This is a vendor defined report, which they probably use in the process of recognizing the device. Since then the issue was mitigated a little bit with commit 7096c26a2e48089424fe90956c80c29617bce9f2, when button array value caps were introduced, which stopped modifying state->items.report_count if the parsed item is an array. The issue is still present in the new hidparse.sys (main.c), where the parsing code has been moved with commit a290c5bf7c9ddc92af56231693c6d8f00c3efd7b. It is present in Output report 2. Here is an excerpt: /* Usage (5Ah), */ /* Collection (Logical), */ /* Report ID (2), */ ... /* Report Count (2), */ /* Output (Variable), */ /* Usage (5Ch), */ /* Usage (5Eh), */ /* Unit (Seconds), */ /* Unit Exponent (-3), */ /* Logical Maximum (32767), */ /* Physical Maximum (32767), */ /* Report Size (16), */ /* Output (Variable), */ /* Physical Maximum (0), */ /* Unit, */ /* Unit Exponent (0), */ /* End Collection, */ Since the Output main items are variable, state->items.report_count is still being modified to 1. So the second Output item ends up with two usages, one 16 bit report, and one 0 bit report. This can be seen in the attached log file wine_6.18.log. For Output report 2, the RCnt for Usage 0x5E is 0. The following debug options were used for the log: WINEDEBUG=+timestamp,+pid,+hid,+hidp,+hid_report,+plugplay. The Wine build is 6.18-107-gbcdb28a563d. I've attached the Simucube 2 device descriptor in SC2_Descr.txt. Hope it can help as a real life example of a HID PID device with multiple ReportIDs. Attached also a patch which is fixing the issue (based on the latest master aa629c4c7225166f4ee46476d98702df2e142711). -- 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 51824] New: TrueDrive, SimHub, Fanaleds,etc.: Non smooth movement tracking with severe skipping/jumping of the steering wheel/controller axis
by WineHQ Bugzilla 13 Dec '21

13 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=51824 Bug ID: 51824 Summary: TrueDrive, SimHub, Fanaleds,etc.: Non smooth movement tracking with severe skipping/jumping of the steering wheel/controller axis Product: Wine Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 325984ded50b354686e5a454aa5aca3aafa81432 Distribution: ArchLinux Created attachment 70711 --> https://bugs.winehq.org/attachment.cgi?id=70711 0001-hidclass.sys-Fix-writing-all-new-reports-at-the-last.patch All the mentioned applications use raw HID access (through HidD/HidP calls) to the devices they controll, so the movement tracking problems appear only there. DirectInput works well. After further investigation, found that the simpler ring buffer (hidclass.sys/device.c) introduced with the mentioned regression commit is causing the issues. Appeared that all new reports are pushed at the last available ring buffer slot, due to reaching the end of the buffer before the reading has started. Usually such devices as joysticks, controllers, steering wheels, etc., use constant stream of INPUT reports to report their axis movement, so any report skipping or change of the sequence, while the interested apps are reading, would lead to such issues. Attached a patch which fixes the issue (based on the current master aa629c4c7225166f4ee46476d98702df2e142711). -- 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 51710] New: 3utools doesn't see iPad
by WineHQ Bugzilla 13 Dec '21

13 Dec '21

https://bugs.winehq.org/show_bug.cgi?id=51710 Bug ID: 51710 Summary: 3utools doesn't see iPad Product: Wine Version: 6.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: aykutboray(a)gmail.com Distribution: --- Created attachment 70586 --> https://bugs.winehq.org/attachment.cgi?id=70586 Bug moment When I wanted to install new IPad OS software 3utools doesn't see my iPad it was connected to pc. -- 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 5