[Bug 20296] League of Legends: crash after eula

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=20296

Amos Wenger <amos at official.fm> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33948|0                           |1
        is obsolete|                            |

--- Comment #49 from Amos Wenger <amos at official.fm> 2011-04-09 19:57:27 CDT ---
Created an attachment (id=34018)
 --> (http://bugs.winehq.org/attachment.cgi?id=34018)
First try implementing dll surrogates in Wine

So here it is, after a few days of reading more than my fair share of DCOM
docs, wine sourcecode, hacking around to see how stuff works under the hood,
here's my first try at implementing dll surrogates in wine. Disclaimer: the
patch is big. 22K, 690 lines, It still depends on a Windows dllhost.exe (I used
the version from my Windows XP SP3 32-bit). FOR TESTING THIS PATCH, DLLHOST.EXE
NEEDS TO BE IN $WINEPREFIX/WINDOWS/SYSTEM32 (or anywhere in your %PATH%,
really, but that's where it belongs anyway). The reason I haven't provided a
dllhost.exe is because I'm not sure how to add a program to tools/ but it
should be really easy to code, afaik it just does CoInitializeEx, then parses
command-line arguments and goes CLSIDFromString, then calls
CoRegisterSurrogateEx and that's it. If CoRegisterSurrogateEx returns, it just
CoUnitializeEx and shuts down!

it probably needs a good cleanup and I can't guarantee it's 100% right -
especially I'm not entirely sure I'm using the right CLSCTX and REGCLS values
everywhere, but everything seems to go find on the local rpc server, generic
marshalling/unmarshalling works like a charm and functions are called remotely
correctly - there might be some apartment handling I haven't looked into yet,
but I think this is pretty much what we had in mind. Also, I'm not sure where
to draw the line between compobj.c and surrogate.c, sometimes I feel some of
compobj.c belongs in surrogate.c, but oh well I'm not sure. Feedback greatly
appreciated!

So here are my observations:

  - When run naively (wine lol.launcher.exe), it shows the patcher, sleeps till
I click "Play", then shows a dialog box telling me LolClient.exe has crashed,
sleeps till I close this dialog box, and *then* the login screen comes up, but
I can't login successfully (obviously it's LolClient.exe that's handling the
login and since it crashed well... it's not even trying to log in with the data
provided).
  - When run with a few debug options (WINEDEBUG=ole,+tid,+relay wine
lol.launcher.exe), it's slow as fuck, but... it works! LolClient.exe doesn't
crash, it displays the patcher then the login screen correctly, I can log in
and even start a game and it begins to load :) (I haven't tested the actual
gameplay because it was so slow and LoL complained about my graphic drivers..
nouveau actually).

So I've done some more investigation on the LolClient.exe crash, by running it
manually (something like winedbg air/LolClient.exe -runtime air
air/META-INF/AIR/application.xml air/) which obviously should fail since
Maestro is not running, but that's not the problem here - it seems to crash in:

Backtrace:
=>0 0x7c574eac ssleay_rand_add+0x30c() in libcrypto.so.1.0.0 (0x0f65c0bc)
  1 0x00956d01 (0xafd17daf)

So now I'm really puzzled, it seems my patch solves the same issue as
attachment #25672, except it does it correctly, because it starts a separate
process to load the dll in, and does everything by rpc after that, so...
problem solved. Now why does the rest crash? Apparently people had the whole
client working only with ole-force-inproc-[...] but I don't. I'd appreciate if
other people could test it, especially on 32-bit distros, I think it might be
the culprit.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.