Created attachment 42138 [details]
Lord of the ring online crashes after 15Oct update (Rider of Rohan). Game launched using PyLOTRO

Comment on attachment 42138 [details]
Lord of the ring online crashes after 15Oct update (Rider of Rohan). Game launched using PyLOTRO

I confirm the issue appeared after the latest update (15 octover, Rider of Rohan). Game launched using PyLOTRO.

I attached my backtrack which seem to be virutally identical although I am running different version of wine and kernel. I am running Kubuntu 12.10 with all updates.

Happens in wine-1.4.1, too, so setting version.

Can you provide a console log?

I can confirm this problem on Gentoo 64bit kernel 3.5.3, wine 1.5.15. Game was running in the same wine prefix, the very same day just before the update. My backtrace is almost identical exept the system information.

Same issue, same backtrace.  
Ubuntu 12.04.1 LTS
kernel 3.2.0-32-generic
Wine version 1.5.14

Was working fine until today's LOTRO update.

Created attachment 42139 [details]
backtrace

Please provide a console log.
http://wiki.winehq.org/FAQ#get_log

Created attachment 42140 [details]
console log

Not enough to go on there - might need someone comfortable with +relay to
have a look.

Not familiar with +relay but willing to try.  I assume this means giving you some access for data collection/review.

export WINEDEBUG=+relay and then lunch the game. I will attach my console output with +relay in just a second

The LOTRO Riders of Rohan client has crashed all through all versions of the Beta. Including the last version 6.1

I have been working with Codeweavers Crossover version of WINE 1.4 throughout the Beta (i.e. since July of 2012).

Result has always been the same.

Note that during the beta it was ascertained that the LOTRO Client is a 32bit client addressing MORE than 4GB of memory.

Turbine also was testing a Mac Client, which exhibited the same symptoms - it is a 32 bit client and crashes to the desktop attempting to address greater than 3.7GB of memory.
Release of the Mac Client has been delayed because of this. (Crash to desktop with a MTBF of about 90 minutes max.)

It is also known that there have been significant changes to the Game Client to implement various new technologies for this release. Which is to say, Update 8 is NOT a simple client patch, but a major one.

WINEDEBUG=+relay makes the console output file to big to upload it here. I compressed it and uploaded to my web server. You can can downlod it here:
http://www.kardasa.pl/downloads/lotro_linux.txt.tar.gz

Created attachment 42143 [details]
ran +relay, last 500 lines here

I also ran with +relay but the attachment is 56MB in size.  I tailed off the last 500 lines here in case they are useful.

