I spoke with him on IRC and the SC2 hacks don't seem to work. Hopefully a finished SC2 patch fixes this issue as well but Blizzard might have added some more unsupported protections, so I'm keeping this bug open.

Don't panic yet.

While there were issues with 3.3.5 PTR (and claims of wldap32.dll native fixing the problem -- see http://forum.winehq.org/viewtopic.php?t=8688 , http://www.wowwiki.com/Wine_troubleshooting#Post-3.3.5_login_issues and its link), I don't think we're running into exactly that yet.

Maintenance is still ongoing, and while before using native wldap32.dll at least got the game to hard crash for me, now it has 0 impact.  I think this is just server maintenance -- though it is likely there'll be a bug to fix once that's done.  See http://forums.worldofwarcraft.com/thread.html?topicId=25552425015 .

Wait until tomorrow, in other words :)

Partial nevermind -- updated to 3.3.5 via an online mirror, now I get a hard crash with or without native wldap32.dll.

Will provide backtrace if you want (and specify how you want it done).

If you have a backtrace, add it to here as an attachment.

I can confirm this. I try the native dll method but the game still crashes at login attempt.

What a sad day for wow linux users.

Created attachment 29076 [details]
Terminal output

Confirmed on Gentoo 64 bit -> Wine 1.2_rc3
I haven't tried the wldap32.dll hack yet but based on other comments I'll just wait till tomorrow to see what happens here.  I do show my realm is online at this point and feel maintenance probably isn't the issue.

I'm gonna clean out some space and I'll make a trace should any devs need to request it.

Dupe of bug 21809

