All installers that contain the Unicode true will fail to build using makensis 3.0 on macOS.
Consider this minimal example:
Unicode true
OutFile "demo.exe"
Section
SectionEnd
This will result in the following error message:
Processing script file: "/tmp/unicode.nsi" (UTF8)
Processed 1 file, writing output (x86-unicode):
libc++abi.dylib: terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
[Finished in 0.0s with exit code -6]
Ran into this issue myself. https://github.com/electron-userland/electron-builder/issues/503#issuecomment-266466859
I discovered it when I was building via Jenkins, when I SSH'd onto the machine and built it, there was no issue. However Jenkins hadnt correctly inherited the systems defsault encoding and was using ASCII. This caused the issue.
Workaround is provided in the link.
I've built the Homebrew formula for
makensiswith those environment variables set, but the problem persists. I'm wondering why the MacPorts version compiles the script just fine.Hi folks!
I am getting this error. Here's the output log with -V4, and the script is attached ...
MakeNSIS v3.06.1 - Copyright 1999-2020 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.
Command line defined: "MAVersion=1.305"
Command line defined: "CompiledSource=/Users/geoff/Documents/MyDocuments/Development/GitSpace/ModelAccuracy/build/tmp/preCreateInstaller"
Changing directory to: "/Users/geoff/Documents/MyDocuments/Development/GitSpace/ModelAccuracy/installer"
Processing script file: "ModelAccuracy.nsi" (UTF8)
Processing default plugins: "/usr/local/share/nsis/Plugins/x86-ansi/*.dll"
Unicode: true
Processing default plugins: "/usr/local/share/nsis/Plugins/x86-unicode/*.dll"
!addplugindir: "plugins"
!include: "/usr/local/share/nsis/Include/MUI2.nsh" (UTF8)
!include: "/usr/local/share/nsis/Contrib/Modern UI 2/MUI2.nsh" (UTF8)
NSIS Modern User Interface version 2.1 - Copyright 2002-2020 Joost Verburg (/usr/local/share/nsis/Contrib/Modern UI 2/MUI2.nsh:14)
!include: closed: "/usr/local/share/nsis/Contrib/Modern UI 2/MUI2.nsh"
!include: closed: "/usr/local/share/nsis/Include/MUI2.nsh"
!include: "/usr/local/share/nsis/Include/LogicLib.nsh" (UTF8)
!include: closed: "/usr/local/share/nsis/Include/LogicLib.nsh"
!include: "/usr/local/share/nsis/Include/x64.nsh" (UTF8)
!define: "X64_NSH_"=""
!include: "/usr/local/share/nsis/Include/LogicLib.nsh" (UTF8)
!include: closed: "/usr/local/share/nsis/Include/LogicLib.nsh"
!define: "IsWow64"=""" IsWow64 """
!define: "RunningX64"=""" RunningX64 """
!define: "GetNativeMachineArchitecture"="!insertmacro GetNativeMachineArchitecture "
!define: "IsNativeMachineArchitecture"=""" IsNativeMachineArchitecture "
!define: "IsNativeIA32"=""" IsNativeMachineArchitecture 332"
!define: "IsNativeAMD64"=""" IsNativeMachineArchitecture 34404"
!define: "IsNativeARM64"=""" IsNativeMachineArchitecture 43620"
!define: "DisableX64FSRedirection"="!insertmacro DisableX64FSRedirection"
!define: "EnableX64FSRedirection"="!insertmacro EnableX64FSRedirection"
!include: closed: "/usr/local/share/nsis/Include/x64.nsh"
!include: "nsProcess.nsh" (UTF8)
!define: "nsProcess::FindProcess"="!insertmacro nsProcess::FindProcess"
!define: "nsProcess::KillProcess"="!insertmacro nsProcess::KillProcess"
!define: "nsProcess::CloseProcess"="!insertmacro nsProcess::CloseProcess"
!define: "nsProcess::Unload"="!insertmacro nsProcess::Unload"
!include: closed: "nsProcess.nsh"
!define: "ARP"="Software\Microsoft\Windows\CurrentVersion\Uninstall\ModelAccuracy"
Name: "ModelAccuracy"
OutFile: "../ModelAccuracyInstall_1.305.exe"
libc++abi.dylib: terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
I'm on a (nold, Mid 2012) MacBook Pro, macOS Cataline 10.15.5.
A fix would be cool.
Comment out the "InstallDir" line and see if the problem goes away. If not, then keep commenting lines out until it does go away. The idea is to find which command causes it. I don't have any macs to test on, sorry.
Maybe this helps?
https://stackoverflow.com/questions/22453001/clang-fails-to-throw-a-stdbad-alloc-when-allocating-objects-that-would-exceed
The problem is within makensis, so that post might help the developers of makensis get rid of this issue. Thanks for pointing it out ... how do I/you/we send it to the developers to help them?
I don't think any of us have Macs so please do what Jason suggests, comment out lines until it stops crashing to figure out which instruction is the cause of the problem.
I've setup a repository with GitHub Actions that compiles a minimal, reproducable example on latest macOS. This exact script does not compile on macOS under certain circumstances (see my speculations below), Interestingly, the compilation does work in that image.
Feel free to fork it and adjust it according to your testing needs.
https://github.com/idleberg/nsis-macos-unicode-bug
Last edit: idleberg 2020-09-03
It's as the original post explains, if I change "Unicode true" to "Unicode false" the build succeeds. Something inside makensis doesn't like "Unicode true".
Cheers,
Geoff
What if you set it to 'unicode true', then add another one that changes it back to false? Does it still fail?
This compiles without error
That's what I was afraid of. It's somewhere else in the code, and not the 'Unicode' command itself (I suspected that might be the case).
If it helps, I did a quick memory check in debug mode using valgrind on Fedora 32. Script is the same as the initial post above, I just commented out 'unicode true' to get the ansi version.
Last edit: Jason 2020-09-03
This question might seem a bit odd, but how are you compiling your installers? I've installed several versions of
makensisusing Homebrew (both the official formula and third party) and MacPort. When I compile the script inside Visual Studio Code, I get the same error with any of the installed versions. However, when I compile in the shell, I don't get that error.Not sure if that question was addressed to me ... I installed makensis using homebrew, and then call it from gradle.
What happens when you run
makensisfrom your shell, does it behave differently?Same result if I call it from the shell ...
Coming back to this with a series of tests
Example Script
Tests
Homebrew
MacPorts
Code Editors
When I compile the same script using both, Homebrew and MacPorts, versions of
makensis, I'm getting problems.Visual Studio Code v1.57.1 & Atom v1.57.0
Using a build plugin, the script fails building in both editors
However, using the built-in terminal of Visual Studio Code the script compiles fine. Also any script with
Unicode falsecompiles fine.Sublime Text 3 (Build 3210)
Compiles just fine
Assumption
I think this brings us back to Emmet's initial posting, in which he suspects that this is somehow related to NodeJS/Electron. However, others in this thread have stated otherwise.
Last edit: idleberg 2021-07-07
Following the upgrade to NSIS v3.07 in the Homebrew formula, we have applied a workaround that allows compiling Unicode installers in their test environment (Docker through GitHub Actions). Following Emmet's advice, we checked the values of the locale and set it explicitly to
en_GB.UTF-8. As a result, the Unicode installer compiles fine.As a follow-up, I tested the following:
This seems to confirm Emmet's assumption, that the error only appears when the locale doesn't use a valid language. I'm wondering if
makensisshould run a basic check and set a fallback value for the locale, if necessary.