[Bug 28898] New: Diablo 3 beta multi-threaded installer freezes (RtlpWaitForCriticalSection block)
http://bugs.winehq.org/show_bug.cgi?id=28898
Bug #: 28898 Summary: Diablo 3 beta multi-threaded installer freezes (RtlpWaitForCriticalSection block) Product: Wine Version: 1.3.31 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs@winehq.org ReportedBy: lyon@pvfree.net Classification: Unclassified
Created attachment 37126 --> http://bugs.winehq.org/attachment.cgi?id=37126 winedbg --command 'bt all'
In short:
Diablo 3 beta online installer freezes during the process of downloading files, repeatedly emitting this error message every minute:
000b:err:ntdll:RtlpWaitForCriticalSection section 0x9500b4 "?" wait timed out in thread 000b, blocked by 0020, retrying (60 sec)
Longer description:
Diablo 3 uses a multi-threaded akamai-like daemon (Agent.exe) for downloading files on background.
The installer itself Diablo-III-Beta-enUS-Setup.exe is just a tool that prepares the basic installation somewhere into c:\users\Public\Application Data/Battle.net, executes Agent.exe and starts Diablo III Launcher afterwards. In default 1.3.31-git wine installation Launcher is never started as the installer progressbar freezes in about 2/3 and RtlpWaitForCriticalSection error message is being spat out every minute.
As shown in the backtrace, the frozen thread belongs to Agent.exe that usually has about 10 threads running and it never wakes up.
Anyway, this problem was not present in Wine 1.2 series so I started to experiment with bisect and found out, that this issue started to appear between 1.3.3 and 1.3.4, specifically these two commits:
cf72f406ec7cdfebbd5135ede6e45547ca82dae0 9c2203123df76a1db1b11b633d0ccab003045fe2
Reverting those against current git snapshot makes the installer working again, at least in terms of downloading several files and successfully spawning the launcher. NOTE: Agent.exe is used by launcher as well for further game data download and installation, but although it is very unstable and crashes every now and then, the revert makes it possible to eventually install the game, without thread blocks. Agent.exe unstability is probably a different bug present already in Wine 1.2.
During the trace a clean wineprefix was used and no DLL overrides were enabled.
If any more information is needed, just let me know, I'm willing to help.
Additional info:
Diablo-III-Beta-enUS-Setup.exe can be downloaded freely from the internet, it's just an installer and it does not require any Battle.net account for installation (would be necessary for gamepaly only). I recommend looking for links leading to edgesuite.net, which is the official source for Battle.net akamai service.
http://bugs.winehq.org/show_bug.cgi?id=28898
lyon@pvfree.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lyon@pvfree.net
http://bugs.winehq.org/show_bug.cgi?id=28898
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|lyon@pvfree.net | Component|ntdll |-unknown Summary|Diablo 3 beta |Diablo 3 beta |multi-threaded installer |multi-threaded installer |freezes |freezes |(RtlpWaitForCriticalSection | |block) |
http://bugs.winehq.org/show_bug.cgi?id=28898
lyon@pvfree.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lyon@pvfree.net
http://bugs.winehq.org/show_bug.cgi?id=28898
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|lyon@pvfree.net |
--- Comment #1 from Dmitry Timoshkov dmitry@baikal.ru 2011-10-26 10:59:11 CDT --- You are the reporter, you already receive all the e-mail notifications, there is no need to add yourself to the cc: list.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #2 from lyon@pvfree.net 2011-10-26 11:01:53 CDT --- Bugzilla does not allow huge attachments, so WINEDEBUG=+relay,+seh,+tid output is available here (230M compressed to 11M):
http://static.635.cz/wine/winedebug_28898_1.log.gz
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #3 from lyon@pvfree.net 2011-10-26 11:09:07 CDT --- Created attachment 37128 --> http://bugs.winehq.org/attachment.cgi?id=37128 Installer window box
Not much to be seen in that image, just the exact point of thread freeze.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #4 from lyon@pvfree.net 2011-10-26 11:10:56 CDT --- A note for further process: Launcher requires installing vcrun2008 from winetricks. Does not solve this bug though.
http://bugs.winehq.org/show_bug.cgi?id=28898
lyon@pvfree.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://us.media.battle.net. | |edgesuite.net/downloads/d3- | |installers/4de82d80-ddeb-4e | |61-80ae-b4e8817f54b0/Diablo | |-III-Beta-enUS-Setup.exe
http://bugs.winehq.org/show_bug.cgi?id=28898
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #5 from Erich Hoover ehoover@mines.edu 2011-10-26 12:21:14 CDT --- (In reply to comment #0)
... Anyway, this problem was not present in Wine 1.2 series so I started to experiment with bisect and found out, that this issue started to appear between 1.3.3 and 1.3.4, specifically these two commits:
cf72f406ec7cdfebbd5135ede6e45547ca82dae0 9c2203123df76a1db1b11b633d0ccab003045fe2
Uh, are you sure about that? 9c2203123df76a1db1b11b633d0ccab003045fe2 just touches tests...
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #6 from lyon@pvfree.net 2011-10-26 12:48:52 CDT --- (In reply to comment #5)
Uh, are you sure about that? 9c2203123df76a1db1b11b633d0ccab003045fe2 just touches tests...
That's what I was asking myself. Maybe something just went wrong in the git bisect, I've just doublechecked and you're right, the ntdll/tests dummy revert is not needed. Only the ws2_32 one...
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #7 from Erich Hoover ehoover@mines.edu 2011-10-26 12:56:35 CDT --- (In reply to comment #6)
That's what I was asking myself. Maybe something just went wrong in the git bisect, I've just doublechecked and you're right, the ntdll/tests dummy revert is not needed. Only the ws2_32 one...
Ok, then based on your backtrace and the modified area of the code then I would guess that AcceptEx is not triggering a completion that it is supposed to. A debug log on winsock might help, it should at least tell us how WS2_AcceptEx and WS2_async_accept are being called.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #8 from lyon@pvfree.net 2011-10-26 13:23:13 CDT --- Created attachment 37131 --> http://bugs.winehq.org/attachment.cgi?id=37131 winedebug + backtrace
Attaching WINEDEBUG=-all,err+ntdll,+winsock,+seh,+tid together with new backtrace. I hope all needed is included.
http://bugs.winehq.org/show_bug.cgi?id=28898
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |cf72f406ec7cdfebbd5135ede6e | |45547ca82dae0
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #9 from Erich Hoover ehoover@mines.edu 2011-10-26 14:22:43 CDT --- Created attachment 37134 --> http://bugs.winehq.org/attachment.cgi?id=37134 Completion for accept socket
(In reply to comment #8)
... Attaching WINEDEBUG=-all,err+ntdll,+winsock,+seh,+tid together with new backtrace. I hope all needed is included.
Please try the attached patch, I believe it might be that the completion event should also go to the accepting socket (based on looking at sample code online). The patch should give some debug information about whether the completion is called, but to confirm you might also want to debug on the "sync" channel to see the CreateIoCompletionPort call.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #10 from lyon@pvfree.net 2011-10-26 14:54:40 CDT --- Created attachment 37135 --> http://bugs.winehq.org/attachment.cgi?id=37135 new winedebug + backtrace
Hmm, does not seem to have any visible effect, behaves still the same. Fresh logs attached.
http://bugs.winehq.org/show_bug.cgi?id=28898
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37134|0 |1 is obsolete| |
--- Comment #11 from Erich Hoover ehoover@mines.edu 2011-10-26 15:22:11 CDT --- Created attachment 37137 --> http://bugs.winehq.org/attachment.cgi?id=37137 Add simple synchronous AcceptEx
(In reply to comment #10)
Hmm, does not seem to have any visible effect, behaves still the same. Fresh logs attached.
Your log invalidated the previous theory. New theory: application expects synchronous behavior. Please try the attached patch.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #12 from lyon@pvfree.net 2011-10-26 15:46:48 CDT --- Created attachment 37138 --> http://bugs.winehq.org/attachment.cgi?id=37138 logs
Still no hit. Will any other debug channel help?
Note: I did not include the previous patch, so no "AcceptEx magic" message this time.
http://bugs.winehq.org/show_bug.cgi?id=28898
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37137|0 |1 is obsolete| |
--- Comment #13 from Erich Hoover ehoover@mines.edu 2011-10-26 15:59:51 CDT --- Created attachment 37139 --> http://bugs.winehq.org/attachment.cgi?id=37139 Add simple synchronous AcceptEx [2]
(In reply to comment #12)
... Still no hit. Will any other debug channel help?
Hmm, not that I can think of. I actually goofed that up a little bit, so the attached both fixes my mistake and tinkers with the return value of the function (I suspect that it returns TRUE when the event is empty). You can grep the output for "WS2_AcceptEx" so you don't need to send such a large log.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #14 from lyon@pvfree.net 2011-10-26 16:21:16 CDT --- 0047:trace:winsock:WS2_AcceptEx (110, 11c, 0xab134c, 0, 144, 144, 0x1b0e6b4, 0xab1314) 0047:fixme:winsock:WS2_AcceptEx queuing async request... 0047:fixme:winsock:WS2_AcceptEx accept status: 259 0047:trace:winsock:WS2_AcceptEx (120, 124, 0xab183c, 0, 144, 144, 0x1b0e6b4, 0xab1804) 0047:fixme:winsock:WS2_AcceptEx queuing async request... 0047:fixme:winsock:WS2_AcceptEx accept status: 259 0047:trace:winsock:WS2_AcceptEx (110, 120, 0xabb184, 0, 144, 144, 0x1b0e384, 0xabb14c) 0047:fixme:winsock:WS2_AcceptEx queuing async request... 0047:fixme:winsock:WS2_AcceptEx accept status: 259 0047:trace:winsock:WS2_AcceptEx (168, 16c, 0xabb514, 0, 144, 144, 0x1b0e384, 0xabb4dc) 0047:fixme:winsock:WS2_AcceptEx queuing async request... 0047:fixme:winsock:WS2_AcceptEx accept status: 259
http://bugs.winehq.org/show_bug.cgi?id=28898
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37139|0 |1 is obsolete| |
--- Comment #15 from Erich Hoover ehoover@mines.edu 2011-10-26 16:30:33 CDT --- Created attachment 37140 --> http://bugs.winehq.org/attachment.cgi?id=37140 Have AcceptEx return true for IOCP
(In reply to comment #14)
...
Bah, I goofed with the return value - please try the attached version. At least we now know it's not trying for synchronous operation. *grumble grumble*
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #16 from lyon@pvfree.net 2011-10-26 16:50:49 CDT --- Created attachment 37141 --> http://bugs.winehq.org/attachment.cgi?id=37141 winsock debug
Just winsock debug, no backtrace.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #17 from Erich Hoover ehoover@mines.edu 2011-10-27 13:19:50 CDT --- Summary of IRC conversation: * Based on the bind() call, the AcceptEx call is clearly related to the torrent capability of the client and not the inter-process socket. * Even though the AcceptEx call should return TRUE for IOCP-type sockets, hacking in such a change does not impact the stalling of the application. * Since the AcceptEx is used only for torrenting, TransmitFile is likely only used if a torrent connection can be made. * It is odd that this hang occurs at all, since the torrenting feature of the application is optional (it is expected for the feature to not work when a user is behind a router or firewall).
I'm not sure where that leaves us, it might be helpful to have a winsock,sync debug log from when the application works (when the AcceptEx patch is reverted). It's possible that there's something IOCP-related going on that only occurs when AcceptEx is available.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #18 from lyon@pvfree.net 2011-10-27 15:10:46 CDT --- Created attachment 37161 --> http://bugs.winehq.org/attachment.cgi?id=37161 sync + winsock without AcceptEx
Debug log for WINEDEBUG=-all,err+ntdll,+sync,+winsock,+seh,+tid with AcceptEx call removed from wine sources (i.e. working installer).
http://bugs.winehq.org/show_bug.cgi?id=28898
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37140|0 |1 is obsolete| |
--- Comment #19 from Erich Hoover ehoover@mines.edu 2011-10-27 15:51:55 CDT --- Created attachment 37162 --> http://bugs.winehq.org/attachment.cgi?id=37162 Output closesocket result
(In reply to comment #18)
Created attachment 37161 [details] ...
Interesting... the application is behaving as if AcceptEx worked (there's a call to SO_UPDATE_ACCEPT_CONTEXT) when that doesn't happen when AcceptEx exists. From the way this appears to be triggered on the close I'm wondering if the closesocket call is behaving funny. Could you run and log the attached for both w/ AcceptEx and w/o AcceptEx?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #20 from lyon@pvfree.net 2011-10-27 16:31:16 CDT --- Created attachment 37163 --> http://bugs.winehq.org/attachment.cgi?id=37163 trace logs with and without AcceptEx
Trace logs with and without AcceptEx. Just for curiosity I've attached the minimal version of the revert patch as well.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #21 from Erich Hoover ehoover@mines.edu 2011-10-27 16:49:14 CDT --- (In reply to comment #20)
Created attachment 37163 [details] trace logs with and without AcceptEx ...
Nope, not the result of the close. However, for some reason the close is called on different sockets even though the sockets are initialized in the same order (128, 134, 138, 13c) in both... --with AcceptEx:-- 000d:trace:winsock:WS_closesocket socket 0128 1 ... 000d:trace:winsock:WS_closesocket socket 0138 1 --without AcceptEx:-- 000d:trace:winsock:WS_closesocket socket 0134 1 ... 000d:trace:winsock:WS_closesocket socket 013c 1
So, with AcceptEx it closes the listener sockets and without AcceptEx it closes the accepting sockets. That seems REALLY bizarre...
http://bugs.winehq.org/show_bug.cgi?id=28898
Ričardas Barkauskas miegalius@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |miegalius@gmail.com
--- Comment #22 from Ričardas Barkauskas miegalius@gmail.com 2011-11-04 15:57:58 CDT --- This seems to be caused by GetQueuedCompletionStatus not working properly when socket gets closed. It should dequeue completion packet setting last error to ERROR_OPERATION_ABORTED. Have only a hack so far and that still results in a crash after some time passes (though it is downloading till the crash).
http://bugs.winehq.org/show_bug.cgi?id=28898
Joshua wine@placesthroughtime.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@placesthroughtime.com
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #23 from Joshua wine@placesthroughtime.com 2012-02-04 12:19:43 CST --- Has anything been determined as the cause of the problem here? It'd be great to have updates for Diablo 3 actually working via Wine.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #24 from Erich Hoover ehoover@mines.edu 2012-02-05 18:43:42 CST --- (In reply to comment #22)
This seems to be caused by GetQueuedCompletionStatus not working properly when socket gets closed. It should dequeue completion packet setting last error to ERROR_OPERATION_ABORTED. Have only a hack so far and that still results in a crash after some time passes (though it is downloading till the crash).
I'm curious what your hack is, it seems that the "Failed to run a required program (Agent)." problem partially results from the first run of the agent not closing properly. Removing AcceptEx support allows the agent to exit cleanly if you run it manually (not from the D3 installer).
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #25 from lyon@pvfree.net 2012-02-06 01:57:57 CST --- Removing AcceptEx however does not fix the installer for me anymore. It just sticks in a loop of restarting itself and gives up after few tries. I'll try to attach some logs when have more time.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #26 from Ričardas Barkauskas miegalius@gmail.com 2012-02-06 08:45:08 CST --- Now it also needs better implementation of GetExtendedTcpTable. Will send something for it after code freeze. Though it still wasn't enough. Maybe bugs in my implementation?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #27 from Erich Hoover ehoover@mines.edu 2012-02-06 13:47:28 CST --- Created attachment 38723 --> http://bugs.winehq.org/attachment.cgi?id=38723 ws2_32: Revise AcceptEx behavior to send completions for cancelled sockets.
(In reply to comment #26)
Now it also needs better implementation of GetExtendedTcpTable. Will send something for it after code freeze. Though it still wasn't enough. Maybe bugs in my implementation?
I don't know how you're approaching the AcceptEx issue, but I've attached my attempt at getting the socket to cancel properly without being too hackish. This patch appears to fix the Agent not closing (when run on its own), but I haven't investigated GetExtendedTcpTable yet. This was originally a bug against a "regression" from Wine 1.2, so it's possible that patches for this could get accepted.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #28 from Joshua wine@placesthroughtime.com 2012-02-13 17:43:08 CST --- It looks like this also effects the World of Warcraft Launcher bug http://bugs.winehq.org/show_bug.cgi?id=27657 I just did some bisecting and came out to the same commit.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #29 from Erich Hoover ehoover@mines.edu 2012-02-13 17:46:05 CST --- (In reply to comment #28)
It looks like this also effects the World of Warcraft Launcher bug http://bugs.winehq.org/show_bug.cgi?id=27657 I just did some bisecting and came out to the same commit.
Does attachment 38723 fix it for you?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #30 from Joshua wine@placesthroughtime.com 2012-02-13 18:03:16 CST --- Yup, using the latest git pull with that patch allows the launcher to exit properly and when pressing Play the game actually launches now.
http://bugs.winehq.org/show_bug.cgi?id=28898
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38723|0 |1 is obsolete| |
--- Comment #31 from Erich Hoover ehoover@mines.edu 2012-02-18 15:34:32 CST --- Created attachment 38954 --> http://bugs.winehq.org/attachment.cgi?id=38954 Try to hack together a solution for the D3 installer
(In reply to comment #30)
Yup, using the latest git pull with that patch allows the launcher to exit properly and when pressing Play the game actually launches now.
Great, unfortunately the D3 installer still needs something else to work. I've attached a patch that hacks a solution together for GetExtendedTcpTable, but it doesn't appear to solve the problem. It's always possible that I'm doing something wrong, but I get the feeling that there is something else going on.
http://bugs.winehq.org/show_bug.cgi?id=28898
William Pettersson william.pettersson+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |william.pettersson+wine@gma | |il.com
--- Comment #32 from William Pettersson william.pettersson+wine@gmail.com 2012-03-05 03:13:18 CST --- I applied the patch from #31 to latest git, then installed wine. I then ran the D3 beta installer and ... it worked. I haven't noticed any particular issues at all.
I am right now running the beta, from said install. Anyone else tested the patch?
http://bugs.winehq.org/show_bug.cgi?id=28898
Christophe Giboudeaux krop@gmx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |krop@gmx.com
--- Comment #33 from Christophe Giboudeaux krop@gmx.com 2012-03-05 16:52:39 CST --- (In reply to comment #32)
I applied the patch from #31 to latest git, then installed wine. I then ran the D3 beta installer and ... it worked. I haven't noticed any particular issues at all.
I am right now running the beta, from said install. Anyone else tested the patch?
Yes, so far, the results are quite nice.
With an already set up game I was able to run the diablo exe (without the options to bypass the patcher).
- On the first run, the patcher appeared and the files check worked (but there was nothing to patch)
- On the second run, the pre-patcher window didn't hang and the login screen appeared.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #34 from lyon@pvfree.net 2012-03-06 15:17:29 CST --- Created attachment 39214 --> http://bugs.winehq.org/attachment.cgi?id=39214 core file + wineserver logs
Hmm, I still got issues with Erich's patch crashing wineserver.
With 1.4-rc6 I do: - run launcher (Diablo III Beta Launcher.exe) => works and updates - run Diablo with bypass (Diablo III.exe -launch) => works - run Diablo without bypassing (Diablo III.exe) => SIGSEGV
With latest git clone I get SIGSEGV with all steps above (core file and wineserver -d log attached):
(gdb) bt #0 0x08066d4d in req_find_process (req=0x94d4178, reply=0xfff2196c) at process.c:1001 #1 0x08076341 in call_req_handler (thread=0x94d4090) at request.c:271 #2 0x08076459 in read_request (thread=0x94d4090) at request.c:305 #3 0x0807bb4e in thread_poll_event (fd=0x94d4228, event=1) at thread.c:252 #4 0x080568db in fd_poll_event (fd=0x94d4228, event=1) at fd.c:443 #5 0x08056b9f in main_loop_epoll () at fd.c:538 #6 0x08056f9f in main_loop () at fd.c:883 #7 0x0805f842 in main (argc=3, argv=0xfff22174) at main.c:148
(gdb) info threads * 1 Thread 25615 0x08066d4d in req_find_process (req=0x94d4178, reply=0xfff2196c) at process.c:1001
(gdb) info locals process = 0x630053 i = 57
(gdb) info registers eax 0x630053 6488147 ecx 0x94d4178 156057976 edx 0x208 520 ebx 0x94d4178 156057976 esp 0xfff21934 0xfff21934 ebp 0xfff21948 0xfff21948 esi 0x0 0 edi 0x0 0 eip 0x8066d4d 0x8066d4d <req_find_process+45> eflags 0x10206 [ PF IF RF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #35 from William Pettersson william.pettersson+wine@gmail.com 2012-03-06 15:20:38 CST --- Actually, yeah, my bad. I didn't realise that I had already set things up to launch D3 directly, I just tried to run Diablo 3 without skipping the launcher and I also got a segmentation fault. It seems I do get the same results as comment 32.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #36 from lyon@pvfree.net 2012-03-06 16:18:28 CST --- (In reply to comment #35)
Actually, yeah, my bad. I didn't realise that I had already set things up to launch D3 directly, I just tried to run Diablo 3 without skipping the launcher and I also got a segmentation fault. It seems I do get the same results as comment 32.
Correct. With a clean wineprefix rc6 it seems to behave quite random. It will eventually start the launcher, update the agent and even start the game. But most of the time it will crash anyway.
But Erich seem to get a good direction anyway :)
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #37 from Erich Hoover ehoover@mines.edu 2012-03-09 16:00:28 CST --- (In reply to comment #34)
... core file + wineserver logs ...
Hmm, I'm confused about how you could get this crash... This code should be pretty robust.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #38 from William Pettersson william.pettersson+wine@gmail.com 2012-03-11 00:23:13 CST --- I'm digging through this at the moment. Somehow ptid_entries[x].ptr is 1 for some value(s) of x (57 for me). This causes a segmentation fault as that can't be dereferenced. However, I'm not sure where the 1 is coming from.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #39 from William Pettersson william.pettersson+wine@gmail.com 2012-03-11 01:57:03 CST --- Created attachment 39307 --> http://bugs.winehq.org/attachment.cgi?id=39307 Fixing up D3 installer
I believe I've fixed the segfault in wineserver. The invalid line was process = (struct process *) ptid_entries[i + PTID_OFFSET].ptr; but the "+ PTID_OFFSET" shouldn't be here, that refers to "ID"s and not indexes into the ptid_entries array.
At least, wineserver doesn't seem to crash any more.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #40 from lyon@pvfree.net 2012-03-11 14:08:12 CDT --- I can confirm that William's modification (comment 39) of Erich's patch (comment 31) does indeed work (yet I have to check running the installer with clean wineprefix). I was able to patch the game from beta version 13 to beta version 14 without any launcher/wineserver crash. This means that a windoze installation is not needed anymore for updating the game, although running the launcher is a bit slow as it might take several minutes for it to get past the "Checking for updates..." phase and the follow-up logo box.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #41 from William Pettersson william.pettersson+wine@gmail.com 2012-03-11 17:01:00 CDT --- Can you try running "Agent.exe" in a separate terminal, see if that makes it faster? I'm noticing that the whole patching process runs better when running it separately compared to just running the launcher.
For the record, Agent.exe (for me) lives in "~/.wined3/drive_c/users/Public/Application Data/Battle.net/Agent/Agent.649", and the 649 is the agent version so check what folders exist if/when any upgrade goes through.
http://bugs.winehq.org/show_bug.cgi?id=28898
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |dank@kegel.com
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #42 from William Pettersson william.pettersson+wine@gmail.com 2012-03-12 00:57:25 CDT --- Sorry for the spam here. For me at least, sometimes the "loading the launcher" process goes just fine, and sometimes it hangs still. So I still am not sure about that.
Also, all of a sudden the actual game started running really badly for me. I'm not sure why though.
http://bugs.winehq.org/show_bug.cgi?id=28898
runetmember@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |runetmember@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #43 from lyon@pvfree.net 2012-03-20 17:14:54 CDT --- Created attachment 39480 --> http://bugs.winehq.org/attachment.cgi?id=39480 Patch with modified lsof parameters.
Ok, I think I've got the cause of the randomness: 'lsof' is doing a reverse lookup for each entry by default, so passing "-n" parameter to it makes my copy of the installer running at the speed of light :)
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #44 from William Pettersson william.pettersson+wine@gmail.com 2012-03-20 17:54:33 CDT --- Nice pickup. However, I don't know if a patch that calls lsof (amongst other things) will be accepted by wine. I realise that during the first revisions it's easiest to just do that, however I think now that it's working someone will probably have to rewrite the patch to actually read /proc directly. In particular, I know that wine currently does not depend on "lsof" as I had to manually install it on my laptop to get D3 to work.
I'm meant to be at work in 10 minutes, so I'll keep digging later, but we do have the inode, so a simple check in /proc/<PID>/fd/ for a link to "socket:<INODE>" would give the corresponding PID (so we'd have to iterate over all possible PIDs, looking for a specific inode).
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #45 from Erich Hoover ehoover@mines.edu 2012-03-20 19:17:34 CDT --- (In reply to comment #44)
Nice pickup. However, I don't know if a patch that calls lsof (amongst other things) will be accepted by wine. I realise that during the first revisions it's easiest to just do that, however I think now that it's working someone will probably have to rewrite the patch to actually read /proc directly. In particular, I know that wine currently does not depend on "lsof" as I had to manually install it on my laptop to get D3 to work.
I'm meant to be at work in 10 minutes, so I'll keep digging later, but we do have the inode, so a simple check in /proc/<PID>/fd/ for a link to "socket:<INODE>" would give the corresponding PID (so we'd have to iterate over all possible PIDs, looking for a specific inode).
Yup, I know exactly how to do this - I just haven't taken the time since: 1) I already have four patches sitting on the queue. 2) I have two patches not on the queue that are ready for submission. 3) Alexandre is on vacation this week. 4) I am one of the organizers for a conference that is next week.
If someone else wants to do this then they are free to use my code as a starting point, otherwise I'll probably get to it late next week or early the week after next.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #46 from lyon@pvfree.net 2012-03-21 03:53:23 CDT --- A note: The installer is running fine now and so does the "Checking for updates" part of the launcher. Running launcher stucks at the Diablo logo, which is however a different problem now as Agent.exe is not crashing anymore. I'm getting:
Caught json::ParseException: Unexpected End of token stream, Line/offset: 1/1
I'll try to investigate more.
http://bugs.winehq.org/show_bug.cgi?id=28898
William Pettersson william.pettersson+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39307|0 |1 is obsolete| |
--- Comment #47 from William Pettersson william.pettersson+wine@gmail.com 2012-03-22 07:33:35 CDT --- Created attachment 39494 --> http://bugs.winehq.org/attachment.cgi?id=39494 AcceptEX changes
I've re-written the patch to not call lsof. I've also split it into two files so the AcceptEX changes (which I have not touched and haven't followed) are in this file, and the TcpTable changes are in the second patch.
They seem to work for me, but I'd like some testing done. And if anyone has experience with submitting stuff to wine, feel free to read my code and point out changes that could be useful. In particular, I don't like how deep the indentation goes.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #48 from William Pettersson william.pettersson+wine@gmail.com 2012-03-22 07:34:31 CDT --- Created attachment 39495 --> http://bugs.winehq.org/attachment.cgi?id=39495 TcpTables patch
Oh and sorry about the awkward file names, I didn't think too much about my commit titles.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #49 from lyon@pvfree.net 2012-03-22 17:09:07 CDT --- Did anyone other test the patch provided by William? It does not work that well to me:
- when running launcher, i'm stuck with Diablo logo (runs properly with previous patch) - when running diablo executable, stucks at "Checking for updates" (previously got past this check but stucked later on logo)
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #50 from William Pettersson william.pettersson+wine@gmail.com 2012-03-23 00:06:13 CDT --- So I'm assuming that both patches applied cleanly at least? Is this against a recent git version, or 1.4 or something else?
And can you run it again with WINEDEBUG=fixme-all,trace+server and post the logs? In particular, I'm only interested in things that mention "find_process" so feel free to grep for that before uploading as well.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #51 from lyon@pvfree.net 2012-03-23 03:49:49 CDT --- Created attachment 39499 --> http://bugs.winehq.org/attachment.cgi?id=39499 find_process log
(In reply to comment #50)
So I'm assuming that both patches applied cleanly at least? Is this against a recent git version, or 1.4 or something else?
And can you run it again with WINEDEBUG=fixme-all,trace+server and post the logs? In particular, I'm only interested in things that mention "find_process" so feel free to grep for that before uploading as well.
The yesterday's report was based on 1.5.0 sources. However, I've pulled latest git and been trying hard this morning to find out more on this as it's still almost the same. The problem is that it is like 50/50 on starting successfully or getting sẗuck on both - running the launcher or running diablo executable directly. In both cases it is just awkwardly random as it works few times, then it just stops and works again few minutes later. Symptoms are the same as in comment 49.
I'm a confused panda. I just can't find a pattern in it.
One find_process log is attached, I'll try later on another machine/distro just to be sure.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #52 from William Pettersson william.pettersson+wine@gmail.com 2012-03-23 03:55:06 CDT --- I'll do some more digging tonight, but I think I just got lucky on my couple of tests. I've tried a bunch more, and yeah I'm getting similar things.
I think for "my" way of finding a pid from an inode might have one particular issue. I think that more than one pid can "open" a socket, and by one pid I mean the same process but different threads (maybe). I'm not 100% on this, though.
However, if that is the case, I simply return the smallest unix_pid for a socket inode, and sometimes wine, when converting that to a "wine" pid, throws INVALID_PARAMETER. I'll try changing my code so that if a "conversion" fails, it keeps trying other unix_pids.
http://bugs.winehq.org/show_bug.cgi?id=28898
William Pettersson william.pettersson+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39495|0 |1 is obsolete| |
--- Comment #53 from William Pettersson william.pettersson+wine@gmail.com 2012-03-23 05:02:06 CDT --- Created attachment 39500 --> http://bugs.winehq.org/attachment.cgi?id=39500 GetExtendedTcpTable
Here's a new version of the tcptables patch. I ran the launcher 8 or 9 times, every time it loaded almost instantly, didn't throw any JSON errors that I noticed, and the two times I tried to actually start D3 by hitting "Play" that also worked fine.
Note that you have to apply both AcceptEX-patch.patch and GetExtendedTcpTable.patch to test this, the AcceptEX patch should still be fine.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #54 from William Pettersson william.pettersson+wine@gmail.com 2012-03-23 06:36:28 CDT --- Ok, I just realised something really odd (which also explains my slow-downs). Somehow, two copies of Diablo III.exe get launched. As in, two distinct copies of the game. I have to exit one, and then I can play the second one smoothly. If I try to play the first, it's choppy.
I have no idea if this relates to my patch (or even how it could) but if it does get slow, test this for me as well.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #55 from lyon@pvfree.net 2012-03-23 07:41:59 CDT --- (In reply to comment #54)
Ok, I just realised something really odd (which also explains my slow-downs). Somehow, two copies of Diablo III.exe get launched. As in, two distinct copies of the game.
This is a known bug in launcher: http://us.battle.net/d3/en/forum/topic/4254455412#12
I'll try your new patch later. I'm on a 64-bit machine right now and I'd need to recompile after installing 32-bit libs first.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #56 from lyon@pvfree.net 2012-03-23 12:38:04 CDT --- The patch looks good so far. Not a single stuck.
http://bugs.winehq.org/show_bug.cgi?id=28898
Aigars Mahinovs aigarius@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aigarius@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
Delporte caffeine@calneva.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |caffeine@calneva.org
--- Comment #57 from Delporte caffeine@calneva.org 2012-03-25 19:58:55 CDT --- Just wanted to report that applying AccepteEX_changes and latest GetExtendedTcpTable patches worked for me against latest 1.5.0. They both applied cleanly and the launcher/updater has worked fine since. My only hiccup was that I had to clear out the 'Updates' folder ( ~/.wine64/drive_c/Program Files (x86)/Diablo III Beta/Updates in my case) of all the .MPQ files and one .MPQ.lock file. Before I did this, the launcher was giving me an error: 'An unexpected error occurred while trying to install. Please try again or contact support." The launcher would then close upon hitting OK. clearing out the 'Updates' folder solved this problem and the game has updated and the launcher has run fine since so I'm not sure if the error is related to the patches or not.
Just wanted to report my success.
64bit gentoo linux, 64bit wine prefix
regards
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #58 from lyon@pvfree.net 2012-03-26 12:47:52 CDT --- These patches also fix the installer/launcher problems in:
World of Warcraft: Mists of Pandaria BETA
http://bugs.winehq.org/show_bug.cgi?id=28898
James Eder jimportal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jimportal@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
Peter forreg@rinaldus.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |forreg@rinaldus.ru
--- Comment #59 from Peter forreg@rinaldus.ru 2012-04-16 11:04:23 CDT --- When will these patches be included in Wine sources?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #60 from James Eder jimportal@gmail.com 2012-04-16 13:20:41 CDT --- (In reply to comment #59)
When will these patches be included in Wine sources?
After they've had sufficient code review. The patches have been sent and are showing on http://source.winehq.org/patches/ so it should be sooner or later.
Patch acceptance time is not a constant but varies based on many factors such as complexity, trust, time to next release, and the weather forecast for disparate locations around the world.
At any rate, at such a time that they are accepted someone will very likely say so here on the bug tracker.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #61 from James Eder jimportal@gmail.com 2012-04-16 20:45:53 CDT --- It looks like the GetExtendedTcpTable changes made it in today. Still waiting on the AcceptEx patches, however.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #62 from Erich Hoover ehoover@mines.edu 2012-04-16 20:49:18 CDT --- (In reply to comment #61)
It looks like the GetExtendedTcpTable changes made it in today. Still waiting on the AcceptEx patches, however.
The AcceptEx patches are covered by Bug #27657. So, I'd say that if the AcceptEx patches fix the remaining issues then this bug should be closed.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #63 from William Pettersson william.pettersson+wine@gmail.com 2012-04-16 20:53:29 CDT --- Seeing as people are trying to track this, please note that I did not submit the GetExtendedTcpTable patch that is in the queue (and has apparently been accepted). The submitted patch seems to be a completely different implementation, based on my quick read of it. Hans (the submitter of said patch) also isn't on this bug report in any way.
We should at least confirm that these patches do fix the GetExtendedTcpTable issue. That is, try latest git with just the AcceptEX changes. If that works, then this can be closed as either resolved, or duplicate of the acceptEX bug.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #64 from James Eder jimportal@gmail.com 2012-04-18 17:11:30 CDT --- I downloaded the D3 installer and with today's git and the AcceptEX patch (from http://source.winehq.org/patches/data/85280 ), I was able to download 7gb of data and all seems to work decently up until the launcher showed a dialog saying: "Failed to retrieve Blizzard Launcher properties." Clicking OK exits the installer.
I then ran "Diablo III Setup.exe" from the downloaded files and clicked the "install" button and got a dialog saying: "The fire from the sky still falls. Diablo III has not yet launched."
We're not crashing but I'm not sure if we're broken either. I since found out that they're doing maintenance of some kind on their end: http://us.battle.net/d3/en/forum/topic/4489049301#1
I'm kinda leaning toward this bug being fixed since at least it's not freezing while downloading files.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #65 from Christophe Giboudeaux krop@gmx.com 2012-04-18 17:51:59 CDT --- (In reply to comment #64)
I then ran "Diablo III Setup.exe" from the downloaded files and clicked the "install" button and got a dialog saying: "The fire from the sky still falls. Diablo III has not yet launched."
We're not crashing but I'm not sure if we're broken either.
That's totally unrelated and just means you're trying to use the retail installer instead of the beta one.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #66 from James Eder jimportal@gmail.com 2012-04-18 19:06:24 CDT --- Does the beta client crash then?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #67 from Joshua wine@placesthroughtime.com 2012-04-18 19:30:11 CDT --- (In reply to comment #66)
Does the beta client crash then?
Yes, the launcher still crashes in the latest git pull..
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #68 from James Eder jimportal@gmail.com 2012-04-18 19:37:58 CDT --- (In reply to comment #67)
Yes, the launcher still crashes in the latest git pull..
To be clear, is that with the AcceptEx patch applied too?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #69 from Joshua wine@placesthroughtime.com 2012-04-18 21:35:02 CDT --- (In reply to comment #68)
(In reply to comment #67)
Yes, the launcher still crashes in the latest git pull..
To be clear, is that with the AcceptEx patch applied too?
That is without, it works just fine with the patch :D
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #70 from Aigars Mahinovs aigarius@gmail.com 2012-04-19 11:13:39 CDT --- Without the patch the retail installer crashes before you get that "The fire from the sky still falls..." message, so that makes it easier to test for people without beta access.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #71 from James Eder jimportal@gmail.com 2012-04-19 11:22:32 CDT --- Then we are back to Erich's suggestion in Comment 62 I guess.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #72 from lyon@pvfree.net 2012-04-19 17:04:29 CDT --- According to http://source.winehq.org/patches/ the AcceptEx watch was again rejected. Is there anywhere to find out why?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #73 from William Pettersson william.pettersson+wine@gmail.com 2012-04-19 17:07:20 CDT --- The wine-devel mailing list is where this discussion took place. In short, bits of the patch looked "pretty hackish, the server shouldn't have to care about the status values or patch them up for the client."
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #74 from Erich Hoover ehoover@mines.edu 2012-04-19 18:28:54 CDT --- (In reply to comment #72)
According to http://source.winehq.org/patches/ the AcceptEx watch was again rejected. Is there anywhere to find out why?
Before it was deferred and not rejected (rejected usually involves an explanation email), but yes - the why is available on wine-devel. I have another thought about how to approach this issue, but I won't have time to give it a try until tomorrow (at the earliest).
http://bugs.winehq.org/show_bug.cgi?id=28898
Lucas Fialho Zawacki lfzawacki@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lfzawacki@yahoo.com.br
http://bugs.winehq.org/show_bug.cgi?id=28898
jacobsen.douglas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacobsen.douglas@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
olivier@well2u.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier@well2u.com
--- Comment #75 from olivier@well2u.com 2012-04-21 00:03:03 CDT --- As an independent confirmation, I could not get the game to load until: Applying Erich solution from: http://source.winehq.org/patches/data/85573 into the latest wine-git source this was built on amd64, on Ubuntu latest 11.10 and patched wine-git. The full game setup from (today's) free Diablo III beta week-end trial installed and ran without a problem, it has now been running for hours and in network mode with a party doing quests. The only issue so far: could not change the graphics mode, the game quit, besides this the game looks platinum -- just needs this 1 fix. Thanks to this thread!
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #76 from Joshua wine@placesthroughtime.com 2012-04-21 01:07:23 CDT --- (In reply to comment #75)
As an independent confirmation, I could not get the game to load until: Applying Erich solution from: http://source.winehq.org/patches/data/85573 into the latest wine-git source this was built on amd64, on Ubuntu latest 11.10 and patched wine-git. The full game setup from (today's) free Diablo III beta week-end trial installed and ran without a problem, it has now been running for hours and in network mode with a party doing quests. The only issue so far: could not change the graphics mode, the game quit, besides this the game looks platinum -- just needs this 1 fix. Thanks to this thread!
See if that graphics mode issue is the same as the one in bug 28201, theres a patch there as well.
http://bugs.winehq.org/show_bug.cgi?id=28898
Gerald Tan woefulwabbit@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |woefulwabbit@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #77 from jacobsen.douglas@gmail.com 2012-04-21 10:06:48 CDT --- (In reply to comment #75)
As an independent confirmation, I could not get the game to load until: Applying Erich solution from: http://source.winehq.org/patches/data/85573 into the latest wine-git source this was built on amd64, on Ubuntu latest 11.10 and patched wine-git. The full game setup from (today's) free Diablo III beta week-end trial installed and ran without a problem, it has now been running for hours and in network mode with a party doing quests. The only issue so far: could not change the graphics mode, the game quit, besides this the game looks platinum -- just needs this 1 fix. Thanks to this thread!
I have had similar results. Tested with the same patch, built the latest checkout of wine. It seems to run fine for me so far.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #78 from jacobsen.douglas@gmail.com 2012-04-21 11:43:00 CDT --- (In reply to comment #76)
See if that graphics mode issue is the same as the one in bug 28201, theres a patch there as well.
I rebuilt using the referenced patch, and was able to modify the graphics settings.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #79 from jacobsen.douglas@gmail.com 2012-04-21 11:54:56 CDT --- Now the only issue I have, is that I get no sound output when I run. But this was the case before and after the d3d patch referenced above.
B.net has been down since I have been able to run it, so I can't tell you if the graphics changes actually do anything, but the patch removed the errors.
http://bugs.winehq.org/show_bug.cgi?id=28898
geriain@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |geriain@gmx.de
--- Comment #80 from geriain@gmx.de 2012-04-22 15:00:52 CDT --- After applying the two Patches GetExtendedTCPTable and AcceptEX to new wine and compiling it I tried to install D2 again, using the beta-installer.
But still it comes up with agent-error
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #81 from lyon@pvfree.net 2012-04-22 16:17:05 CDT --- (In reply to comment #80)
After applying the two Patches GetExtendedTCPTable and AcceptEX to new wine and compiling it I tried to install D2 again, using the beta-installer.
But still it comes up with agent-error
Could you post the actual error? Those open_http_connection messages in your log are pretty much normal and harmless.
Did you try installing vcrun2008?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #82 from jacobsen.douglas@gmail.com 2012-04-22 16:21:02 CDT --- Also, as a note. I didn't actually have to use the GetExtendedTCPTable patch. I only needed the AcceptEx patch.
Also, I don't know if you did this already or not (I assume you did since you were able to build wine) but make sure you're calling the newly built wine, and not a different previously installed wine. You can check by using "wine --version".
As an example, my version is wine-1.5.2-191-gd080774, and I built it yesterday.
http://bugs.winehq.org/show_bug.cgi?id=28898
Mike Mestnik cheako+winehq@mikemestnik.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cheako+winehq@mikemestnik.n | |et
--- Comment #83 from Mike Mestnik cheako+winehq@mikemestnik.net 2012-04-24 12:31:49 CDT --- I didn't have this issue and I applied the GetExtendedTcpTable and AcceptEX changes patches.
Ubuntu Precise binaries available here, only 32bit tested: https://launchpad.net/~cheako/+archive/wine4diabloiii/
http://bugs.winehq.org/show_bug.cgi?id=28898
Lamn post-box2000@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |post-box2000@mail.ru
http://bugs.winehq.org/show_bug.cgi?id=28898
John Porterfield ycarus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ycarus@gmail.com
--- Comment #84 from John Porterfield ycarus@gmail.com 2012-05-07 17:06:06 CDT --- Error persists in 1.5.3 and the provided patch does will not properly apply to the source. Can I ignore the errors in the patch?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #85 from Mike Mestnik cheako+winehq@mikemestnik.net 2012-05-07 19:13:41 CDT --- John, what are the errors?
This looks interesting: http://www.markusbe.com/2009/11/how-to-apply-a-patch-and-solve-hunk-failed-c...
http://bugs.winehq.org/show_bug.cgi?id=28898
André Fettouhi A.Fettouhi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |A.Fettouhi@gmail.com
--- Comment #86 from André Fettouhi A.Fettouhi@gmail.com 2012-05-12 02:00:06 CDT --- I just tried to apply both the GetExtendedTcpTable and AcceptEX patches against wine 1.5.4 and GetExtendedTcpTable fails with this error:
1 out of 1 hunk FAILED -- saving rejects to file dlls/iphlpapi/iphlpapi_main.c.rej 7 out of 8 hunks FAILED -- saving rejects to file dlls/iphlpapi/ipstats.c.rej 1 out of 5 hunks FAILED -- saving rejects to file include/wine/server_protocol.h.rej
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #87 from Joshua wine@placesthroughtime.com 2012-05-12 08:48:55 CDT --- bug 27657 has been a bit more up to date with the patches in development to fix this issue.. or here they are as of May 12th, 2012:
http://source.winehq.org/patches/data/86102 - [PATCH 1/4] server: Add completion information to async IO callback (try 2, resend). http://source.winehq.org/patches/data/86103 - [PATCH 2/4] server: Update stored completion information even after an async IO is queued (resend). http://source.winehq.org/patches/data/86104 - [PATCH 3/4] ws2_32,ntdll: Update async IO callbacks to include completion information (try 2, resend). http://source.winehq.org/patches/data/86105 - [PATCH 4/4] ws2_32: Use completion information to send AcceptEx completions (try 2, resend).
Thanks Erich Hoover, keep on trying!
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #88 from Mike Mestnik cheako+winehq@mikemestnik.net 2012-05-12 13:52:32 CDT --- (In reply to comment #86)
I just tried to apply both the GetExtendedTcpTable and AcceptEX patches against wine 1.5.4 and GetExtendedTcpTable fails with this error:
1 out of 1 hunk FAILED -- saving rejects to file dlls/iphlpapi/iphlpapi_main.c.rej 7 out of 8 hunks FAILED -- saving rejects to file dlls/iphlpapi/ipstats.c.rej 1 out of 5 hunks FAILED -- saving rejects to file include/wine/server_protocol.h.rej
GetExtendedTcpTable was included since 1.5.3, AFAIK.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #89 from Mike Mestnik cheako+winehq@mikemestnik.net 2012-05-12 13:58:24 CDT --- I've setup a PPA: https://launchpad.net/~cheako/+archive/packages4diabloiii
Users, let me know of any problems directly.
If there are patches missing, I'd like to know. You can review the patches by unpacking the current debian.tar.gz: https://launchpad.net/~cheako/+archive/packages4diabloiii/+files/wine1.5_1.5...
This is a small archive that includes a debian/patches folder with the several patches applied to pristine source taken from wine git.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #90 from Erich Hoover ehoover@mines.edu 2012-05-12 19:23:53 CDT --- (In reply to comment #87)
... Thanks Erich Hoover, keep on trying!
No problem, I've been attempting to be persistent with suggested patches without being a jerk and spamming the patch list too much. I think the current iteration I have submitted is a great solution - but Alexandre hasn't read it yet. We'll see how it goes.
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |adys.wh@gmail.com Ever Confirmed|0 |1
--- Comment #91 from Jerome Leclanche adys.wh@gmail.com 2012-05-14 12:54:28 CDT --- (In reply to comment #90) Erich, I get an error when building wine64 with your patch:
In file included from ../../server/request.c:66:0: ../../server/request.h:617:1: error: size of unnamed array is negative ../../server/request.h:773:1: error: size of unnamed array is negative ../../server/request.h:820:1: error: size of unnamed array is negative ../../server/request.h:821:1: error: size of unnamed array is negative make[1]: *** [request.o] Error 1 make[1]: Leaving directory `/home/adys/src/wine/build64/server' make: *** [server] Error 2
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #92 from Erich Hoover ehoover@mines.edu 2012-05-14 12:58:54 CDT --- (In reply to comment #91)
(In reply to comment #90) Erich, I get an error when building wine64 with your patch:
In file included from ../../server/request.c:66:0: ../../server/request.h:617:1: error: size of unnamed array is negative ...
Did tools/make_requests get patched properly? The patch should change the size of apc_call_t from 40 bytes to 44 bytes, without that change you'll get that error.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #93 from Jerome Leclanche adys.wh@gmail.com 2012-05-14 12:59:35 CDT --- (In reply to comment #92) Yeah, but it appears I had to re-run configure for build64. Nevermind :)
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #94 from André Fettouhi A.Fettouhi@gmail.com 2012-05-14 13:14:35 CDT --- I tried your patches as well against wine 1.5.4 and I get this error:
gcc -c -I../../../wine/dlls/ntdll -I. -I../../../wine/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=0 -o sync.o ../../../wine/dlls/ntdll/sync.c ../../../wine/dlls/ntdll/sync.c: In function ‘invoke_apc’: ../../../wine/dlls/ntdll/sync.c:871:69: fejl: ‘const struct <anonymous>’ has no member named ‘chandle’ ../../../wine/dlls/ntdll/sync.c:872:44: fejl: ‘const struct <anonymous>’ has no member named ‘ckey’ make[1]: *** [sync.o] Error 1 make[1]: Leaving directory '/home/af/wine/src/wine-64-build/dlls/ntdll' make: *** [dlls/ntdll] Error 2 ==> ERROR: There was an error in build().
I'm using arch linux 64 bit btw.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #95 from Jerome Leclanche adys.wh@gmail.com 2012-05-14 13:14:50 CDT --- (In reply to comment #93) I have to withdraw that, after a re-configure it still fails to build on wine64. I'm on IRC if you want to avoid the noise on this bug.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #96 from Erich Hoover ehoover@mines.edu 2012-05-14 13:59:00 CDT --- Created attachment 40172 --> http://bugs.winehq.org/attachment.cgi?id=40172 Revised patch for adding completion info (part 1/4).
(In reply to comment #95)
(In reply to comment #93) I have to withdraw that, after a re-configure it still fails to build on wine64. I'm on IRC if you want to avoid the noise on this bug.
Please try this revised patch for part 1 of 4, I'm not 100% certain it will work - but I believe that it will.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #97 from Jerome Leclanche adys.wh@gmail.com 2012-05-14 14:06:34 CDT --- Compiles but I get this on wineboot
% wineboot wineserver: ../../server/request.c:759: open_master_socket: Assertion `sizeof(union generic_reply) == sizeof(struct request_max_size)' failed.
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pitlicek@gmail.com
--- Comment #98 from Jerome Leclanche adys.wh@gmail.com 2012-05-14 15:17:33 CDT --- *** Bug 27657 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Diablo 3 beta |Blizzard Launcher/Installer |multi-threaded installer |needs AcceptEx improvements |freezes |(Affects WoW, D3...)
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39500|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #39480|0 |1 is obsolete| |
--- Comment #99 from Jerome Leclanche adys.wh@gmail.com 2012-05-14 15:44:02 CDT --- Comment on attachment 39480 --> http://bugs.winehq.org/attachment.cgi?id=39480 Patch with modified lsof parameters.
--- a/dlls/iphlpapi/iphlpapi_main.c +++ a/dlls/iphlpapi/iphlpapi_main.c @@ -1883,15 +1883,36 @@ DWORD WINAPI GetTcpTable(PMIB_TCPTABLE pTcpTable, PDWORD pdwSize, BOOL bOrder) DWORD WINAPI GetExtendedTcpTable(PVOID pTcpTable, PDWORD pdwSize, BOOL bOrder, ULONG ulAf, TCP_TABLE_CLASS TableClass, ULONG Reserved) {
- DWORD table_size;
- VOID *table;
- DWORD ret;
- TRACE("pTcpTable %p, pdwSize %p, bOrder %d, ulAf %u, TableClass %u, Reserved %u\n", pTcpTable, pdwSize, bOrder, ulAf, TableClass, Reserved);
- if (ulAf == AF_INET6 || TableClass != TCP_TABLE_BASIC_ALL)
- if (!pdwSize) return ERROR_INVALID_PARAMETER;
- if (ulAf == AF_INET6) {
FIXME("ulAf = %u, TableClass = %u not supportted\n", ulAf, TableClass);
FIXME("AF_INET6 not supported\n"); return ERROR_NOT_SUPPORTED;
- return GetTcpTable(pTcpTable, pdwSize, bOrder);
- ret = tcp_build_table(GetProcessHeap(), 0, &table, &table_size, bOrder, TableClass);
- if (!ret) {
if (!pTcpTable || *pdwSize < table_size) {*pdwSize = table_size;ret = ERROR_INSUFFICIENT_BUFFER;}else {*pdwSize = table_size;memcpy(pTcpTable, table, table_size);}HeapFree(GetProcessHeap(), 0, table);- }
- TRACE("returning %d\n", ret);
- return ret;
}
/****************************************************************** --- a/dlls/iphlpapi/ipstats.c +++ a/dlls/iphlpapi/ipstats.c @@ -1617,15 +1617,17 @@ DWORD WINAPI AllocateAndGetUdpTableFromStack(PMIB_UDPTABLE *ppUdpTable, BOOL bOr }
-static MIB_TCPTABLE *append_tcp_row( HANDLE heap, DWORD flags, MIB_TCPTABLE *table,
DWORD *count, const MIB_TCPROW *row )+static VOID *append_tcp_row( HANDLE heap, DWORD flags, VOID *table, DWORD *count,
const VOID *row, DWORD row_size, DWORD table_struct_size ){
- if (table->dwNumEntries >= *count)
- DWORD dwNumEntries = *(DWORD *)table;
- if (dwNumEntries >= *count) {
MIB_TCPTABLE *new_table;DWORD new_count = table->dwNumEntries * 2;
VOID *new_table;DWORD new_count = dwNumEntries * 2;
if (!(new_table = HeapReAlloc( heap, flags, table, FIELD_OFFSET(MIB_TCPTABLE, table[new_count] ))))
if (!(new_table = HeapReAlloc( heap, flags, table, table_struct_size + row_size*new_count ))) { HeapFree( heap, 0, table ); return NULL;@@ -1633,7 +1635,8 @@ static MIB_TCPTABLE *append_tcp_row( HANDLE heap, DWORD flags, MIB_TCPTABLE *tab *count = new_count; table = new_table; }
- memcpy( &table->table[table->dwNumEntries++], row, sizeof(*row) );
- memcpy( (CHAR *)table + sizeof(DWORD) + dwNumEntries*row_size, row, row_size );
- *(DWORD *)table = dwNumEntries+1; return table;
}
@@ -1674,38 +1677,34 @@ static int compare_tcp_rows(const void *a, const void *b) }
-/******************************************************************
- AllocateAndGetTcpTableFromStack (IPHLPAPI.@)
- Get the TCP connection table.
- Like GetTcpTable(), but allocate the returned table from heap.
- PARAMS
- ppTcpTable [Out] pointer into which the MIB_TCPTABLE is
allocated and returned.
- bOrder [In] whether to sort the table
- heap [In] heap from which the table is allocated
- flags [In] flags to HeapAlloc
- RETURNS
- ERROR_INVALID_PARAMETER if ppTcpTable is NULL, whatever GetTcpTable()
- returns otherwise.
- */
-DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bOrder,
HANDLE heap, DWORD flags)+#include "wine/server.h" +#define STATUS_SUCCESS 0 +DWORD tcp_build_table(HANDLE heap, DWORD flags, VOID **table, DWORD *table_size, BOOL bOrder,
TCP_TABLE_CLASS TableClass){
- MIB_TCPTABLE *table;
- MIB_TCPROW row;
- DWORD ret = NO_ERROR, count = 16;
- TRACE("table %p, bOrder %d, heap %p, flags 0x%08x\n", ppTcpTable, bOrder, heap, flags);
- DWORD ret = NO_ERROR, row_size, table_struct_size;
- MIB_TCPROW_OWNER_PID row;
- DWORD count = 16;
- if (!ppTcpTable) return ERROR_INVALID_PARAMETER;
- switch(TableClass)
- {
case TCP_TABLE_BASIC_ALL:row_size = sizeof(MIB_TCPROW);table_struct_size = sizeof(MIB_TCPTABLE)-row_size;break;case TCP_TABLE_OWNER_PID_ALL:row_size = sizeof(MIB_TCPROW_OWNER_PID);table_struct_size = sizeof(MIB_TCPTABLE_OWNER_PID)-row_size;break;default:FIXME("TableClass = %u not supported\n", TableClass);return ERROR_NOT_SUPPORTED;- }
- if (!(table = HeapAlloc( heap, flags, FIELD_OFFSET(MIB_TCPTABLE, table[count] ))))
- if (!(*table = HeapAlloc( heap, flags, table_struct_size+row_size*count ))) return ERROR_OUTOFMEMORY;
- table->dwNumEntries = 0;
- *(DWORD *)*table = 0;
#ifdef __linux__ { @@ -1720,13 +1719,43 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO ptr = fgets(buf, sizeof(buf), fp); while ((ptr = fgets(buf, sizeof(buf), fp))) {
if (sscanf( ptr, "%x: %x:%x %x:%x %x", &dummy, &row.dwLocalAddr, &row.dwLocalPort,&row.dwRemoteAddr, &row.dwRemotePort, &row.u.dwState ) != 6)
int inode;if (sscanf( ptr, "%x: %x:%x %x:%x %x %*s %*s %*s %*s %*s %d", &dummy, &row.dwLocalAddr, &row.dwLocalPort,&row.dwRemoteAddr, &row.dwRemotePort, &row.dwState, &inode ) != 7) continue;if (inode){char cmd[200], ret[200];FILE *handle;size_t r = 0;ret[0] = 0;snprintf(cmd, sizeof(cmd), "lsof -n +c 0 -i :%d | grep '\\.exe' | grep ' %d ' | sed 's/[^ ]* *//' | sed 's/ .*//'", row.dwRemotePort, inode);handle = popen(cmd, "r");while(!feof(handle))r = fread(ret, 1, sizeof(ret), handle);if(r){int unix_pid, status;sscanf(ret, "%d", &unix_pid);SERVER_START_REQ( find_process ){req->unix_pid = unix_pid;status = wine_server_call( req );if (status == STATUS_SUCCESS)row.dwOwningPid = reply->pid;}SERVER_END_REQ;+FIXME("found pid %d\n", row.dwOwningPid);
}pclose(handle);} row.dwLocalPort = htons( row.dwLocalPort ); row.dwRemotePort = htons( row.dwRemotePort );
row.u.State = TCPStateToMIBState( row.u.dwState );if (!(table = append_tcp_row( heap, flags, table, &count, &row )))
row.dwState = TCPStateToMIBState( row.dwState );if (!(*table = append_tcp_row( heap, flags, *table, &count, &row, row_size, table_struct_size ))) break; } fclose( fp );@@ -1749,8 +1778,8 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO row.dwLocalPort = htons( entry->tcpConnLocalPort ); row.dwRemoteAddr = entry->tcpConnRemAddress; row.dwRemotePort = htons( entry->tcpConnRemPort );
row.u.dwState = entry->tcpConnState;if (!(table = append_tcp_row( heap, flags, table, &count, &row ))) break;
row.dwState = entry->tcpConnState;if (!(*table = append_tcp_row( heap, flags, *table, &count, &row, row_size, table_struct_size ))) break; } HeapFree( GetProcessHeap(), 0, data ); }@@ -1828,8 +1857,8 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO row.dwLocalPort = pINData->inp_lport; row.dwRemoteAddr = pINData->inp_faddr.s_addr; row.dwRemotePort = pINData->inp_fport;
row.u.State = TCPStateToMIBState (pTCPData->t_state);if (!(table = append_tcp_row( heap, flags, table, &count, &row ))) break;
row.dwState = TCPStateToMIBState (pTCPData->t_state);if (!(*table = append_tcp_row( heap, flags, *table, &count, &row, row_size, table_struct_size ))) break; }done:
@@ -1840,14 +1869,51 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO ret = ERROR_NOT_SUPPORTED; #endif
- if (!table) return ERROR_OUTOFMEMORY;
- if (!*table) return ERROR_OUTOFMEMORY; if (!ret) {
if (bOrder && table->dwNumEntries)qsort( table->table, table->dwNumEntries, sizeof(row), compare_tcp_rows );*ppTcpTable = table;
DWORD dwNumEntries = *(DWORD *)*table;if (bOrder && dwNumEntries)qsort( (CHAR*)(*table) + sizeof(DWORD), dwNumEntries, row_size, compare_tcp_rows );if (table_size)*table_size = table_struct_size + row_size*dwNumEntries;
- else HeapFree( heap, flags, table );
- else HeapFree( heap, flags, *table );
- return ret;
+}
+/******************************************************************
- AllocateAndGetTcpTableFromStack (IPHLPAPI.@)
- Get the TCP connection table.
- Like GetTcpTable(), but allocate the returned table from heap.
- PARAMS
- ppTcpTable [Out] pointer into which the MIB_TCPTABLE is
allocated and returned.
- bOrder [In] whether to sort the table
- heap [In] heap from which the table is allocated
- flags [In] flags to HeapAlloc
- RETURNS
- ERROR_INVALID_PARAMETER if ppTcpTable is NULL, whatever GetTcpTable()
- returns otherwise.
- */
+DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bOrder,
HANDLE heap, DWORD flags)+{
- MIB_TCPTABLE *table;
- DWORD ret;
- TRACE("table %p, bOrder %d, heap %p, flags 0x%08x\n", ppTcpTable, bOrder, heap, flags);
- if (!ppTcpTable) return ERROR_INVALID_PARAMETER;
- ret = tcp_build_table(heap, flags, (VOID **)&table, NULL, bOrder, TCP_TABLE_BASIC_ALL);
- if (ret == NO_ERROR)
*ppTcpTable = table;- TRACE( "returning ret %u table %p\n", ret, table ); return ret;
} --- a/dlls/iphlpapi/ipstats.h +++ a/dlls/iphlpapi/ipstats.h @@ -27,6 +27,8 @@ #include "winbase.h" #include "iprtrmib.h"
+DWORD tcp_build_table(HANDLE heap, DWORD flags, VOID **table, DWORD *table_size, BOOL bOrder, TCP_TABLE_CLASS TableClass);
/* Fills in entry's interface stats, using name to find them.
- Returns ERROR_INVALID_PARAMETER if name or entry is NULL, NO_ERROR otherwise.
*/ --- a/dlls/ws2_32/socket.c +++ a/dlls/ws2_32/socket.c @@ -1700,7 +1700,7 @@ static NTSTATUS WS2_async_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS sta if (status != STATUS_PENDING) goto finish;
- return STATUS_SUCCESS;
- return STATUS_ALERTED;
finish: iosb->u.Status = status; @@ -1708,8 +1708,6 @@ finish:
if (wsa->user_overlapped->hEvent) SetEvent(wsa->user_overlapped->hEvent);
if (wsa->cvalue)
WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information );*apc = ws2_async_accept_apc; return status;
@@ -2040,7 +2038,9 @@ static BOOL WINAPI WS2_AcceptEx(SOCKET listener, SOCKET acceptor, PVOID dest, DW req->async.callback = wine_server_client_ptr( WS2_async_accept ); req->async.iosb = wine_server_client_ptr( overlapped ); req->async.arg = wine_server_client_ptr( wsa );
/* We don't set event or completion since we may also have to read */
req->async.cvalue = cvalue;/* We don't set event since we may also have to read, completion returns STATUS_ALERTED* to indicate that no completion should be queued. */ status = wine_server_call( req );--- a/include/wine/server_protocol.h +++ a/include/wine/server_protocol.h @@ -716,6 +716,20 @@ struct init_thread_reply
+struct find_process_request +{
- struct request_header __header;
- int unix_pid;
+}; +struct find_process_reply +{
- struct reply_header __header;
- process_id_t pid;
- char __pad_12[4];
+};
struct terminate_process_request { struct request_header __header; @@ -4897,6 +4911,7 @@ enum request REQ_get_startup_info, REQ_init_process_done, REQ_init_thread,
- REQ_find_process, REQ_terminate_process, REQ_terminate_thread, REQ_get_process_info,
@@ -5151,6 +5166,7 @@ union generic_request struct get_startup_info_request get_startup_info_request; struct init_process_done_request init_process_done_request; struct init_thread_request init_thread_request;
- struct find_process_request find_process_request; struct terminate_process_request terminate_process_request; struct terminate_thread_request terminate_thread_request; struct get_process_info_request get_process_info_request;
@@ -5403,6 +5419,7 @@ union generic_reply struct get_startup_info_reply get_startup_info_reply; struct init_process_done_reply init_process_done_reply; struct init_thread_reply init_thread_reply;
- struct find_process_reply find_process_reply; struct terminate_process_reply terminate_process_reply; struct terminate_thread_reply terminate_thread_reply; struct get_process_info_reply get_process_info_reply;
@@ -5646,6 +5663,6 @@ union generic_reply struct set_suspend_context_reply set_suspend_context_reply; };
-#define SERVER_PROTOCOL_VERSION 431 +#define SERVER_PROTOCOL_VERSION 432
#endif /* __WINE_WINE_SERVER_PROTOCOL_H */ --- a/server/async.c +++ a/server/async.c @@ -256,10 +256,12 @@ void async_set_result( struct object *obj, unsigned int status, unsigned int tot else { if (async->timeout) remove_timeout_user( async->timeout );
if (async->completion && async->data.cvalue && status != STATUS_ALERTED)add_completion( async->completion, async->comp_key, async->data.cvalue, status, total );else if (async->completion && async->data.cvalue && status == STATUS_ALERTED)status = STATUS_SUCCESS; async->timeout = NULL; async->status = status;
if (async->completion && async->data.cvalue)add_completion( async->completion, async->comp_key, async->data.cvalue, status, total ); if (apc) { apc_call_t data;--- a/server/process.c +++ a/server/process.c @@ -989,6 +989,24 @@ DECL_HANDLER(new_process) release_object( info ); }
+/* Find a process from the Unix pid */ +DECL_HANDLER(find_process) +{
- struct process *process;
- int i;
- for(i=0; i<used_ptid_entries; i++)
- {
process = (struct process *) ptid_entries[i].ptr;if (process && process->unix_pid == req->unix_pid){reply->pid = get_process_id( process );return;}- }
- set_error( STATUS_INVALID_PARAMETER );
+}
/* Retrieve information about a newly started process */ DECL_HANDLER(get_new_process_info) { --- a/server/protocol.def +++ a/server/protocol.def @@ -695,6 +695,14 @@ typedef union @END
+/* Find a process from the Unix pid */ +@REQ(find_process)
- int unix_pid; /* Unix pid of the process */
+@REPLY
- process_id_t pid; /* Wine process id of the process */
+@END
/* Terminate a process */ @REQ(terminate_process) obj_handle_t handle; /* process handle to terminate */ --- a/server/request.h +++ a/server/request.h @@ -117,6 +117,7 @@ DECL_HANDLER(new_thread); DECL_HANDLER(get_startup_info); DECL_HANDLER(init_process_done); DECL_HANDLER(init_thread); +DECL_HANDLER(find_process); DECL_HANDLER(terminate_process); DECL_HANDLER(terminate_thread); DECL_HANDLER(get_process_info); @@ -370,6 +371,7 @@ static const req_handler req_handlers[REQ_NB_REQUESTS] = (req_handler)req_get_startup_info, (req_handler)req_init_process_done, (req_handler)req_init_thread,
- (req_handler)req_find_process, (req_handler)req_terminate_process, (req_handler)req_terminate_thread, (req_handler)req_get_process_info,
@@ -696,6 +698,10 @@ C_ASSERT( FIELD_OFFSET(struct init_thread_reply, info_size) == 24 ); C_ASSERT( FIELD_OFFSET(struct init_thread_reply, version) == 28 ); C_ASSERT( FIELD_OFFSET(struct init_thread_reply, all_cpus) == 32 ); C_ASSERT( sizeof(struct init_thread_reply) == 40 ); +C_ASSERT( FIELD_OFFSET(struct find_process_request, unix_pid) == 12 ); +C_ASSERT( sizeof(struct find_process_request) == 16 ); +C_ASSERT( FIELD_OFFSET(struct find_process_reply, pid) == 8 ); +C_ASSERT( sizeof(struct find_process_reply) == 16 ); C_ASSERT( FIELD_OFFSET(struct terminate_process_request, handle) == 12 ); C_ASSERT( FIELD_OFFSET(struct terminate_process_request, exit_code) == 16 ); C_ASSERT( sizeof(struct terminate_process_request) == 24 ); --- a/server/trace.c +++ a/server/trace.c @@ -1100,6 +1100,16 @@ static void dump_init_thread_reply( const struct init_thread_reply *req ) fprintf( stderr, ", all_cpus=%08x", req->all_cpus ); }
+static void dump_find_process_request( const struct find_process_request *req ) +{
- fprintf( stderr, " unix_pid=%d", req->unix_pid );
+}
+static void dump_find_process_reply( const struct find_process_reply *req ) +{
- fprintf( stderr, " pid=%04x", req->pid );
+}
static void dump_terminate_process_request( const struct terminate_process_request *req ) { fprintf( stderr, " handle=%04x", req->handle ); @@ -3920,6 +3930,7 @@ static const dump_func req_dumpers[REQ_NB_REQUESTS] = { (dump_func)dump_get_startup_info_request, (dump_func)dump_init_process_done_request, (dump_func)dump_init_thread_request,
- (dump_func)dump_find_process_request, (dump_func)dump_terminate_process_request, (dump_func)dump_terminate_thread_request, (dump_func)dump_get_process_info_request,
@@ -4170,6 +4181,7 @@ static const dump_func reply_dumpers[REQ_NB_REQUESTS] = { (dump_func)dump_get_startup_info_reply, NULL, (dump_func)dump_init_thread_reply,
- (dump_func)dump_find_process_reply, (dump_func)dump_terminate_process_reply, (dump_func)dump_terminate_thread_reply, (dump_func)dump_get_process_info_reply,
@@ -4420,6 +4432,7 @@ static const char * const req_names[REQ_NB_REQUESTS] = { "get_startup_info", "init_process_done", "init_thread",
- "find_process", "terminate_process", "terminate_thread", "get_process_info",
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38954|0 |1 is obsolete| |
--- Comment #100 from Jerome Leclanche adys.wh@gmail.com 2012-05-14 15:44:36 CDT --- Comment on attachment 38954 --> http://bugs.winehq.org/attachment.cgi?id=38954 Try to hack together a solution for the D3 installer
diff --git a/dlls/iphlpapi/iphlpapi_main.c b/dlls/iphlpapi/iphlpapi_main.c index 2a3285f..88946ba 100644 --- a/dlls/iphlpapi/iphlpapi_main.c +++ b/dlls/iphlpapi/iphlpapi_main.c @@ -1883,15 +1883,36 @@ DWORD WINAPI GetTcpTable(PMIB_TCPTABLE pTcpTable, PDWORD pdwSize, BOOL bOrder) DWORD WINAPI GetExtendedTcpTable(PVOID pTcpTable, PDWORD pdwSize, BOOL bOrder, ULONG ulAf, TCP_TABLE_CLASS TableClass, ULONG Reserved) {
- DWORD table_size;
- VOID *table;
- DWORD ret;
- TRACE("pTcpTable %p, pdwSize %p, bOrder %d, ulAf %u, TableClass %u, Reserved %u\n", pTcpTable, pdwSize, bOrder, ulAf, TableClass, Reserved);
- if (ulAf == AF_INET6 || TableClass != TCP_TABLE_BASIC_ALL)
- if (!pdwSize) return ERROR_INVALID_PARAMETER;
- if (ulAf == AF_INET6) {
FIXME("ulAf = %u, TableClass = %u not supportted\n", ulAf, TableClass);
FIXME("AF_INET6 not supported\n"); return ERROR_NOT_SUPPORTED;
- return GetTcpTable(pTcpTable, pdwSize, bOrder);
- ret = tcp_build_table(GetProcessHeap(), 0, &table, &table_size, bOrder, TableClass);
- if (!ret) {
if (!pTcpTable || *pdwSize < table_size) {*pdwSize = table_size;ret = ERROR_INSUFFICIENT_BUFFER;}else {*pdwSize = table_size;memcpy(pTcpTable, table, table_size);}HeapFree(GetProcessHeap(), 0, table);- }
- TRACE("returning %d\n", ret);
- return ret;
}
/****************************************************************** diff --git a/dlls/iphlpapi/ipstats.c b/dlls/iphlpapi/ipstats.c index db475fb..8d81b92 100644 --- a/dlls/iphlpapi/ipstats.c +++ b/dlls/iphlpapi/ipstats.c @@ -1617,15 +1617,17 @@ DWORD WINAPI AllocateAndGetUdpTableFromStack(PMIB_UDPTABLE *ppUdpTable, BOOL bOr }
-static MIB_TCPTABLE *append_tcp_row( HANDLE heap, DWORD flags, MIB_TCPTABLE *table,
DWORD *count, const MIB_TCPROW *row )+static VOID *append_tcp_row( HANDLE heap, DWORD flags, VOID *table, DWORD *count,
const VOID *row, DWORD row_size, DWORD table_struct_size ){
- if (table->dwNumEntries >= *count)
- DWORD dwNumEntries = *(DWORD *)table;
- if (dwNumEntries >= *count) {
MIB_TCPTABLE *new_table;DWORD new_count = table->dwNumEntries * 2;
VOID *new_table;DWORD new_count = dwNumEntries * 2;
if (!(new_table = HeapReAlloc( heap, flags, table, FIELD_OFFSET(MIB_TCPTABLE, table[new_count] ))))
if (!(new_table = HeapReAlloc( heap, flags, table, table_struct_size + row_size*new_count ))) { HeapFree( heap, 0, table ); return NULL;@@ -1633,7 +1635,8 @@ static MIB_TCPTABLE *append_tcp_row( HANDLE heap, DWORD flags, MIB_TCPTABLE *tab *count = new_count; table = new_table; }
- memcpy( &table->table[table->dwNumEntries++], row, sizeof(*row) );
- memcpy( (CHAR *)table + sizeof(DWORD) + dwNumEntries*row_size, row, row_size );
- *(DWORD *)table = dwNumEntries+1; return table;
}
@@ -1674,38 +1677,34 @@ static int compare_tcp_rows(const void *a, const void *b) }
-/******************************************************************
- AllocateAndGetTcpTableFromStack (IPHLPAPI.@)
- Get the TCP connection table.
- Like GetTcpTable(), but allocate the returned table from heap.
- PARAMS
- ppTcpTable [Out] pointer into which the MIB_TCPTABLE is
allocated and returned.
- bOrder [In] whether to sort the table
- heap [In] heap from which the table is allocated
- flags [In] flags to HeapAlloc
- RETURNS
- ERROR_INVALID_PARAMETER if ppTcpTable is NULL, whatever GetTcpTable()
- returns otherwise.
- */
-DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bOrder,
HANDLE heap, DWORD flags)+#include "wine/server.h" +#define STATUS_SUCCESS 0 +DWORD tcp_build_table(HANDLE heap, DWORD flags, VOID **table, DWORD *table_size, BOOL bOrder,
TCP_TABLE_CLASS TableClass){
- MIB_TCPTABLE *table;
- MIB_TCPROW row;
- DWORD ret = NO_ERROR, count = 16;
- TRACE("table %p, bOrder %d, heap %p, flags 0x%08x\n", ppTcpTable, bOrder, heap, flags);
- DWORD ret = NO_ERROR, row_size, table_struct_size;
- MIB_TCPROW_OWNER_PID row;
- DWORD count = 16;
- if (!ppTcpTable) return ERROR_INVALID_PARAMETER;
- switch(TableClass)
- {
case TCP_TABLE_BASIC_ALL:row_size = sizeof(MIB_TCPROW);table_struct_size = sizeof(MIB_TCPTABLE)-row_size;break;case TCP_TABLE_OWNER_PID_ALL:row_size = sizeof(MIB_TCPROW_OWNER_PID);table_struct_size = sizeof(MIB_TCPTABLE_OWNER_PID)-row_size;break;default:FIXME("TableClass = %u not supported\n", TableClass);return ERROR_NOT_SUPPORTED;- }
- if (!(table = HeapAlloc( heap, flags, FIELD_OFFSET(MIB_TCPTABLE, table[count] ))))
- if (!(*table = HeapAlloc( heap, flags, table_struct_size+row_size*count ))) return ERROR_OUTOFMEMORY;
- table->dwNumEntries = 0;
- *(DWORD *)*table = 0;
#ifdef __linux__ { @@ -1720,13 +1719,43 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO ptr = fgets(buf, sizeof(buf), fp); while ((ptr = fgets(buf, sizeof(buf), fp))) {
if (sscanf( ptr, "%x: %x:%x %x:%x %x", &dummy, &row.dwLocalAddr, &row.dwLocalPort,&row.dwRemoteAddr, &row.dwRemotePort, &row.u.dwState ) != 6)
int inode;if (sscanf( ptr, "%x: %x:%x %x:%x %x %*s %*s %*s %*s %*s %d", &dummy, &row.dwLocalAddr, &row.dwLocalPort,&row.dwRemoteAddr, &row.dwRemotePort, &row.dwState, &inode ) != 7) continue;if (inode){char cmd[200], ret[200];FILE *handle;size_t r = 0;ret[0] = 0;snprintf(cmd, sizeof(cmd), "lsof +c 0 -i :%d | grep '\\.exe' | grep ' %d ' | sed 's/[^ ]* *//' | sed 's/ .*//'", row.dwRemotePort, inode);handle = popen(cmd, "r");while(!feof(handle))r = fread(ret, 1, sizeof(ret), handle);if(r){int unix_pid, status;sscanf(ret, "%d", &unix_pid);SERVER_START_REQ( find_process ){req->unix_pid = unix_pid;status = wine_server_call( req );if (status == STATUS_SUCCESS)row.dwOwningPid = reply->pid;}SERVER_END_REQ;+FIXME("found pid %d\n", row.dwOwningPid);
}pclose(handle);} row.dwLocalPort = htons( row.dwLocalPort ); row.dwRemotePort = htons( row.dwRemotePort );
row.u.State = TCPStateToMIBState( row.u.dwState );if (!(table = append_tcp_row( heap, flags, table, &count, &row )))
row.dwState = TCPStateToMIBState( row.dwState );if (!(*table = append_tcp_row( heap, flags, *table, &count, &row, row_size, table_struct_size ))) break; } fclose( fp );@@ -1749,8 +1778,8 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO row.dwLocalPort = htons( entry->tcpConnLocalPort ); row.dwRemoteAddr = entry->tcpConnRemAddress; row.dwRemotePort = htons( entry->tcpConnRemPort );
row.u.dwState = entry->tcpConnState;if (!(table = append_tcp_row( heap, flags, table, &count, &row ))) break;
row.dwState = entry->tcpConnState;if (!(*table = append_tcp_row( heap, flags, *table, &count, &row, row_size, table_struct_size ))) break; } HeapFree( GetProcessHeap(), 0, data ); }@@ -1828,8 +1857,8 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO row.dwLocalPort = pINData->inp_lport; row.dwRemoteAddr = pINData->inp_faddr.s_addr; row.dwRemotePort = pINData->inp_fport;
row.u.State = TCPStateToMIBState (pTCPData->t_state);if (!(table = append_tcp_row( heap, flags, table, &count, &row ))) break;
row.dwState = TCPStateToMIBState (pTCPData->t_state);if (!(*table = append_tcp_row( heap, flags, *table, &count, &row, row_size, table_struct_size ))) break; }done:
@@ -1840,14 +1869,51 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO ret = ERROR_NOT_SUPPORTED; #endif
- if (!table) return ERROR_OUTOFMEMORY;
- if (!*table) return ERROR_OUTOFMEMORY; if (!ret) {
if (bOrder && table->dwNumEntries)qsort( table->table, table->dwNumEntries, sizeof(row), compare_tcp_rows );*ppTcpTable = table;
DWORD dwNumEntries = *(DWORD *)*table;if (bOrder && dwNumEntries)qsort( (CHAR*)(*table) + sizeof(DWORD), dwNumEntries, row_size, compare_tcp_rows );if (table_size)*table_size = table_struct_size + row_size*dwNumEntries;
- else HeapFree( heap, flags, table );
- else HeapFree( heap, flags, *table );
- return ret;
+}
+/******************************************************************
- AllocateAndGetTcpTableFromStack (IPHLPAPI.@)
- Get the TCP connection table.
- Like GetTcpTable(), but allocate the returned table from heap.
- PARAMS
- ppTcpTable [Out] pointer into which the MIB_TCPTABLE is
allocated and returned.
- bOrder [In] whether to sort the table
- heap [In] heap from which the table is allocated
- flags [In] flags to HeapAlloc
- RETURNS
- ERROR_INVALID_PARAMETER if ppTcpTable is NULL, whatever GetTcpTable()
- returns otherwise.
- */
+DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bOrder,
HANDLE heap, DWORD flags)+{
- MIB_TCPTABLE *table;
- DWORD ret;
- TRACE("table %p, bOrder %d, heap %p, flags 0x%08x\n", ppTcpTable, bOrder, heap, flags);
- if (!ppTcpTable) return ERROR_INVALID_PARAMETER;
- ret = tcp_build_table(heap, flags, (VOID **)&table, NULL, bOrder, TCP_TABLE_BASIC_ALL);
- if (ret == NO_ERROR)
*ppTcpTable = table;- TRACE( "returning ret %u table %p\n", ret, table ); return ret;
} diff --git a/dlls/iphlpapi/ipstats.h b/dlls/iphlpapi/ipstats.h index 3522716..c546512 100644 --- a/dlls/iphlpapi/ipstats.h +++ b/dlls/iphlpapi/ipstats.h @@ -27,6 +27,8 @@ #include "winbase.h" #include "iprtrmib.h"
+DWORD tcp_build_table(HANDLE heap, DWORD flags, VOID **table, DWORD *table_size, BOOL bOrder, TCP_TABLE_CLASS TableClass);
/* Fills in entry's interface stats, using name to find them.
- Returns ERROR_INVALID_PARAMETER if name or entry is NULL, NO_ERROR otherwise.
*/ diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c index 0ff19d6..0aa6596 100644 --- a/dlls/ws2_32/socket.c +++ b/dlls/ws2_32/socket.c @@ -1707,7 +1707,7 @@ static NTSTATUS WS2_async_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS sta if (status != STATUS_PENDING) goto finish;
- return STATUS_SUCCESS;
- return STATUS_ALERTED;
finish: iosb->u.Status = status; @@ -1715,8 +1715,6 @@ finish:
if (wsa->user_overlapped->hEvent) SetEvent(wsa->user_overlapped->hEvent);
if (wsa->cvalue)
WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information );*apc = ws2_async_accept_apc; return status;
@@ -2047,7 +2045,9 @@ static BOOL WINAPI WS2_AcceptEx(SOCKET listener, SOCKET acceptor, PVOID dest, DW req->async.callback = wine_server_client_ptr( WS2_async_accept ); req->async.iosb = wine_server_client_ptr( overlapped ); req->async.arg = wine_server_client_ptr( wsa );
/* We don't set event or completion since we may also have to read */
req->async.cvalue = cvalue;/* We don't set event since we may also have to read, completion returns STATUS_ALERTED* to indicate that no completion should be queued. */ status = wine_server_call( req );diff --git a/include/wine/server_protocol.h b/include/wine/server_protocol.h index 0e989da..9851cbb 100644 --- a/include/wine/server_protocol.h +++ b/include/wine/server_protocol.h @@ -716,6 +716,20 @@ struct init_thread_reply
+struct find_process_request +{
- struct request_header __header;
- int unix_pid;
+}; +struct find_process_reply +{
- struct reply_header __header;
- process_id_t pid;
- char __pad_12[4];
+};
struct terminate_process_request { struct request_header __header; @@ -4897,6 +4911,7 @@ enum request REQ_get_startup_info, REQ_init_process_done, REQ_init_thread,
- REQ_find_process, REQ_terminate_process, REQ_terminate_thread, REQ_get_process_info,
@@ -5151,6 +5166,7 @@ union generic_request struct get_startup_info_request get_startup_info_request; struct init_process_done_request init_process_done_request; struct init_thread_request init_thread_request;
- struct find_process_request find_process_request; struct terminate_process_request terminate_process_request; struct terminate_thread_request terminate_thread_request; struct get_process_info_request get_process_info_request;
@@ -5403,6 +5419,7 @@ union generic_reply struct get_startup_info_reply get_startup_info_reply; struct init_process_done_reply init_process_done_reply; struct init_thread_reply init_thread_reply;
- struct find_process_reply find_process_reply; struct terminate_process_reply terminate_process_reply; struct terminate_thread_reply terminate_thread_reply; struct get_process_info_reply get_process_info_reply;
@@ -5646,6 +5663,6 @@ union generic_reply struct set_suspend_context_reply set_suspend_context_reply; };
-#define SERVER_PROTOCOL_VERSION 431 +#define SERVER_PROTOCOL_VERSION 432
#endif /* __WINE_WINE_SERVER_PROTOCOL_H */ diff --git a/server/async.c b/server/async.c index dd28dff..b8be5cd 100644 --- a/server/async.c +++ b/server/async.c @@ -256,10 +256,12 @@ void async_set_result( struct object *obj, unsigned int status, unsigned int tot else { if (async->timeout) remove_timeout_user( async->timeout );
if (async->completion && async->data.cvalue && status != STATUS_ALERTED)add_completion( async->completion, async->comp_key, async->data.cvalue, status, total );else if (async->completion && async->data.cvalue && status == STATUS_ALERTED)status = STATUS_SUCCESS; async->timeout = NULL; async->status = status;
if (async->completion && async->data.cvalue)add_completion( async->completion, async->comp_key, async->data.cvalue, status, total ); if (apc) { apc_call_t data;diff --git a/server/process.c b/server/process.c index de3b594..7fe50c9 100644 --- a/server/process.c +++ b/server/process.c @@ -989,6 +989,24 @@ DECL_HANDLER(new_process) release_object( info ); }
+/* Find a process from the Unix pid */ +DECL_HANDLER(find_process) +{
- struct process *process;
- int i;
- for(i=0; i<used_ptid_entries; i++)
- {
process = (struct process *) ptid_entries[i + PTID_OFFSET].ptr;if (process && process->unix_pid == req->unix_pid){reply->pid = get_process_id( process );return;}- }
- set_error( STATUS_INVALID_PARAMETER );
+}
/* Retrieve information about a newly started process */ DECL_HANDLER(get_new_process_info) { diff --git a/server/protocol.def b/server/protocol.def index 80c0cd3..b36b878 100644 --- a/server/protocol.def +++ b/server/protocol.def @@ -695,6 +695,14 @@ typedef union @END
+/* Find a process from the Unix pid */ +@REQ(find_process)
- int unix_pid; /* Unix pid of the process */
+@REPLY
- process_id_t pid; /* Wine process id of the process */
+@END
/* Terminate a process */ @REQ(terminate_process) obj_handle_t handle; /* process handle to terminate */ diff --git a/server/request.h b/server/request.h index 5b45cf9..8d59a46 100644 --- a/server/request.h +++ b/server/request.h @@ -117,6 +117,7 @@ DECL_HANDLER(new_thread); DECL_HANDLER(get_startup_info); DECL_HANDLER(init_process_done); DECL_HANDLER(init_thread); +DECL_HANDLER(find_process); DECL_HANDLER(terminate_process); DECL_HANDLER(terminate_thread); DECL_HANDLER(get_process_info); @@ -370,6 +371,7 @@ static const req_handler req_handlers[REQ_NB_REQUESTS] = (req_handler)req_get_startup_info, (req_handler)req_init_process_done, (req_handler)req_init_thread,
- (req_handler)req_find_process, (req_handler)req_terminate_process, (req_handler)req_terminate_thread, (req_handler)req_get_process_info,
@@ -696,6 +698,10 @@ C_ASSERT( FIELD_OFFSET(struct init_thread_reply, info_size) == 24 ); C_ASSERT( FIELD_OFFSET(struct init_thread_reply, version) == 28 ); C_ASSERT( FIELD_OFFSET(struct init_thread_reply, all_cpus) == 32 ); C_ASSERT( sizeof(struct init_thread_reply) == 40 ); +C_ASSERT( FIELD_OFFSET(struct find_process_request, unix_pid) == 12 ); +C_ASSERT( sizeof(struct find_process_request) == 16 ); +C_ASSERT( FIELD_OFFSET(struct find_process_reply, pid) == 8 ); +C_ASSERT( sizeof(struct find_process_reply) == 16 ); C_ASSERT( FIELD_OFFSET(struct terminate_process_request, handle) == 12 ); C_ASSERT( FIELD_OFFSET(struct terminate_process_request, exit_code) == 16 ); C_ASSERT( sizeof(struct terminate_process_request) == 24 ); diff --git a/server/trace.c b/server/trace.c index cfef963..5b0c85e 100644 --- a/server/trace.c +++ b/server/trace.c @@ -1100,6 +1100,16 @@ static void dump_init_thread_reply( const struct init_thread_reply *req ) fprintf( stderr, ", all_cpus=%08x", req->all_cpus ); }
+static void dump_find_process_request( const struct find_process_request *req ) +{
- fprintf( stderr, " unix_pid=%d", req->unix_pid );
+}
+static void dump_find_process_reply( const struct find_process_reply *req ) +{
- fprintf( stderr, " pid=%04x", req->pid );
+}
static void dump_terminate_process_request( const struct terminate_process_request *req ) { fprintf( stderr, " handle=%04x", req->handle ); @@ -3920,6 +3930,7 @@ static const dump_func req_dumpers[REQ_NB_REQUESTS] = { (dump_func)dump_get_startup_info_request, (dump_func)dump_init_process_done_request, (dump_func)dump_init_thread_request,
- (dump_func)dump_find_process_request, (dump_func)dump_terminate_process_request, (dump_func)dump_terminate_thread_request, (dump_func)dump_get_process_info_request,
@@ -4170,6 +4181,7 @@ static const dump_func reply_dumpers[REQ_NB_REQUESTS] = { (dump_func)dump_get_startup_info_reply, NULL, (dump_func)dump_init_thread_reply,
- (dump_func)dump_find_process_reply, (dump_func)dump_terminate_process_reply, (dump_func)dump_terminate_thread_reply, (dump_func)dump_get_process_info_reply,
@@ -4420,6 +4432,7 @@ static const char * const req_names[REQ_NB_REQUESTS] = { "get_startup_info", "init_process_done", "init_thread",
- "find_process", "terminate_process", "terminate_thread", "get_process_info",
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37131|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=28898
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
--- Comment #101 from Alexey Loukianov mooroon2@mail.ru 2012-05-14 21:24:48 CDT --- I can confirm that patchset from comment #87 applied over current Wine git HEAD (which is close to "Wine 1.5.4" release) fixes the problems with Diablo III installer and launcher apps.
It also helps to increase stability of the installer, but I have no idea why does it happen. Without this patchset downloader seems to hand once in a while during game download process in case P2P transfers are enabled. With this patchset I hadn't been able to reproduce downloader hangs despite I had been trying hardly - had downloaded full game package for over than 10 times yesterday without a glitch. With the unpatched version I've got two hangs over four successful download attemps, so it looks like this patchset helps somehow to increase the stability of the downloader.
I'm not sure if CodeWeavers guys had used the same patchset for their unsupported CrossOver 11.0.3rc1 "D3 preliminary support" build, but if that's the case - it also helped there. I've been able to successfully download (twice), install and play D3 using CO 11.0.3rc1, so in case CW guys would happen to read this comment, they should be proud of the good work they've done to deliver CO version that is capable of driving D3 just at the right moment.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #102 from Alexey Loukianov mooroon2@mail.ru 2012-05-14 21:26:23 CDT --- Correction: "...to increase stability of the installer,..." should be read as "to increase stability of the downloader,...". Sorry for extra noise, it's early morning here and having some sleep won't hurt :-).
http://bugs.winehq.org/show_bug.cgi?id=28898
stefan.buller@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan.buller@gmail.com
--- Comment #103 from stefan.buller@gmail.com 2012-05-15 00:37:15 CDT --- (In reply to comment #94)
I tried your patches as well against wine 1.5.4 and I get this error:
gcc -c -I../../../wine/dlls/ntdll -I. -I../../../wine/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=0 -o sync.o ../../../wine/dlls/ntdll/sync.c ../../../wine/dlls/ntdll/sync.c: In function ‘invoke_apc’: ../../../wine/dlls/ntdll/sync.c:871:69: fejl: ‘const struct <anonymous>’ has no member named ‘chandle’ ../../../wine/dlls/ntdll/sync.c:872:44: fejl: ‘const struct <anonymous>’ has no member named ‘ckey’ make[1]: *** [sync.o] Error 1 make[1]: Leaving directory '/home/af/wine/src/wine-64-build/dlls/ntdll' make: *** [dlls/ntdll] Error 2 ==> ERROR: There was an error in build().
I'm using arch linux 64 bit btw.
This caught me too. Gotta run 'tools/make_requests'.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #104 from André Fettouhi A.Fettouhi@gmail.com 2012-05-15 00:41:46 CDT --- I did that.
http://bugs.winehq.org/show_bug.cgi?id=28898
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oneadvent@gmail.com
--- Comment #105 from Jerome Leclanche adys.wh@gmail.com 2012-05-15 01:14:20 CDT --- *** Bug 30198 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #106 from Erich Hoover ehoover@mines.edu 2012-05-15 09:46:32 CDT --- New patch attempt: [1/3] http://source.winehq.org/patches/data/86263 [2/3] http://source.winehq.org/patches/data/86264 [3/3] http://source.winehq.org/patches/data/86265
This version is similar to a previous attempt, but it uses a better return value (referenced in a lot of MSDN documentation for this purpose) and includes code to handle an IOCP being associated with a file handle after an async operation has started.
http://bugs.winehq.org/show_bug.cgi?id=28898
chemacg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chemacg@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
Marco D moonbane@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |moonbane@gmx.net
--- Comment #107 from Marco D moonbane@gmx.net 2012-05-15 10:17:11 CDT --- (In reply to comment #106)
Do these Patches supersede your earlier patches # 86102 - 86105 completely?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #108 from Erich Hoover ehoover@mines.edu 2012-05-15 10:33:34 CDT --- (In reply to comment #107)
(In reply to comment #106)
Do these Patches supersede your earlier patches # 86102 - 86105 completely?
They are an alternative solution, so yes - you can consider them to supersede those patches.
http://bugs.winehq.org/show_bug.cgi?id=28898
Vic Fryzel vic.fryzel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vic.fryzel@gmail.com
--- Comment #109 from Vic Fryzel vic.fryzel@gmail.com 2012-05-15 17:07:59 CDT --- (In reply to comment #108)
(In reply to comment #107)
(In reply to comment #106)
Do these Patches supersede your earlier patches # 86102 - 86105 completely?
They are an alternative solution, so yes - you can consider them to supersede those patches.
Erich,
This round of patches does not work against HEAD. Wine fails to run, with no meaningful output to stdout.
Here is the full debug output: https://docs.google.com/open?id=0BzT42yAEwdOOMExNR3htWXp3VWc
Are you unable to test your patches before sending them? Do you have a copy of the game?
Thanks, Vic
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #110 from Jerome Leclanche adys.wh@gmail.com 2012-05-15 17:10:19 CDT --- (In reply to comment #109) Patches work fine here. What happens?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #111 from Vic Fryzel vic.fryzel@gmail.com 2012-05-15 17:11:39 CDT --- (In reply to comment #110)
(In reply to comment #109) Patches work fine here. What happens?
In the previous series of patches, I've gotten the exact errors you yourself reported. In the latest round, the program exits with no stdout as I mentioned.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #112 from Erich Hoover ehoover@mines.edu 2012-05-15 17:18:03 CDT --- (In reply to comment #109)
... This round of patches does not work against HEAD. Wine fails to run, with no meaningful output to stdout.
That is rather surprising... Are you using 64-bit or 32-bit Wine? Did you make && sudo make install all of Wine or just a portion of it?
Here is the full debug output: https://docs.google.com/open?id=0BzT42yAEwdOOMExNR3htWXp3VWc
It would be very difficult for me to figure out the problem from that log.
Are you unable to test your patches before sending them? Do you have a copy of the game?
I test my patches against a suite of tests I've added to Wine from playing with the beta, I won't be able to test against the full game until I get home tonight and then make a trip to the regional UPS distribution center to pick it up.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #113 from Vic Fryzel vic.fryzel@gmail.com 2012-05-15 17:20:16 CDT --- (In reply to comment #112)
(In reply to comment #109)
... This round of patches does not work against HEAD. Wine fails to run, with no meaningful output to stdout.
That is rather surprising... Are you using 64-bit or 32-bit Wine? Did you make && sudo make install all of Wine or just a portion of it?
Yes. What isn't clear to me is when the others on this thread who reported the same issues resolved their issues? I am able to reproduce each set of errors verbatim for each different patch set.
I test my patches against a suite of tests I've added to Wine from playing with the beta, I won't be able to test against the full game until I get home tonight and then make a trip to the regional UPS distribution center to pick it up.
Okay, let me know if that doesn't work out and I'll just buy you a version of the game you can download.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #114 from Vic Fryzel vic.fryzel@gmail.com 2012-05-15 17:29:42 CDT --- (In reply to comment #112)
That is rather surprising... Are you using 64-bit or 32-bit Wine? Did you make && sudo make install all of Wine or just a portion of it?
Sorry, 64-bit Wine.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #115 from James Eder jimportal@gmail.com 2012-05-15 17:33:11 CDT --- The 3 patches work fine for me too. Have you tried rebuilding after a make distclean?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #116 from Erich Hoover ehoover@mines.edu 2012-05-15 17:42:17 CDT --- (In reply to comment #113)
... Yes. What isn't clear to me is when the others on this thread who reported the same issues resolved their issues? I am able to reproduce each set of errors verbatim for each different patch set.
The last set that had 64-bit problems was resolved with the revised part 1/4 patch (attachment 40172) and changing line 66 of server/protocol.def from "pad[16]" to "pad[18]. I'm sorry I didn't post that here, that was from a discussion on IRC. I test on 32-bit Wine since I have a very old Wine install with lots of applications that I do not wish to trash by changing over to 64-bit Wine.
However, this new patch set should be more robust. Can you run notepad? Are you using a fresh prefix? (it's possible something else loaded on start exposes the problem) It might be easiest to find the problem if you do one patch at a time and see which one breaks everything. My guess would be that it's the first patch and that it's somehow triggered by another application that loads when you first start Wine.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #117 from Vic Fryzel vic.fryzel@gmail.com 2012-05-15 18:21:58 CDT --- (In reply to comment #116)
Wine is exiting with status code 1. I've tried a fresh, clean build, fresh WINEPREFIX, and am doing make && sudo make install. Notepad runs fine, but when attempting to run either the downloader or the installer, wine exits with status code 1.
git checkout -f make distclean git apply part1.patch git apply part2.patch git apply part3.patch tools/make_requests include/wine/server_protocol.h updated git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: dlls/ws2_32/socket.c # modified: dlls/ws2_32/tests/sock.c # modified: include/wine/server_protocol.h # modified: server/async.c # modified: server/fd.c # modified: server/file.c # modified: server/file.h # modified: server/mailslot.c # modified: server/mapping.c # modified: server/named_pipe.c # modified: server/serial.c # modified: server/signal.c # modified: server/sock.c # modified: server/thread.c # modified: server/trace.c ./configure --enable-win64 --prefix=/usr/local make
# Does not work WINEPREFIX=~/.diablo3 ./wine64 ~/downloads/Diablo-III-8370-enUS-Installer-downloader.exe fixme:iphlpapi:NotifyAddrChange (Handle 0xede338, overlapped 0xede300): stub wine: configuration in '/home/batman/.diablo3' has been updated. WINEPREFIX=~/.diablo3 ./wine64 ~/downloads/Diablo-III-8370-enUS-Installer/Diablo\ III\ Setup.exe
sudo make install
# Does not work WINEPREFIX=~/.diablo3 /usr/local/bin/wine64 ~/downloads/Diablo-III-8370-enUS-Installer-downloader.exe
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #118 from Erich Hoover ehoover@mines.edu 2012-05-15 18:36:29 CDT --- (In reply to comment #117)
...
What happens when you try to launch it without the patches? I'm wondering if it's failing for a wholly unrelated reason. If it runs without the patches could you try with just applying patch 1?
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #119 from Vic Fryzel vic.fryzel@gmail.com 2012-05-15 19:31:11 CDT --- (In reply to comment #118)
(In reply to comment #117)
...
What happens when you try to launch it without the patches? I'm wondering if it's failing for a wholly unrelated reason. If it runs without the patches could you try with just applying patch 1?
Well, one good piece of news is that it fails even on a fresh checkout now. It may be that the patches are working (before they were exiting with assertion failures or compiler errors), and now the real problem with my setup is showing. However, like others, I'm just on 64-bit Arch Linux, so not sure what the differences are...
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #120 from Vic Fryzel vic.fryzel@gmail.com 2012-05-15 20:52:49 CDT --- I wanted to update here that I got it working with Adys' configure line. I was failing to specify a few specific dependencies. Thank you for the help.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #121 from Marco D moonbane@gmx.net 2012-05-16 03:32:12 CDT --- (In reply to comment #106)
These patches work fine with latest git. Been playing D3 half the night.
They compile clean and with my own debianized version of Wine.
http://bugs.winehq.org/show_bug.cgi?id=28898
leonhard leonhard@in-verted.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leonhard@in-verted.de
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #122 from Joshua Welch oneadvent@gmail.com 2012-05-16 07:48:37 CDT --- (In reply to comment #121)
(In reply to comment #106)
These patches work fine with latest git. Been playing D3 half the night.
They compile clean and with my own debianized version of Wine.
Can you post what process you used? I got a bunch of errors with those patches.
Thanks!!
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #123 from Joshua Welch oneadvent@gmail.com 2012-05-16 10:05:39 CDT --- Also I cannot compile wine or those patches on 12.04
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #124 from Alexey Loukianov mooroon2@mail.ru 2012-05-16 10:14:00 CDT --- Joshua, are you on 64bit 12.04? If so - then you would have to stick with creating chrooted 32bit development environment and compile Wine inside it (you would hit some problems on this path although, read wine-devel mainling list archive for details), or would have to stick into building and using 64bit Wine - and I'm not sure it would work with D3.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #125 from Joshua Welch oneadvent@gmail.com 2012-05-16 10:19:38 CDT --- Yea you have me. I have been trying that PPA that someone posted but I still can't login. Was trying to compile to see if it fixes that error. I have the wine64 compiled but I have to figure out how to use another directory for this one game. If I figure it out I'll post if it works!
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #126 from Alexey Loukianov mooroon2@mail.ru 2012-05-16 10:26:48 CDT --- If you're having login problems like "error 3007" - try executing "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope" in a terminal before starting Diablo III. It might fix your problem. If so - it is bug #30410 and not this one.
P.S. If by "use another directory" you mean "use nother WINEPREFIX" - just export something like WINEPREFIX="$HOME/.wine-d3" into your environment before trying to play with freshly compiled Wine and unexport it after you finish with it. I.e. start up something like this in terminal:
# export WINEPREFIX="$HOME/.wine-d3" ... # <do whatever you want to test your wine build> ... # export -n WINEPREFIX
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #127 from James Eder jimportal@gmail.com 2012-05-16 11:18:26 CDT --- Please try to keep things on topic. If you have questions about how to use or build Wine, they are probably better suited for a forum discussion.
Also, this bug is not a catch all for any problems you might have running D3. Keep in mind that many regular Windows users are experiencing connection and game play issues that will probably settle down a bit in a few days or so.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #128 from Alexey Loukianov mooroon2@mail.ru 2012-05-16 12:59:34 CDT --- I can confirm that game installer/updater works with 32bit Wine patched with latest patchset by Erich (that one that consist of three parts).
http://bugs.winehq.org/show_bug.cgi?id=28898
Chris_9 jukeller@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jukeller@gmx.de
--- Comment #129 from Chris_9 jukeller@gmx.de 2012-05-16 14:42:48 CDT --- The same here, i am able to install, update and play the game. The patches (86263, 86264 and 86265) works perfectly.
Using Ubuntu 12.04 - 64Bit
http://bugs.winehq.org/show_bug.cgi?id=28898
Todd Mokros tmokros@tmokros.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tmokros@tmokros.net
http://bugs.winehq.org/show_bug.cgi?id=28898
Bob Igo bob@igo.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob@igo.name
http://bugs.winehq.org/show_bug.cgi?id=28898
Erik wine@erikdokter.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@erikdokter.nl
http://bugs.winehq.org/show_bug.cgi?id=28898
arthur.huillet@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.huillet@free.fr
http://bugs.winehq.org/show_bug.cgi?id=28898
Adam Bolte boltronics@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |boltronics@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #130 from Erich Hoover ehoover@mines.edu 2012-05-25 16:09:12 CDT --- New patch attempt: [1/4] http://source.winehq.org/patches/data/86603 [2/4] http://source.winehq.org/patches/data/86604 [3/4] http://source.winehq.org/patches/data/86605 [4/4] http://source.winehq.org/patches/data/86606
This new version is a result of a brief discussion with Alexandre about 86263 wrt. how the completions are stored and updated.
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #131 from Alexey Loukianov mooroon2@mail.ru 2012-05-25 16:38:41 CDT --- I can confirm that patchset from #130 applies cleanly to wine-1.5.5 source tree, compiles without additional errors and warnings and fixes the issue of Diablo III installer/launcher/updater stalling on attempt to download something. Nice work, Erich, I hope you would finally push this one into HEAD.
http://bugs.winehq.org/show_bug.cgi?id=28898
Sean Bogie spbogie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spbogie@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
John Schmitt marmalodak@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marmalodak@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
Kevin Lyles kevinlyles@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kevinlyles@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
Dennis Straffin dbstraffin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dbstraffin@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #132 from Erich Hoover ehoover@mines.edu 2012-06-06 19:56:07 CDT --- Part of the previous attempt has been revised and accepted, the remainder is available here: [1/2] http://source.winehq.org/patches/data/86896 [2/2] http://source.winehq.org/patches/data/86895
http://bugs.winehq.org/show_bug.cgi?id=28898
--- Comment #133 from Erich Hoover ehoover@mines.edu 2012-06-07 13:44:14 CDT --- (In reply to comment #132)
Part of the previous attempt has been revised and accepted, the remainder is available here: [1/2] http://source.winehq.org/patches/data/86896 [2/2] http://source.winehq.org/patches/data/86895
Wow, *does a little a dance*. This should now be resolved as of commit 7e9e8b6b800f7a0393b6a0d4b1a893d9ae78e262.
http://bugs.winehq.org/show_bug.cgi?id=28898
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |7e9e8b6b800f7a0393b6a0d4b1a | |893d9ae78e262 Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #134 from Jerome Leclanche adys.wh@gmail.com 2012-06-07 13:52:02 CDT --- Congrats and thanks! Marking fixed, reopen if it's not fixed after that commit.
http://bugs.winehq.org/show_bug.cgi?id=28898
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #135 from Alexandre Julliard julliard@winehq.org 2012-06-08 15:28:49 CDT --- Closing bugs fixed in 1.5.6.
http://bugs.winehq.org/show_bug.cgi?id=28898
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.4.x
http://bugs.winehq.org/show_bug.cgi?id=28898
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.4.x |---
https://bugs.winehq.org/show_bug.cgi?id=28898
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hunt.jonr@gmail.com
--- Comment #136 from Anastasius Focht focht@gmx.net --- *** Bug 31975 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=28898
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Component|-unknown |winsock
-
wine-bugs＠winehq.org