Defines with \0 included in them are incorrect in memory starting with 6.0.4

[rsielken]

Please include the following in your bug report:

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 6.0.8 (aeb6792)
Copyright (C) 2026 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But working back through https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md, this started in 6.0.4. Therefore, I'd suspect it is caused by "llvm-libc was updated to LLVM 22.1.8. (#27374)"

Failing command line in full:
Runtime failure.

Full link command and output with -v appended:

em++ -DEMSDK -DMOBILE -DOPENGL -DREACT_INFOBOX -DNO_DYNAMIC_LOADING -DMOBILE_NSL -DMOBILE_NFL -pthread -s PROXY_TO_PTHREAD=1 -s PTHREAD_POOL_SIZE=16 -s FETCH=1 -s FETCH_SUPPORT_INDEXEDDB=0 -s FULL_ES2=1 -s USE_FREETYPE=1 -s USE_LIBPNG=1 -s DISABLE_EXCEPTION_CATCHING=0 -s INITIAL_MEMORY=268435456 -s ALLOW_MEMORY_GROWTH=1 -s FORCE_FILESYSTEM=1 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s OFFSCREEN_FRAMEBUFFER=1 -s ABORT_ON_WASM_EXCEPTIONS=1 -s EXIT_RUNTIME=1 -s LEGACY_RUNTIME=1 -s MIN_SAFARI_VERSION=-1 -s STACK_SIZE=5MB -s EXPORTED_RUNTIME_METHODS='HEAPU8,HEAPU32,lengthBytesUTF8,stringToUTF8' -s WASMFS  -DGCC3 -DGCC4 -fno-strict-aliasing -DGCC_LBLB_NOT_SUPPORTED -Wno-int-conversion -Wno-dynamic-exception-spec -Wno-register -Wno-incompatible-function-pointer-types -g2 -r   -Wl,--whole-archive,--unresolved-symbols=ignore-all

Note: Where possible, please avoid attaching screen shots of code or console
logs. Instead, please include them as text so that they may be copied /
searched. To make code blocks more readable and syntax highlighted, please
escape them with three backticks before and after, like this:

#define NEWUSER_LOOKUPITEMS "MailServer\0MailFile\0MailDomain\0MailSystem\0Profiles"
#define NEWUSER_MAILSERVERITEM	0
#define NEWUSER_MAILFILEITEM	1
#define NEWUSER_MAILDOMAINITEM  2
#define NEWUSER_MAILSYSTEMITEM	3
#define NEWUSER_PROFILEITEM		4
#define NEWUSER_LOOKUPITEMCOUNT 5

But at runtime, when I look at the memory at NEWUSER_LOOKUPITEMS, I have "MailServer\0" as expected, but the memory that follows is other stuff and not the "MailFile\0MailDomain\0MailSystem\0Profiles" it should be. The callee is expecting these other values (and that is what the caller thinks it is passing when it passes NEWUSER_LOOKUPITEMS), and doesn't return the expected items which then causes other problems done the line.

