Ok, I could reduce the problem to not calling malloc() through a function
pointer (but realloc and free seems to be fine). Basically applying this
diff with 3 changed lines:
diff --git a/libs/spine-c/src/spine/extension.c
b/libs/spine-c/src/spine/extension.c
index 85b8d30..0e8d63c 100644
--- a/libs/spine-c/src/spine/extension.c
+++ b/libs/spine-c/src/spine/extension.c
@@ -45,10 +45,10 @@ static void (*freeFunc)(void *ptr) = free;
static float (*randomFunc)() = _spInternalRandom;
void *_spMalloc(size_t size, const char *file, int line) {
- if (debugMallocFunc)
- return debugMallocFunc(size, file, line);
+// if (debugMallocFunc)
+// return debugMallocFunc(size, file, line);
- return mallocFunc(size);
+ return malloc(size);
}
void *_spCalloc(size_t num, size_t size, const char *file, int line) {
...to this file:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.1/spine-c/spine-c/src/spine/extension.c
...makes it all work (builds and runs with emmalloc and optimizations on,
both _spMalloc and the default debugMallocFunc call malloc through a
function pointer)
I still don't understand *why* this happens though, and why a function
pointer to malloc() would lead to a linker error about missing calloc() -
and only when using emmalloc.
Cheers!
On Sunday, 4 September 2022 at 15:40:12 UTC+2 Floh wrote:
> Followup: could this somehow be related to function pointers to C runtime
> functions? E.g. spine-c memory allocations calls all go through functions
> pointers:
>
>
> https://github.com/EsotericSoftware/spine-runtimes/blob/933ccbba6244cd8aefb04dadf8324be2442eb858/spine-c/spine-c/src/spine/extension.c#L37-L43
>
> ...it all works fine (with emmalloc and optimizations) if I simply bypass
> this entire code by wiring the spine-c allocation macros directly to
> malloc, calloc, realloc and free (here:
> https://github.com/EsotericSoftware/spine-runtimes/blob/933ccbba6244cd8aefb04dadf8324be2442eb858/spine-c/spine-c/include/spine/extension.h#L69-L91
> ).
>
> ...which works for me ATM, but it would still be good to get to the bottom
> of this issue.
> On Saturday, 3 September 2022 at 17:03:59 UTC+2 Floh wrote:
>
>> Ok, it gets weirder:
>>
>> If I add the -sEXPORTED_FUNCTIONS=_calloc, the sample links alright, but
>> then doesn't run. There's no crash message on the JS console either, it
>> just sits there with a black screen.
>>
>> This time it's the same behaviour in release and debug mode, yet debug
>> mode works alright without the EXPORTED_FUNCTIONS option (because it builds
>> with -O0, which triggers the problem).
>>
>> Ok, that's enough "rabbit-holeing" for today. My options for this
>> particular sample currently seem to be:
>>
>> (1) don't use emmalloc
>> (2) don't build with optimizations enabled
>>
>> ...both options suck TBH ;)
>> On Saturday, 3 September 2022 at 16:44:41 UTC+2 Floh wrote:
>>
>>> PPPS: building with "-sEXPORTED_FUNCTIONS=_calloc" also works, but I
>>> don't understand why I need this only for this one specific sample, for a
>>> problem triggered by a library that doesn't even call calloc. I didn't have
>>> to deal with EXPORTED_FUNCTIONS for years (instead EMSCRIPTEN_KEEPALIVE did
>>> the job), and especially never for any C runtime functions.
>>>
>>> Any ideas of what's the issue here would be greatly appreciated. I'll
>>> put the EXPORTED_FUNCTIONS into my build options as a hack for now, but it
>>> would be nice if that wouldn't be needed (especially since I don't
>>> understand the reason, lol).
>>>
>>> Cheers!
>>>
>>> On Saturday, 3 September 2022 at 16:26:07 UTC+2 Floh wrote:
>>>
>>>> Another information tidbit:
>>>>
>>>> Adding a calloc() call in any of the other (very similar) samples
>>>> always works without problems (e.g. I don't need to add calloc to
>>>> EXPORTED_FUNCTIONS as advised by the emsdk linker - I don't use
>>>> EXPORTED_FUNCTIONS anywhere in my compiler settings).
>>>>
>>>> It also works if I remove any calls to that spine-c library in my own
>>>> code (but mind that the spine-c library doesn't call into calloc - emsdk's
>>>> llvm-nm doesn't show any references to calloc in the resulting library).
>>>>
>>>> The only place where I can find a reference to calloc is as 'weak
>>>> symbol' in libemmalloc.a, but I don't understand how any potential
>>>> problems
>>>> in emmalloc would be triggered by the presence or absence of a random
>>>> third
>>>> party library that doesn't even call into calloc...
>>>>
>>>> On Saturday, 3 September 2022 at 15:54:37 UTC+2 Floh wrote:
>>>>
>>>>> Ok, it works if I change one thing: setting the -O flag from -O3 to
>>>>> -O0 (-O1 also already breaks).
>>>>>
>>>>> ...also it seems that calloc *is* actually called somewhere (the wasm
>>>>> crashes in the calloc stub when I build with
>>>>> ERROR_ON_UNDEFINED_SYMBOLS=0).
>>>>> But I still think it's not anywhere in my code (e.g. the Spine runtime
>>>>> has
>>>>> CALLOC macros all over the place, but this resolves to a call to a helper
>>>>> function with malloc+memset.
>>>>>
>>>>>
>>>>> On Saturday, 3 September 2022 at 15:21:18 UTC+2 Floh wrote:
>>>>>
>>>>>> PPS: ...looks like I can only go back to SDK version 3.0.0 on ARM
>>>>>> Macs, and the problem already existed in that version.
>>>>>>
>>>>>> On Saturday, 3 September 2022 at 15:16:42 UTC+2 Floh wrote:
>>>>>>
>>>>>>> PS: this is the wasm-ld cmdline:
>>>>>>>
>>>>>>> em++: error:
>>>>>>> '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o
>>>>>>> /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-vscode-release/spine-sapp.wasm
>>>>>>>
>>>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-sapp.c.obj
>>>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-assets.c.obj libs/sokol/libsokol.a
>>>>>>> libs/spine-c/libspine-c.a libs/stb/libstb.a libs/util/libfileutil.a
>>>>>>> fips-cimgui_cimgui/libcimgui.a
>>>>>>> -L/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto
>>>>>>>
>>>>>>> -lGL-webgl2 -lal -lhtml5 -lstubs -lc -lcompiler_rt -lc++-noexcept
>>>>>>> -lc++abi-noexcept -lemmalloc -lc_rt -lsockets -mllvm
>>>>>>> -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj
>>>>>>> -mllvm
>>>>>>> -disable-lsr
>>>>>>> --allow-undefined-file=/var/folders/dz/g9ydwg8973z9nn5bvffcwf3h0000gn/T/tmphqvycm26.undefined
>>>>>>>
>>>>>>> --strip-debug --export-if-defined=main --export-if-defined=stackSave
>>>>>>> --export-if-defined=stackRestore --export-if-defined=stackAlloc
>>>>>>> --export-if-defined=__wasm_call_ctors
>>>>>>> --export-if-defined=__errno_location
>>>>>>> --export-if-defined=malloc --export-if-defined=free
>>>>>>> --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm
>>>>>>> --export-table -z stack-size=5242880 --initial-memory=33554432
>>>>>>> --entry=main
>>>>>>> --max-memory=2147483648 --global-base=1024' failed (returned 1)
>>>>>>>
>>>>>>> ...I'm now trying to bisect the SDK version to see if this is a
>>>>>>> regression...
>>>>>>>
>>>>>>> On Saturday, 3 September 2022 at 15:03:21 UTC+2 Floh wrote:
>>>>>>>
>>>>>>>> I just stumbled over a very weird problem in a new sample for my
>>>>>>>> sokol headers which includes a non-trivial 3rd party C library - the
>>>>>>>> spine-c runtime (
>>>>>>>> https://github.com/EsotericSoftware/spine-runtimes/tree/4.1/spine-c/spine-c
>>>>>>>> )
>>>>>>>>
>>>>>>>> When building in release mode (but not in debug mode) the linker
>>>>>>>> complains about an unresolved 'calloc' call. Adding detailed output
>>>>>>>> via LLD_REPORT_UNDEFINED=1 I get tons of:
>>>>>>>>
>>>>>>>> wasm-ld: error:
>>>>>>>> /Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libemmalloc.a(emmalloc.o):
>>>>>>>>
>>>>>>>> undefined symbol: calloc
>>>>>>>>
>>>>>>>> ... how does that even make sense when emmalloc is supposed to
>>>>>>>> provide an implementation of calloc... anyway...
>>>>>>>>
>>>>>>>> The error goes away when compiling in debug mode (some differences
>>>>>>>> that come to mind to the release mode is that debug mode doesn't use
>>>>>>>> -flto,
>>>>>>>> and also doesn't run the closure compiler).
>>>>>>>>
>>>>>>>> The problem also goes away when not building with emmalloc.
>>>>>>>>
>>>>>>>> Now the weird thing is that the entire code this sample is built
>>>>>>>> from doesn't appear to call calloc anywhere... and that other samples
>>>>>>>> which
>>>>>>>> actually use calloc build just fines.
>>>>>>>>
>>>>>>>> Has anybody seen a similar problem yet, before I jump myself into
>>>>>>>> the rabbit hole? :)
>>>>>>>>
>>>>>>>> The problematic command line is:
>>>>>>>>
>>>>>>>> em++ -s DISABLE_EXCEPTION_CATCHING=1 -fno-exceptions -fno-rtti
>>>>>>>> -fstrict-aliasing -Wall -Wno-multichar -Wextra -Wno-unknown-pragmas
>>>>>>>> -Wno-ignored-qualifiers -Wno-long-long -Wno-overloaded-virtual
>>>>>>>> -Wno-deprecated-writable-strings -Wno-unused-volatile-lvalue
>>>>>>>> -Wno-inconsistent-missing-override -Wno-warn-absolute-paths
>>>>>>>> -Wno-expansion-to-defined -flto -O3 -DNDEBUG -s
>>>>>>>> DISABLE_EXCEPTION_CATCHING=1 --memory-init-file 0 -s
>>>>>>>> INITIAL_MEMORY=33554432 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s
>>>>>>>> NO_EXIT_RUNTIME=1 -s LLD_REPORT_UNDEFINED=1 -s ALLOW_MEMORY_GROWTH=1
>>>>>>>> -s
>>>>>>>> USE_WEBGL2=1 -s "MALLOC='emmalloc'" -s NO_FILESYSTEM=1 -s WASM=1
>>>>>>>> --shell-file /Users/floh/projects/sokol-samples/webpage/shell.html
>>>>>>>> -O3
>>>>>>>> -flto --closure 1 -s ASSERTIONS=0
>>>>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-sapp.c.obj
>>>>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-assets.c.obj -o
>>>>>>>> /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-vscode-release/spine-sapp.html
>>>>>>>>
>>>>>>>> libs/sokol/libsokol.a libs/spine-c/libspine-c.a libs/stb/libstb.a
>>>>>>>> libs/util/libfileutil.a fips-cimgui_cimgui/libcimgui.a
>>>>>>>>
>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/d9da826e-eb97-41c6-b47e-625d328273aen%40googlegroups.com.
