Out of memory when trying to copy PACK records in TES5Edit

[GoogleCodeExporter]

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]

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]

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]

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]

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]

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

• Changed state: Started

[GoogleCodeExporter]

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]

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]

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]

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]

Solved by Elminster , no ?

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

[GoogleCodeExporter]

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]

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

• Changed state: Fixed