https://bugs.winehq.org/show_bug.cgi?id=44391
Bug ID: 44391 Summary: Star Trek Online: Hang when clicking "Engage" Product: Wine Version: 3.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: mbt@fortifiedtechsystems.com Distribution: ---
Updated to Wine 3.0 and decided to try STO to see if it would work.
The upside is that it works better than it did when I tried it last time, but it still doesn't work. It patches (slowly, but it does finish), but when clicking the "Engage" button after the patch has done, the program blocks, never to be heard from again.
Now, the debug output in total is too large to even really attach as a compressed archive of files, so I'm going to defer to waiting for a detailed request for information. However, what I _do_ know is that the program is blocking on a read of a pipe file descriptor that is apparently not ready. The pipe is created during program startup:
pipe2([7, 8], O_CLOEXEC) = 0
And then (MUCH, MUCH LATER), when I click on the Engage button:
write(3, "\v\1\0\0\0\0\0\0\0\0\0\0\234\1\0\0D\244\254E\0\0\0\0D\244\254E\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 writev(3, [{iov_base="\32\0\0\0000\0\0\0\0\0\0\0\2\0\0\0\330\3162\0\0\0\0\0\377\377\377\377\377\377\377\177"..., iov_len=64}, {iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=40}, {iov_base="\1\0\0\0\340\1\0\0", iov_len=8}], 3) = 112 read(5, "\3\1\0\0\0\0\0\0\377\377\377\377\377\377\377\177\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(7,
It will sit for _forever_ that way. (At that point, it is still the socket from earlier; I actually worked backwards from the fd number in /proc/$PID/fd/7 in order to figure out where it was instantiated in the log file.) The only way out of it is to kill the process, which then wraps out the log as thus:
read(7, <unfinished ...>) = ? +++ killed by SIGKILL +++
At that point, of course, the program ends and Wine shuts back down. Retrial does the same time, and it does not appear to matter what version of Windows WINE is set to report.
I would _love_ to report more information. But I need to be told what to gather to turn this into a _really_ useful bug report. STO is just about the only thing I boot up Windows for... it'd sure be nice to be rid of that requirement!
Thanks, and keep up the good work.