[Bug 44391] New: Star Trek Online: Hang when clicking "Engage"

[wine-bugs at winehq.org]

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 at winehq.org
          Reporter: mbt at 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.

-- 
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.