Mac Crashing

redwall

When I use my macbook ESO tends to crash everyonce and a while.

Anybody else have this problem?

Calmyron

Yes. It's due to a memory leak from the research I've done. I’m a Mac Consultant, so I was curious to find out why my ESO client kept crashing. I use a memory cleaner to give back unused memory that a program is holding on to even though it’s finished using it. Not too many programs have this issue, but a few do. After a while, I run out of RAM.

When watching how ESO is using memory, I’ve found that when you zone from a building in/out or change zones, ESO asks Finder for enough memory to handle the graphics it needs to build on the screen. The problem comes in where ESO forgets to let go of the memory it was using for the previous zone. It’s stops using it, but doesn’t tell Finder that it’s available for use again. Eventually, ESO gobbles up all the memory and when Finder can’t give it any more, ESO crashes. If you log out characters and move to other characters for banking issues, mainly mules, you’ll hit this problem pretty fast. If you stay on the same character for a while, it might take a couple of hours before it crashes, but it will if you stay on long enough.

I’ve watched this process in Beta and since the five (5) day early access. The ESO updates have not addressed this on the Mac. I have no idea if the PC version has this problem. I used the PC version via BootCamp on my Mac, but I don’t have the same tools to test it with and I didn’t notice the same problem. The PC version would crash from time to time, but I couldn’t pin it down as to why and since it was Beta, I would just post my information on what I was doing at the time and move on.

Please understand that this is purely from my observations. I don’t know enough about their code to narrow it down to what’s doing what, but it seems pretty clear the ESO is hogging the memory and not letting it go properly when it’s no longer using it.

redwall

Calmyron wrote: »

Yes. It's due to a memory leak from the research I've done. I’m a Mac Consultant, so I was curious to find out why my ESO client kept crashing. I use a memory cleaner to give back unused memory that a program is holding on to even though it’s finished using it. Not too many programs have this issue, but a few do. After a while, I run out of RAM.

When watching how ESO is using memory, I’ve found that when you zone from a building in/out or change zones, ESO asks Finder for enough memory to handle the graphics it needs to build on the screen. The problem comes in where ESO forgets to let go of the memory it was using for the previous zone. It’s stops using it, but doesn’t tell Finder that it’s available for use again. Eventually, ESO gobbles up all the memory and when Finder can’t give it any more, ESO crashes. If you log out characters and move to other characters for banking issues, mainly mules, you’ll hit this problem pretty fast. If you stay on the same character for a while, it might take a couple of hours before it crashes, but it will if you stay on long enough.

I’ve watched this process in Beta and since the five (5) day early access. The ESO updates have not addressed this on the Mac. I have no idea if the PC version has this problem. I used the PC version via BootCamp on my Mac, but I don’t have the same tools to test it with and I didn’t notice the same problem. The PC version would crash from time to time, but I couldn’t pin it down as to why and since it was Beta, I would just post my information on what I was doing at the time and move on.

Please understand that this is purely from my observations. I don’t know enough about their code to narrow it down to what’s doing what, but it seems pretty clear the ESO is hogging the memory and not letting it go properly when it’s no longer using it.

wow, seems like you really did your research man.

ZOS_EveP

This thread has been moved from the French Mac Technical Support to the English Mac Technical Support

KhajitFurTrader

Calmyron wrote: »

Yes. It's due to a memory leak from the research I've done. I’m a Mac Consultant, so I was curious to find out why my ESO client kept crashing. I use a memory cleaner to give back unused memory that a program is holding on to even though it’s finished using it. Not too many programs have this issue, but a few do. After a while, I run out of RAM.

When watching how ESO is using memory, I’ve found that when you zone from a building in/out or change zones, ESO asks Finder for enough memory to handle the graphics it needs to build on the screen.

I concur with the gist of your analysis, it's still being discussed in this thread and has been so for a while.

Furthermore, I'm sorry to say this, but...

"Memory cleaners" are snake oil. Not just in OS X, but in all operating systems. The OS is perfectly capable of handling resources like memory all by itself. It's what OSs are built to do in the first place. It's practically Operating System Design 101. I just hope you didn't pay any money for it. You can make all relevant observations you need with the built-in Activity Monitor. Or grab Xcode for a fully-fledged debugger and profiler.

Second, no application, program, or process will ever ask the Finder to allocate anything. The Finder is just another program, if a rather prominent one. Processes use calls to system library functions like malloc(size_t size) and free(void *ptr) to handle memory allocation and release. If you malloc() more than you free(), you'll run into trouble sooner or later (with sooner being the best bet), simple as that. There are also special OS thingies like autorelease of unreferenced pointers, but that would go far for the scope of this reply.

Dimillian

@KhajitFurTrader‌ Perfect. It's exactly the description of a memory leak, and what happening with ESO (I'm sure it'll be fixed soon)

No memory cleaner will help you with that, nor it'll help you with anything, especially on Mavericks where the RAM management has been totally reworked.

Moonraker

The other guys have said it really.

I’ve watched this process in Beta and since the five (5) day early access. The ESO updates have not addressed this on the Mac.

This is not accurate. Ever since testing in mass testing weekends changes were made to the Mac client to try and help reduce the impact of this issue. This was put in before Early Access and has helped reduced frequency especially in PVE questing though there are still more frequent crashes in big battles.

