Bug #1296

MacBook Pro (core i7) freezes after character selection

Added by yglukhov about 4 years ago. Updated over 3 years ago.

Status:New Start date:05/20/2011
Priority:High Due date:
Assignee:- % Done:

0%

Category:OS: Mac
Target version:-

Description

After character selection and starting the game, the progress bar loads up to 100%, and the whole computer freezes. Force quit doesn't work, and hard reset is needed.
This occurs in both fullscreen and window modes.
This occurs with latest AppStore version (0.11.0), with Ryzom Core Client (downloaded from this site) version (0.8.1412), and with manually built client from sources (hg revision: 1474:6cb376ef0013) (Please note however, that in the last case the freeze occurs immediately after launch, before any windows created).

Note: on the same macbook, Ryzom for windows works fine in VMWare Fusion virtual machine. So looks like the issue can be fixed or worked around from the software side.

system.log (9.2 kB) yglukhov, 05/20/2011 06:03 pm

kernel.log (78 kB) yglukhov, 05/20/2011 06:03 pm

client.log (2.2 MB) yglukhov, 05/20/2011 06:03 pm

MacBook_Pro.spx (97.8 kB) yglukhov, 05/31/2011 06:36 pm

sample.txt (29 kB) Magnifier yglukhov, 06/15/2011 10:26 pm

sample2.txt (28.6 kB) Magnifier yglukhov, 06/15/2011 10:26 pm

History

#1 Updated by yglukhov about 4 years ago

The MacBook Pro is 13 inch model, with "Intel HD Graphics 3000".

#2 Updated by rti about 4 years ago

Could you please attach the information from the apple bug reporter showing up after computer restart? The client.log file from ~/Library/Application\ Support/Ryzom/client.log could be interesting as well.

#3 Updated by yglukhov about 4 years ago

Unfortunately, there was no bug reporter, as technically there was no crash or kernel panic. However, there are some entries in system.log and kernel.log that might be of interest.

#4 Updated by kervala about 4 years ago

ace talked about these problems with new MacBooks pro.

Apparently, a lot of applications are concerned by them :(

#5 Updated by yglukhov about 4 years ago

Another build (hg: 1527:ee970fd2b540) - another freeze. Any info on where in code the freeze occurs? Tried to debug, but i guess it should be debugged with remote kernel debugging. Unfortunately, i dont have a spare mac for it.

#6 Updated by rti about 4 years ago

Maybe this could be mentioned on the next submission to the Mac AppStore?
Lets see what apple has to say about that?

@yglukhov: What are the exact specs of your machine? Maybe you can paste what "System Profiler.app" -> "Hardware Overview" tells you?

#7 Updated by yglukhov about 4 years ago

System Profile attached. I suspect the issue is related to Intel HD Graphics 3000 on sandybridge chips. But thats an assumption.

#8 Updated by yglukhov about 4 years ago

Ok, some further investigation showed that the "whole system freeze" affects only window-server related stuff. Connecting by ssh works just perfect. So when the hang occured, i attached with GDB, but no luck here. The debugger just froze along with ryzom_client. However sampling the process gave me a pretty good backtrace (sample.txt attached). After stubbing the CDriverGL::setupARBVertexProgram with "return false" and fixing a crash (see below), i've ran ryzom once again and saw the same freeze. The backtrace is a bit different (sample2.txt attached), but both backtraces are stuck in GHAL3D::CPrivateCommandTransport::FlushCommandBuffer, and that makes me more confident in Intel HD 3000 drivers problem. So, looks like the problem can not be located by backtracing the hang, as many opengl calls lead to GHAL3D::CPrivateCommandTransport::FlushCommandBuffer (again, just an assumption), but rather by figuring out what particular operation has locked that semaphore (mentioned in kernel.log) and forgot to unlock it =). Or by getting an Apple software update with good drivers from Intel, which can never happen.

Crash: in driver_opengl_vertex_program.cpp remove 2 occurrences of "_VtxPrgDrvInfos.erase(it)", since "it" is already erased from the list in CVertexProgamDrvInfosGL destructor. Strange architectural decision, IMHO =)

#9 Updated by yglukhov about 4 years ago

MacOS 10.6.8 did not fix the issue.

#10 Updated by yglukhov about 4 years ago

Ah, finally, i've found the fix to the problem. At least a temporary workaround for you guys. Playing with registerGlExtensions() function i've tracked the problem down to DisableHardwareVertexArrayAGP flag. Setting this flag to false, fixes the issue just fine. So now, MacOS clients with this problem can just write a "DisableVtxAGP = 1;" to the config file and be ok with it, until you do a coded workaround in the next release. I hope the 1-star ratings on the app store will be over for you =). Good luck with the great game!

#11 Updated by yglukhov about 4 years ago

Btw, can i get an unlimited account for that? =)

#12 Updated by rti about 4 years ago

  • Priority changed from Normal to High

This is great news. Thanks a lot.

#13 Updated by yglukhov about 4 years ago

Sorry, there's a mistake in my post. Should be "Setting DisableHardwareVertexArrayAGP flag to true".

#14 Updated by kervala about 4 years ago

yglukhov wrote:

Sorry, there's a mistake in my post. Should be "Setting DisableHardwareVertexArrayAGP flag to true".

Thanks, I will check in driver code what is really disabled when this option is enabled.

#15 Updated by GelluleX almost 4 years ago

Hi,
I'm one of the affected user. The workaround (involving both DisabelVtxAgp and DisableVtxProgram), works for me. Is there anything else I could help with?
Regards,
-Gellule

#16 Updated by mrpotat0 over 3 years ago

hey, i am also affected by this bug, however, mine is core i5 w Intel HD Graphics 3000.

as i am not a technie, could someone kindly teach me step by step on how to resolve this issue? i really want to give this game a try on my mac!

thanks.
-sam

Also available in: Atom PDF