Memory Leak

Synta - Dreamweaver

Ok so I know this was mentioned in blue's thread but geno wanted new threads for everything.
Let's finally sort this thing...

I'm not particularly clued up technically so I can't go into much detail, but essentially there is a memory leak that causes the RAM to build up. Once it hits 1.8GB, the client crashes.

This is most evident in busy areas and times, such as NW.
Task manager is a good way of seeing the RAM increasing, though I'm not sure how to isolate the leak itself.
Programs like minimem that purge the RAM prevent crashes.

Will need someone who knows the technical details to give more info.

Sizzer - Raging Tide

This is thread ======>where Memory Leak was discussed in full details and in depth,
There is actually a memory leak & i confirm it .

Allisandre - Sanctuary wrote: »

Initial testing in full-screen mode. Client resolution is 1680x1050.

Location ~ Commit Memory ~ Private Memory
Login screen ~ 622MB ~ 470MB
Character Selection Screen ~ 811MB ~ 545MB
Dragons End ~ 866MB ~ 684MB (What I would call normal, and similar to what used to be the constant)
Cave of the Vicious ~ 930MB ~ 723MB (an expected rise here, had herc out and gathered half the instance.)
Plume ~ 1.1GB ~ 934MB (a little more populated, there's the giant tree and all too, and expected rise.)
Archosaur ~ 1.6GM ~ 1.2GB (Holy freaking cow! Although TBH, it's kind of expected to rise here as well. The real test is coming up.)
Back to Dragons End ~ 1.4GB ~ 1GB (Here's where we start to see the issue. It hasn't released the data from Arch. It's still hanging onto quite a bit of ram and it's not necessary, as seen by the previous data from this location.)
Character Selection Screen ~ 1GB ~ 812MB (There's a huge difference between this and when we started the client. It has absolutely no reason to be holding onto all of that ram now.)
Even after sitting at Dragons End for an hour, it's still holding the ram. A program that isn't releasing the private memory it's allocated is a sure sign of a memory leak.

Now to do the same test in Windowed mode with a resolution of 1440x900.

Location ~ Commit Memory ~ Private Memory
Login screen ~ 489MB ~ 460MB
Character Selection Screen ~ 768MB ~ 585MB
Dragons End ~ 795MB ~ 665MB
Cave of the Vicious ~ 954MB ~ 789MB
Plume ~ 1.0GB ~ 934MB
Archosaur ~ 1.4GB ~ 1.1GB
Back to Dragons End ~ 1.2GB ~ 1.0GB
Login Screen ~ 1.0GB ~ 847MB
As you can see the numbers are rather similar, although a bit less. Likely because of the lower resolution. It's still not dumping ram when it doesn't need it allocated anymore.

Now to monitor the memory load when it crashes....

Now this is screenshot in Arch South near banker a heavily populated area please look at the Ram usage
This is screenshot at Empty area of Timberfield the usage is just bit lower not much you can see the difference in both the screenshots.

Marid - Dreamweaver

Great, exactly the kind of post I was hoping for xD
It didn't occur to me to search the technical forum, that was a bit of a failb:surrender

DoodsWH - Sanctuary

MMm i'm not sure its actually a memory leak (It very well could be), When it crashes like u said around nw events its because there is too many ppl in one tiny spot. If u notice as u run around the client is constantly unloading and loading people/land/buildings etc. When nw happens and u stand near the npc to go in (a better example is after nw at the forges since there is only one exit compared to multi entry points) you havent loaded everyone there that actually can take up to a couple mins. once it loads more then the capped ram of 2 gigs the client crashes.

This sounds more like a limitation rather then a memory leak. as pointed out in previous posts raising it would help. also mentioned was that it was brought to the higher ups and shot down. Now that many new flyers and wpns and mounts with enhanced graphics have been added since it last was brought up maybe its time to revisit the raising of the memory cap. as it is I never crash unless there is but-loads of ppl in a square inch of space. tho if i turn off all effects, distances, names , etc i can stay there without crashing as long as i stay outside of the square inch of doom, as it wont load everything,

Thats my 2 cents on the situation. b:bye

Sizzer - Raging Tide

From my personal experience when i'm in TW specially i play at lowest setting yet i crash atleast 3-4 times in a TW my video drivers are fully updated i have tried all sorts of necessary stuffs needed to avoid the crash yet i crash. Elementclient heavily uses CPU and RAM instead of GPU because the client was made back in 2006 like every technology is updating day by day the dev's need to update the client for sure to keep up time. Anyways Let's hope for the best ! b:victory

Soul_Ripper_ - Harshlands

If you guys and gals are having memory issues and use a Windows OS, I strongly suggest getting FreeRAM XP Pro. I use it full time and even though it won't stop memory leaks, it will allow you to free up memory and monitor it as well. It does work on all versions of WinOS going back to Win95 and myself using Win7 X64, it helps a lot. It's free and not a very big program.

Not advertising this program, but only suggesting it to those who are memory resource conscious.

_Arjun_ - Raging Tide

Bump.

Marid - Dreamweaver

_Arjun_ - Raging Tide wrote: »

Bump.

No need to bump, it was said that even though they may not reply, that doesn't mean the GMs don't read the threads

Deadalus - Harshlands

I have to add, even by using "Minimem" the client crashes. It never reaches 2GB of ram by using that programm (its around 300MB in archo and 500~MB, when standing infront of the NW NPC, when NW starts in 5mins).

So i would guess, its not only the 2GB ram limit, which causes a crash. Maybe just too many players for that engine but its an mmorpg, they have to handle this, dont they? guess not b:pleased

Fissile - Archosaur

Minimem frees up RAM by forcing program data from physical memory (RAM) into virtual memory (page file). It does not force PWI to release any memory.

Deadalus - Harshlands

Well yes, but still it helps and pwi doesnt crash reaching 2GB of ram, because it never reaches this number by using minimem.

Doesnt solve the problem by crashing, when too many ppl are around b:thanks

Fissile - Archosaur

Deadalus - Harshlands wrote: »

Well yes, but still it helps and pwi doesnt crash reaching 2GB of ram, because it never reaches this number by using minimem.

Doesnt solve the problem by crashing, when too many ppl are around b:thanks

That is not correct. PWI crashes when it reaches the end of addressable memory, it doesn't matter if that is in the page file or physical memory. The operating system abstracts the memory addressing such that every 32bit program on your computer (notable exceptions below) sees 2GB of addressable memory (user address space). Even if your computer only has 1GB of RAM that program (and every other program) can still use 2GB. If you have a page file enabled, whatever is left over will get stored on the hard drive (with no page file it would crash). If it allocates more than 2GB of memory (regardless of where the operating system has stored it), the program will crash.

Applications that implement LARGEADDRESSAWARE are allowed to address more space. The unapproved patch for the client that allows it to address more memory simply sticks this flag in the header for the client. Given that the application was not originally designed with this feature enabled, I wouldn't trust that its handling of memory operations is compatible with this feature and it may lead to other problems such as buffer overflow/underflow.

Windows also has something called AWE (address windowing extension) that allows 32-bit applications to address more than 2GB (in fact they can even access more than 4GB). This allows things like science, engineering, and database applications to access large amounts of memory on enterprise systems with a 36-bit address space.

Deadalus - Harshlands

Ok i knew, that when not enough ram is available, that windows stores some data on the HDD but its very slow.
But i didnt knew, that it doesnt have sth to do with the actuall space needed (2GB) and the adress its stored in.

I wont stick with "but it crashes at 2gb and it never reaches it using...", so thank you for letting me know, that its something else causing this problem.

cheers b:victory

Shardik - Lost City

Fissile - Archosaur wrote: »

That is not correct. PWI crashes when it reaches the end of addressable memory, it doesn't matter if that is in the page file or physical memory. The operating system abstracts the memory addressing such that every 32bit program on your computer (notable exceptions below) sees 2GB of addressable memory (user address space). Even if your computer only has 1GB of RAM that program (and every other program) can still use 2GB. If you have a page file enabled, whatever is left over will get stored on the hard drive (with no page file it would crash). If it allocates more than 2GB of memory (regardless of where the operating system has stored it), the program will crash.

Applications that implement LARGEADDRESSAWARE are allowed to address more space. The unapproved patch for the client that allows it to address more memory simply sticks this flag in the header for the client. Given that the application was not originally designed with this feature enabled, I wouldn't trust that its handling of memory operations is compatible with this feature and it may lead to other problems such as buffer overflow/underflow.

Windows also has something called AWE (address windowing extension) that allows 32-bit applications to address more than 2GB (in fact they can even access more than 4GB). This allows things like science, engineering, and database applications to access large amounts of memory on enterprise systems with a 36-bit address space.

o_O !

f:shocked

Fissile - Archosaur

Yeah, Windows sever versions had this feature starting with Windows 2000.

Salari - Raging Tide

Here is what I posted in another thread, which goes along with what fissle is saying

This is a hardware limitation on 32bit systems not a software problem(other than mismanage dynamic memory). Hardware on a 32 bit system will only allow from 1.5-2 gig's of addressable memory, this can not be change by the OS nor software(there are some workarounds but beyond this discussion). The patch you are referring to only works on a 64 bit system. Introducing such a patch on a 32bit system to address more than hardware allows will do nothing but cause problems. You can however change the OS allocations the 3-4gigs of total memory for each process. It can be change so you have a larger pool of dynamic memory. The problem with this will be knowing how much static memory the program or game(pwi) + what the OS loads in static memory uses. If you lower the static memory to 1gig and 1.5 is needed you can run into problems as well. Both Windows and other OS's do have built in mechanics to handle this, but that is no guarantee the program will run, or run correctly.

b:surrender