It is a known issue which is not a simple matter of memory not being freed etc. If you check in game the client will often free up memory when you enter a building for instance. But over time the address space gets used up. One of those reasons is memory leak but it's not the only reason why the mac client crashes and the PC doesn't in the same way. The development team continue to work on this as the last remaining main issue in the native Mac client.

The other factor in the difference between the Mac & PC client is the additional data that's loaded into VM at launch of character in the Mac client which reduces the available memory (like a 'buffer') between VM used and the 32-bit 4GB limit (well nearer 3.7GB with overheads) This is proportional to the graphics settings and leaves the Mac client less usable memory. Combined with memory leak and other factors, I think this is why the Mac client tends to crash while the PC client does not (though it has issues especially in PvP of it's own)

You generally wont see technical fixes etc. included in the Patch Notes (I have never seen any PC ones for instance, some Mac ones were added by request to clarify the Intel Iris issue for instance) But they can and do go in after being submitted and going through QA and internal testing (PTS depending is it is up)

For the record, the memory issue is more noticeable now the game is live with the high launch populations as other player density has a big impact on this i.e. crowded towns. So logging to bank alts in a busy bank etc. will certainly add to this. On PTS test server before Early Access I played a week for 4-5-6 hours an evening without one crash mainly due to the fact that there were few other players in game.

Referring to the Finder just makes no sense as @KhajitFurTrader explained and just confuses things. As does use of memory cleaners or purge etc. (one reason Apple removed purge command and required sudo now to run it in Mavericks) With the Compressed Memory now used in 10.9 it's more likely to slow it down than anything. Not that I ever get close to even needed memory compressed with 16GB and that's probably the same with 8GB especially given the Mac client is 32-bit.

The only time I can see purge would be useful is with limited RAM like 4GB and there is only a little free Memory left. In that instance it is better to reboot the Mac before playing and quit all other apps before play including the Launcher will help a lot more.

KhajitFurTrader

Moonraker wrote: »

The only time I can see purge would be useful is with limited RAM like 4GB and there is only a little free Memory left. In that instance it is better to reboot the Mac before playing and quit all other apps before play including the Launcher will help a lot more.

# man purge 8



All that purge(8 ) only ever does is to relabel "Inactive Memory" to "Free Memory" and thus it re-sets the system's memory map to that of an after-boot state, when there have not yet been any user applications run, and then closed. Its only viable use lies in software development and testing. Inactive memory is kind of an "application restart accelerator", a kind of cache (additional to any disk buffers the OS manages), or a transparent ram disk image. And OS X knows better than any program how to handle it.

Start an application, use it, then close it. Then start it again, even after a longer while. Boom! Instantly there. Because the memory that the app last used on its previous run has been labeled "inactive", and on restarting the app, instead of loading the bits from the disk, that last used memory gets reactivated as a fully functional process. Even in the age of SSDs it's still a lot faster to do it this way. There has to be some magic done with (re-)initializing program states and some such, but Apple has learned a lot from iOS, so apps get that logic built right in.

So the thing is, inactive memory is free memory from a process' point of view, i.e. if any process requests more memory than the free pool currently holds, the OS will give the missing amount from the inactive pool automatically, provided there is anything to give at all. There is no speed penalty in doing this, it's instant. Only restarting a previously used app, that has had its inactive memory rededicated, isn't instant any more.

Punch line: there have been commercial "memory cleaners" with lots of fancy widgets and colorful graphics (i.e. "bells & whistles"), that only ever launched purge(8 ) in the background.

Edit: overzealous BBCode is overzealous 8)

Moonraker

@KhajitFurTrader I get all that and understand it in fact why I would not or don't use purge or some other memory cleaner app et and advice against it as you do.

I'm just citing one example where, for some, it seems to alleviate system sluggishness when reduced to a few MBs of free memory. I read that also in Apple support a few times so it may have one certain roll.

Of course what really confuses things is when Apple change all the words they actually use for memory 10.9 is like another language in AM. I got my head around most of it now.

Real Memory (always at least as big as Memory)
Total Memory currently consumed by an application (including Virtual pages)
Memory
Memory used in RAM
Purgeable Memory
Memory which can be cleaned by MMU, if another process needs more real memory.
Then, for the system in total

Physical Memory
The amount of RAM installed.
Memory Used
The amount of RAM being used and not immediately available.
Virtual Memory
The amount of disk or flash drive space being used as virtual memory.
Swap Used
The space on your drive being used to swap unused files to and from RAM.
App Memory
The amount of space being used by apps.
Wired Memory
Memory that can’t be cached to disk, so it must stay in RAM. This memory can’t be borrowed by other apps.
Compressed
The amount of memory in RAM that is compressed.
File Cache
The space being used to temporarily store files that are not currently being use

LOL. Thanks Apple

Publius_Scipio

Seeing as how this is such a jarring issue for most. Playing and then crash. It would be great for some words from ZOS on progress on the matter.

Either way, I hope the day comes soon when we can all be in Cyrodiil for as long as we want without crashing to desktop.

But then again I scratch my head about this because games for ages have been 32 bit and I don't remember encountering crashes related to memory leak.