Hi Sam, I can run the code in a single thread without problems, and I have done that for a while. So I assume that the code is stable.
Here is the command line I use in a .bat file: emcc ./src/main.c ^ ... ./src/w_com.c ^ -I ./include/ ^ -g3 ^ --source-map-base ./ ^ -gsource-map ^ -s ALLOW_MEMORY_GROWTH=1 ^ -s ENVIRONMENT=web,worker ^ --shell-file ./index_template.html ^ -s SUPPORT_ERRNO=0 ^ -s MODULARIZE=1 ^ -s ABORTING_MALLOC=0 ^ -sWASM_WORKERS ^ -s "EXPORT_NAME='wasmMod'" ^ -s EXPORTED_FUNCTIONS="['_malloc','_free','_main']" ^ -s EXPORTED_RUNTIME_METHODS= "['cwrap','UTF16ToString','UTF8ToString','stringToUTF8','allocateUTF8']" ^ -o index.html I will start familiarizing myself with pthreads to test whether that would work better. BTW, as an old C programmer I am fascinated by emscripten and its possibilities. Excellent job! Cheers, Dieter s...@google.com schrieb am Donnerstag, 25. Mai 2023 um 20:29:58 UTC+2: > This looks like some kind of memory corruption, most likely due to the use > of muiltithreading/wasm_workers Are you able to build a single threaded > version of your program, or one that uses normal pthreads rather than wasm > workers? > > Also, can you share the full link command you are using? > > cheers, > sam > > On Thu, May 25, 2023 at 9:20 AM 'Dieter Weidenbrück' via > emscripten-discuss <emscripte...@googlegroups.com> wrote: > >> This is a memory snapshot when using SAFE_HEAP. So here I am quite below >> the browser limits, still the segfault occurs in different places. >> Ignore the first console line, it results from Norton Utilities I think. >> >> [image: error2.png] >> >> Dieter Weidenbrück schrieb am Donnerstag, 25. Mai 2023 um 18:06:27 UTC+2: >> >>> Hi Sam, >>> I noticed already that I am bumping against browser limits, especially >>> with sanitizer switched on, so I reduced the pre-allocation calls. >>> It turns out that asan uses so much memory that I can't use it to >>> analyze this case. >>> >>> I use >>> -s ALLOW_MEMORY_GROWTH=1 >>> but don't specify any MAXIMUM_MEMORY. >>> >>> No pthreads version so far. I might try this next. >>> >>> Cheers, >>> Dieter >>> >>> s...@google.com schrieb am Donnerstag, 25. Mai 2023 um 17:55:41 UTC+2: >>> >>>> Firstly, if you are allocating 1.8Gb you are likely pushing up against >>>> browser limits. Are you specifying a MAXIMUM_MEMORY of larger than 2GB? >>>> >>>> Secondly, it looks like you are using wasm workers, which are still >>>> relatively new. Do you have a version of your code that uses pthreads >>>> instead? It might tell is if the issue is related to wasm workers. >>>> >>>> cheers, >>>> sam >>>> >>>> On Thu, May 25, 2023 at 8:06 AM 'Dieter Weidenbrück' via >>>> emscripten-discuss <emscripte...@googlegroups.com> wrote: >>>> >>>>> The joy was premature, even with pre-allocated heap size segfaults >>>>> occur. :( >>>>> >>>>> Dieter Weidenbrück schrieb am Donnerstag, 25. Mai 2023 um 16:28:37 >>>>> UTC+2: >>>>> >>>>>> All, >>>>>> I am experiencing segmentation faults when using wasm workers. >>>>>> Overview: >>>>>> I am working on a project with considerable 3D data sets. The code >>>>>> has been stable for a while when running in the main thread alone. Then >>>>>> I >>>>>> started using js workers (no shared memory), and again all was well. >>>>>> Now I've switched to SharedArrayBuffers and wasm workers, and I keep >>>>>> running into random problems. >>>>>> I have prepared the code such that I can run with 0 workers up to >>>>>> hardware.concurrency workers. All is well with 0 workers, but as soon as >>>>>> I >>>>>> use one or more workers, I keep getting segfaults because of invalid >>>>>> pointers, access out of bounds and similar. >>>>>> >>>>>> What happens in main thread and what in the wasm workers: >>>>>> I allocate all objects in the main thread when importing the 3D file. >>>>>> Then i fire off a function for each object that will do some serious >>>>>> calculations of the data, including allocating and disposing of memory. >>>>>> The >>>>>> workers allocate approx. 300 to 400 MB in addition to the main thread. >>>>>> All >>>>>> this happens in the same sharedArrayBuffer, of course. >>>>>> >>>>>> Here is what I've tried so far: >>>>>> - compiling with SAFE_HEAP=1 >>>>>> not a lot of helpful information, >>>>>> - compiling with -fsanitize=address >>>>>> everything works without problems here! >>>>>> - compiling with ASSERTIONS=2 >>>>>> gave me this information: >>>>>> [image: error.png] >>>>>> >>>>>> To me it looks like another resize call is executed while other >>>>>> workers keep working on the buffer, and then something gets into >>>>>> conflict. >>>>>> To test this, I allocated 1.8 GB right after startup in the main >>>>>> thread and disposed the mem blocks again just to trigger heap resize. >>>>>> After >>>>>> that everything works like a charm. >>>>>> >>>>>> Is there anything I am doing wrong? >>>>>> Sorry for not providing a sample, but there is a lot of code >>>>>> involved, and it is not easy to simulate this behavior. Happy to answer >>>>>> questions. >>>>>> >>>>>> All comments are appreciated. >>>>>> Thanks, >>>>>> Dieter >>>>>> >>>>> -- >>>>> 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 emscripten-disc...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/emscripten-discuss/80d56314-59d8-4332-bb2e-ebe00fe52ea3n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/emscripten-discuss/80d56314-59d8-4332-bb2e-ebe00fe52ea3n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> 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 emscripten-disc...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/cfc03512-f69f-44b0-8c14-1f1a8e4ffe9fn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/cfc03512-f69f-44b0-8c14-1f1a8e4ffe9fn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/e568e189-4259-460f-9601-e7996927cdb7n%40googlegroups.com.