(In reply to comment #5)
> What a sad day for wow linux users.

(In reply to comment #1)
> I spoke with him on IRC and the SC2 hacks don't seem to work. Hopefully a
> finished SC2 patch fixes this issue as well but Blizzard might have added some
> more unsupported protections, so I'm keeping this bug open.

Technically, the SC2 hacks don't work anymore either, the patch needs to be updated. (Although, for me at least, they do work for WoW...)

(In reply to comment #5)
> What a sad day for wow linux users.

Please keep your cool. Wine is in code freeze currently, and I talked with a couple of distro maintainers in order to get them to include henri's hack for wine-1.2 shipping. But yeah, for a couple of weeks, it's compiling will be necessary.

(Triple post, sorry for spam.)

Seeing the same thing here, Wine 1.2 rc3.  Tested with a Fedora 13 x64 machine and a Fedora 13 x32 machine...same result.

I'm compiling RC4 now, I'll test when it's done and post back.

-Jase

(In reply to comment #12)
> Seeing the same thing here, Wine 1.2 rc3.  Tested with a Fedora 13 x64 machine
> and a Fedora 13 x32 machine...same result.
> 
> I'm compiling RC4 now, I'll test when it's done and post back.
> 
> -Jase

I just commented over on the SC2 thread (http://bugs.winehq.org/show_bug.cgi?id=21809), I just tested 1.2-rc4 with the SC2 patch from that thread and no dice for me (Fedora 13 x86_64).  Interested to hear if your results are any different.

> wine --version 
wine-1.2-rc4-70-g802c4de
> uname -a
Linux rage 2.6.33.5-112.fc13.x86_64 #1 SMP Thu May 27 02:28:31 UTC 2010 x86_64
x86_64 x86_64 GNU/Linux

(In reply to comment #11)
> (In reply to comment #5)
> > What a sad day for wow linux users.
> 
> Please keep your cool. Wine is in code freeze currently, and I talked with a
> couple of distro maintainers in order to get them to include henri's hack for
> wine-1.2 shipping. But yeah, for a couple of weeks, it's compiling will be
> necessary.
> 
> (Triple post, sorry for spam.)

While it's true that wine is currently broken for this particular game, it's also noteworthy that this patch is what you described (a hack) and there's a reason it's not been accepted.  It changes the order of operations in DLL initialization and this could easily break a lot of other applications.

It would not be a good idea to have distros shipping a patch that hasn't been regression tested as part of wine releases and misleading people into thinking apps that have been working fine were broken in 1.2 when in reality it was a workaround for WoW that broke them.

http://www.winehq.org/pipermail/wine-devel/2010-March/082358.html

(In reply to comment #11)
> Please keep your cool. Wine is in code freeze currently, and I talked with a
> couple of distro maintainers in order to get them to include henri's hack for
> wine-1.2 shipping. But yeah, for a couple of weeks, it's compiling will be
> necessary.
> 
As others have already mentioned, there's a good reason that patch isn't in the tree, and including it in a distribution package would be a mistake.

I have been unable to duplicate this bug on either 1.1.38 or 1.2_r4. WoW currently runs just fine on both without the need of winetricks or importing DLLs. Cedega, however, seems to be suffering from the same issue you guys are here.

Distribution: Gentoo AMD64
Kernel: 2.6.32-gentoo-r7

USE Flags: X alsa cups dbus gecko jpeg ncurses opengl perl png pulseaudio% ssl threads truetype xcomposite xinerama gsm xml

GCC Version: 4.3.4

(In reply to comment #16)
> I have been unable to duplicate this bug on either 1.1.38 or 1.2_r4. WoW
> currently runs just fine on both without the need of winetricks or importing
> DLLs. 

Would you mind attaching a copy of your emerge --info?

Created attachment 29079 [details]
emerge --info

As requested.

Created attachment 29080 [details]
Terminal output, native DLLs, debugging symbols

I had msvcr80.dll and msvcr90.dll from Winetricks in order to get past a bug since 3.3 where WoW wanted the former DLL, so I tried using winecfg overrides to make those native (since you said you did not use winetricks at all), and still got the crash.  Here's the terminal output with debugging symbols unstripped.

I get the crash while in OpenGL mode, but not in Direct3D mode. Hope this helps.

(Too bad performance in Direct3D mode sucks)

Tested in Direct3D mode, I still get a crash (but I do get a "Connecting..." window first).
Tried with the latest SC2 patch, again still a crash.

Yes the first time I tried with Direct3D I was stuck at "Connecting..." too. After exiting and cleaning the Cache folder, I tried again and connected.

Out of curiosity, is there anyone using the United States servers for who this is working? I have the sneaking suspicion every "works" report is coming from Europe, where Blizzard's new "Real ID" feature has not gone live yet.

The European 3.3.5 patch isn't out yet, so as long as everyone who has posted has 3.3.5 displated in the lower-left corner of WoW's startup screen :)

Thanks woeful, but removing the Cache directory doesn't change anything for me.

(In reply to comment #24)
> Out of curiosity, is there anyone using the United States servers for who this
> is working? I have the sneaking suspicion every "works" report is coming from
> Europe, where Blizzard's new "Real ID" feature has not gone live yet.

Heh... Yes, I'm from the US.

(In reply to comment #26)
> (In reply to comment #24)
> > Out of curiosity, is there anyone using the United States servers for who this
> > is working? I have the sneaking suspicion every "works" report is coming from
> > Europe, where Blizzard's new "Real ID" feature has not gone live yet.
> 
> Heh... Yes, I'm from the US.

Hm. I'm using Gentoo's ~amd64 keyword instead of the stable tree, and it definitely is not working for me. the SC2 patch/hack notwithstanding. Do you have anything special set in your wine config, Rhaest? Maybe I'll just go back, un-keyword testing, and see what happens...

(In reply to comment #27)

> Hm. I'm using Gentoo's ~amd64 keyword instead of the stable tree, and it
> definitely is not working for me. the SC2 patch/hack notwithstanding. Do you
> have anything special set in your wine config, Rhaest? Maybe I'll just go back,
> un-keyword testing, and see what happens...

I'm also ~amd64 and have tried 1.2rc2, rc3 and rc4 with no success. Compiled using the same use flags as Rhael.  Same GCC version as well and our emerge infos are very similar.  I also tried an older version of Crossover games and it doesn't crash but I get a "failed to login" error message instead.

I'll probably try the GIT version with and without the SC2 patch when I get back home.

For Mark and the other Fedora users, rc4 didn't change anything on either test
machine.

opengl vs. directx doesn't make a diff, and I wouldn't think it would because
the app runs fine under both, but crashes during a network communication
operation.  My experience has been GL vs. Directx crashes happen 9 times out of
10 at app start up.

So, I'm thinking that, with where the crashing is happening, and the changes
with realID and what not, could we have a network implementation deficiency in
Wine here?  Would it be worth trying some native core networking libraries
(e.g. winsock)?  Seems like WoW may be now using an operation currently missing
from Wine's network implementation. Also, if anyone knows, does realID involve
wow making an additional connection to a server that it previously did not make
or is this a back-end deal?

One more thing I just tested

I'm using the BattleNet Authenticator and instead of putting in a valid code I just put in my password and "123456" and it still crashed.   Are those in the US that have this working also using an authenticator?

(In reply to comment #30)
> One more thing I just tested
> 
> I'm using the BattleNet Authenticator and instead of putting in a valid code I
> just put in my password and "123456" and it still crashed.   Are those in the
> US that have this working also using an authenticator?

Yes. And the issue arises when the server tries to authenticate. You can put in completely false information and it will still crash.

Using a native wldap32 fixes the issue for me.
Placed a native version of wldap32 in the WoW folder, added an override in winecfg for wldap32 and set it to native only.  Logged in with no problems after.

uname -a:
Linux 2.6.32-gentoo-r7 #1 SMP Mon May 31 13:00:48 CDT 2010 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux

wine --version:
wine-1.1.43

emerge -pv wine:
app-emulation/wine-1.1.44 [1.1.43] USE="X alsa dbus gecko jpeg ncurses opengl oss perl png ssl threads truetype xml (-capi) -cups -custom-cflags (-esd) -fontconfig -gnutls (-gphoto2) -gsm (-hal) -jack -lcms -ldap (-mp3) -nas -openal -pulseaudio -samba (-scanner) -test -win64 -xcomposite -xinerama"

Updating to wine-1.1.44 now, will report back if it somehow breaks again.

I downgraded my kernel version down to 2.6.29.6 with default settings (Im running Slackware 13.1, used config options from Slackware 13.0 to compile)

and now I can login.

Might be worth trying for some of you

It seems to work on older kernels.


First machine Fedora 13 (2.6.33.5-124 kernel) It doesn't seem to mater if I use wine from the repo or build it from git. Wow is broken!

Second machine OpenSuse 11.2 (2.6.31 kernel) with repo provided wine. Wow works just fine. 

Third machine Fedora 12 (2.6.32.11-99 kernel) with repo provided wine. Wow Works fine.

I have also noticed Ubuntu and OpenSuse people are not complaining. It seems to be people that would be using newer kernels. Is this a kernel bug or a bug with wine talking to newer kernels?

I can confirm, downgrading my kernel from gentoo-sources-2.6.34 to gentoo-sources-2.6.32-r7 definitely resolved the issue.  I didn't try any flavor of 2.6.33 yet.

I too am having issues with this (posts following will include attachments from emerge --info as well as wine debugging information).  I've tried the various solutions proposed (everything from downgrading wine and using native wldap32 dlls to different variants of vcrun2005's dlls as well as stock wine.

All methods fail from 1.1.43 to 1.2_rc4 (I didn't test all known available versions, just the range listed as it would have otherwise taken me days).

Distribution: Gentoo
Platform: (x86_64) amd64

Compile time options: -O2 -march=barcelona -mtune=barcelona
(This is for the AMD Quad-core Opteron Family)

$ uname -a
Linux unimatrix-01 2.6.34-gentoo #2 SMP PREEMPT Wed May 19 12:27:02 PDT 2010 x86_64 Quad-Core AMD Opteron(tm) Processor 2378 AuthenticAMD GNU/Linux

$ gcc --version
gcc (Gentoo 4.3.4 p1.1, pie-10.1.5) 4.3.4
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Next posts to follow will include generally requested attachments.

Created attachment 29094 [details]
emerge --info

Created attachment 29095 [details]
wine debug information

Confirmed:
Wine-1.2rc4 + SC2 patch* + 2.6.32.15 Vanilla == Working WoW 3.3.5 for me.
*probably unnecessary given previous comments

However, on .34, nothing, including virtually every combination of 1.2rc4 through 1.1.43 + the SC2 patch would work.

I'm using kernel 2.6.34, so you could be on to something.
I wonder if we can get this down to a specific kernel commit... very odd.

I suspect there is something to the kernel.  Out of sheer luck, I hadn't deleted my 2.6.32 gentoo kernel.  

# uname -a
Linux unimatrix-01 2.6.32-gentoo-r1 #2 SMP PREEMPT Wed Jan 6 01:22:07 PST 2010 x86_64 Quad-Core AMD Opteron(tm) Processor 2378 AuthenticAMD GNU/Linux

This works post patch 3.3.5.  However, what worries me is that this might be a low level call Wine isn't expecting to occur and that's the reason we're getting the error messages and crashes regardless of wine version.  I haven't updated my kernel since May 19th (a month and 4 days ago) and hadn't had an issue until this patch.

Haven't tested extensively but I'll also confirm that I was able to login and
move around with

gentoo-sources-2.6.32-r1
Wine 1.1.43

I never turned off wldap from before so I'm going to give that a try after I
load one of the later releases of wine. :D

I will update later with a status.

(In reply to comment #42)
> Haven't tested extensively but I'll also confirm that I was able to login and
> move around with
> 
> gentoo-sources-2.6.32-r1
> Wine 1.1.43

I am at the same kernel level. I found that wine 1.1.44 crashed just the same as on the newer kernel. It seems 1.1.43 is the only stable one at the moment.

It sounds like a change was introduced in the 1.1.44 set but not present during regression testing and thus wasn't visible until the 3.3.5 patch came out.

Perhaps you can git bisect and find the patch that screwed it up?
That might also provide clues to why the kernel version being different is causing problems, too.

(In reply to comment #44)
> Perhaps you can git bisect and find the patch that screwed it up?

I don't know enough to find the problem, but hopefully this information points to it.

wine 1.1.44 (1.1.43 is fine) and later versions don't appear to work on kernels later than 2.6.32 (2.6.32 is fine) with WoW 3.3.5.

All you need is time :)
It's just testing between each individual patch between those two Wine versions to find the exact patch that broke.

There's a fantastic walkthrough here, if you can help: http://wiki.winehq.org/RegressionTesting

(In reply to comment #46)
> All you need is time :)

I don't have that in abundance.  We've provided the information and I'll leave it to the right people to determine what caused it and what the fix is. ;-)

Alright ;)

If I get some time later tonight and manage to get an old kernel working (what's the newest kernel that has been found to work? 2.6.32 series? Should 2.6.32.15 work?) then I'll git bisect myself, at least on Wine.  Who knows, I might not be able to get it to work at all... heh.

(In reply to comment #43)
> (In reply to comment #42)
> > Haven't tested extensively but I'll also confirm that I was able to login and
> > move around with
> > 
> > gentoo-sources-2.6.32-r1
> > Wine 1.1.43
> 
> I am at the same kernel level. I found that wine 1.1.44 crashed just the same
> as on the newer kernel. It seems 1.1.43 is the only stable one at the moment.
> 
> It sounds like a change was introduced in the 1.1.44 set but not present during
> regression testing and thus wasn't visible until the 3.3.5 patch came out.

wine-1.2-rc4-119-g410f8e9 + sc2 "hack" 
kernel-2.6.32-gentoo-r11 with
lspci (for completeness)
     02:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

The above work fine for me. I'm not sure that there is just a wine bug or just
a kernel bug, feels like wine is exercising some part of the networking stack
that it broken or changed in later kernels. I wonder what it is. If i get time
i'll look in dmesg and see if I'm getting anything odd back. 

I expect that 1.2_rc4 (without the "SC2 hack") will work fine, but do not have
the time to test to night or tomorrow.

 Your comment was:

    J and Devin,

    I'll help as time allows.  I'll start troubleshooting from 2.6.32-r1 and
    1.1.43.  It'll take me some reading on the bisect stuff but if it works like
    I'm guessing, by getting a delta of changed files and committing each change
    one at a time to my local branch, then you're right about it literally being
    just a matter of time. :D

    FWIW I tried compiling from git earlier today with the SC2 patch and it broke
    somewhere.

    For tonight though, I need to run my dailies, lol...

>wine 1.1.44 (1.1.43 is fine) and later versions don't appear to work on kernels
>later than 2.6.32 (2.6.32 is fine) with WoW 3.3.5.

I compiled an earlier version of wine (1.1.20 in this case) with no "SC2 hack"
I chose at random to test, seeing the same thing on Fedora 13 32bit. 

Going to roll out Fedora 12 and compile 1.2 rc 4 and see what happens.

-Jase

I did, at one point, get *ONE* successful login on my 2.6.34 kernel with wine 1.2_rc4.  I could not replicate the circumstances, and part of me wonders if I even hallucinated it.  Be that as it may, though, when I was trying to reproduce the success, I noticed that even though I did not get any anomalous entries in dmesg or anywhere in /var/log, running netstat -tap would hang for a good 15 seconds right after WoW crashed, up until the TIME_WAIT on WoW's connections expired and the kernel closed them out.

I tested with some kernels on Debian sid with wine 1.1.42~winehq1
I used a clean .wine

2.6.34 - crash
2.6.33.4 - crash
2.6.32.15 - works

So it is looking like something that went in with 2.6.33

Later versions of Wine with 2.6.32.15 work or do not?

Thanks very much for your info :)

*** Bug 23344 has been marked as a duplicate of this bug. ***

I got fedora 13 working by building kernel-2.6.32.12-115.fc13.i686.rpm from the
fedora 12 kernel-2.6.32.12-115.fc12.src.rpm

wine --version = wine-1.2-rc4-119-g410f8e9 (Vanilla)

Tested Wine 1.0.1 on Centos 5.5 (from the EPEL repo) works well.  

Totally on board with a kernel issue here.

(In reply to comment #57)
> Tested Wine 1.0.1 on Centos 5.5 (from the EPEL repo) works well.  
> 
> Totally on board with a kernel issue here.

Forgot to mention the kernel version:

2.6.18-194.3.1.el5

So I believe we've isolated this to a kernel bug between 2.6.32.x and 2.6.33?
Though I suppose it could be a problem with Wine that's exposing it?

Time to find the breaking commit, I guess.  Git bisecting the kernel won't be too fun though, I imagine xD

I have it working with 2.6.32.15 (and it failed on 2.6.33) so you can safely guess the change (or combination of changes) is in the diff between 2.6.32.15 and 2.6.33

There was mention of the network being affected, maybe start with those commits ?

Confrmed workaround, switching to kernel 2.6.32.15 also fixes the problem for me.

I'm messing with a git bisect now, but don't let that stop any of you from doing your own -- this'll likely take a while, and I have other stuff to attend to as well :)

Also confirming 2.6.32.15 does not crash (given that vcrun2005 is installed). This certainly explains why some report everything working fine without any changes.

I've managed to login in with 2.6.34 a couple of times so it is possible but appears to be an extremely low chance of success. Scheduler having timing issues perhaps?

The linux patch you're looking for may be http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=blobdiff;f=kernel/signal.c;h=5bb9baffa4f121c732b05ab568e37484a02a537c;hp=934ae5e687b960ddf78c939db4b0e55936799243;hb=a27341cd5fcb7cf2d2d4726e9f324009f7162c00;hpb=eaa5eec739637f32f8733d528ff0b94fd62b1214, which was related to wine bug 20380, and is in linux 2.6.34.

I can confirm that downgrading wine to 1.1.43 and my kernel to 2.6.32 allows me to log into and do quests in wow. The workaround seems to work for now.

Austin, that's the commit.

Reverting it with `patch -Np1 -R`, using kernel v2.6.34 and Wine v1.2-rc4, gives me a completely perfect login.

So, where to from that? :)

...ignore that, I think.
I'm pretty confused now, WoW is still bugging up.

Trying to find out what the heck is going on.

Nope, doesn't work.
(In reply to comment #65)
> Austin, that's the commit.
> 
> Reverting it with `patch -Np1 -R`, using kernel v2.6.34 and Wine v1.2-rc4,
> gives me a completely perfect login.
> 
> So, where to from that? :)

Yeah... I think I ran into what the other people were talking about (randomly working once).


2.6.32.15 still reliably works, but that commit isn't the bad one.
Git bisect still needed.

I can reproduce this crash on FreeBSD:

FreeBSD xxx 8.1-STABLE FreeBSD 8.1-STABLE #0 r209090+409f0da: Sun Jun 13 23:13:20 CDT 2010     xxx:/compile/obj/compile/src/sys/XXX  amd64

With both wine-1.1.37 and wine-1.2-rc2, so I'm not sure it's necessarily a Linux kernel problem.

Reverted to kernel 2.6.32.1 and it works fine now on RC-4.

As Gentoo doesn't yet provide wine-1.2_rc4, I created my own overlay and ebuild to use the SC2 patch plus that version.  The sc2 patch mentioned in this thread plus the rc4 source and kernel 2.6.32-gentoo-r1 does compile and get beyond the login screen.

wine-1.2_rc4 stock with kernel 2.6.32-gentoo r1 did not work (or any version of wine after 1.1.43) and exhibited the same error message as this thread started with.

I will have to test to see if this breaks other applications I use, but this is tentatively good news.  It confirms that the sc2 patch works around it - but not if that breaks other applications.

> wine-1.2_rc4 stock with kernel 2.6.32-gentoo r1 did not work (or any version of
That's interesting and conflicts with my system.  

I did the same with the overlay to get "the latest" but I've not applied the SC2 patch to it and it's been working just fine. :/

# uname -a
Linux skywatcher 2.6.32-gentoo-r1 #1 SMP PREEMPT Mon Jan 18 22:09:47 CST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU P7450 @ 2.13GHz GenuineIntel GNU/Linux

# wine --version
wine-1.2-rc4

[D] app-emulation/wine
     Installed versions:  1.2_rc4!t(10:02:18 06/24/10)(X alsa cups dbus gecko jpeg lcms ncurses openal opengl oss perl png ssl threads truetype xml -capi -custom-cflags -esd -fontconfig -gnutls -gphoto2 -gsm -hal -jack -ldap -mp3 -nas -pulseaudio -samba -scanner -test -win64 -xcomposite -xinerama)


I'm preparing to do some kernel bisects today to see if I can narrow it down to the offending patch.

Update:

Still crashes on FreeBSD 8.1, no matter what I try.

* Updated to wine-1.2-rc4
* Applied SC2 patch and recompiled
* Copied native wldap32.dll and set to native only

No combination of the above allows me to log in.

Interesting find for those who are working on the issue.

Ubuntu 10 64
Kernel 2.6.32-22
Wine 1.1.42

I had been experiencing the fatal exception error on log-in intermittently. As I was working with updating my add-ons, recreating my WTF folder, etc sometimes I would get the error, other times not.

What I have found as a temporary work-around, that works every time for me is: If I get the error, first I use the system administration to ensure the wow.exe process is killed, then I delete the contents of the world of warcraft/cache folder. its usually another folder named WDB that I delete. Once deleted I can log in fine without the error message. Something is getting saved in that WDB folder that is causing the crash but I don't have a clue what.

Basically after every successful login I have to delete the WDB folder in the cache otherwise I will get the fatal exception error.

I tested under Fedora 12 with Kernel 2.6.32.14-127.fc12.x86_64 and Wine 1.2 rc 4, didn't experience a single issue.  With my testing on Centos, I was able to login but the game would visually corrupt and crash (separate issue) but both systems were running kernels < 2.6.33.  

There def. is a correlation, whether it's the true issue or not.  In the WoW, Cedega and Cross Over forums, people seem to have roughly the same result but going to a kernel below 2.6.33.

Created attachment 29135 [details]
Launching Wow after deleting cache folder.

Deleting cache folder doesn't fix issue for me. I can now see login status window before crash though...

Fedora 13
2.6.33.5-124.fc13.x86_64
NVidia 256.35
wine-1.2-rc4

(In reply to comment #72)
> > wine-1.2_rc4 stock with kernel 2.6.32-gentoo r1 did not work (or any version of
> That's interesting and conflicts with my system.  

I think I might have an answer on that.  I gave it some thought.

Perhaps this is processor+kernel specific (and perhaps requiring the SC2 patch as a result - but all processor families require a kernel <= 2.6.32).  I noticed a number of folks with issues tend to be in the AMD family (myself included).  

That may indicate why the SC2 patch works for some but not others.  It might be helpful for everyone who has _not_ already done so to include a "uname -a" in their bug reports.

Perhaps we can continue to refine the affected systems so the developers know where to start. :)

For me personally (downgrade to kernel 2.6.32.x fixes all problems reliably, nothing else works), I am using a Core 2 Q6600.

Downgrading my kernel from 2.6.33.1 to 2.6.32.15 fixed this issue for me.

#uname -a
Linux madadh 2.6.32-gentoo-r11-asf1 #1 SMP PREEMPT Wed Jun 23 20:22:20 CDT 2010 x86_64 AMD Athlon(tm) X2 Dual Core Processor BE-2400 AuthenticAMD GNU/Linux

#wine --version
wine-1.2-rc4-119-g410f8e9 + SC2 hack

lspci | grep -i ether
02:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

I still get this problem some times, a few times in a row and then it works, and lets me in. It was every time with a 2.6.33 kernel. There is nothing odd in dmesg, i have not tried running wireshark or pcap and getting a packet stream to look at(i tend to have a lot of other traffic to and from this computer.

After several days of trying, I've finally been able to get in to play! 

My system and uname -a:

Slackware 13.1, Wine 1.2-rc5, NVIDIA Driver version 256.35, Asus M4A79T Deluxe, 4G ram, EVga GeForce 9800 GT, 512M ram.

Linux spoofer2 2.6.33.4-smp #2 SMP Wed May 12 22:47:36 CDT 2010 i686 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux

(In reply to comment #81)
> After several days of trying, I've finally been able to get in to play! 
> 
> My system and uname -a:
> 
> Slackware 13.1, Wine 1.2-rc5, NVIDIA Driver version 256.35, Asus M4A79T Deluxe,
> 4G ram, EVga GeForce 9800 GT, 512M ram.
> 
> Linux spoofer2 2.6.33.4-smp #2 SMP Wed May 12 22:47:36 CDT 2010 i686 AMD
> Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux

Can you post the exact steps in which you took to make it work so other users may try them and then narrow down?

(In reply to comment #68)
...
> 2.6.32.15 still reliably works, but that commit isn't the bad one.
> Git bisect still needed.

Hi,

i've done a git bisect with wow ptr 0.3.5 resulting in:

08d68323d1f0c34452e614263b212ca556dae47f is the first bad commit

I've also managed to resolve the login issue with an up-to-date kernel
(2.6.35-rc3) by patching do_debug within the linux kernel. Maybe this is a
useful starting point for others.

Maybe this issue is also related to the problem described in 
https://patchwork.kernel.org/patch/68452/. The patch there is similar to mine,
but didn't resolve the issue for me.

Regards,
Stefan

Created attachment 29155 [details]
Patch for do_debug (linux kernel 2.6.35-rc3)

(In reply to comment #83)
> (In reply to comment #68)
> ...
> > 2.6.32.15 still reliably works, but that commit isn't the bad one.
> > Git bisect still needed.
> 
> Hi,
> 
> i've done a git bisect with wow ptr 0.3.5 resulting in:
> 
> 08d68323d1f0c34452e614263b212ca556dae47f is the first bad commit
> 
> I've also managed to resolve the login issue with an up-to-date kernel
> (2.6.35-rc3) by patching do_debug within the linux kernel. Maybe this is a
> useful starting point for others.
> 
> Maybe this issue is also related to the problem described in 
> https://patchwork.kernel.org/patch/68452/. The patch there is similar to mine,
> but didn't resolve the issue for me.
> 
> Regards,
> Stefan

Tested this fix with 2.6.35-rc3. Works perfectly. :)

I'm seeing this in the trial as well.

uname -a:
Linux laptop 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 i686 GNU/Linux

ubuntu lucid, wine 1.2-rc5 compiled from git. It's semi-random here, however, and seem to depend on the network. I'm on wireless, and it seems to crash about 1/3 of the time. Once it crashes, attempting another login will crash for another 30 seconds or so. After that, logs in fine.

Native wininet doesn't help, didn't try wldap32 or SC2 patch yet.

Native wldap32 may or may not help. I launched about 20 times, with no failures, then a crash.

Seems to be an intermittent network bug somewhere, though I've got an older kernel (2.6.32-22) that gets the crash. This is on a US server.

(In reply to comment #82)
> (In reply to comment #81)
> > After several days of trying, I've finally been able to get in to play! 
> > 
> > My system and uname -a:
> > 
> > Slackware 13.1, Wine 1.2-rc5, NVIDIA Driver version 256.35, Asus M4A79T Deluxe,
> > 4G ram, EVga GeForce 9800 GT, 512M ram.
> > 
> > Linux spoofer2 2.6.33.4-smp #2 SMP Wed May 12 22:47:36 CDT 2010 i686 AMD
> > Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux
> 
> Can you post the exact steps in which you took to make it work so other users
> may try them and then narrow down?

Nothing special other than loading Firefox and Thunderbird on another KDE desktop.

(In reply to comment #83)
> i've done a git bisect with wow ptr 0.3.5 resulting in:
> 
> 08d68323d1f0c34452e614263b212ca556dae47f is the first bad commit
> 

For reference, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=08d68323d1f0c34452e614263b212ca556dae47f

(In reply to comment #88)
> (In reply to comment #82)
> > (In reply to comment #81)
> > > After several days of trying, I've finally been able to get in to play! 
> > > 
> > > My system and uname -a:
> > > 
> > > Slackware 13.1, Wine 1.2-rc5, NVIDIA Driver version 256.35, Asus M4A79T Deluxe,
> > > 4G ram, EVga GeForce 9800 GT, 512M ram.
> > > 
> > > Linux spoofer2 2.6.33.4-smp #2 SMP Wed May 12 22:47:36 CDT 2010 i686 AMD
> > > Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux
> > 
> > Can you post the exact steps in which you took to make it work so other users
> > may try them and then narrow down?
> 
> Nothing special other than loading Firefox and Thunderbird on another KDE
> desktop.

So it eventually just worked? Did you change anything in your system configurations, update/downgrade your kernel? Wine version difference?

(In reply to comment #84)
> Created an attachment (id=29155) [details]
> Patch for do_debug (linux kernel 2.6.35-rc3)

I can confirm this patch works, thank you for saving me the pain of raiding on vmware.... 5 days were about to drive me insane.

  -> uname -a; wine --version; emerge --version
Linux vulcan 2.6.34-zen1 #2 ZEN SMP PREEMPT Sun Jun 27 07:44:33 EEST 2010 x86_64 Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz GenuineIntel GNU/Linux
wine-1.2-rc5
Portage 2.2_rc67 (default/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r0, 2.6.34-zen1 x86_64)

Actually, seems I was seeing a different bug in comment #86 (probably from wireless connection).

I just installed 2.6.35 from the kernel PPA and tried wow. Getting a crash every time. The crash here though is caught by WoW, so I get a WoW error box, asking to submit a report, etc.

The crash I was getting in 2.6.32 was in wine, with a backtrace (not juicy at all, no signals).

So yeah, this bug is definitely kernel dependent, as the patch in comment #84 would indicate.

(In reply to comment #92)
> Actually, seems I was seeing a different bug in comment #86 (probably from
> wireless connection).
> 
> I just installed 2.6.35 from the kernel PPA and tried wow. Getting a crash
> every time. The crash here though is caught by WoW, so I get a WoW error box,
> asking to submit a report, etc.
> 
> The crash I was getting in 2.6.32 was in wine, with a backtrace (not juicy at
> all, no signals).
> 
> So yeah, this bug is definitely kernel dependent, as the patch in comment #84
> would indicate.

If this is a kernel issue, is there a bug at kernel.org on the subject yet?

Before a kernel bug is filed, we need to produce a small test application which can illustrate the bug (assuming it is one). Then a bug should be filed at kernel.org. A qualified Wine developer should do that.

Thanks, Stefan, your patch works like a charm!  Kernel 2.6.34 + Wine 1.2-rc5, now working.

Would you mind explaining a bit what the problem was, how it affected Wine, and how your patch fixes it?
I am very curious :)

(In reply to comment #56)
> I got fedora 13 working by building kernel-2.6.32.12-115.fc13.i686.rpm from the
> fedora 12 kernel-2.6.32.12-115.fc12.src.rpm
> 
> wine --version = wine-1.2-rc4-119-g410f8e9 (Vanilla)

I'm running fedora 13 and downgraded my kernel to kernel-PAE-2.6.32.14-127.fc12 from a fedora 12 mirror. I also installed the matching kmod-nvidia (kmod-nvidia-2.6.32.14-127.fc12.i686.PAE-195.36.24-1.fc12) from rpmfusion, and am now able to login. 

Thanks for that suggestion!

(In reply to comment #84)
> Created an attachment (id=29155) [details]
> Patch for do_debug (linux kernel 2.6.35-rc3)

I can confirm this patch against 2.6.34 has fixed the login issue for me.
Debian sid, wine 1.1.42~winehq1

(In reply to comment #95)
> Thanks, Stefan, your patch works like a charm!  Kernel 2.6.34 + Wine 1.2-rc5,
> now working.
> 
> Would you mind explaining a bit what the problem was, how it affected Wine, and
> how your patch fixes it?
> I am very curious :)

Hi Devin,

after I had found the problematic commit I compared the code before the commit with the current code. As I don't know what the code does I did trial-and-error runs on the differences to create a minimal patch solving the issue for me.


I'll show the difference in the problematic code fragment:

The code fragment before the commit:

        if (condition & DR_STEP) {
                if (!user_mode(regs))
                        goto clear_TF_reenable;
        }

        si_code = get_si_code(condition);
        /* Ok, finally something we can handle */
        send_sigtrap(tsk, regs, error_code, si_code);
...
clear_TF_reenable:
        set_tsk_thread_flag(tsk, TIF_SINGLESTEP);
        regs->flags &= ~X86_EFLAGS_TF;
        preempt_conditional_cli(regs);
        return;

The code fragment in the current kernel:

        if ((dr6 & DR_STEP) && !user_mode(regs)) {
                tsk->thread.debugreg6 &= ~DR_STEP;
                set_tsk_thread_flag(tsk, TIF_SINGLESTEP);
                regs->flags &= ~X86_EFLAGS_TF;
        }
        si_code = get_si_code(tsk->thread.debugreg6);
        if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS))
                send_sigtrap(tsk, regs, error_code, si_code);
        preempt_conditional_cli(regs);

Note, that the variable "condition" was renamed to "dr6" in the new code.
As you can see the two "if"-conditions of the first code fragment are equal to the "if"-condition of the second one. But in the first code fragment the program jumps to the end of the function and "get_si_code"/"send_sigtrap" are never called whereas in the second code fragment "get_si_code" is always and "send_sigtrap" may be called.

Furthermore, if you just look at the code after the "if"-case you can see:
"send_sigtrap" is always called in the first code fragment whereas it only is called in the second one if a certain a condition is fulfilled.


My patch more or less restores the old behaviour. I.e. "get_si_code"/"send_sigtrap" are never called in the if-case and are always called in the else-case.


As I said initially, I don't really know what the kernel code does here.
So I can't tell you how and why this affects wine.
Neither can I tell you if this patch fixes the issue in the right way.
Nevertheless I hope this satifies your curiosity a little bit ;)

Maybe a good starting point for further investigations is http://lkml.org/lkml/2009/12/17/462 which has some discussion about the same commit and a similar patch (which doesn't work for me as mentioned in my previous post).


Regards,
Stefan

Thanks again Stefan :)  That did help somewhat.
Now I suppose we wait for this to be brought to the attention of a kernel dev (or do the bringing of attention), for this mystery to be completely solved.

(In reply to comment #95)
> Thanks, Stefan, your patch works like a charm!  Kernel 2.6.34 + Wine 1.2-rc5,
> now working.
> 
> Would you mind explaining a bit what the problem was, how it affected Wine, and
> how your patch fixes it?
> I am very curious :)

Patch also fixes my issue.

Fedora 13
Vanilla 2.6.35-rc3 + patch (64bit)
Wine 1.2-rc5

Applied the patch to Linux 2.6.34, Wine 1.2-rc5 on Slackware 13.1, 32-bit. Still crashes after entering login info. Compiled vanilla Linux 2.6.32.15 with same Wine and had no problems with the game at all. Unfortnately sound broke on my entire system.

Finally figured out how to actually patch a kernel... You'd think after 10 years of running linux I would have done this at some point... Now running Linux main.localdomain 2.6.33.5-124.wowpatch.fc13.x86_64 #1 SMP Mon Jun 28 00:22:43 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux with wine-1.2-rc4 from the fedora updates-testing repo and it seems to be working great. So far nothing else appears to be broken from this patch. Thanks for your hard work. I was getting sick and tired of rebooting just to fire up WoW. Now anyone know why curse 3.0.0.10 suddenly stopped working?

(In reply to comment #94)
> Before a kernel bug is filed, we need to produce a small test application which
> can illustrate the bug (assuming it is one). Then a bug should be filed at
> kernel.org. A qualified Wine developer should do that.

I ran winetest under the newer kernel and noticed several new failures:
kernel32:debugger - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/kernel32:debugger.html

kernel32:process - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/kernel32:process.html

kernel32:thread - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/kernel32:thread.html

kernel32:toolhelp - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/kernel32:toolhelp.html

kernel32:virtual - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/kernel32:virtual.html

ntdll:exception - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/ntdll:exception.html

ntdll:info - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/ntdll:info.html

psapi:psapi_main - http://test.winehq.org/data/db68b1e60228a562f6df723adf682bd216457c0c/wine_ae-ub1004lap-2.6.35/psapi:psapi_main.html

which should help with writing a testcase.

So... winetest with patch and without, compare differences?

(In reply to comment #104)
> So... winetest with patch and without, compare differences?

That would be good, but I don't have time to compile a kernel on that computer. Someone who has the patched kernel already installed could do so pretty quickly.

winetest is crashing for me during an html test, and even Stop fails...

I don't have this issue, as i'm still on 2.6.32, but wondering if anyone is gonna try 2.6.33/34 with the new patch released today, 3.3.5a before the patch to the kernel and see if it works?

For when i do upgrade to .34

WoW uses opcode 0xf1 (icebp) and expects to see a single step exception,
probably as a way to detect hardware debuggers. With the kernel change icebp is
no longer raising a SIGTRAP since it doesn't set any dr6 bits, so WoW doesn't
get its exception.

MacNean, 3.3.5a working fine for me with the patch.

Kernel bug filed at https://bugzilla.kernel.org/show_bug.cgi?id=16315.

(In reply to comment #107)

> gonna try 2.6.33/34 with the new patch released today, 3.3.5a before the patch
> to the kernel and see if it works?

Linux skywatcher 2.6.33-gentoo-r1 #1 SMP PREEMPT Mon Apr 26 10:56:01 CDT 2010
x86_64 Intel(R) Core(TM)2 Duo CPU P7450 @ 2.13GHz GenuineIntel GNU/Linux

WoW 3.3.5a

Failed with NO patch to the kernel.  In other words 3.3.5a appears to behave
the same as 3.3.5 which doesn't surprise me.

Can anyone direct me as to how this patch is applied?
I've been searching for kernel patching, but cannot find the information, or rather confirm that I have found the right information.

Kernel downgrading got me looking for older video drivers to no avail.

Arch Linux 2.6.34

This isn't the place for that, simplesnake.
Post on the Arch forums, I'll help you personally there.

*** Bug 22673 has been marked as a duplicate of this bug. ***

(In reply to comment #74)
> Interesting find for those who are working on the issue.
> 
> Ubuntu 10 64
> Kernel 2.6.32-22
> Wine 1.1.42
> 
> I had been experiencing the fatal exception error on log-in intermittently. As
> I was working with updating my add-ons, recreating my WTF folder, etc sometimes
> I would get the error, other times not.
> 
> What I have found as a temporary work-around, that works every time for me is:
> If I get the error, first I use the system administration to ensure the wow.exe
> process is killed, then I delete the contents of the world of warcraft/cache
> folder. its usually another folder named WDB that I delete. Once deleted I can
> log in fine without the error message. Something is getting saved in that WDB
> folder that is causing the crash but I don't have a clue what.
> 
> Basically after every successful login I have to delete the WDB folder in the
> cache otherwise I will get the fatal exception error.


Ubuntu 9.10
Kernel 2.6.31-22
Wine 1.2.RC?-RC5

I'm just good enough at Linux to understand the ideas talked about here but not completely sure how much my information will help.. I've been using this kernel for some time, since before starting WoW (1 month ago) and have had no problems. The first problem was with the 3.3.5 patch last week.

I had the same problem as above, it would intermittently crash after entering my battle.net authenticator, but usually a second try would let me connect immediately. This was all while using Wine 1.2, generally updating the rc's as they came through.

Today's 3.3.5a patch was different, as I haven't been able to complete the patch without the program crashing. after a little while I checked my updates, installed RC5, no success. After using the above workaround however, today's patch has successfully installed.

I did get an initial crash, however, an immediate second try allows me to log in as before. I only had to end the processes, did not have to clear the cache before the second try. Again, this isn't my area of expertise, but hopefully this helps.

(In reply to comment #110)
> Kernel bug filed at https://bugzilla.kernel.org/show_bug.cgi?id=16315.

Thank you all for your investigations. I did not even know
this icebp instruction.

I'm sorry I can not take this fix: http://bugs.winehq.org/show_bug.cgi?id=23323#c84 because it would really break other things
like sending undesired signals in case of in kernel breakpoints.

OTOH, I've uploaded a fix in the kernel bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=16315#c2

Tell me if it's fine so that I can push it upstream.

Thanks.

Frederics Fix works for me.

Patched and built the current 2.6.34 vanilla kernel. So far that seems to fix it.

Debian testing 64
2.6.34

I use FreeBSD 8.1 amd64
As of this morning World of Warcraft 3.3.5a still crashes right after login.

Alexander said this in a earlier comment:

WoW uses opcode 0xf1 (icebp) and expects to see a single step exception,
probably as a way to detect hardware debuggers. With the kernel change icebp is
no longer raising a SIGTRAP since it doesn't set any dr6 bits, so WoW doesn't
get its exception.


I have been playing World of Warcraft on FreeBSD amd64 since December of 2009
using the beta Nvidia 64bit drivers and this wine how-to

http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d

I can verify that on PCBSD 8.1 RC1 32bit World of Warcraft works post 3.3.5
so far as I can tell it is only broken on amd64.


I posted this problem to the FreeBSD hackers mailing list, and someone quickly replied, that the icebp single step exception works on FreeBSD 8 stable
does anyone have any ideas as to why, FreeBSD amd64 crashes and i386 does not? 

icebp generates the SIGTRAP on latest 8-stable, verified
by the following trivival assembler program:
       .text
       .globl  main
main:
       .byte   0xf1
       xorl    %edi,%edi
       call    exit



Thank you for your help

Sam Fourman Jr.
Fourman Networks
http://www.fourmannetworks.com

(In reply to comment #118)
> I use FreeBSD 8.1 amd64
> As of this morning World of Warcraft 3.3.5a still crashes right after login.
> 
> Alexander said this in a earlier comment:
> 
> WoW uses opcode 0xf1 (icebp) and expects to see a single step exception,
> probably as a way to detect hardware debuggers. With the kernel change icebp is
> no longer raising a SIGTRAP since it doesn't set any dr6 bits, so WoW doesn't
> get its exception.
> 
> 
> I have been playing World of Warcraft on FreeBSD amd64 since December of 2009
> using the beta Nvidia 64bit drivers and this wine how-to
> 
> http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d
> 
> I can verify that on PCBSD 8.1 RC1 32bit World of Warcraft works post 3.3.5
> so far as I can tell it is only broken on amd64.
> 
> 
> I posted this problem to the FreeBSD hackers mailing list, and someone quickly
> replied, that the icebp single step exception works on FreeBSD 8 stable
> does anyone have any ideas as to why, FreeBSD amd64 crashes and i386 does not? 
> 
> icebp generates the SIGTRAP on latest 8-stable, verified
> by the following trivival assembler program:
>        .text
>        .globl  main
> main:
>        .byte   0xf1
>        xorl    %edi,%edi
>        call    exit
> 
> 
> 
> Thank you for your help


A quick way to know if this really works is to try this testcase:
https://bugzilla.kernel.org/attachment.cgi?id=26982

This is what I used to test the Linux fix. If launching it doesn't display
"trapped", it means there is a bug and you can submit this testcase to the BSD guys.

(In reply to comment #117)
> Frederics Fix works for me.
> 
> Patched and built the current 2.6.34 vanilla kernel. So far that seems to fix
> it.
> 
> Debian testing 64
> 2.6.34


Thanks, the patch has been applied:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commit;h=a1e80fafc9f0742a1776a0490258cb64912411b0

It will reach mainline and 2.6.33/34 stable trees soon.

> https://bugzilla.kernel.org/show_bug.cgi?id=16315#c2
> 

Frederic's patch against 2.6.34 is working for me with WoW patch 3.3.5a
Debian sid , wine 1.1.42~winehq1


Thanks Frederic.

Downloaded the 2.6.34 kernel, patched/compiled/installed it.  Wow works now.  Thanks to everyone for their effort.  I hope everyone gets back on.

I also can reproduce it on freebsd RELEASE8.0-p3 amd64
i tried the following versions of wine:
1.2.r4; 1.1.41, 1.1.36

Henri's patches for SC2 and native wldap32.dll didn't help. doesn't matter what i use: opengl or directX

What about x86_64 kernels?? I use Fedora 13..

uname -a
Linux shutffl-note 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

wine32 --version
wine-1.1.3

WoW patched and starts normal after remove wine-*.x86_64 RPMs.. But cann`t log in..

(In reply to comment #124)
> What about x86_64 kernels?? I use Fedora 13..
> 
> uname -a
> Linux shutffl-note 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010
> x86_64 x86_64 x86_64 GNU/Linux
> 
> wine32 --version
> wine-1.1.3
> 
> WoW patched and starts normal after remove wine-*.x86_64 RPMs.. But cann`t log
> in..

All good!! Simply rpm -i --force for kernel 2.6.32 and install kmod-nvidia for it.. Now work..

I would like to confirm that patching the kernel worked just fine for me... all is well now.

I use Arch Linux X86 with the 2.6.34-arch kernel and wine 1.1.44

I would just like to say that this happens on FreeBSD 8-STABLE and 8.1 (both AMD54) with Wine wine-1.2-rc4/5
Like I posted there http://forums.freebsd.org/showthread.php?t=15595

Anyone has any idea on how to fix it for FreeBSD?

(In reply to comment #120)
> (In reply to comment #117)
> > Frederics Fix works for me.
> > 
> > Patched and built the current 2.6.34 vanilla kernel. So far that seems to fix
> > it.
> > 
> > Debian testing 64
> > 2.6.34
> 
> 
> Thanks, the patch has been applied:
> http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commit;h=a1e80fafc9f0742a1776a0490258cb64912411b0
> 
> It will reach mainline and 2.6.33/34 stable trees soon.

I don't think the patch as posted in the kernel bug applies properly to 2.6.33.  When I apply it to gentoo-sources-2.6.34-r1, it successfully applies 3 "hunks".  For 2.6.33 it only applies 2 "hunks", though patch does not error.  However, the re-compiled 2.6.33 does not fix the wine bug.  2.6.34 works fine here, as others have said.

Created attachment 29339 [details]
Patch for 2.6.33

I had to adapt the patch for 2.6.33 as it misses some updates that happened in further versions.

In attachement is the patch I have submitted for the 2.6.33 stable branch.

Hey.

I applied Frederick's patch on my machine, it showed 3 successful updates, but im still unable to log in into WoW. I have set the wldap32.dll to native also.

insane zen.git # uname -a
Linux insane 2.6.34-zen1 #10 ZEN SMP PREEMPT Sun Jul 4 02:18:45 FNT 2010 x86_64 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel GNU/Linux

Stable Zen Git repo.

Using Crossover Games 7.1.2. I get no debug messages, wow just freezes up and stays frozen.

Using kernel 2.6.32-sabayon or linux-2.6.32-gentoo-r11 works just fine as a workaround with only the native wldap32.dll thing. Ima give it a try on some other 2.6.34 kernel, and get back to you guys to inform whether or not it worked.

If you need additional info, let me know. Thanks for helping.

Dennis, I would try the test program in the Linux kernel bug thread linked here on FreeBSD.  If it doesn't work (no icebp), then talk to a FreeBSD kernel developer about this.

Raphael, try with a clean wine (no native wldap32.dll, nothing).

(In reply to comment #129)
> Created an attachment (id=29339) [details]
> Patch for 2.6.33
> 
> I had to adapt the patch for 2.6.33 as it misses some updates that happened in
> further versions.
> 
> In attachement is the patch I have submitted for the 2.6.33 stable branch.

I'm glad I'm not the only one who ran into this - I ended up recompiling my kernel four times, twice for 2.6.33.4, twice for 2.6.32.15.  I'll report back later assuming this fixes my problem.  Thanks Frederic!

(In reply to comment #131)
> Dennis, I would try the test program in the Linux kernel bug thread linked here
> on FreeBSD.  If it doesn't work (no icebp), then talk to a FreeBSD kernel
> developer about this.
> 
> Raphael, try with a clean wine (no native wldap32.dll, nothing).

Tried like you said, still WoW freezes and i have to kill it.

I'm finishing up my linux-2.6.34-gentoo-r1 compilation and will give it a try on it. Thanks for trying.

Just got linux-2.6.34-gentoo-r1 to work, ran WoW and it freezes same way when i try to log in. It shows me the "Connecting" and freezes.

Linux insane 2.6.34-gentoo-r1 #1 SMP PREEMPT Sun Jul 4 15:06:45 FNT 2010 x86_64 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel GNU/Linux

With or without the wldap32.dll native , and kernel is patched with Frederic's patch.

Guess ima just have to keep on playing on 2.6.32 for now until i can figure out whats the hold back.

(In reply to comment #129)
> Created an attachment (id=29339) [details]
> Patch for 2.6.33
> 
> I had to adapt the patch for 2.6.33 as it misses some updates that happened in
> further versions.
> 
> In attachement is the patch I have submitted for the 2.6.33 stable branch.

This fixes the issue in gentoo-sources-2.6.33-r2.  Thanks again!

mike@x-blade:~$ uname -a
Linux x-blade 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 GNU/Linux
mike@x-blade:~$ wine --version
wine-1.2-rc6

I'm using the 2.6.32 kernel and getting the crash on login.  It is very random tho, login works about 25% of the time.  Without changing or doing anything, if I try to launch wow and it crashes at login I just try again until it works, usually no more than 4 tries before it works.  Sometimes it works on the first try, so it hasn't really been disrupting my play time, just annoying me :P  I'm not sure why it would be so random like this, maybe some battle.net check that doesn't occur at every login?  I don't believe I have this problem with my older install with 2.6.31 kernel.

I'm getting the same problem as Mike

Linux 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux
wine-1.2-rc6

Randomly crashes after entering password and logging in.
Tried both with opengl and direct3d, both native and builtin wldap32.dll, no difference, the crash can be reproduced in any setup.

I believe this is not the same issue as the kernel 2.6.33 bug, although the crash occurs at the same place.

Console message at crash:

wine: Unhandled page fault on read access to 0xffffffff at address 0xb20e2e3 (thread 0009), starting debugger...
Assertion 'pa_atomic_load(&e->pool->stat.exported_size) >= (int) b->length' failed at pulsecore/memblock.c:1106, function pa_memexport_process_release(). Aborting.
Segmentation fault

If it's not the hard crash immediately upon login, it's a seperate issue.
Post another bug, talk in forums, etc.

(In reply to comment #137)
> Console message at crash:
> 
> wine: Unhandled page fault on read access to 0xffffffff at address 0xb20e2e3
> (thread 0009), starting debugger...
> Assertion 'pa_atomic_load(&e->pool->stat.exported_size) >= (int) b->length'
> failed at pulsecore/memblock.c:1106, function pa_memexport_process_release().
> Aborting.
> Segmentation fault

That's a PulseAudio assert you're hitting.

(In reply to comment #0)

I am having a similar problem to you guys:

http://ubuntuforums.org/showthread.php?p=9556680#post9556680

I downloaded Ubuntu Netbook Edition (10.04) onto my Gateway LT2104u Netbook. It had windows 7 starter on it before, I put WoW on it (3.3.5, WotLK) and it worked fine. Win 7 starter crashed, thats when I put UNE on it, tried reinstalling WoW and it didnt work. I can get the launcher page with the news to show up, but past that nothing. I was getting the error code 132 in the beginning, but that doesn't even show up anymore. The above thread shows a few of the avenues i took to try and get it running, but i am still having no luck running it. I have only skimmed the posts here as there are a lot, is anyone at all having any luck? or does anyone know if there is gonna be a fix in the next wine?

running wine package 1.2 (wine 1.1.42)

Since a few days there is a new kernel available for Arch linux wich has been poatched already... it is build using the newest source for kernel 2.6.34 
So i gues that if you where to manually build on other os versions the problem should be solved aswell.

#141 What kernel is that? I am using Arch and I am not aware of it. Would love to give it a try.

The original bug has been confirmed. A patch has been created that has been confirmed to solve the problem.  Further replies on this thread are only wasting space in mailboxes as they are either unrelated to the original problem (and should be opened in another thread) or confirming the original problem (which we already know).

I know most people replying aren't familiar with bugzilla, but this isn't a message board.  Once the issue is confirmed and fixed, you don't need to add your confirmation as well. 

To the original author of this bug, I'd ask you mark it fixed/resolved as it has been done so and will clutter fewer mailboxes. :-)

#1 J, attitude really unness. If you don't want bugmail for this bug, simply un-CC yourself.

#2, Can those of us not using Arch and not watching the kernel bug get a summary? The patch has been applied and released to a particular kernel version?

I'd like to know the clean, apt-get install/yum install resolution for the non Kernel patching savvy users.  Are we looking for a particular kernel release?  Some of use I believe are running an older Kernel and just skipping kernel updates until we know we can safely take the update.

This bug is invalid because it's not a Wine bug. The only reason it's open is to collect duplicates.

Jase, what they might be referring to is kernel 2.6.34.1 (I'm not sure if the
bug is fixed in that version actually).

Also, I agree with J.  "Simply un-CC yourself" is not a good solution because
if this bug re-appears it will get re-opened and then people would wish to
still recieve updates from it, etc.  When a bug is fixed, it gets closed. 
Simple.

For all the people that still want to talk about this, like the ones that don't know how to build a kernel or wich one install to solve the problem, there is a thread on wine forums when the issue was first reported: http://forum.winehq.org/viewtopic.php?t=8772

I guess thats ok and we are not going to read anymore "my mailbox is full stop talking"

The kernel bug fix does not show up in the 2.6.34.1 kernel changelog.

(In reply to comment #148)
> The kernel bug fix does not show up in the 2.6.34.1 kernel changelog.

No but it will likely show up on 2.6.34.2

Please be patient. The stable policy is to not backport fixes that are not
upstream in the current development version.

ie: it needs to reach 2.6.35-rcX before beeing merged in .34 and .33

In fact here is the complete path of the patch: bug report, trial fix posted waiting for test, test, post on LKML, review, merge on the -tip tree (that handles maintainance of x86, amongst lots of other things), then merge on Linus tree (the true upstream one), then backport on stable trees, then distros ship one of these new stable trees.

Each of these steps have their own latency properties. Fortunately, when it's about a regression fix, the path between patch posting and upstream merge is quite fast. Now the rest depends. The stable trees have their own frequency of releases. And the end depends on your distro.

It has been merged few days ago in 2.6.35-rc4, so it will certainly be in 2.6.34.2 and 2.6.33.7.

Sorry -- didn't mean to seem impatient.  Should've marked as reply to #141.  I was just clarifying for the prior commenter that had mentioned that a standard rebuild "should fix it" since .1 had come out, that it had not been merged just yet.

(In reply to comment #150)
> Sorry -- didn't mean to seem impatient.  Should've marked as reply to #141.  I
> was just clarifying for the prior commenter that had mentioned that a standard
> rebuild "should fix it" since .1 had come out, that it had not been merged just
> yet.


Ah ok, sorry then :-)

Hey guys.  Dont see this listed.  but the easiest way I've found to fix this is to simply rename the "ijl15.dll" file in your World of Warcraft directory to something else.  I imagine just deleting it would work too.   I've just been renaming it "ijl15.dll.bak" and I have no problems running it.

Ubuntu 10.04(AmD64)
Wine 1.1.42

Hope this helps.   Really irked me when it stopped working for me too.  =D

FYI for Fedora 13 users, Red Hat has back ported this fix into the latest kernel update for Fedora 13 (kernel-2.6.33.6-147.fc13).

https://bugzilla.redhat.com/show_bug.cgi?id=609548

-Jase

Same thing with PCLinuxOS.  Wow crashed when clicking login using kernel 2.6.33.5 but was fixed when the kernel was downgraded to 2.6.32.15.

(In reply to comment #154)
> Same thing with PCLinuxOS.  Wow crashed when clicking login using kernel
> 2.6.33.5 but was fixed when the kernel was downgraded to 2.6.32.15.

A fix is included in Linux kernel 2.6.35-rc4. I compiled and installed this kernel on Slackware 13.1 and WoW worked without any extra fiddling.

There is a quick fix for FreeBSD amd64 users: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-July/032330.html

This is a patch for testing, but it works for me on FreeBSD 8.0-RELEASE-p3 and wine 1.2rc4.

Note: game still crashes if you enter wrong password

For me (ubuntu lucid 64bit) I still get a crash on login with latest backports-kernel (2.6.35-7.11 which includes 2.6.35-rc4).

Stock lucid kernel works, but I need some stuff in the backports-kernel.

So apparently the kernel fix does not work for me.
Are there any other known WoW issues regarding newer kernels?

For me, WoW crashes with "Internal errors: Invalid parameters received". The last console output is:

fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (5000): STUB
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 5000
fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (5000): STUB
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 5000
fixme:reg:GetNativeSystemInfo (0x374042c4) using GetSystemInfo()
fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONTEXT_VALUE; STUB
fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONTEXT_VALUE; STUB
wine: Unhandled page fault on read access to 0x34aa7821 at address 0x3ccbcd1f (thread 0028), starting debugger...
Can't attach process 0027: error 5

I had no such problem on Ubuntu Lucid. Running Maverick amd64 with kernel 2.6.35-rc4, which has the SIGTRAP patch applied. So it must be a different issue.

So I upgraded my Linux from OpenSuSE 11.2 to 11.3, and after getting everything set up i try to get into Warcraft and see that it crashes as soon as i get to the loading screen, it crashes.

Thankfully i was able to come here and see that the problem isn't in my Wine, but in the new Kernel that comes with 11.3. And even better that there was already an answer for it.

The only problem is that i'm not really sure where to go from here. I've never patched a kernel before and don't really know where to start. I tried following the forum link above which said that there would be discussion on how to do it and such, but there are only 5 posts all asking about what the problem is, and not discussing the solution.

If anyone can help me to patch my kernel, step by step, I'd be most appreciative. The current Kernel that 11.3 uses is 2.6.34-12, which i understand is a SuSE specific deviation. Can i just patch to that version, or do i need to download a whole new source from kernel.org and patch to that?

If anyone could provide a link with step by step instructions, or can email me with that help, I'd be very grateful.

BTW: I tried downgrading my kernel back to 2.6.31 (vanilla) using the 11.2 repository, but that seems to cause even more issues as Compiz isn't working, and WoW crashes as soon as the launcher comes up.

This isn't the appropriate place for general discussion (kernel patching for example).

Ask in the SUSE forums for their advised method of applying a kernel patch, or if they offer a older stable kernel from 2.6.32 or earlier you can downgrade to.

I apologize. I have as a matter of fact posted in the openSuSE forums about this very problem, and haven't yet gotten an answer.

I do agree that this isn't an area for 'general' talk of patching kernels, but I WAS asking about applying the specific patch that the bug being spoken of in the thread requires, that was developed by those that post in this thread. If you notice I also did ask anyone to email me DIRECTLY, not to discuss it on the list.

Again I apologize if my post was in error or offended anyone, I just figured that the people who were working on this very bug would be able to be a help to me. Should anyone wish to help, I would still appreciate if you could send me an email that would either help guide me through it, or point me towards a site that will help.

Please do NOT respond in this thread.

*** Bug 23713 has been marked as a duplicate of this bug. ***

*** Bug 23806 has been marked as a duplicate of this bug. ***

I reported a similar issue there:
http://bugs.winehq.org/show_bug.cgi?id=23858

With Starcraft 2: 1.0.1.16195 and 2.6.35-rc6 kernel.

ACCESS_VIOLATION after login with battle.net account.

I was not sure it was the same issue since upgrading the kernel didn't resolved the problem.

Since I didn't see this directly mentioned anywhere else...

I'm now on Gentoo 2.6.35 with Wine 1.3.0.  I'm successfully getting into the game.

Everyone may have already expected that but since I just picked up 2.6.35 in last nights sync this was my first reasonable chance to test it.  :D

OK, so it looks like this is fixed now, the solution being 'upgrade to 2.6.35+'.

On Ubuntu Lucid amd64 with 2.6.35 from kernel ppa, wow still crashes on login

(In reply to comment #167)
> On Ubuntu Lucid amd64 with 2.6.35 from kernel ppa, wow still crashes on login

For those still having this issue, I'd recommend that you look at your kernel's update log for the specific patch the resolves the issue.  As in my case, (Fedora 13) the kernel update that resolved the issue specifically quoted this defect in the patch log, so I knew that kernel and beyond were a go.

-Jase

*** Bug 23222 has been marked as a duplicate of this bug. ***

This also still happens after upgrading to a vanilla 2.6.36-rc1, on my x86_64 on wine 1.3

I've been bisecting kernels since the patch that fixes SIGTRAP, and here are my results so far (also I have really fallen in love with kexec in the process :) :

git bisect log
# bad: [da5cabf80e2433131bf0ed8993abc0f7ea618c73] Linux 2.6.36-rc1
# good: [a1e80fafc9f0742a1776a0490258cb64912411b0] x86: Send a SIGTRAP for user icebp traps
git bisect start 'v2.6.36-rc1' 'a1e80fa'
# good: [cece1945bffcf1a823cdfa36669beae118419351] net: disable preemption before call smp_processor_id()
git bisect good cece1945bffcf1a823cdfa36669beae118419351
# bad: [d71048e22f47725a5808ea2e4e1e72fa36c1a788] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
git bisect bad d71048e22f47725a5808ea2e4e1e72fa36c1a788
# bad: [ab69bcd66fb4be64edfc767365cb9eb084961246] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6
git bisect bad ab69bcd66fb4be64edfc767365cb9eb084961246
# good: [9779714c8af09d57527f18d9aa2207dcc27a8687] Merge branch 'kms-merge' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb
git bisect good 9779714c8af09d57527f18d9aa2207dcc27a8687
# good: [3a3527b6461b1298cc53ce72f336346739297ac8] Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect good 3a3527b6461b1298cc53ce72f336346739297ac8
# bad: [9da79ab83ee33ddc1fdd0858fd3d70925a1bde99] tracing/kprobes: unregister_trace_probe needs to be called under mutex
git bisect bad 9da79ab83ee33ddc1fdd0858fd3d70925a1bde99
# bad: [b7dcb857cc3eb89136111fefe89780129c1af1d7] perf probe: Support static and global variables
git bisect bad b7dcb857cc3eb89136111fefe89780129c1af1d7
# bad: [a1ac1d3c085420ea8c809ebbee3bb212ed3616bd] perf record: Add option to avoid updating buildid cache
git bisect bad a1ac1d3c085420ea8c809ebbee3bb212ed3616bd
# bad: [68aa00ac0a82e9a876c799bf6be7622b8f1c8517] perf, x86: Make a second write to performance counter if needed
git bisect bad 68aa00ac0a82e9a876c799bf6be7622b8f1c8517
# bad: [bafb67470b294810f62db40b348643062255702b] perf tools: Allow building perf source tarballs on non-configured tree
git bisect bad bafb67470b294810f62db40b348643062255702b
# bad: [45de34bbe3e1b8f4c8bc8ecaf6c915b4b4c545f8] perf buildid: add perfconfig option to specify buildid cache dir
git bisect bad 45de34bbe3e1b8f4c8bc8ecaf6c915b4b4c545f8
# bad: [c45c6ea2e5c57960dc67e00294c2b78e9540c007] perf tools: Add the ability to specify list of cpus to monitor
git bisect bad c45c6ea2e5c57960dc67e00294c2b78e9540c007
# bad: [761844b9c68b3c67b085265f92ac0675706cc3b3] perf report: Make -D print sampled CPU
git bisect bad 761844b9c68b3c67b085265f92ac0675706cc3b3

I have a feeling that either bisect or I picked something wrong... this last commit (which bisect says is the first bad commit) doesn't even come after the icebp patch.

Created attachment 30245 [details]
A list of kernel commits that may affect this bug.

Alright, what a fun lunch break :P

Using just the data available, I narrowed it down to the range:

v2.6.35..9da78ab

It breaks on 9da78ab, but works on v2.6.35

There are 148 commits between the two.

Filtering by paths (I think the problem is in arch/x86, not sure though), and removing the merge commits, this leaves:

$ git log --oneline v2.6.35...9da79ab83ee33ddc -- arch/x86 | grep -v Merge
cc05152 x86,mmiotrace: Add support for tracing STOS instruction
4c21adf x86 cpufreq, perf: Make trace_power_frequency cpufreq driver independent
39ef13a perf, x86: P4 PMU -- redesign cache events
567a9fd kprobes/x86: Fix kprobes to skip prefixes correctly
f7809da x86: Support for instruction breakpoints
0c4519e x86: Set resume bit before returning from breakpoint exception
c882e0f x86, perf: Add power_end event to process_*.c cpu_idle routine
018378c x86: Unify save_stack_address() and save_stack_address_nosched()
147ec4d x86: Make save_stack_address() !CONFIG_FRAME_POINTER friendly
e785059 perf: Convert perf_event to local_t
1996bda arch: Implement local64_t
68aa00a perf, x86: Make a second write to performance counter if needed
8d2cacb perf: Cleanup {start,commit,cancel}_txn details
b0f82b8 perf: Drop the skip argument from perf_arch_fetch_regs_caller
c9cf4db x86: Unify dumpstack.h and stacktrace.h
e768aee perf, x86: Small fix to cpuid10_edx
45c34e0 Oprofile: Change CPUIDS from decimal to hex, and add some comments

The full list without the path filter is attached.

Anyone more kernel-knowledgeable want to chime in?

Alright, after a rebasing followed by more rebasing, I have isolated the commit that causes WoW to crash:

f7809da x86: Support for instruction breakpoints

Everything is peachy before this commit.

I reverted this commit on my 2.6.36-rc1, and now I can log in without any issue.

Created attachment 30278 [details]
Wine fixmes

In kernels 2.6.33.6-147.2.4.fc13 and 2.6.33.8-149.fc13 the bug appears to still affect StarCraft II, even though they both have the icebp traps patch by Frederic. My 2.6.33.6 also lacks the "Support for instruction breakpoints" patch which Kelvie Wong believes causes the problem.

I have been attempting this with the described kernels on a Thinkpad T60 with the x11-drv-ati driver (which apparently shows up in lsmod as "radeon"?).

The program is crashing while loading, before the log in screen.

It may be that this is a slightly different ACCESS_VIOLATION bug, but I suspect it is at least closely related. I shall also attach my blizzard error and backtrace report.

Created attachment 30279 [details]
Blizzard Error Report

(In reply to comment #176)
> Created an attachment (id=30279) [details]
> Blizzard Error Report

I am pretty sure this is a separate issue.  The blizzard crash handler shouldn't even get called for this issue.

(In reply to comment #158)

Just wanted to say, this is still an issue on wine-1.3.1 and vanilla kernel 2.6.36-rc3. As it's mentioned in the original post, this might be a different issue from the originally reported one - should a new report be opened ?

(In reply to comment #178)
> (In reply to comment #158)
> 
> Just wanted to say, this is still an issue on wine-1.3.1 and vanilla kernel
> 2.6.36-rc3. As it's mentioned in the original post, this might be a different
> issue from the originally reported one - should a new report be opened ?

https://bugzilla.kernel.org/show_bug.cgi?id=16315#c26

It's fixed with this patch here, and I presume it will be in the next RC.

Kelvie,

I couldn't fully follow the issue you were tracking here and on the kernel bugtracker.

Is this an issue introduced after 2.6.35 (so in 2.6.36-rc1)?
Or another (related) issue to the one that was fixed earlier?

For me, WoW still doesn't work, so I would like to know if I should just wait for this fix to be included, or start debugging it and track down if I'm watching the right bug.

Situation:
Ubuntu Lucid amd64
default kernel (2.6.32-24-generic): everything works
kernel ppa (2.6.35-19-generic): crash upon login - sometimes with blizzard bug report tool, sometimes wine message about bad instruction.
I tried the "mainline" 2.6.35 from ubuntu kernel ppa, but same issues there.

both 2.6.35's contain the fix from earlier.

(In reply to comment #180)
> Kelvie,
> 
> I couldn't fully follow the issue you were tracking here and on the kernel
> bugtracker.
> 
> Is this an issue introduced after 2.6.35 (so in 2.6.36-rc1)?
> Or another (related) issue to the one that was fixed earlier?
> 
> For me, WoW still doesn't work, so I would like to know if I should just wait
> for this fix to be included, or start debugging it and track down if I'm
> watching the right bug.
> 
> Situation:
> Ubuntu Lucid amd64
> default kernel (2.6.32-24-generic): everything works
> kernel ppa (2.6.35-19-generic): crash upon login - sometimes with blizzard bug
> report tool, sometimes wine message about bad instruction.
> I tried the "mainline" 2.6.35 from ubuntu kernel ppa, but same issues there.
> 
> both 2.6.35's contain the fix from earlier.

It's hard to tell -- I am not sure what patches the Ubuntu guys put on.

To summarize, this is what we know:

1. Commit 08d6832 breaks the login
2. Commit a1e80fa fixes commit 08d6832 (this is in 2.6.35)
3. Commit f7809da also breaks the login (this is in 2.6.36-rc1 and later)
4. Frederick's new patch fixes commit f7809da (this hasn't been checked in)

So, it will break

1. If your kernel has 08d6832 and not a1e80fa

OR

2. If you have commit f7809da

OR

3. Some other issue.

*** Bug 24227 has been marked as a duplicate of this bug. ***

For all those who upgrade to current maverick:

the 2.6.32-25 kernel from lucid-repos allows for wow to work. (and no errors in other apps so far)

the one in maverick (2.6.35-22) does NOT let you play wow, eve-online works ;)

that is at least the generic-pae on x86 install on my laptop.
Intel(R) Core(TM)2 Duo CPU     T9400  @ 2.53GHz
nVidia Corporation G96 [GeForce 9600M GS]

The one in maverick (2.6.35-*) does let you play wow.
At least for me it turned out the bug was not this one reported here, but rather http://bugs.winehq.org/show_bug.cgi?id=24193

As a workaround I turn off (0) this new ubuntu security feature before WoW and switch it back on afterwards (1).

(as root)
echo 0 > /proc/sys/kernel/yama/ptrace_scope

Disabling security features is not as bad as it sounds.
Vanilla 2.6.35 does not contain it.
Everything before 2.6.35 doesn't as well.
So you will be "as secure as lucid" so to speak.

Thanks a lot, I can confirm this is working.
running 2.6.35-22-generic-pae on maverick with the security feature off and wow runs fine. 

And after compiling wine myself using these patches: 
http://art.ified.ca/?page_id=40 
pulseaudiosupport is back as well.

No crash so far. 

The option of turning the security feature off should be mentioned in any WoW-by-Wine report, as it will affect alot of people and the solution to it seems to be rather complicated (starting at the logical level of wineserver and its child processes?). Thanks again, I would not have found this otherwise.

(In reply to comment #184)
> The one in maverick (2.6.35-*) does let you play wow.
> At least for me it turned out the bug was not this one reported here, but
> rather http://bugs.winehq.org/show_bug.cgi?id=24193
> 
> As a workaround I turn off (0) this new ubuntu security feature before WoW and
> switch it back on afterwards (1).
> 
> (as root)
> echo 0 > /proc/sys/kernel/yama/ptrace_scope
> 
> Disabling security features is not as bad as it sounds.
> Vanilla 2.6.35 does not contain it.
> Everything before 2.6.35 doesn't as well.
> So you will be "as secure as lucid" so to speak.

I can also confirm this is working in maverick. I was starting to give up hope of
playing!

How did you manage to tun the security feature off? 

When I try this:

"sudo echo 0 > /proc/sys/kernel/yama/ptrace_scope"

I got the following output:

"bash: /proc/sys/kernel/yama/ptrace_scope: Permission denied"


And I'm not able to run an older/newer (beta/mainline) kernel. The installation process wents fine but when I try to boot I don't have a gui anymore :/

(In reply to comment #187)
> How did you manage to tun the security feature off? 
> 
> When I try this:
> 
> "sudo echo 0 > /proc/sys/kernel/yama/ptrace_scope"
> 
> I got the following output:
> 
> "bash: /proc/sys/kernel/yama/ptrace_scope: Permission denied"
> 
> 
> And I'm not able to run an older/newer (beta/mainline) kernel. The installation
> process wents fine but when I try to boot I don't have a gui anymore :/

The way that is interpreted is:
(sudo echo 0) > /proc/sys/kernel/blah/blah
Meaning you only used sudo to run echo, which bash then tried to write (without sudo permissions).

You'd need to either do:
echo 0 | sudo tee /proc/sys/kernel/etc/etc
or
sudo sh -c "echo 0 > /proc/sys/blah/blah"


Anyway, this isn't a wine bug, the two issues that cause it are well known and addressed... I'd say this can be closed.

Yes, I think enough time has passed for this issue to be mostly gone.

Closing invalid.

*** Bug 21809 has been marked as a duplicate of this bug. ***

Upstream