[Bug 28913] New: Wininet.dll violates DLL unloading requirements by calling Winsock functions from DLL_PROCESS_DETACH
http://bugs.winehq.org/show_bug.cgi?id=28913
Bug #: 28913 Summary: Wininet.dll violates DLL unloading requirements by calling Winsock functions from DLL_PROCESS_DETACH Product: Wine Version: 1.3.31 Platform: All OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: wininet AssignedTo: wine-bugs@winehq.org ReportedBy: aicommander@gmail.com Classification: Unclassified
Currently, Wininet has the following callchain in DllMain() handling DLL_PROCESS_DETACH: collect_connections() -> free_netconn() -> closesocket(). This is invalid because it calls into ws2_32.dll after it may have already received DLL_PROCESS_DETACH and freed instance variables (locks, lists, and things) it needs to handle API calls. This is in direct violation of MSDN's documentation regarding DllMain():
"Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized."
from: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).as...
I'm not sure the right way to go about fixing this one. I see why it's necessary to cleanup those connections but I don't where the right place is to do it. Any suggestions/fixes would be greatly appreciated.
http://bugs.winehq.org/show_bug.cgi?id=28913
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other OS/Version|All |other Severity|normal |enhancement
--- Comment #1 from Dmitry Timoshkov dmitry@baikal.ru 2011-10-28 00:25:08 CDT --- Do you have an application that misbehaves because of this, or is this a pure speculation?
http://bugs.winehq.org/show_bug.cgi?id=28913
--- Comment #2 from aicommander@gmail.com 2011-10-28 00:32:55 CDT --- (In reply to comment #1)
Do you have an application that misbehaves because of this, or is this a pure speculation?
It causes a deadlock on ReactOS because the DLL loader unloads msafd.dll which frees a critical section that protects the socket list. In the closesocket() call, it tries to enter the critical section again to remove the socket, but the critical section is invalid so it deadlocks. This causes any apps that use wininet.dll to deadlock on close (until the lock is forcibly broken after the critical section timeout elapses). I'm trying to avoid simply hacking around the issue, so a real fix gets created for both WINE and ReactOS. If you've got any ideas, I'd be happy to give it a shot and upstream it to you guys if it works.
http://bugs.winehq.org/show_bug.cgi?id=28913
--- Comment #3 from Cameron Gutman aicommander@gmail.com 2011-10-28 00:43:59 CDT --- My initial thought is we could possibly use HINTERNET that we get from InternetOpen. If we associate each of those connections to that, we could walk the connection list when that handle gets closed and kill the connections then. I'm not 100% sure why we retain these connections, so I may have this totally wrong, but it's a start.
http://bugs.winehq.org/show_bug.cgi?id=28913
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru 2011-10-28 01:01:39 CDT --- Sounds like you need to investigate and fix it on the ReactOS side.
Not a Wine bug.
http://bugs.winehq.org/show_bug.cgi?id=28913
--- Comment #5 from Cameron Gutman aicommander@gmail.com 2011-10-28 01:11:03 CDT --- (In reply to comment #4)
Sounds like you need to investigate and fix it on the ReactOS side.
Not a Wine bug.
This is certainly a Wine bug. The ReactOS loader is functioning within NT spec (try loading your wininet.dll on real NT), but bugs in Wine's wininet.dll are causing deadlocks. Even Microsoft's own documentation says that the current Wine wininet DllMain() code is wrong and can cause all sorts of mayhem depending on the way the loader decides to unload DLLs (a future Wine loader change could trigger this). DllMain should always be order-agnostic and in this case it is not. I'd like to help get this fixed for both projects, so I'd appreciate it if you could help me get in touch with the developer(s) in charge of wininet so we can properly fix this bug.
http://bugs.winehq.org/show_bug.cgi?id=28913
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2011-10-28 05:24:28 CDT --- There's no bug on Wine because it doesn't use ws2_32, closesocket is a straight system call. But if you find a clean way to do this differently it will certainly be considered.
http://bugs.winehq.org/show_bug.cgi?id=28913
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |nerv@dawncrow.de
--- Comment #7 from André H. nerv@dawncrow.de 2011-10-29 08:17:41 CDT --- closing invalid
-
wine-bugs＠winehq.org