http://bugs.winehq.org/show_bug.cgi?id=30532
Bug #: 30532 Summary: wininet:CommitUrlCacheEntryInternal entry already in cache Product: Wine Version: 1.5.2 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: wininet AssignedTo: wine-bugs@winehq.org ReportedBy: davide.monge@gmail.com Classification: Unclassified
Eve online ver: 7.40.366544 (365966)
Previous config: wine 1.5.2 - xubuntu 11.10 32bit -> perfection. Actual config: wine 1.5.2 - xubuntu 12.04 64bit -> critical/blocking.
Sadly no backtrace, dbg did not start.
The problem occur when a great number of object appears, like warping to Jita 4-4 station and the client have to load *many* object from the db - this occurs also if on 0.0 space the client hast to load *many* reds!!!. So, at this point, the client freeze and a dialog named:
"Wine program crash"
said:
"internal errors - invalid parameters received".
Only the xkill of the wine instance permit to restart the client.
**This is critical/blocking.**
Eve online, launched from a shell, report this:
fixme:dbghelp:EnumerateLoadedModulesW64 If this happens, bump the number in mod fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! wine: Unhandled page fault on read access to 0x57737c67 at address 0x1e0fee3e (thread 0030), starting debugger... Can't attach process 002f: error 5
At disposal for any test you suggest. I not agree to return back to 32bit environment to have the eve online environment running correctly :p
http://bugs.winehq.org/show_bug.cgi?id=30532
--- Comment #1 from davide.monge@gmail.com 2012-04-28 03:37:16 CDT --- Created attachment 39941 --> http://bugs.winehq.org/attachment.cgi?id=39941 shell-output-snippet.
http://bugs.winehq.org/show_bug.cgi?id=30532
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|wininet |-unknown Summary|wininet:CommitUrlCacheEntry |Eve online ver: 7.40.366544 |Internal entry already in |crashes |cache | Severity|critical |normal
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com 2012-04-28 03:42:58 CDT --- Please perform regression test http://wiki.winehq.org/RegressionTesting.
http://bugs.winehq.org/show_bug.cgi?id=30532
James Lewis james@fsck.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |james@fsck.co.uk
--- Comment #3 from James Lewis james@fsck.co.uk 2012-04-29 00:55:32 CDT --- I confirm exactly the same error/crash, with exactly the same error message:-
wine: Unhandled page fault on read access to 0x57737c67 at address 0x1e0fee3e (thread 003e), starting debugger...
I am also running on Ubuntu 12.04 64 bit, but I have also tested this with the 1.4 build shipped with the distro, and it is also present in this version. So, the trigger for this problem is a change in Eve Online, rather than Wine... It may not be a regression, but rather a change in the app which cannot be handled by the current version of Wine.
http://bugs.winehq.org/show_bug.cgi?id=30532
--- Comment #4 from James Lewis james@fsck.co.uk 2012-04-29 01:12:07 CDT --- https://forums.eveonline.com/default.aspx?g=posts&t=100279
CCP suggested that they are aware of this issue, caused by rendering T3 ship models... according to this thread, there may be a fix on the test server now to be released soon. Lets hope this is true.
It's also interesting the CCP is sensitive to issues in Wine, or possibly this issue also happens on Windows (I've often seen issues in the client which affect Windows by affect Wine much worse)... so perhaps Wine even helps CCP fix hard to replicate bugs.
http://bugs.winehq.org/show_bug.cgi?id=30532
--- Comment #5 from James Lewis james@fsck.co.uk 2012-04-29 01:25:41 CDT --- CCP Snorlax wrote: This seems to be an issue in how Python under Wine deals with file descriptors - opening a file with os.open and closing it with os.close causes this error.
The Python source code has a comment indicating that this is handled in a hacky way, using internal structures of the Microsoft CRT.
I'll see if I can achieve the same thing in a different way, but I don't have a way to test under Linux, nor should I technically be spending time on this, this being an unsupported platform and all. Still, I don't like seeing EVE crashing.
Hopefully this gives Wine developers a clue, nonetheless.
http://bugs.winehq.org/show_bug.cgi?id=30532
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |jacek@codeweavers.com, | |piotr@codeweavers.com Component|-unknown |msvcrt Ever Confirmed|0 |1
--- Comment #6 from Jacek Caban jacek@codeweavers.com 2012-04-29 02:02:46 CDT --- It's a known issue of our msvcr90.dll implementation, which forwards most of its work to msvcrt.dll. The problem is that internal, but exported, structs differ between them. That makes the bug tricky to fix without massive code duplication.
http://bugs.winehq.org/show_bug.cgi?id=30532
--- Comment #7 from James Lewis james@fsck.co.uk 2012-05-11 03:26:34 CDT --- CCP has released a new client in the normal patch cycle which changes the way this piece of code uses Python to access these cached ship models, and hence does not trigger this issue any more.
Obviously CCP do not support Wine "officially", but luckily there are developers there who are sympathetic to supporting Wine if it can be done without too much issue.
I guess this particular bug can/should be closed... but it does still leave this known incompatibility with Python, as well as the fact that Eve Online will not run with "native" MSCRT, which would presumably have avoided this issue anyway.
That last point is quite important, becuase the launcher/patch tool will not run with "builtin" MSCRT... so currently when there it a patch to apply... which is very often, one must quit the client, reconfigure Wine, reload the client, wait till it has applied the patch, quit again, reset to "builtin" and then restart the client again...
I'm not sure if this is something that is worthy of a separate bug, but it's worth noting anyway.
http://bugs.winehq.org/show_bug.cgi?id=30532
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |ABANDONED
--- Comment #8 from Austin English austinenglish@gmail.com 2012-05-11 12:24:53 CDT --- (In reply to comment #7)
CCP has released a new client in the normal patch cycle which changes the way this piece of code uses Python to access these cached ship models, and hence does not trigger this issue any more.
Abandoned then, since we can't test the old versions.
Obviously CCP do not support Wine "officially", but luckily there are developers there who are sympathetic to supporting Wine if it can be done without too much issue.
I guess this particular bug can/should be closed... but it does still leave this known incompatibility with Python, as well as the fact that Eve Online will not run with "native" MSCRT, which would presumably have avoided this issue anyway.
See bug 29764.
http://bugs.winehq.org/show_bug.cgi?id=30532
--- Comment #9 from davide.monge@gmail.com 2012-05-12 08:54:42 CDT --- I concur. CCP patches solved the problem. Thank you all for the prompt assistance.
http://bugs.winehq.org/show_bug.cgi?id=30532
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Frédéric Delanoy frederic.delanoy@gmail.com 2012-05-31 07:06:28 CDT --- Closing ABANDONED bugs
-
wine-bugs＠winehq.org