[Bug 52024] New: App Never Receives Winsock FD_* Messages After FD_ACCEPT

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52024

            Bug ID: 52024
           Summary: App Never Receives Winsock FD_* Messages After
                    FD_ACCEPT
           Product: Packaging
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-packages
          Assignee: wine-bugs at winehq.org
          Reporter: jbrown at statslog.com
                CC: dimesio at earthlink.net
      Distribution: ---

Created attachment 71023
  --> https://bugs.winehq.org/attachment.cgi?id=71023
Broken +server,+winsock Trace from 6.x

I'm using a 32-bit Wine 6.21devel prefix on Ubuntu 20.04.3. I have a custom
application written in VB6 that uses the winsock (ws2_32.dll) API to listen for
network connections and respond to requests.

I use the following winetricks:

DISPLAY=:99 winetricks -q vcrun2008
DISPLAY=:99 winetricks -q vcrun2010
DISPLAY=:99 winetricks -q msxml6
DISPLAY=:99 winetricks -q corefonts
DISPLAY=:99 winetricks -q vb6run

I run the application with the following command line:

WINEARCH="win32" WINEDLLOVERRIDES="oleaut32=n" wine RCWebServerTest.exe &

NOTE: I've tried both with and without the oleaut32 native override.

The application is able to bind OK to 127.0.0.1:8080, but when try to curl to
it with the following command:

curl http://127.0.0.1:8080

curl is able to connect to the application, but the application does not
subsequently respond to the request.

Some debugging shows that the I'm receiving an FD_ACCEPT message in my app's
socket windowproc, but unexpectedly I receive no other FD_ messages (notably,
no FD_READ message).

After dumping +server,+winsock debug channels (attached), I see the server's
"get_message" and "select" calls are apparently "stuck" in a PENDING state,
with many repeated log messages along these lines:

0024: get_message( flags=00000000, get_win=00000000, get_first=00000000,
get_last=ffffffff, hw_id=00000000, wake_mask=00000000, changed_mask=00000000 )
0024: get_message() = PENDING { win=00000000, msg=00000000, wparam=00000000,
lparam=00000000, type=0, x=0, y=0, time=00000000, active_hooks=80000001,
total=0, data={} }
0024: select( flags=2, cookie=0031ef4c, timeout=infinite, size=8,
prev_apc=0000, result={}, data={WAIT,handles={007c}}, context={} )
0024: select() = PENDING { call={APC_NONE}, apc_handle=0000, context={} }

I've tried the exact same app on 5.x versions of Wine and it works as expected
- curl connects and receives data from my application. I performed a similar
+server,+winsock dump under the working 5.x version, and 2 things that stand
out are that the 5.x series performs periodic "flush" calls, and the
"get_message" and "select" calls never have a "PENDING" status. For example:

0009: flush(
async={handle=0004,event=0000,iosb=0032ee10,user=006414b8,apc=00000000,apc_context=00000000}
)
0009: flush() = 0 { event=00d8 }
0009: select( flags=2, cookie=0032eadc, timeout=infinite, prev_apc=0000,
result={}, data={WAIT_ALL,handles={00d8}} )
0009: select() = 0 { timeout=infinite, call={APC_NONE}, apc_handle=0000 }
0009: get_message( flags=00000001, get_win=00000000, get_first=00000000,
get_last=ffffffff, hw_id=00000000, wake_mask=00000000, changed_mask=00000000 )
0009: get_message() = 0 { win=0001006c, msg=00000804, wparam=000000d4,
lparam=00000001, type=6, x=0, y=0, time=a00af81e, active_hooks=80000001,
total=0, data={} }

The attached working & broken logs are quite large, but if you search for
FD_ACCEPT, that's where the curl connection gets accepted, and then the
subsequent lines are where the problem is evident in the broken log (or
expected behaviour is evident in the working log).

At this point I am stumped and not sure what else I can do to get the app
working under Wine 6.x, as I believe that there is a bug that is beyond my
capabilities to diagnose & fix. 

Thank you in advance for any help, and If there's any additional information
needed from me, I will provide it.

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