Memory hole?
 

I'm not sure why but this example below will use upwards towards 90MB of memory within 20 mins. In my test I pointed the download file to something small, around 20K in size.
I've tested this bug(?) with various builds, including the latest CVS release.


-------------------------
Name "memoryhole"
OutFile "memoryhole.exe"
Caption "memoryhole"
SilentInstall silent

Section ""

foo:
NSISdl::download http://www.noname.com/poo.jpg $EXEDIR\outfile.exe
sleep 25
goto foo

SectionEnd
-------------------------

Unless its leaking memory, I don't see a bug since its an infinite loop.

It uses more and more memory with each loop. That is a memory leak, is it not?!

No, is not. Like rainwater said, you only have an endless loop, but it'll grab memory.
Leak is when you don't empty the space in the memory. In this case you just loading up.

so why is it gobbling up memory and how can it be freed?

mmm, because there's no exit for the loop.

what you say makes no sense. I don't see why having "no exit for the loop" is a reason for this example to gobble 90MB+ in less than 20 mins.

that's how IE works, and i think not NSIS is to blame for this ;)

NSISdl does not use IE.

It's memory "usage", no leaking, of the Win32 APIs. Since there's no stop in the loop, the OS (Windows) works endless.

ah, so the usage is keeping track of where it is in the loop?

Yes :)

No, that's not supposed to happen. No API call should increase memory usage when used in a loop assuming its freeing function is also called in the loop.

so would this mean there is a bug in NSIS?

It's not a NSIS bug. It's the computer working out with an endless loop.

It is a bug in the NSISdl plug-in.

Lobo, try:

loop:
sleep 1
goto loop

code:


Name "memoryleak"

OutFile "memoryleak.exe"

Caption "memoryleak"

SilentInstall silent



Section ""

Loop:

sleep 1

goto Loop

SectionEnd

The memory usage of the EXE still 2,188 KB. No overflow of the memory...

Indeed. So there is something wrong with NSISdl.

I stand corrected then. I thought an infinite loop would start eating up the stack, but I guess it doesn't.

The main leak is in your code. You forgot to Pop the returned value. This leaks 1KB each iteration of the loop. Other than that, there were some problems with NSISdl. Hopefully they were all fixed in the latest CVS version. See the change log for more details.