We're getting a strange "out of memory" error trying to recompile an InnoSetup script using the InnoSetup action in Finalbuilder. This does not appear to be related to any of the "out of memory" errors previously encountered in InnoSetup's earlier versions.
Here's the log output (I've removed all the successful parsing and directory creation messages:
[ISPP] Preprocessed.
Parsing [Setup] section, line 42
...
Parsing [Files] section, line 175
Compiling [Code] section
Creating setup files
Updating icons (SETUP.EXE)
Compressing: e:\build\install\bin\ServHelp.dll
Out of memory.
File :
Line : 0
There was an error compiling or it was aborted by the application
If I replace the InnoSetup action with a generic "Execute Program" action, running the ISCC.EXE compiler directly, then our InnoSetup script compiles successfully without any such errors. We would much rather use the InnoSetup action so as to be sure that errors etc are reported correctly rather than relying on our configuration of a generic "Execute Program" action (what should we be testing for in terms of ERRORLEVEL from the ISCC.EXE etc?)
This was originally found using InnoSetup 5.2.3 but I have subsequently upgraded our build process to the latest InnoSetup (5.3.5) to ensure that the problem was not related to using an older version of InnoSetup and the problem still occurs.
FinalBuilder 6.30.0.1783
The action and the FinalBuilder tools options are configured for InnoSetup 5.x
The problem appears to be related to the amount of memory required for the compression of files in the InnoSetup project.
If I change the Compression type used in the project to a method that has a lower memory requirement then the compression phase of the project progresses further but still eventually fails with an Out Of Memory error before completing.
This is the case even when Compression is set to none!!!
What I don't understand is that with Compression set to lzma/ultra64, compiling the project with the ISCC.EXE command line compiler results in memory use for the compiler process (running in a cmd.exe) escalates to 700MB+ but completes successfully. Running the exact same script using the InnoSetup action in FinalBuilder halts on the very first file in the compression phase, but memory use (as reported by Task Manager) of the FinalBuilder process does not increase beyond 48MB.
I don’t have an answer for this. BTW, this is now the second report in the last few weeks with the same issue. We use the Inno setup compiler dll, and call into it’s api to do the compile. The reason for this is that the api provides progress feedback that we don’t get with the command line compiler. I’m not sure why this has started happening. We use Innosetup ourselves and haven’t experienced this at all, but then our resulting exe is only around 30MB. I’ll contact Jordan and see if we can figure something out.
In case it's relevant, our resulting setup exe is 131MB when Compression is none. With Compression set to lzma/ultra64 this compresses to less than 25MB.
Also, we are using SolidCompression = true (though making this false made no difference to the problem).
In the meantime I found the ISCC console compiler reference that provided the ERRORLEVEL information we needed in order to be a little more confident about handling errors in our script. With that information we are at least able to use the generic "Execute Program" action for the time being, so although a resolution would obviously be desirable it's no longer as urgent.
I am having somewhat related problems. Using FB 6.3.0.1712 and InnoSetup 5.3.6. With Compression set to LZMA/Ultra I can create a series of setup's in an action group. If I try to build the same series in an ASync Action group, I get the "Out of Memory" Errors. Changing the Compression to BZip has no effect.
I have tried opening two of the builds outside FB and I can manually run both in parallel with no problem.
BTW, I have Vista x64 with 8 gig of memory. Task manager reports only 40% used.
This appears to be caused by the lzma compression engine used by Inno setup requesting a large contiguous amount of memory.
FinalBuilder is a 32 bit process, so can only access 2G of memory no matter what the machine has installed. FinalBuilder also hosts the .NET CLR, which appears to be loading assemblies in a manner that makes it impossible for the native memory manager in FinalBuilder to allocate large contiguous chunks of memory.
We are going to change the InnoSetup action to call it’s command line compiler rather than load the compiler dll and use it’s api. The downside to that is we will not have any progress feedback, however running Innosetup in a separate process will allow it full access to the memory it needs.
In the mean time you can either disable the use of the async group, or use the Execute Program action to call the command line compiler.
Why not keep the DLL support in the action but make it an option?
[x] Use InnoSetup DLL
[x] Use InnoSetup command line
For people that initially have no issue with the InnoSetup DLL but who then start experiencing the problem later on, they need only flip that option rather than delete and recreate the action from scratch. Similarly if a fix is ever found that would enable the DLL to be used under conditions where it currently cannot, reverting to the DLL would also be an option flip.
I did just enounter the same problem, and had to register to this forum just to see the search results that were found on the keywords "out of memory".
A suggestion for improvement: when the DLL is used and "out of memory" encountered, either ask to change to command line directly, or at least hint at this in the output. Would have saved me hours so far to know this (spent the last weeks manually compiling as part of the build chain)!