SaveScum / skyrim-plugin-decoding-project

Automatically exported from code.google.com/p/skyrim-plugin-decoding-project
0 stars 0 forks source link

Out of memory when trying to copy PACK records in TES5Edit #157

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Start TES5Edit and browse Packages
2. Select top 40-50 records
3. Click Copy as override

What is the expected output?
Popup window with a destination selection

What do you see instead?
TES5Edit hangs and starts to consume insane amount of memory.
If trying to copy 100+ packages, it will quicky run out of memory and crash.

What version of the product are you using? On what operating system?
r1530

Please provide any additional information below.
I think it is related to the issue 140, but getting much worse lately.
Also when I tried to Deep copy all packages, it worked, but around half of them 
were not copied at all.

Original issue reported on code.google.com by zila...@gmail.com on 5 Feb 2014 at 5:12

GoogleCodeExporter commented 9 years ago
Effectivly, there are three issues:
  for copying the whole package group:
    Error while copying GRUP Top "PACK": Found a STAT reference, expected: PACK
    the error interrupts the copying (already happens in 3.0.31)

  when iterating for all the siblings of a contaiiner element, each iteration of each sibling consumes memory, do it enough time (ie with enough packages selected) you reach an out of memory. The similarity with issue 140 is why allocate again if you are checking the same element ?

  Finally, why I am checking the non selected siblings for master, I won't copy them anyway :(

Original comment by HuguesLe...@gmail.com on 5 Feb 2014 at 9:23

GoogleCodeExporter commented 9 years ago
I am changing:
{N} (Index: 611; Name: 'IsNullPackageData'; ParamType1: ptPackage),
to
{N} (Index: 611; Name: 'IsNullPackageData'; ParamType1: ptPackdata),

Original comment by HuguesLe...@gmail.com on 5 Feb 2014 at 10:23

GoogleCodeExporter commented 9 years ago
r1532 optimises memory and processing by avoiding to iterate through group 
records when searching for masters as group records cannot contain record 
members.

Original comment by HuguesLe...@gmail.com on 5 Feb 2014 at 10:55

GoogleCodeExporter commented 9 years ago
Thanks for checking this.
Completely forgot about formid errors, that wrong package def is probably a 
product of copy paste when I was decoding conditions, doing hundreds of them at 
once been really tiresome.
I have a question - even if it iterates over excess records, why does it never 
release memory? It ate around 1GB of RAM when I tried to copy 40 PACKs, that's 
just insane leaking.

Original comment by zila...@gmail.com on 6 Feb 2014 at 5:29

GoogleCodeExporter commented 9 years ago
Thats the part I deliberatly did not enter last night :)

Each package "costs" ~4 or 8K to scan, multiplied by more than 4000 siblings 
and  looping up to 4000 times if you s.
I made it explode at more than 3GB :)

So the two questions to be asked:
 1)why is the memory not freed when the package looses focus after being decoded?
 2)if the package is still in memory, why decode it again if it was'nt freed ?

Original comment by HuguesLe...@gmail.com on 6 Feb 2014 at 8:08

GoogleCodeExporter commented 9 years ago
oh and ptPackage is what Delphi proposes when you start typing ptPackData :) so 
you got had by the "type ahead"

Original comment by HuguesLe...@gmail.com on 6 Feb 2014 at 8:10

GoogleCodeExporter commented 9 years ago
Probably, need to check it in CK though to be sure.
Exploded up to 3GB? Damn, lets just compile it in x64 and forget :)

Original comment by zila...@gmail.com on 6 Feb 2014 at 9:19

GoogleCodeExporter commented 9 years ago
If you're willing to wait "a little"...

For displaying ptPackData, I suppose we should convert the ID to the actual 
PackData name but yesterday at first glance it was'nt easy.

Original comment by HuguesLe...@gmail.com on 6 Feb 2014 at 11:16

GoogleCodeExporter commented 9 years ago
Not worth it for a single condition. Besides, until that memory leak is fixed, 
better not to strain xEdit with additional resolvers. I made resolvers for 
aliases earlier, but turned them off by default since it was unbearable, memory 
consumption was too much since aliases are used everywhere in skyrim plugins.

Original comment by zila...@gmail.com on 6 Feb 2014 at 12:54

GoogleCodeExporter commented 9 years ago
Solved by Elminster , no ?

Original comment by HuguesLe...@gmail.com on 9 Sep 2014 at 11:21

GoogleCodeExporter commented 9 years ago
Yep, there are no memory leaks now in xEdit, or at least I haven't encountered 
any after the memory fix update.

Original comment by zila...@gmail.com on 9 Sep 2014 at 11:56

GoogleCodeExporter commented 9 years ago

Original comment by HuguesLe...@gmail.com on 12 Sep 2014 at 11:26