Is there some reason you added `-sABORTING_MALLOC=0`.. that looks a little suspicious, since it means the program can continue after malloc fails.. which mean that any callsite that doesn't check the return value of malloc can lead to segfaults. If you remove that setting does the behaviour change?
On Thu, May 25, 2023 at 1:27 PM 'Dieter Weidenbrück' via emscripten-discuss <emscripten-discuss@googlegroups.com> wrote: > 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 > <https://groups.google.com/d/msgid/emscripten-discuss/e568e189-4259-460f-9601-e7996927cdb7n%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/CAL_va2-%2BiLoZhfCwr%2B9dtt9RceqJGusRv0F4apCNwJhk6pm_Og%40mail.gmail.com.