In the code there are multiple defines like NEWUSER_LOOKUPITEMS that start with "MailServer\0" but then have other values after that. It is as if some optimization (although I'm using -O0 to try to avoid any of that in my testing) thinks that it only needs "MailServer\0" and the rest after the zero can be ignored. So, it points all my defines that start with "MailServer\0" to the same memory which is incorrect.

If I run with 6.0.3, the memory looks as expected.

I spent hours and plenty of CoPilot tokens trying to create a recreateable scenario, but it continually failed. I'm sure it is related to our real project being quite large with many .o files and libs are eventually linked together. I tried all sorts of combinations of breaking up the defines across models, but I couldn't get it to fail. So, I'm giving up on that path (at least for now) and just reporting what I know. It recreates consistently for me, so I could test an EMSDK build to debug, but I can't give you our whole product's source code which is the only way I can recreate the issue at this point.

[rsielken]

Here is what CoPilot had to say when I asked for a summary after we failed to create a recreatable scenario to share:

Bug report summary:

In Emscripten 6.0.8 (emcc/wasm-ld), C string literals that contain embedded null characters (e.g., "MailServer\0MailFile\0MailDomain\0MailSystem\0Profiles") can be silently replaced in the final WASM binary by a different string from the merged .rodata string pool that merely shares the same first null-terminated segment. At the WASM object-file level, embedded-null string literals are correctly placed in non-STRINGS-flagged data segments (segment flags = 0x00, distinct from the 0x01-flagged .rodata.str segments used for ordinary null-terminated strings). However, during the link phase, wasm-ld incorrectly applies its STRINGS-pool address to these non-STRINGS segments when their leading bytes match a canonical pool entry: the 51-byte literal "MailServer\0MailFile\0…\0Profiles" is removed entirely from the output and any code reference to it is redirected to the pool's "MailServer" address — which, in a large binary, is immediately followed by an unrelated string ("VirtualServer\0ReplicateWithServer\0…") rather than the expected "MailFile\0…". The result is that NEWUSER_LOOKUPITEMS[11] reads 'V' instead of 'M' at runtime. The correct full 51-byte content ("MailServer\0MailFile\0MailDomain\0MailSystem\0Profiles") is completely absent from the 64 MB linked binary, confirmed by binary inspection. The bug requires a large link (many STRINGS-flagged segments from multiple libraries) to trigger the incorrect address assignment; a two-file reproducer with the same structural conditions passes because the pool accidentally places the correct data at the redirected address in small binaries.

[sbc100]

Gemini was able to track this down to llvm/llvm-project#210747. Which makes sense to be since you are using the -r flag.

BTW, what is the reason for using -r in your use case? This flag tells emcc to output a single object file for later linking, but its a not a very widely used flag so its not too surprising that you would run into the odd issue like this.

[sbc100]

Fix is in llvm/llvm-project#219606

[rsielken]

Gemini was able to track this down to llvm/llvm-project#210747. Which makes sense to be since you are using the -r flag.

BTW, what is the reason for using -r in your use case? This flag tells emcc to output a single object file for later linking, but its a not a very widely used flag so its not too surprising that you would run into the odd issue like this.

Using what I had before (EMSDK 5.0.3), I tried to update to EMSDK 6.0.4 and just rebuild as is. That started with these errors which then led me down various paths making changes to get it to work which resulted in my adding -r in the end:

wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/nem.wasm.a(mapmsg.wasm.o): relocation R_WASM_MEMORY_ADDR_LEB cannot be used against symbol g_pImmGetContext; recompile with -fPIC
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/nem.wasm.a(mapmsg.wasm.o): relocation R_WASM_MEMORY_ADDR_LEB cannot be used against symbol KautoCTX; recompile with -fPIC
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/nem.wasm.a(mapmsg.wasm.o): relocation R_WASM_MEMORY_ADDR_LEB cannot be used against symbol g_pImmGetConversionStatus; recompile with -fPIC
so I added -fPIC to the compile flags (it was already in the linking flags).

When I recompiled with -fPIC and then tried to link, I got (the ~ aren't really there but it has other data I don't want to expose here, so I changed things to have ~ as the prefix as it shouldn't matter for this issue):

em++ -DEMSDK -DMOBILE -DOPENGL -DREACT_INFOBOX -DNO_DYNAMIC_LOADING -DMOBILE_NSL -DMOBILE_NFL -pthread -s PROXY_TO_PTHREAD=1 -s PTHREAD_POOL_SIZE=16 -s FETCH=1 -s FETCH_SUPPORT_INDEXEDDB=0 -s FULL_ES2=1 -s USE_FREETYPE=1 -s USE_LIBPNG=1 -s DISABLE_EXCEPTION_CATCHING=0 -s INITIAL_MEMORY=268435456 -s ALLOW_MEMORY_GROWTH=1 -s FORCE_FILESYSTEM=1 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s OFFSCREEN_FRAMEBUFFER=1 -s ABORT_ON_WASM_EXCEPTIONS=1 -s EXIT_RUNTIME=1 -s LEGACY_RUNTIME=1 -s MIN_SAFARI_VERSION=-1 -s STACK_SIZE=5MB -s EXPORTED_RUNTIME_METHODS='HEAPU8,HEAPU32,lengthBytesUTF8,stringToUTF8' -s WASMFS -DGCC3 -DGCC4 -fno-strict-aliasing -DGCC_LBLB_NOT_SUPPORTED -Wno-int-conversion -Wno-dynamic-exception-spec -Wno-register -Wno-incompatible-function-pointer-types -g2 -felide-constructors -Wl,--whole-archive -pthread -s PROXY_TO_PTHREAD=1 -s PTHREAD_POOL_SIZE=16 -s FETCH=1 -s FETCH_SUPPORT_INDEXEDDB=0 -s FULL_ES2=1 -s USE_FREETYPE=1 -s USE_LIBPNG=1 -s DISABLE_EXCEPTION_CATCHING=0 -s INITIAL_MEMORY=268435456 -s ALLOW_MEMORY_GROWTH=1 -s FORCE_FILESYSTEM=1 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s OFFSCREEN_FRAMEBUFFER=1 -s ABORT_ON_WASM_EXCEPTIONS=1 -s EXIT_RUNTIME=1 -s LEGACY_RUNTIME=1 -s MIN_SAFARI_VERSION=-1 -s STACK_SIZE=5MB -s EXPORTED_RUNTIME_METHODS='HEAPU8,HEAPU32,lengthBytesUTF8,stringToUTF8' -s WASMFS -O1 --closure 0 --js-library $EMSDK/upstream/emscripten/src/lib/libwebsocket.js -L~/repos/group2/notes/bin/wasm/bin -lcrypto --post-js ~/repos/group2/notes/main/wasm/electron/electronfs.js -lnodefs.js -o $NOTESBIN/ -o ~/group2/notes/bin/wasm/bin/nomad.html build %1 @obj.nomad.wasm.tmp -d -s /repos/group2/notes/bin/wasm/lib/notes0.o -Wl -L/repos/group2/notes/bin/wasm/bin -lnotes -lnoteswasm -Wl,--no-whole-archive -lm --shell-file ./nomadshell.html
Iris Macro Substitution Utility Version 2.02
Copyright (c) Iris Associates, Inc., 1984-2001. All rights reserved.

em++: warning: -pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see WebAssembly/design#1271 [-Wpthreads-mem-growth]
wasm-ld: error: attempted static link of dynamic object ~/repos/group2/notes/bin/wasm/bin/libnotes.a
wasm-ld: error: attempted static link of dynamic object ~/repos/group2/notes/bin/wasm/bin/libnoteswasm.a

At some point in the past, our .a was getting too large, so we split it into linbnotes.a and libnoteswasm.a. I don't know if I undid that split now if we'd hit the same size problem we hit years ago. I did not try that now.

If I only remove -shared and keep -fPIC, the link still fails:
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/nem.wasm.a(mapmsg.wasm.o): undefined symbol: OSGetNativeCLS
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/nem.wasm.a(mapmsg.wasm.o): undefined symbol: GlobalLock
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/nem.wasm.a(mapmsg.wasm.o): undefined symbol: CNstrlen

If I remove -shared and fix -FPIC to be -fPIE, the link still fails.
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/sdk.wasm.a(wasminit.wasm.o): undefined symbol: WriteDesktop
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/os.wasm.a(file.wasm.o): undefined symbol: wasmIsRunningInNode
wasm-ld: error: /Users/robert.sielken/repos/group2/notes/bin/wasm/lib/os.wasm.a(file.wasm.o): undefined symbol: wasmIsRunningInNode

So, I removed -shared -fPIC from the link flags and added -r instead (meaning I didn't have -fPIC or -fPIE). That worked and is where it was when I opened the issue.

That's how I ended up with -r (along with CoPilot leading me through the various errors - some changes I kept and others I discarded).
Is there a way to get everything compiled and linked without -r if I change other things? Possibly, but I don't know what those things are and stopped once I figured out something that would work.
If you have suggestions on how we should be doing something differently, we are more than willing to try those. Otherwise, we'll probably stick with the -r after we get the llvm fix verified.

[sbc100]

Its almost always easier / better / simpler / faster to use ar archives (using emar) rather than linking with emcc -r.

emar produces a staic library file that can be linked into you final program. (If you see attempted static link of dynamic object: libnotes.a then the thing you are trying to link is a dynamic library not an ar archive, so something went wrong with the build of libnotes.a).

The only thing to not regarding static libraries is that their contents are linked on-demand only, so in some cases you maybe need to link using -Wl,--whole-archive libnotes.a -Wl,--no-whole-archive, but in most cases that is not needed or recommended.