(In reply to comment #12)
> The LOTRO Riders of Rohan client has crashed all through all versions of the
> Beta. Including the last version 6.1
> 
> I have been working with Codeweavers Crossover version of WINE 1.4 throughout
> the Beta (i.e. since July of 2012).
> 
> Result has always been the same.
> 
> Note that during the beta it was ascertained that the LOTRO Client is a 32bit
> client addressing MORE than 4GB of memory.
> 
> Turbine also was testing a Mac Client, which exhibited the same symptoms - it
> is a 32 bit client and crashes to the desktop attempting to address greater
> than 3.7GB of memory.
> Release of the Mac Client has been delayed because of this. (Crash to desktop
> with a MTBF of about 90 minutes max.)
> 
> It is also known that there have been significant changes to the Game Client to
> implement various new technologies for this release. Which is to say, Update 8
> is NOT a simple client patch, but a major one.

I should add: Crossover version 11.2.2 running on OSX Mountain Lion 10.8.2

I suspect we need a wine developer to have a look directly with +relay,+seh.
Attaching logs might not be all that helpful.

(In reply to comment #13)
> WINEDEBUG=+relay makes the console output file to big to upload it here. I
> compressed it and uploaded to my web server. You can can downlod it here:
> http://www.kardasa.pl/downloads/lotro_linux.txt.tar.gz

What is the partition type of Z:/storage/wine/gry/tools/PyLotRO ? If fat/ntfs/network try again in a native partition. Possibly that's not the problem but helps eliminating this question.

Wow! what a busy bug!

So I have some time right now so I'll debug it, but I'm having some problems with
winedbg at the moment moment, so I'll have to troubleshoot that first. 
Building current git wine first as well and then going to try this patch submitted on the appdb page:

--- wine-1.5.10.orig/dlls/user32/winpos.c       2012-07-31 21:08:12.000000000 +0200
+++ wine-1.5.10/dlls/user32/winpos.c    2012-09-01 14:43:47.000000000 +0200
@@ -251,8 +251,7 @@ BOOL WINAPI ClientToScreen( HWND hwnd, L
  */
 BOOL WINAPI ScreenToClient( HWND hwnd, LPPOINT lppnt )
 {
-    MapWindowPoints( 0, hwnd, lppnt, 1 );
-    return TRUE;
+    return MapWindowPoints( 0, hwnd, lppnt, 1 ) != 0;
 }

(In reply to comment #12)
Wiliam, thanks for all of this info.  Of course, it may or may not be the cause of this *particular* crash, but it is very helpful! 

> Release of the Mac Client has been delayed because of this. (Crash to desktop
> with a MTBF of about 90 minutes max.)

Note that this crash is happening immediately.

> It is also known that there have been significant changes to the Game Client to
> implement various new technologies for this release. Which is to say, Update 8
> is NOT a simple client patch, but a major one.

So is this being called Update 8?  Trying to manage this in appdb is a real pain, since we have such non-standard versions, like "Volume III, Book 2" then "Update 7", which as I understand, didn't add any new "books".  Then the version info of the client executable, currently containing the following entries:

CompatibiltyVersion 7479
FileVersion         03.08.00.8026
TurbineBuildVersion 03.08.00.8026.RELEASE
ProductVersion      03.08.00.8026 u08
TurbineFriendlyName u08

Well, amazingly enough, building from git with this patch fixes the problem.  I haven't yet tested latest git without the patch however, so I'll do that and post the result.

> What is the partition type of Z:/storage/wine/gry/tools/PyLotRO ? If
> fat/ntfs/network try again in a native partition. Possibly that's not the
> problem but helps eliminating this question.

I do not have any Windows, my games are lunched from ext4 partition

Created attachment 42144 [details]
patch to fix problem

OK, I can confirm that this patch indeed fixes it.  We need to figure out who the credit goes to however. It was originally posted by the user HuSSaR on appdb.

If I don't have a development environment setup how do I get the patch into my binaries?

Created attachment 42145 [details]
winedbg session showing (parts of) the problem

This was my first winedbg session, so take it easy on me, please.

As per the attachment, analyzed this a bit with winedbg.
Looking at the patch posted, this looks like the culprit and solution.

What I _think_ might be happening is that the new Rohan client calls this function much earlier than before (if it was called before, at all), when the initialization isn't properly finished.

(In reply to comment #19)
> (In reply to comment #12)
> Wiliam, thanks for all of this info.  Of course, it may or may not be the cause
> of this *particular* crash, but it is very helpful! 
> 
> > Release of the Mac Client has been delayed because of this. (Crash to desktop
> > with a MTBF of about 90 minutes max.)
> 
> Note that this crash is happening immediately.
> 
> > It is also known that there have been significant changes to the Game Client to
> > implement various new technologies for this release. Which is to say, Update 8
> > is NOT a simple client patch, but a major one.
> 
> So is this being called Update 8?  Trying to manage this in appdb is a real
> pain, since we have such non-standard versions, like "Volume III, Book 2" then
> "Update 7", which as I understand, didn't add any new "books".  Then the
> version info of the client executable, currently containing the following
> entries:
> 
> CompatibiltyVersion 7479
> FileVersion         03.08.00.8026
> TurbineBuildVersion 03.08.00.8026.RELEASE
> ProductVersion      03.08.00.8026 u08
> TurbineFriendlyName u08

Turbine began using "Update x.x.x" terminology following the Free to Play
release... I think because THEY couldn't keep track.

So, this one is "officially" called: "Update 8, Riders of Rohan" in the title
of the release notes.

asking again:  If I don't have a development environment setup how do I get the patch into my binaries? I forced an update from 1.5.14 to 1.5.15 but that's as far as I got.  Problem still exists.

(In reply to comment #27)
> asking again:  If I don't have a development environment setup how do I get the
> patch into my binaries? I forced an update from 1.5.14 to 1.5.15 but that's as
> far as I got.  Problem still exists.

First off wireloose, this isn't a support forum, it's a bug tracking database.  You simply cannot use this patch without setting up a development environment.  Why don't you go post on the appdb page and specify which distro (and version) you are running and see if anybody will build one for you.  It would be good to have in the interrum, until this patch is merged & released.  Alternately, I posted a few links at the top of the appdb page on how to build wine.

I don't know if it's possible to build a static libwine, since it pulls in so many other libraries, and they would each have to be built statically as well.

Thanks the answer.

OK, confirming the patch works for me as well. Against wine-1.5.15 from git earlier.

Sadly, this patch was posted to the "bullroarer beta" forum, I guessing for participants in the beta testing, and that forum has reportedly been wiped, so I'm having trouble finding who to credit this patch to, but it's a very good find!

I also confirm patched GIT does work. Didn't test anything in-game. 

For those asking, I compiled from git without trouble, it's not hard. 
It's outside the scope of a bug report though. I'll still post how I did it...

1. I used ubuntu 12.04 32bit. To get the dependency:

# sudo apt-get build-dep wine1.4
# sudo apt-get install wine

2. Dowload source code from git (info here: http://wiki.winehq.org/GitWine)

# git clone git://source.winehq.org/git/wine.git ~/wine-git

3. Apply the patch (did it manually it's only 2lines). See attachment above (patch to fix problem)

4. Compile in the usual way ( "./configure ; make depend ; make" )

# ./configure
# make depend
# make

5. Install with "sudo make install" or simply run from directory (wine executable in git directory)

(optional) # sudo make install

6. Set path to the new executable in PyLOTRO if needed.

This patch solved the problem for me also. I patched by editing original wine ebuild from portage tree. One line with epatch, reemarge and wine is lunching the game w/o any problem. 
The person who created it deserves a beer or a hug what ever he or she prefers.

(In reply to comment #22)
> Created attachment 42144 [details]
> patch to fix problem

Why are you assuming that MapWindowPoints() returning zero is always an error?

Created attachment 42168 [details]
revised patch

Yes, you are correct. Mia cupla.

MSDN says that they are idiots and that Gates has a small **nis.  We already knew that part, but they also say to use SetLastError prior to calling MapWindowPoints to distinguish an error from a valid zero offset.  This sounds really stupid to me, since the damn thing should just always set an error or clear the condition IMO.

But I suppose we can play that game.  I'm going by the assumption that can be called while we have an error that hasn't been checked yet, since it is not supposed to alter the last error its self.

Since I'm short on time, please note that this patch has *not* been tested yet.  However, I will test it when I return later this evening.

Created attachment 42169 [details]
correct patch

Well I guess that's what I get for being in a hurry, I attached the wrong patch, sorry about that.  This is the revised patch, still not tested yet, but I think I need to do some more tests on my laptop (where I can dual-boot windows) and verify the behavior.

Surely, a test case would help to have this patch accepted by Alexandre.

(In reply to comment #32)
> I also confirm patched GIT does work. Didn't test anything in-game. 
> 
> For those asking, I compiled from git without trouble, it's not hard. 
> It's outside the scope of a bug report though. I'll still post how I did it...
> 
> 1. I used ubuntu 12.04 32bit. To get the dependency:
> 
> # sudo apt-get build-dep wine1.4
> # sudo apt-get install wine
> 
> 2. Dowload source code from git (info here: http://wiki.winehq.org/GitWine)
> 
> # git clone git://source.winehq.org/git/wine.git ~/wine-git
> 
> 3. Apply the patch (did it manually it's only 2lines). See attachment above
> (patch to fix problem)
> 
> 4. Compile in the usual way ( "./configure ; make depend ; make" )
> 
> # ./configure
> # make depend
> # make
> 
> 5. Install with "sudo make install" or simply run from directory (wine
> executable in git directory)
> 
> (optional) # sudo make install
> 
> 6. Set path to the new executable in PyLOTRO if needed.

local1907@kubuntu:/var/chroot/wine$ ls
aclocal.m4  config.log    COPYING.LIB    fonts    LICENSE.OLD  Makefile.in        Make.vars.in  README  VERSION
ANNOUNCE    configure     dlls           include  libs         Make.rules.in      po            server
AUTHORS     configure.ac  documentation  LICENSE  loader       Maketest.rules.in  programs      tools
local1907@kubuntu:/var/chroot/wine$ make depend
make: *** Hedef `depend' i derlemek için  hiçbir kural yok. Durdu.
local1907@kubuntu:/var/chroot/wine$

Read the step 4 again:
> 4. Compile in the usual way ( "./configure ; make depend ; make" )

Oh, just to validate the *need* for giving a correct return value and checking for things like being passed a null handle, here's the snippet from a +relay log:

  8.385:0009:Call user32.ScreenToClient(00000000,0033fd68) ret=006d4d87

So yes, they really do call it with a null handle.

Created attachment 42179 [details]
basic tests for ScreenToClient

So here's the test code.  I haven't run it on windows yet because I'm having a heck of a time getting wine correctly configured on my windows machine and each attempt (configure && make depend) takes about an hour :(

(In reply to comment #41)
> Created attachment 42179 [details]
> basic tests for ScreenToClient
> 
> So here's the test code.  I haven't run it on windows yet because I'm having a
> heck of a time getting wine correctly configured on my windows machine and each
> attempt (configure && make depend) takes about an hour :(

You should talk to Christian Costa, he's been working on tests too. He sent a patch recently (http://source.winehq.org/patches/data/91034) and there is a discussion about it (http://www.mail-archive.com/wine-devel@winehq.org/msg76697.html).

Created attachment 42269 [details]
wine 1.5.16

Same behaviour here in Dungeon & Dragons Online (based on LOTRO) last patch. See post here http://forums.ddo.com/showthread.php?t=397951

Fixed in latest git.

(In reply to comment #45)
> Fixed in latest git.

You mean this patch?
http://source.winehq.org/git/wine.git/commitdiff/5dea6543170fd12928cf2196b55fec9c2fe82c75

It's rather this one http://source.winehq.org/git/wine.git/?a=commit;h=7fc61f6fea27d207706f896dbf47285516ebe760.

(In reply to comment #47)
> It's rather this one
> http://source.winehq.org/git/wine.git/?a=commit;h=7fc61f6fea27d207706f896dbf47285516ebe760.

Fixed.

Closing bugs fixed in 1 5.18.