Pages: 1 2 3 :: [one page] |
|
Author |
Thread Statistics | Show CCP posts - 3 post(s) |
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.23 20:38:00 -
[1]
So we can show CCP the degree to which the newest client update is troubling us, please post here if the 1.1.2 update from a few days ago has made the game unplayable due to crashes to desktop.
Mention your system, videocard and frequency, if possible.
----------
I'm crashing an average of every few minutes. Even just sitting in a station doing nothing. Sometimes before even fully logging in. Sometimes after five or ten minutes.
Mac Pro 8-core 2.8ghz w/ 16gmb ram and GeForce 8800
Have completely removed EVE and reinstalled it. No luck. Problem begam minutes after upgrading the client. |
Dr Sheepbringer
|
Posted - 2008.10.23 20:45:00 -
[2]
But hey in Live Dev Blog they said it's quite stable now :) |
Suzie Sly
|
Posted - 2008.10.24 00:16:00 -
[3]
iMac dual-core 3.06Ghz 24" with 4Gb ram and GeForce 8800 (i.e. current top of range iMac). Dual screen - native + a 1600*1200 lcd plugged in.
Since patch lucky if 1 instance stays up and running, especially if I switch to another app such as Firefox.
Starting a second instance is a pure falacy... doesnt last more than a few seconds.
No matter what i do i cant get the client to start in windowed mode - and yes I had it workin fine pre-patch and have tried the same setting changes since.
Tonight I'm going to delete my cache settings etc. but quite frankly dont see why I should have to setup my screen each time theres a patch.
If it doesnt work I'll look to see how effective it is to restore the game pre-patch - thank god for time machine! ...
Overall pretty hacked off... 3 accounts and I can only view 1 at a time... prepatch I used to run all 3 fine albeit the 2nd and 3rd had small windows to reduce overheads.
Now... considering letting one of more of the accounts expire till I can dual log again.
|
Kirkus Jameus
Amarr Guardian Gold Rakashasa Corporation
|
Posted - 2008.10.24 00:24:00 -
[4]
I don't know that I'd call it entirely unstable, however I would say that it is now the worst it has been since I started playing last November.
It used to crash to desktop once in 6-8 hours, sometimes not for 10-12. Now it happens sometimes in 30 min, sometimes right at login.
I never used to lose connections. Since the patch it has happened maybe a dozen times. Most annoying!
I always start fresh after a reboot and never run any other programs while playing Eve. iMac 1.83ghz, 2GB X1600 (i think.)
Most recent patch rendered the inside of stations black except for a few scattered light effects. No big deal really, but would be nice to have back to the way it was. (Who doesn't twirl their ship once in a while?)
After the October 8 patch my FPS drop from 6-10 during a mission battle to 1-3. Now the FPS is back up but there is the station and map lines issues.
Drones are unreliable at best. They sometimes drift away from each other. They go off and attack random targets. They don't always return when told to. This never used to happen to me before.
That's my story so far.
KJ
I can get by for now as long as I don't risk low or null sec...
|
Andrew Highwind
Caldari State Secret Service
|
Posted - 2008.10.24 00:42:00 -
[5]
I'm not quite at the point of unuseable, but it's getting pretty close. The client will crash almost without fail if I switch to it using Spaces. I haven't ran multi clients yet, but after reading responses in other threads, it doesn't sound like a good idea. Even the SiSi client is starting to misbehave.
I haven't played long enough in a day since the patch for the client to get fubar'd.
I'm rolling with a 2.4Ghz iMac with the ATI RadeonHD 2600 256MB VRAM, the machine has 4GB of ram. Meanwhile the game runs perfectly fine on my brand new MacBook, for some reason, I find this hilarious.
|
|
CCP Casqade
|
Posted - 2008.10.24 01:06:00 -
[6]
Hi all.
Just so you know, we are aware of that some peoples stability have gone down, a lot. We are working on a solution short term and long term. Those of you who have crash occur, and then another crash as soon as you enter the game again. Can you please try the following:
1. After the first crash occurring, do not relaunch the client 2. Start the Activity monitor 3. Check if you see if there is a "cider" or "wineserver" process running. 4. If so, please type the following into a terminal window "killall -9 cider wineserver" 5. Launch EVE again
Does this help at all?
Those of you who are experiencing these crashes, can you also please try the following in terminal:
1. Open Terminal 2. "cd ../.." 3. cd Applications/EVE\ Online.app/Contents/MacOS 4. ./cider -debugmsg +seh,+tid,+module,+debugstr &> ~/Desktop/EVEcrashlog.log 5. Have the crash occur 6. Compress the logfile generated on your desktop 7. Attach to a bug report with the title "Mac crash issue - For Casqade" 8. If the file is too big, please upload it to EVE-Files or a similar file site.
Thanks
|
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.24 01:44:00 -
[7]
I'll perform the above steps next time I start up and wind up with a crash. I had considered gathering a core and pstack (or whatever the OSX equivalent is) for a bug report, but hadn't yet discovered the steps for doing so in OSX (presuming there is a 'coreadm' equivalent).
Anyway, thanks for the comment. Wasn't looking to rag on CCP with this post, but rather gather people with the same problem together in one spot (there have been lots of individual threads on it) so that you guys could see what we're up against and/or at least acknowledge that you're aware of it being an issue.
|
Anton Brienne
|
Posted - 2008.10.24 05:09:00 -
[8]
Just submitted a bug report... hopefully this'll be resolved soon. Casqade: No cider or wineserver processes are left running on my computer after crashes. I think it may have something to do with running the client in a window; when I run full screen it doesn't crash before I can log on (which it normally does) but I haven't tried any serious playtesting, so I could be totally wrong. Oh, and the station interiors still aren't displaying properly, as would be suggested by the latest patch notes. Just FYI. |
Tank Charlie
Caldari Blacksheep Incorporated
|
Posted - 2008.10.24 05:43:00 -
[9]
I run 3 instances of Eve on my 15" MacBook Pro.
When I saw the update come out a couple days ago, I downloaded/patched my first instance. That instance has been quite predictable ... it crashes any time another application comes to the foreground. My other two instances of the Eve client, both unpatched, have been much more stable.
I'll see if I can get crash logs from the first/primary install ... but it's definitely been a step in the wrong direction. |
|
CCP Casqade
|
Posted - 2008.10.24 10:46:00 -
[10]
Originally by: Qordel Wasn't looking to rag on CCP with this post, but rather gather people with the same problem together in one spot (there have been lots of individual threads on it) so that you guys could see what we're up against and/or at least acknowledge that you're aware of it being an issue.
Much appreciated.
Originally by: Anton Brienne Just submitted a bug report... hopefully this'll be resolved soon. Casqade: No cider or wineserver processes are left running on my computer after crashes.
Thank you.
Originally by: Anton Brienne
I think it may have something to do with running the client in a window; when I run full screen it doesn't crash before I can log on (which it normally does) but I haven't tried any serious playtesting, so I could be totally wrong.
Interesting. Are you running it using the window mode switch in the config file to start it up in window mode? If you are running it in full screen, do you eventually get the crash too?
Originally by: Anton Brienne
Oh, and the station interiors still aren't displaying properly, as would be suggested by the latest patch notes. Just FYI.
Explanation: http://oldforums.eveonline.com/?a=topic&threadID=903116&page=1#10
Originally by: Tank Charlie
That instance has been quite predictable ... it crashes any time another application comes to the foreground.
I'll see if I can get crash logs from the first/primary install ...
Thank you. Good reproduction usually help even more. It is important to give us information about the circumstances like; are you starting the client in window mode? Are you switching it to window mode after start? What program is it that comes up in the foreground?
Originally by: Tank Charlie but it's definitely been a step in the wrong direction.
We fully agree. |
|
|
Shin Chogan
|
Posted - 2008.10.24 15:47:00 -
[11]
Edited by: Shin Chogan on 24/10/2008 15:49:19
Originally by: CCP Casqade
Originally by: Anton Brienne
I think it may have something to do with running the client in a window; when I run full screen it doesn't crash before I can log on (which it normally does) but I haven't tried any serious playtesting, so I could be totally wrong.
Interesting. Are you running it using the window mode switch in the config file to start it up in window mode? If you are running it in full screen, do you eventually get the crash too?
I've come to the same conclusion as well. It is suspiciously coincidental with bringing another app to the foreground. I've not tried it full screen yet.
By the way using the window mode switch in the config file no longer works ... way to regression test your patches ;)
I've not run eve from the terminal yet - my crashes don't appear to be as frequent as some here, I can play for an uninterrupted hour or two (as long as I don't switch apps) But I've noticed a lot of error messages in the console logs that weren't there pre patch. I'll raise a bug report as you suggested but the short version is a lot of messages like the following : _NSAutoreleaseNoPool(): Object 0x3e5ab550 of class NSCFDictionary autoreleased with no pool in place - just leaking
Any chance you could release an UN Patch Patch ;)
|
Ami Nia
Caldari
|
Posted - 2008.10.24 15:47:00 -
[12]
It has been unstable for me, so I switched back to the unpatched client.
It did crash almost every time when switching to another app and back (especially if the other App happened to be on a different workspace). But I was running with "GLSL" = "Y" (no problem with stations as I have "load station environment" unchecked).
I now switched back again ONE of my client installations to the patched version and changed "GLSL" = "M". It seems to be a bit more stable, after that. I'll keep using the patched version and if I find a way to crash it reliably I'll produce a crash log.
One thing that I think I already suggested somewhere else is to confront with cedega and verify with them if it's possible to find a way to run the logserver (the one you use in windows) somehow. I'm not sure how the client talks to the logserver. I guess it's either a standard TCP/IP socket or a pipe. If it's a socket, having it running should be extremely easy. If it's a pipe, they should be able to remap the Windows pipes API calls to either a TCP/IP socket or unix pipes. If they do that we'd be able to provide both the "standard" log data and the cyder log data. I think this would make things much easier for everyone.
Originally by: CCP Mitnal So we can 1 v 1 with Garmon.
|
Ami Nia
Caldari
|
Posted - 2008.10.24 16:03:00 -
[13]
Originally by: Shin Chogan By the way using the window mode switch in the config file no longer works ... way to regression test your patches ;)
It does work for me. Are you sure you did change the correct setting?
Originally by: Shin Chogan _NSAutoreleaseNoPool(): Object 0x3e5ab550 of class NSCFDictionary autoreleased with no pool in place - just leaking
That means that cider did start a new thread that (directly or indirectly) uses Objective C data but forgot to setup a pool. It's a sign that something should be fixed and that some memory is probably being leaked, but it should not be too worrying and is probably unrelated to the crashes and instabilities.
It MAY have something to do with performance/instability that is noticeable after a long time playing, however. But it's easy to verify if that's the case: keep Activity Monitor up and check how much the application "eats" memory over time.
|
Shin Chogan
|
Posted - 2008.10.24 16:36:00 -
[14]
Originally by: Ami Nia
Originally by: Shin Chogan By the way using the window mode switch in the config file no longer works ... way to regression test your patches ;)
It does work for me. Are you sure you did change the correct setting?
I was going to yes ... however doing a double check ... ooopps Wrong directory !!!!
<slaps self> Way to go shooting my mouth off :/
|
Paula Quartz
|
Posted - 2008.10.24 17:03:00 -
[15]
Originally by: CCP Casqade
Those of you who are experiencing these crashes, can you also please try the following in terminal: [etcetera]
Did that, and just posted the petition. |
Ami Nia
Caldari
|
Posted - 2008.10.24 19:31:00 -
[16]
Casqade, I've filed a bug report (id 64273) as for your instructions. I've attached a zip file with some stuff, including a MyMachineConfig.txt file with details of my settings and a some more explanations.
I'm posting the last three paragraphs of that file here too:
I had a look at the crash log. The exception is an invalid instruction execution trap. I cannot say (well, probably I could if I really wanted to hack this info out, but I'll leave you the pleasure to do it. Besides ... it may be against the EULA!) if it's inside the cedega code or inside the python code (not the python source probably, but it could be in some python C library or in the python itself). In any case it should not bee to difficult for CCP/Cedega to find out.
I've seen from the crash log that the cedega code reacted to the exception by creating ntdll_crashReport.txt and ntdll_minidump.dmp in the "P: drive". So I went to the preferences dir that is mapped to P: and took those files too. They are attached for your enjoyment.
My personal petition to you: fight for keeping the mac-patch optional until we are VERY sure it's allright. Especially across the Midas (or whatever "rising" they call it now) deployment. Have that deployment go with an unpatched client and then post an optional patch for macs again. This will save us (and you too) from hell.
|
Ami Nia
Caldari
|
Posted - 2008.10.24 19:38:00 -
[17]
Originally by: Ami Nia
Originally by: Shin Chogan By the way using the window mode switch in the config file no longer works ... way to regression test your patches ;)
It does work for me. Are you sure you did change the correct setting?
Originally by: Shin Chogan _NSAutoreleaseNoPool(): Object 0x3e5ab550 of class NSCFDictionary autoreleased with no pool in place - just leaking
That means that cider did start a new thread that (directly or indirectly) uses Objective C data but forgot to setup a pool. It's a sign that something should be fixed and that some memory is probably being leaked, but it should not be too worrying and is probably unrelated to the crashes and instabilities.
It MAY have something to do with performance/instability that is noticeable after a long time playing, however. But it's easy to verify if that's the case: keep Activity Monitor up and check how much the application "eats" memory over time.
After monitoring the memory consumption and looking at the crash log I must say I'm nearly certain the "leak" is a non issue. It only happens at the very beginning, therefore no over-time-memory-leakage should be experienced.
Plus when EvE starts you see a process going up, then launching another process and finally dying out (look at the dock during startup). I'm 99% confident that it is the launcher process that has a thread that misses the Objective C memory pool initialization, therefore all the memory is actually reclaimed by the OS when that thread dies.
|
|
CCP Casqade
|
Posted - 2008.10.24 20:10:00 -
[18]
Originally by: Paula Quartz Edited by: Paula Quartz on 24/10/2008 17:21:59
Originally by: CCP Casqade
Those of you who are experiencing these crashes, can you also please try the following in terminal: [etcetera]
Did that, and just posted the petition.
Edit: and another one send in. I hit my petition limit, so I switched e-mail addresses :)
Anyone up for a 'crashlogs delivered' competition?
Do not file petitions about this! These are bug reports and should go into the bug report system. Petitions go to Game masters/Customer support. Bug report system: https://bugs.eve-online.com/newbugreport.asp |
|
Shin Chogan
|
Posted - 2008.10.24 20:25:00 -
[19]
Originally by: Ami Nia
Originally by: Ami Nia
Originally by: Shin Chogan By the way using the window mode switch in the config file no longer works ... way to regression test your patches ;)
It does work for me. Are you sure you did change the correct setting?
Originally by: Shin Chogan _NSAutoreleaseNoPool(): Object 0x3e5ab550 of class NSCFDictionary autoreleased with no pool in place - just leaking
That means that cider did start a new thread that (directly or indirectly) uses Objective C data but forgot to setup a pool. It's a sign that something should be fixed and that some memory is probably being leaked, but it should not be too worrying and is probably unrelated to the crashes and instabilities.
It MAY have something to do with performance/instability that is noticeable after a long time playing, however. But it's easy to verify if that's the case: keep Activity Monitor up and check how much the application "eats" memory over time.
After monitoring the memory consumption and looking at the crash log I must say I'm nearly certain the "leak" is a non issue. It only happens at the very beginning, therefore no over-time-memory-leakage should be experienced.
Plus when EvE starts you see a process going up, then launching another process and finally dying out (look at the dock during startup). I'm 99% confident that it is the launcher process that has a thread that misses the Objective C memory pool initialization, therefore all the memory is actually reclaimed by the OS when that thread dies.
I've noticed these entries appearing when I dock as well. |
Paula Quartz
|
Posted - 2008.10.24 20:39:00 -
[20]
Originally by: CCP Casqade Do not file petitions about this! These are bug reports and should go into the bug report system. Petitions go to Game masters/Customer support. Bug report system: https://bugs.eve-online.com/newbugreport.asp
Ah, I see, apologies. Would you like me to re-submit them there? Got your name stamped on 'em in the petitions, so they should reach you. |
|
Ami Nia
Caldari
|
Posted - 2008.10.24 22:18:00 -
[21]
Originally by: Shin Chogan I've noticed these entries appearing when I dock as well.
I'll do some more checks then.
|
Tridik
Caldari the united
|
Posted - 2008.10.25 00:51:00 -
[22]
Macbook pro -
Im having tremendous issues while running my client. It randomly crashes to desktop after this latest patch.
|
Anton Brienne
|
Posted - 2008.10.25 02:02:00 -
[23]
Originally by: CCP Casqade
Interesting. Are you running it using the window mode switch in the config file to start it up in window mode? If you are running it in full screen, do you eventually get the crash too?
I Cmd-Enter to enter windowed mode immediately after starting the game. It seems that entering windowed mode and switching apps before actually entering the game (i.e. while logging on) causes more instability, for me at least. If I leave the game fullscreen until actually in-game, it is then much more stable. I can always create a crash by starting the client, entering windowed mode, beginning to log-in, switching applications, then switching back to eve. Sometimes it actually gets as far as starting the game proper, but it always crashes in a minute or two at most. Waiting until in-game to switch apps gives me half an hour or so. I haven't had any crashes while in full screen, but I frankly can't stand to run the thing fullscreen for any length of time, so I'm not sure if it'd eventually happen. It seems to be linked to running in a window, though.
|
beta6
|
Posted - 2008.10.25 03:50:00 -
[24]
I'm Running Imac intel core duo 2.4Ghz 1Gb RAM ATI,RadeonHD2600 OS 10.5.5 .
I run two accounts in windowed mode on the mac client. I can not go longer then 40 min with out a crash after the latest patch. To be honest I'm getting tired of all the sh*tuff I have to do to try and get the client playable. Last time I checked I pay CCP to do that so I can PLAY eve. Engage in activity for enjoyment and recreation rather than a serious or practical purpose. <--PLAY
|
Apple Boy
Gallente Federation of Freedom Fighters Executive Outcomes
|
Posted - 2008.10.25 05:46:00 -
[25]
Edited by: Apple Boy on 25/10/2008 05:46:50 next time I reboot back to OS X I'll create the logs and submit, but in the meantime from memory, current ways to reproduce various crashes: - startup the client, and then in rapid succession cmd+tab between eve and something else while in full screen mode. (had this issue since day one) - startup the client, cmd+return to switch to windowed mode, cmd+tab between windows and it'll crash (only since latest patch) - startup the first client, switch to windowed mode, startup second, just let them idle. guaranteed to crash both (only since latest patch)
I have a second generation macbook pro, model number: MA611LL/A http://support.apple.com/kb/SP24 it's running leopard |
Summer Fire
|
Posted - 2008.10.25 07:12:00 -
[26]
Since the patch I have no longer been able to run 2 clients. While running 2 was never trouble free at least I was able to play the game. I start one, wait a few minutes then start the other. Within 3 mins I am getting serious frame rate drop then the 2nd instance crashes. It is never the first instance. No disconnect just crash. After combing the net and boards for more info and finding nothing new I started playing with only one client. Got tired of this very quickly and thought that if I ran both clients in a reduced window it might ease things... BINGO. Been playing for 10 hours without a problem. Graphics card issue perhaps? The frame rate is still not good and oddly the 2nd client has a better rate than the first.
Another small issue is that each time I log on now I get a new mail reminder. There is no new mail.
Finally, Why is one instance of the client so much larger in terms of RAM and Virtual RAM. One is much older character of course but does this increase memory so much ? PID Process CPU RSIZE VSIZE Time Prts RPRVT 1262 EVE Online40.6855.70 MB1.80 GB56:12.69249859.70 MB1,790,2621,656,035108.45 MB22 1099 EVE Online49.3590.78 MB1.39 GB1:34:33.72255584.19 MB3,386,7943,139,786139.03 MB22
iMac 2.8Ghz, 4GB RAM, 1 TB HDD, ATI Radeon 2600HD 256MB
|
Shin Chogan
|
Posted - 2008.10.25 08:01:00 -
[27]
I tried starting and running in fullscreen last night, normally I play in a window, and despite many attempts to crash my client I couldn't - about 3 hours of uninterrupted play.
|
Paula Quartz
|
Posted - 2008.10.25 10:39:00 -
[28]
I'm not sure if it's true, but I recognize the "don't switch programs" sentiment. When I run the client and I want it to stay up for a while (e.g. waiting for an upcoming skill completion), I try to keep the Eve window active as much as possible. Didn't have the fear of switching with the old client. I could easily mail, browse and watch videos with that.
|
Bit Steen
|
Posted - 2008.10.25 11:01:00 -
[29]
I have a lot of crashes too - much more then before the patch
System: Mac Pro 2.8ghz, NVidia 8800GT, 14gb Memory and OS X 10.5.5 |
Srg Hedge
|
Posted - 2008.10.25 11:11:00 -
[30]
Hi CCP Casqade. My mac book pro NEVER and i quote crashed until this patch and from happening every 10 or so minutes it is happening every 1-2 minutes even doing nothing! ------------------------------------- MBP-2.6ghz-4gb-200gb 7400rpm-8600gt
|
|
callder
Gallente Covert Agenda
|
Posted - 2008.10.25 21:54:00 -
[31]
iMac 20" 2.4 GHz 3gb RAM, running OSX 10.5.5. Since the patch the overall game has slowed, everything is laggy and crashes happen more frequently. |
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.26 03:01:00 -
[32]
Originally by: CCP Casqade
1. After the first crash occurring, do not relaunch the client 2. Start the Activity monitor 3. Check if you see if there is a "cider" or "wineserver" process running.
I've monitored a running 'ps' throughout the crash incident and each time cider/wineserver are not running post-crash.
Quote:
4. ./cider -debugmsg +seh,+tid,+module,+debugstr &> ~/Desktop/EVEcrashlog.log 5. Have the crash occur 6. Compress the logfile generated on your desktop 7. Attach to a bug report with the title "Mac crash issue - For Casqade"
Done. It is ticket #64347. The log is 1.2mb (84kb, gzipped). Presumably, multiple sets of debug data from the same environment would be helpful. Shall I upload a few more? If so, shall I do so under this same ticket?
Much appreciation for the attention to this issue. |
Cornina Tesla
|
Posted - 2008.10.26 03:26:00 -
[33]
Edited by: Cornina Tesla on 26/10/2008 03:26:35 Just so I understand ..
We're expected to debug this client we're paying good money to use? Did anyone consider perhaps testing the patch before attempting to deploy it? I run my own internet business and I know that changes are necessary and how bad I get bitten in the a** when I don't properly test a deployment. At the very least CCP could give us what's actually being done to resolve this instead of putting the onus back on us (the paying customers) to do their testing for them. |
Ami Nia
Caldari
|
Posted - 2008.10.26 05:00:00 -
[34]
Originally by: Cornina Tesla Edited by: Cornina Tesla on 26/10/2008 03:26:35 Just so I understand ..
We're expected to debug this client we're paying good money to use?
No. We are expected to give them the information they need to debug it.
Originally by: Cornina Tesla Did anyone consider perhaps testing the patch before attempting to deploy it?
They did. They tested it and found it unstable. So they delayed it. When their testing told them it was working they deployed it. Now they can do two things: 1) say: it works on our machines. The problem is with you. 2) say: send us a log of what happens on your machine and we'll look at it.
Originally by: Cornina Tesla I run my own internet business and I know that changes are necessary and how bad I get bitten in the a** when I don't properly test a deployment.
What kind of internet business? If it's server based, does it work for all the browsers and all the browser versions on all the platforms?
Did you ever try supporting a complex widely used software that runs on the client machine? And by complex I mean sufficiently complex that if you run it on 50 different test machines in your lab you get no less than 4 or 5 different behaviors. And with widely used I mean it is used by a few thousands people, each having a different machine/setup.
I agree with you that CCP is lacking badly in their support of the Mac platform. But I strongly disagree with your attitude that the users are not supposed to help improving (and fixing) the software.
Originally by: CCP Mitnal So we can 1 v 1 with Garmon.
|
Betadorian
|
Posted - 2008.10.26 06:45:00 -
[35]
Edited by: Betadorian on 26/10/2008 06:54:24 Edited by: Betadorian on 26/10/2008 06:44:56 To help improve the game is one thing. To help make the client run is another.
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.26 06:58:00 -
[36]
Originally by: Cornina Tesla Edited by: Cornina Tesla on 26/10/2008 03:26:35
We're expected to debug this client we're paying good money to use? Did anyone consider perhaps testing the patch before attempting to deploy it?
You must not be familiar with software development.
Predicting or encountering every possible defect that could occur in every possible environment and way a piece of software could possibly ever be used is not feasible. If someone encounters a catastrophic bug before release, I'm sure they'll address it. But just because a large portion of the player-base encounters a bug doesn't mean that the QA process internally came across it.
And when you do encounter a defect, you can't expect someone to know what the problem is and how to solve it based on "it doesn't work". You need to provide as much detail as possible both in terms of a reproducible test-case and and actual data for analysis (core dumps, pstacks, involved libraries, error messages, log files, system environment, etc). Could you imagine asking your mechanic to fix your car based on "when I try to start my car it doesn't work"?
And then, once a problem has been identified and a test-case provided you still usually need a business case. That is, a business justification to assist in prioritizing the defect. For instance, five people on peculiar systems running into a crash every few hours is less significant than ten thousand people who can't even get the client to launch in the first place. It involves estimating the potential impact, severity and financial cost to both the developer and the customer/business/end-users.
Now, I'm sure you encounter problems in your internet business regardless of how much effort you put into testing things out prior to rolling them out to the paying public. Some things are inevitable. That's why there are backup plans and redundant systems in most places of business.
If you think gathering a very simple set of debug data for a videogame is absurd, I'd be greatly dissatisfied in having to deal with you on a professional level.
I'm a developer at a software/hardware company known for a particular UNIX based OS that came out of Stanford. We have a number of major enterprise server applications that are used by the largest companies, governments and institutions the world over. From JPL and NASA to universities and the US Army and Comcast and Sprint and AT&T and Cingular. They are the most vital, mission-critical, massive deployments you could ever imagine for everything from web servers, application servers, email servers, ldap servers, identity servers and calendar servers. They pay tens of millions for our software (and hardware) and then often pay six or seven figures per year for support contracts for this software.
And guess what? When their email server borks and starts crashing repeatedly under some abnormality within their system or a tuning issue or quirk in their 30,000,000 mailbox environment, they don't come to us and say "fix it now - without any data!".
Despite the many millions of dollars invested and the extreme urgent nature of their services, they understand -- to an individual -- that they need to work with us to ascertain the particulars of their deployment, environment and the particular crashing circumstances. And then we analyze the data and - if necessary - write and test a hotfix to deploy to their system as quickly as possible to address it.
However, if they take the "we're expected to debug this software we're paying good money to use?!" attitude? We can't help them. No amount of money could help us help them. We aren't Kreskin. We can't conjure up a solution to a vague problem description or an irreprodicable incident.
Unless CCP is able to and has reproduced the exact same problem internally, they wouldn't necessary have a clue what is wrong and nothing would be done to resolve it. That is why they request the debug data from their user-base. |
Paula Quartz
|
Posted - 2008.10.26 09:12:00 -
[37]
Originally by: Qordel
Originally by: Cornina Tesla Edited by: Cornina Tesla on 26/10/2008 03:26:35 Unless CCP is able to and has reproduced the exact same problem internally, they wouldn't necessary have a clue what is wrong and nothing would be done to resolve it. That is why they request the debug data from their user-base.
I suggest all Fanfest attendees bring their Mac's and have a big "check this out, *CRASH*" sitdown with CCP
Seriously, thanks for the insightful post. |
callder
Gallente Covert Agenda
|
Posted - 2008.10.26 15:18:00 -
[38]
Quote: I suggest all Fanfest attendees bring their Mac's and have a big "check this out, *CRASH*" sitdown with CCP
Seriously, thanks for the insightful post.
that might be the only way |
Sai Pantian
|
Posted - 2008.10.26 17:37:00 -
[39]
Originally by: Qordel However, if they take the "we're expected to debug this software we're paying good money to use?!" attitude? We can't help them. No amount of money could help us help them. We aren't Kreskin. We can't conjure up a solution to a vague problem description or an irreprodicable incident.
Qordel raises some very good points. The takeaway is that it's each individual's responsibility to make sure to communicate to CCP with as much information as possible any problems they're having, if they expect CCP to affect change.
There is also the unfortunate "Internet echo chamber" phenomenon, where people reading the EVE Forums or chatting on the OS X channel are left to believe that since they have problems, everyone else must be having problems as well. and that's simply not the case.
For example, I've seen graphical oddities with the latest patches in stations, and I fully admit that I've had stability problems in the past. But I've been using the Mac builds since they were first released a year ago, and they're a lot better, both in terms of performance and stability *on my system* than they used to be.
I don't discount in any way the problems people are having with the Mac client. I know, from direct experience, how incredibly frustrating it can be, especially when you're paying good money for the privilege of playing online. But let's temper our disappointment and anger with the understanding that CCP is definitely aware of the problems.
And yeah, I'm hoping that we'll get a chance at Fanfest in a couple of weeks to sit down with CCP and TransGaming (who I know is going as well) to discuss what's happening with the Mac client and get some consensus on what's going to happen in the future.
|
Hartlier Xirone
Caldari Deep Core Mining Inc.
|
Posted - 2008.10.26 20:00:00 -
[40]
I've only had one crash yet using my Alu iMac 20" 2.4Ghz, 4GB Ram, ATi X2600
During Mission Damsel in Distress, when it was al lot of enemies on screen it throwed me out on desktop. Haven't happened after that, have been sitting in hour in station too. ___________________________________
"Building the Future and keeping the past alive is one and the same Thing" |
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.26 20:06:00 -
[41]
Originally by: Hartlier Xirone I've only had one crash yet using my Alu iMac 20" 2.4Ghz, 4GB Ram, ATi X2600
During Mission Damsel in Distress, when it was al lot of enemies on screen it throwed me out on desktop. Haven't happened after that, have been sitting in hour in station too.
Out of curiosity, are you playing in full-screen?
What happens if you do CMD+ENTER to switch into windowed-mode and then tab to other programs and back into EVE every now and then / off-and-on? It'd be interesting to know if your relatively stable system suddenly becomes unstable as far as eve is concerned.
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.26 22:08:00 -
[42]
So, I've provided a set of data to CCP via an open bug, which I'm sure they'll analyze shortly. However, upon reviewing several sets of data I've generated from reproducing the problem, I notice that the stack traces show the crashed threads occurring in the same process, regarding reading affiliate.plist (I'm not sure what that is?) which is missing.
Don't take anything I say here as gospel. Just some insight from my own review of the data. Don't take any actions on it. Probably useless to do so.
Each stack trace shows that the cider process crashes just after CFDictionaryGetValue, trying to read affiliate.plist (which the crash log says is missing). The crashlog also says "old-style plist parser: missing semicolon in dictionary", which makes me wonder if something is improperly written to the .plist file and then reading it back in causes a null-pointer/memory problem, forcing the cider crash.
If the affiliate file retains some sort of configuration data, it could make sense. After all, CMD+ENTER temporarily sets the configuration variable, but not permanently. Perhaps CMD+ENTER writes windowed mode to file and then re-reads that file, causing a crash. Or perhaps it just re-reads that file when it goes into windowed-mode (without making any changes to it) and realizes the file isn't there. Again causing some sort of memory problem.
However, the only reference to affiliate.plist in all of google points back to the EVE forums, where it is indicated that this file doesn't need to exist (there was even a bug opened against it once some time ago, which was closed). And second, that in the few cases that people have encountered this problem, it has been something to do with their user directory being mounted on a networked drive or otherwise corrupted - neither of which should be the case here unless the patch update itself corrupted the install (which was operating just fine minutes before).
STACK TRACE Process: cider [27287] Path: /Applications/EVE Online.app/Contents/MacOS/cider Identifier: com.transgaming.EVEOnline Version: 2.3 Mac (1) Build Info: Cedega-5.3~5.3 Code Type: X86 (Native) Parent Process: launchd [1]
Date/Time: 2008-10-26 15:22:07.061 -0600 OS Version: Mac OS X 10.5.5 (9F33) Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000000d7183dcb Crashed Thread: 0
Thread 0 Crashed: 0 libobjc.A.dylib 0x91511688 objc_msgSend + 24 1 com.apple.CoreFoundation 0x91e5a1fd CFDictionaryGetValue + 141 2 com.apple.Foundation 0x96dd0b22 NSMapGet + 50 3 com.apple.AppKit 0x9526ebae -[NSCursor dealloc] + 286 4 libsdldrv.dylib 0x55c7ae7e SDLDRV_CreateAndApplyCustomMacCursor + 602 5 libsdldrv.dylib 0x55c79ade SDLDRV_DoRecreateCursorImage + 47 6 libsdldrv.dylib 0x55c7a70b SDLDRV_MainThreadCheckForSpecialUI + 408 7 libsdldrv.dylib 0x55c71bc6 SDLDRV_MainThreadEventLoop + 16 8 cider 0x80004bac -[WineMain applicationDidFinishLaunching:] + 115 9 com.apple.Foundation 0x96dc12dc _nsnote_callback + 364
CRASH LOG 2008-10-26 15:18:11.073 cider[27283:10b] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary. 2008-10-26 15:18:11.094 cider[27283:10b] Error reading affiliate.plist:The file ôaffiliate.plistö does not exist. Could not stat /Applications/EVE Online.app/Contents/Resources/transgaming/f_drive (No such file or directory), ignoring drive F: 2008-10-26 15:18:11.806 cider[27283:5513] *** _NSAutoreleaseNoPool(): Object 0x3e5be790 of class NSCFDictionary autoreleased with no pool in place - just leaking
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.26 22:13:00 -
[43]
For others encountering this situation -- specifically when CMD+ENTER-ing to go into windowed-mode. I'd appreciate knowing if your crash data mirrors mine above. Plese do the following, if you're comfortable with it.
+ Launch 'Crash Reporter' and select "Developer" mode. + Follow CCP Casqades command line instructions previously in this thread which launch EVE/Cider in debug mode from the command line. + Log into EVE, CMD+ENTER into windowed-mode and then reproduce the crashing situation.
Once the crash occurs, click on the crash reporter's "SEND REPORT" button. This will pull up a window where you can see specific details about the crash. Select the tab on that window that shows stack trace data in the format of my above posting example. Does the crashed thread show CFDIctionaryGetValue, too? Does it show cider crashing and the same exception type/code?
Now open up the debug eve log file which should be on your desktop. Do the most recent log entries mention affiliate.plist missing?
I'd be highly curious to find this out, because everything else I've read claims that affiliate.plist does not need to exist and that errors involving it seem to indicate permissions/corruption/network drive issues -- but if the same issue is happening to all of us (or many of us) immediately after patching, then I'm not sure of another explanation beside the patch installer changing permissions on us or otherwise corrupting the data.
If you get a chance... let us know.
Please run the debug command line to launch EVE that CCP Casqade posted earlier in the thread. |
Hartlier Xirone
Caldari Deep Core Mining Inc.
|
Posted - 2008.10.26 23:04:00 -
[44]
Originally by: Qordel
Originally by: Hartlier Xirone I've only had one crash yet using my Alu iMac 20" 2.4Ghz, 4GB Ram, ATi X2600
During Mission Damsel in Distress, when it was al lot of enemies on screen it throwed me out on desktop. Haven't happened after that, have been sitting in hour in station too.
Out of curiosity, are you playing in full-screen?
What happens if you do CMD+ENTER to switch into windowed-mode and then tab to other programs and back into EVE every now and then / off-and-on? It'd be interesting to know if your relatively stable system suddenly becomes unstable as far as eve is concerned.
I haven't tested CMD+ENTER for Windowed Mode but I have tabbed alot between FireFox and EVE without any notisable unstability, I'm gonna test Windowed mode tommorow and report back.. ___________________________________
"Building the Future and keeping the past alive is one and the same Thing" |
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.26 23:29:00 -
[45]
Edited by: Qordel on 26/10/2008 23:30:34 I have successfully played EVE in CMD+ENTER windowed mode for awhile now, without crashing (previously I could generate a crash within minutes).
Taking a cue from the only previous issues I could find referencing "affiliate.plist" not existing (as the stack traces and logs indicate), I decided to purge the client and perform a number of maintenance routines (in my case, just using Onyx) to address permissions and caches. I'm not sure why cider was trying to read a file that isn't there and (supposedly) doesn't even *need* to be there. However, this seems to have addressed my problem.
I suspect this could be what other people are encountering, still. I don't think it is unique to my situation and I do have some suspicions that the EVE patch was responsible for doing something to the installation that caused this behavior.
Why do I believe this? Because EVE ran fine for a number of months with no changes (except the released patches to it). The problem only began immediately after logging in, performing the recent patch update and then re-starting the EVE client. Immediately.
Now, I should note that the client I just installed is the latest downloadable version - eve-001881_64451_mac.dmg while my previous existing installation had been eve-001481_58188_mac.dmg -- which was then patched up to each latest edition automatically.
So, the next step will be to remove the latest full install and then re-install the older version. I'll then let it automatically patch-update and see if the crashes return. If they don't, I guess that doesn't necessarily remove suspicion from it still being some sort of patch-update issue, but it would at least show that achieving a non-crashing state may be possible by starting with a clean slate.
So, to repeat what I just did:
+ Uninstalled EVE. + Emptied the trash. + Launched my Onyx utility and let it check SMART status. + Verified permissions under Maintenance. + Ran daily/weekly/monthly scripts (even though they were recently run) + Rebuilt LaunchServices. + Ran the default selections for System, User, Logs, Misc under Cleaning. + Restarted OSX. + Installed the latest full Eve installer downloaded from EVEOnline (it's about 700mb now), which is eve-001881_64451_mac.dmg
|
Tridik
Caldari the united
|
Posted - 2008.10.26 23:32:00 -
[46]
So whens the fix patch coming out, or is it time to cancel? |
Ami Nia
Caldari
|
Posted - 2008.10.26 23:59:00 -
[47]
AFAIK the affiliate.plist file is only used internally by CCP/cedega for development and need not be deployed.
The check for affiliate.plist is done very early, before the client is loaded.
Also the "Old-style plist parser: missing semicolon in dictionary." warning is generated by CFPropertyListCreateFromXMLData() very early, even before the client is actually loaded. You can see both it appear on the console (if you have it open) as soon as you run the client.
The actual crash is an access to an invalid address. It does NOT happen after any tentative access to the affiliate.plist or something like that.
It happens within objc_msgSend which is a core function of Objective C used for sending a message to an object (aka calling a method). That function is called from CFDictionaryGetValue that is part of CoreFoundation. In turn that is called from NSMapGet wich is called by the deallocation of a NSCursor object. all this happens inside the Apple libraries.
Going back again in the stack trace you see the cursor is being deallocated as part of the creation of a new cursor icon from within SDL (SDLDRV_CreateAndApplyCustomMacCursor called by SDLDRV_DoRecreateCursorImage called by SDLDRV_MainThreadCheckForSpecialUI).
In other words, something is wrong in the way the client (probably the cedega code) handles the redisplay of the cursor used by the game when you switch back from another application to the EvE Window. Probably an erratic pointer or something like that slipped through. This may or may not be related to the missing autorelease pool warning we can also see when the client starts: both that warning and this invalid address are signs that someone in cedega did not handle memory allocation/deallocation properly.
Originally by: CCP Mitnal So we can 1 v 1 with Garmon.
|
Ami Nia
Caldari
|
Posted - 2008.10.27 00:09:00 -
[48]
Originally by: Qordel I'd be highly curious to find this out, because everything else I've read claims that affiliate.plist does not need to exist and that errors involving it seem to indicate permissions/corruption/network drive issues -- but if the same issue is happening to all of us (or many of us) immediately after patching, then I'm not sure of another explanation beside the patch installer changing permissions on us or otherwise corrupting the data.
No. The warning about the missing affiliate.plist file has been with us for a while, even before the recent patches.
The errors involved are the errors you get when a file cannot be accessed. They are the same errors you can get when you have permission problems or corrupted data or network problems just because those problems also prevent you from accessing a file. The file is not there, it most probably does not need to be there and the warning diagnostic you see is benign.
You probably only need to worry about not having that file if you are an affiliate of transgaming and are developing software to run on cedega.
Originally by: CCP Mitnal So we can 1 v 1 with Garmon.
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.27 00:32:00 -
[49]
Edited by: Qordel on 27/10/2008 00:35:12
Originally by: Ami Nia
In other words, something is wrong in the way the client (probably the cedega code) handles the redisplay of the cursor used by the game when you switch back from another application to the EvE Window. Probably an erratic pointer or something like that slipped through. This may or may not be related to the missing autorelease pool warning we can also see when the client starts: both that warning and this invalid address are signs that someone in cedega did not handle memory allocation/deallocation properly.
Yes, it's clearly a null-pointer / malloc issue, but I concluded due to the matching method in the stack and the reference in the log file that it was perhaps not due to the cursor function (first guess) but poor handling of a problem with the plist being read in. I suspected this because of the log entry regarding it and "CFDictionaryGetValue" prior to the msgSend (suspecting, perhaps incorrectly, that CFDictionaryGetValue was probably just reading a key/value pair from the plist file).
Clearly I was wrong and sniffing a red herring there. Before I went traipsing off on the affiliate.plist thing, the cursor seemed rather likely simply based on the fact that the issue often occurs not just when moving back and forth between the game and other windows (in windowed mode) but also when right-clicking certain things (like training new skills).
Anyway, it should be simple enough to reproduce if it is a problem with the most recent existing client code - but I can't get up to the latest patch level again now. I installed the latest downloadable OSX client and installed it with no problem. Was even able to run it without incident for awhile (no crashes).
But, when returning to the older client and allowing it to patch-update itself, it downloads the 40+mb patch and then throws an error that it was unable to verify/authenticate the downloaded patch and then stops. I've let it try to redownload it twice. I've even wiped everything again and re-installed (using the old version) all over again -- only to have the patch die upon re-download again.
So, for the time being I'm going to just install the latest full client and see if it starts happening again. Hopefully more people encountering what they have described as similar issues will be able to pull the same data and see if the crashes match up. |
DreadedHunter
|
Posted - 2008.10.27 00:35:00 -
[50]
I'll post my crash logs when I get home tonight but mine are from recollection duplications of:
2008-10-26 15:18:11.806 cider[27283:5513] *** _NSAutoreleaseNoPool(): Object 0x3e5be790 of class NSCFDictionary autoreleased with no pool in place - just leaking
|
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.27 00:39:00 -
[51]
Originally by: DreadedHunter I'll post my crash logs when I get home tonight but mine are from recollection duplications of:
2008-10-26 15:18:11.806 cider[27283:5513] *** _NSAutoreleaseNoPool(): Object 0x3e5be790 of class NSCFDictionary autoreleased with no pool in place - just leaking
Also be sure to launch CrashReporterPrefs (you can find it with spotlight, if needed). It's just a simple window with three options to select crash reporter mode. If you select "Developer" before launching EVE it should produce a full stack trace that will make comparisons easier (just look at the thread that is indicated as the crashing thread).
I don't do any real work on OSX (unix guy) so I'm not sure if there are more preferred methods to gather this data, but that's what works for me, so . . .
But based on the log error, it matches at least part of what the above thread shows.
It'll also be interesting to see if I really no longer encounter the problem after installing the full latest downloadable client, instead of the patched-up version. Presuming they're the same set of running code... |
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.27 00:52:00 -
[52]
Originally by: Tridik So whens the fix patch coming out, or is it time to cancel?
CCP already pinged me hours ago to request some additional data on the crashes for the bug I filed, which I then updated. I'm sure they'll start reviewing it again in the morning. If it's something they can fix, I'm sure they'll review their options, work the fix in, test it and roll it out as soon as possible.
In the mean time, the workaround would appear to be running in full-screen mode - presuming you are not crashing frequently in that mode, too.
Another workaround (unproven) at this point, but seems to be better for me so far) would be to remove your currently installed EVE application. Purge your trash. Then download and install the very latest full EVE client installer. I was able to run for at least an hour in windowed/CMD+ENTER mode (and no crashes at all) compared to crashes within minutes previously.
If you are experiencing very chronic crashes while in FULL-SCREEN mode, it may be a different issue entirely. Follow the above steps (both provided by CCP Casqade to gather debug logs and my earlier instructions to gather stack traces with the Crash Reporter) and comparing the crashed thread from the stack (the interface will tell you what thread number it was) to what I posted above. If you want, you could post those few lines here and probably take a peak, too. If it's entirely different, it may be worthy of another bug being filed as a unique issue.
Definitely not worth quitting, as long as it still works in full-screen mode. It's very inconvenient (especially if you have multiple monitors, since EVE blacks out all extra monitors!), but still mostly playable. And since the bug was only filed in the last 24 hours . . . I mean, they need time. |
Tridik
Caldari the united
|
Posted - 2008.10.27 01:08:00 -
[53]
Being forced to play in fullscreen is NOT a solution. Nor is it viable for me. My issues and errors are the same as everyone else has been posting. Fullscreen isnt an option. Tried redoing both client installs, and after starting, insta crashed.
Im not looking for a work around. Im looking for a solution to a problem CCP caused. |
Ami Nia
Caldari
|
Posted - 2008.10.27 01:09:00 -
[54]
Originally by: Qordel I don't do any real work on OSX (unix guy) so I'm not sure if there are more preferred methods to gather this data, but that's what works for me, so . . .
But based on the log error, it matches at least part of what the above thread shows.
Well, there are some wonderful debugging/tracing tools around, if you installed the developers package. If you are a developer, you may want to check them out. But using those on the EVE client I think would be EULA challenging. Crash reporter is an end user tool. And so are any logging functionality the client or the cedega layer provide us (like the command line options Casqade told us to use). Guesswork from information available from those reports can hardly be considered "reverse engineering" or against the EULA. Tracing each and every call an application makes, together with the arguments and the return value, however, I think it would.
As for the warning about an autoreleased dictionary, I think it may be benign. It only happens once at the very beginning, so there's no real leak. However it is extremely easy to fix for cedega, as soon as they find out which thread is autoreleasing before setting up an autorelease pool.
|
Ami Nia
Caldari
|
Posted - 2008.10.27 01:17:00 -
[55]
I also think that running in full screen mode is not a solution. But I agree that maybe transgaming people are not working at night on weekends and we will probably have a third patch attempt sometimes this week.
Unfortunately ... I'm not sure I want them to succeed, as the new cedega layer is taxing my MacBook Pro much more than the old version and running two instances is nearly impossible now.
Originally by: CCP Mitnal So we can 1 v 1 with Garmon.
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.27 01:27:00 -
[56]
Originally by: Ami Nia Guesswork from information available from those reports can hardly be considered "reverse engineering" or against the EULA. Tracing each and every call an application makes, together with the arguments and the return value, however, I think it would.
I'm not really sure that would be a valid complaint on anyone's part. A debugger is an inherent utility with an operating system (gdb/adb/etc) and the operating system is configured to drop core files. And you have the libraries on your system from the installation. Unless the xcode (presume that's what you're referring to?) utilities offer more than just the ability to step through functions/threads/executions/memory addresses and symbol tables, I wouldn't see what the big dela could be - they're all debugging utilities and software you own on your system. Not breaking anything or changing anything. Just analyzing crash data.
As far as I'm concerned, it's like fixing your car. You have a right to know what each part is and analyze what each part is doing to determine where in the vehicle the problem lays.
If you were *doing* something with that info, that could potentially be an issue, I suppose. Like writing some TSR crack based off of a dump and some hex work... or whatever...
|
Mara Rinn
Minmatar
|
Posted - 2008.10.27 02:04:00 -
[57]
"p" drive, affiliate.plist, and a bunch of other complaints pop up before the EVE client even displays the login window.
However, the note about the cursor is interesting - I use Teleport to use my iMac keyboard + mouse to control my MacBook too. When my iMac is not running EVE, the cursor disappears from the iMac screen when I'm controlling the MacBook. When EVE is running, the cursor stays on the iMac screen - all button presses go to the MacBook though. It gets quite annoying!
I'll be following the instructions for tracking down this bug tonight, I expect in my four hour session I'll see at least six crash-to-desktop instances.
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.27 06:59:00 -
[58]
After completely removing EVE and installing the latest downloadable version of the full EVE installer, I have been able to run in Windowed mode for more than four hours straight, now.
Previously, I had been operating with an older version of the client which had simply been auto-patched with each update. Removing that (specific version mentioned in a previous post on this thread) and installing the latest one available on this site seems to have resolved the issue (so far, at least).
So if your crash data looks similar to mine and your base install is an older version of EVE that has been auto-patched up to the latest code, it might be worth doing a full uninstall, clear your trash - possibly even run some maintenance (something like the Onyx utility) and then downloading the latest installer may help.
I tried to confirm if it was a problem with the old version plus auto-patching on top of it by installing the older version and letting it auto patch itself, but every time it completes the patch update download, it complains that it can't verify the patch download and will therefore not apply it. So verifying that (on my end at least) is not possible. |
Ami Nia
Caldari
|
Posted - 2008.10.27 15:04:00 -
[59]
Originally by: Qordel I'm not really sure that would be a valid complaint on anyone's part. A debugger is an inherent utility with an operating system (gdb/adb/etc) and the operating system is configured to drop core files. And you have the libraries on your system from the installation. Unless the xcode (presume that's what you're referring to?) utilities offer more than just the ability to step through functions/threads/executions/memory addresses and symbol tables, I wouldn't see what the big dela could be - they're all debugging utilities and software you own on your system. Not breaking anything or changing anything. Just analyzing crash data.
As far as I'm concerned, it's like fixing your car. You have a right to know what each part is and analyze what each part is doing to determine where in the vehicle the problem lays.
If you were *doing* something with that info, that could potentially be an issue, I suppose. Like writing some TSR crack based off of a dump and some hex work... or whatever...
I can see your point. But there's a difference between your car and a software. Technically speaking you own your car, but the software is covered by a license and you do not own it. If you were to rent a unique car, you would not have the right to analyze it in any way. Not even to fix it. At least not if the rental contract tells you you cannot and your own remedy is to call them if you have any problem.
Technically reverse engineering the client is against the EULA. What constitutes reverse engineering and what constitutes collecting data for the debuggers? The line is a little blurry, of course. Using the crash reporter and providing them a crash log that they told you how to create and provide, is definitively within the license terms. Generating detailed trace data of a live application and analyzing it or using a debugger to peek into the inner workings of the code, may well be considered reverse engineering even if you do not use the knowledge you gain for anything bad.
Originally by: CCP Mitnal So we can 1 v 1 with Garmon.
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.27 15:28:00 -
[60]
I don't think that debugging a problem (whether or not it is on the suggestion of the developer) qualifies as reverse engineering a product. And reverse engineering a product is normally not in violation of anything, either. A lot of software and hardware technologies that are used today are the result of reverse engineering. Unfortunately, software is currently a different beast thanks to the combination of patents *and* copyright, making some legal rulings fall against reverse engineering.
But for the sake of debugging, you're not doing anything that exposes any proprietary code. At best, you're revealing method names and data passed to them and the order in which they were called (and crashed). And this data is already provided to your system and utilities, so you're not performing any DMCA violating actions either.
It would be fascinating to know the details if any company has ever actually tried to claim that debugging an application on someone's system was in anyway a violation of anything though.
|
|
Nekopyat
|
Posted - 2008.10.27 16:23:00 -
[61]
Ok, trying to run the client with the debug flags+log as suggested so hopefully I"ll be able to get more details, but here is I what I do know so far:
Starting in Full Screen Switching to windowed (after having logged in) Switching between EvE and Camino EvE client crashes on bringing brought to the foreground Happens both in and outside stations.
I did kill off cider and wineserver which returned a bunch of memory to the system. Nicing the process seemed to help for a while. My top looks like:
Processes: 61 total, 4 running, 57 sleeping... 236 threads 12:22:12 Load Avg: 1.16, 1.10, 1.15 CPU usage: 52.0% user, 11.5% sys, 36.6% idle SharedLibs: num = 172, resident = 35.0M code, 4.99M data, 16.9M LinkEdit MemRegions: num = 13505, resident = 807M + 13.3M private, 249M shared PhysMem: 195M wired, 549M active, 1.03G inactive, 1.76G used, 246M free VM: 14.2G + 127M 228596(3) pageins, 78540(0) pageouts
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 7909 top 11.3% 0:04.87 1 18 20 1.58M 492K 2.06M 27.0M 7908 cider 97.8% 7:26.82 18 207 1916 342M 138M 366M 4.27G 7907 wineserver 0.0% 0:01.09 2 27 35 192K 32.8M 1.04M 60.1M
With the vsize being of particular worry. |
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.27 16:35:00 -
[62]
Originally by: Nekopyat Ok, trying to run the client with the debug flags+log as suggested so hopefully I"ll be able to get more details, but here is I what I do know so far:
Yeah, 4gb seems a little much.
Can you launch CrashReporterPrefs and set it to "Developer" and then make it crash again and look at the trace that it produces? It'll pop up a window. Click "report" and then switch to the tab that shows a big window full of text. It'll show a stack trace. Find the thread that crashed and see if you can paste just that chunk (it should be about ten lines) here -- perhaps along with the name of the process it says crashed and the type/event it says was the cause.
Might help us all figure out if we're seeing the exact same thing, even though the described symptoms already sound similar. |
Nekopyat
|
Posted - 2008.10.27 16:56:00 -
[63]
Originally by: Qordel
Can you launch CrashReporterPrefs and set it to "Developer" and then make it crash again and look at the trace that it produces?
Already had the crash and sent that in, but now I've set the crash report pref an am running again to see if I get it again. |
Hartlier Xirone
Caldari Deep Core Mining Inc.
|
Posted - 2008.10.28 19:28:00 -
[64]
Have tested EVE for 1-2 hours in WIndowed Mode, get about 5-10FPS lower AVG.FPS, otherwise it seems quite stable.
Got one more of these random crashes during a Kill Mission again. ___________________________________
"Building the Future and keeping the past alive is one and the same Thing" |
Bernadictus
Caldari BlackScope Black Scope Project
|
Posted - 2008.10.29 10:46:00 -
[65]
Edited by: Bernadictus on 29/10/2008 10:50:03 I'm running the latest patched EVE client on my 2008 iMac too,and I mainly crash when switching my windowed eve with Entourage, Expose, AdiumX, Illustrator, InDesign, Photoshop and a whole load of other applications.
|
WisdomLikeSilence
Federal Defence Union
|
Posted - 2008.10.29 12:44:00 -
[66]
I was having crashes every few seconds. On the advise of another poster here I logged out and logged back in and I havent crashed since. Its a weird thing to do on a mac, since with just one user you never really see the log in screen, but try it.
Im running 3 instances on a new Imac with the 8800 nvidia card. Framerate is ass, but its rock solid now.
|
droii
|
Posted - 2008.10.30 13:38:00 -
[67]
Yeah, unplayable much?
Just 15 min sitting in a pos not touching anything makes it "nosedive". Accualy pressing buttons can make it worse, not always thu. Just dont try to be doing anything else on the computer...that just ends baaaad! (Numerous bugs logged in the system, just posting here to "keep the pressure up".)
Model Name:iMac Model Identifier:iMac8,1 Processor Name:Intel Core 2 Duo Processor Speed:3.06 GHz Number Of Processors:1 Total Number Of Cores:2 L2 Cache:6 MB Memory:2 GB Bus Speed:1.07 GHz
Chipset Model:NVIDIA GeForce 8800 GS Type:Display Bus:PCIe PCIe Lane Width:x16 VRAM (Total):512 MB Vendor:NVIDIA (0x10de) Device ID:0x0609 Revision ID:0x00a2
|
Verite Rendition
Caldari F.R.E.E. Explorer Elitist Cowards
|
Posted - 2008.10.30 19:08:00 -
[68]
Originally by: droii Yeah, unplayable much?
Just 15 min sitting in a pos not touching anything makes it "nosedive".
For some reason POSs just **** the EVE client, it happens under Windows too. The difference tends to be that the Mac client is doesn't have much in the way of performance it can shed before it's grinding to a halt. ---- FREE Explorer Lead Megalomanic EVE Null-Sec Player Influence Map http://dl1.eve-files.com/media/corp/Veritefw/FWinf |
Morn Judith
Caldari
|
Posted - 2008.10.31 12:24:00 -
[69]
Lots of crashes here as well. Not even two minutes every time, never fails. Weird, i patched, was on for 7 hours, then ran software update for OSX and NOW it crashes. I want to say it conflicted with recent OSX software updates. Good luck guys!!
-Macbook Pro 2.4ghz, 8600gtm, old school client
Quote: Bah, Eve>women. Heck, I left my wife for eve. Well, that and because she had a boyfriend.
|
Batuka
|
Posted - 2008.10.31 15:32:00 -
[70]
Echoing many posts already. Too unstable to run missions/haul through low-sec due to constant crashing. Uploading EVE client again right now to see if this will change. Also horrible graphics since patch as well!
|
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.10.31 22:16:00 -
[71]
Originally by: Morn Judith Lots of crashes here as well. Not even two minutes every time, never fails. Weird, i patched, was on for 7 hours, then ran software update for OSX and NOW it crashes. I want to say it conflicted with recent OSX software updates. Good luck guys!!
It's probably the latest client patch and not OSX. When it crashes, are you playing in full screen or in windowed mode?
If you can gather the requested data and open a bug report to CCP on this site, they can use that data to further address the problem and attach it to an internal defect. I haven't seen any indication from CCP that they have all the crash data they need from us, so it wouldn't hurt to send it along.
If you're up for it, just read the first couple pages of this thread including CCP Casqade's instructions for running in debug mode to gather debug logs as well as my comments about setting OSX to gather stack traces and profile info. Then open up a bug, attach the files with a description of your system, problem and how you reproduce it and they should get back to you.
That said, I haven't seen/heard any update to the defect (other than the initial request for a little more info from me) since it was filed more than a week ago. Hopefully we'll at least get some sort of acknowledgement that the problem is understood now or if it's in the process of being fixed or if it's fixed and being QA'd or... whatever (since the report online doesn't seem to really offer a way to get a status on it).
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.11.01 02:44:00 -
[72]
Edited by: Qordel on 01/11/2008 02:45:24 From CCP:
Transgaming working on it...
|
Dnaagct
|
Posted - 2008.11.01 15:40:00 -
[73]
I'm crashing a lot running two clients on an iMac 24" 4GB RAM dual core ATI radion HD2600.
The crashes did not happen after patch, when I was running Tiger and launching my lone copy of Eve twice. Crashes started happenening after I upgraded to Leopard, couldn't launch twice and made a 2nd copy. Now they crash frequently on changing windows, especially during session changes. If I don't wait for the session timer to complete before changing windows, one client will crash. And both are super laggy in space now. They weren't using Tiger.
|
Qordel
Caldari School of Applied Knowledge
|
Posted - 2008.11.01 20:44:00 -
[74]
Right, that's not a problem with Leopard though. It's a problem with the Cedega end of the EVE client. The previous patch worked just fine on Leopard and the latest patch started the crashing when in windowed mode.
Clearly there's a difference between Tiger and Leopard that cause different behavior in the same client version, but the problem itself is introduced by the eve (cedega) client; not the OSX upgrade itself.
Certainly is frustrating though.
|
Morn Judith
Caldari
|
Posted - 2008.11.03 23:56:00 -
[75]
Originally by: Qordel
Originally by: Morn Judith Lots of crashes here as well. Not even two minutes every time, never fails. Weird, i patched, was on for 7 hours, then ran software update for OSX and NOW it crashes. I want to say it conflicted with recent OSX software updates. Good luck guys!!
It's probably the latest client patch and not OSX. When it crashes, are you playing in full screen or in windowed mode?
If you can gather the requested data and open a bug report to CCP on this site, they can use that data to further address the problem and attach it to an internal defect. I haven't seen any indication from CCP that they have all the crash data they need from us, so it wouldn't hurt to send it along.
If you're up for it, just read the first couple pages of this thread including CCP Casqade's instructions for running in debug mode to gather debug logs as well as my comments about setting OSX to gather stack traces and profile info. Then open up a bug, attach the files with a description of your system, problem and how you reproduce it and they should get back to you.
That said, I haven't seen/heard any update to the defect (other than the initial request for a little more info from me) since it was filed more than a week ago. Hopefully we'll at least get some sort of acknowledgement that the problem is understood now or if it's in the process of being fixed or if it's fixed and being QA'd or... whatever (since the report online doesn't seem to really offer a way to get a status on it).
I am running it in fullscreen mode, as i never run in windowed mode. Just use alt+tab to switch between apps.
Havent had a problem after that first crash. Crashed again and again, got mad, turned the computer off for the night. Came back to it the next day, played about 8 hour sessions for the next 3 days with only one crash. Weird, but i havent been able to get it to crash again for bug report info.
Quote: Bah, Eve>women. Heck, I left my wife for eve. Well, that and because she had a boyfriend.
|
Apple Boy
Gallente Federation of Freedom Fighters Executive Outcomes
|
Posted - 2008.11.04 06:33:00 -
[76]
currently 1441 works great for me besides the graphics issues that I can deal with, although I'm not excited to go into huge fleet combat with it. 1481 has the graphics issues solved but is just way too unstable. I've been messing around with the sisi client, but it still has the graphics issues . The upside is it's more stable than 1481, downside is it isn't as stable as 1441 and I have yet to be able to consistently reproduce any of the crashes.
|
|
|
|
Pages: 1 2 3 :: [one page] |