Ah, wrote the reply before seeing the most recent messages in this thread: so it looks like the allocations are accounted to happen inside the Wasm heap, in which case the interesting question is where these occur in that aren't freed. --memoryprofiler is one tool that can capture outstanding memory allocations and bucket them according to callstack. If there's a rogue running allocation that occurs from the same callstack, then it should be visible there.
2017-12-22 15:13 GMT+02:00 Jukka Jylänki <[email protected]>: > To help diagnose if it's the browser that's leaking memory, or if it's the > user wasm code that is expanding in size, in addition to --memoryprofiler, > there exists two other ways to grab memory allocation statistics inside the > Wasm heap: > - you can wrap malloc() and free() to manually track memory allocations: > https://github.com/kripken/emscripten/blob/incoming/tests/wrap_malloc.cpp > - you can also get stats info from the built-in allocator: > https://github.com/kripken/emscripten/blob/incoming/tests/mallinfo.cpp > > Overall, the interesting question is whether the Wasm heap size is what is > blowing up, or if it's something else in the browser. > > 2017-12-20 6:28 GMT+02:00 Alon Zakai <[email protected]>: > >> Is the behavior the same on other browsers? It's possible you're running >> into a Chrome bug here. >> >> On Firefox, you can use about:memory to inspect browser memory >> internally, which might help if the issue is not the wasm memory itself. >> >> >> >> On Tue, Dec 19, 2017 at 6:38 PM, Zheng Tao Lee <[email protected]> >> wrote: >> >>> any thoughts on how i can find out whats allocating in that private data? >>> i used --memoryprofiler and --tracing, but couldnt find anything wrong >>> with my code. theres lots of memory unaccounted for. >>> >>> Thanks, >>> Tao >>> >>> >>> On Tuesday, December 19, 2017 at 5:56:28 PM UTC+8, Zheng Tao Lee wrote: >>>> >>>> Hi, >>>> >>>> I am working an a project where we have a model with quite a few lines >>>> and points, these are allocated in my c++ code. using ALLOW_MEMORY_GROWTH, >>>> we can see that the memory keeps on growing until it eventually goes out of >>>> memory. >>>> >>>> on other platforms the same code runs and uses about 300mb of memory. >>>> on WASM however it keeps on allocating more. >>>> >>>> What i am concerned about is the amount of private data in the working >>>> set. >>>> >>>> Can anyone shine some light on what goes on inside there? i am using >>>> the sysinternals tool VMMAP to obtain this chart. >>>> >>>> >>>> >>>> <https://lh3.googleusercontent.com/-WwTr_O2YdzA/WjjgTpFCviI/AAAAAAAABDM/aqN8ASF2dksXcrUSJ91uc7uVeHVoWOUuACLcBGAs/s1600/vmmap_memory%2Bmap.png> >>>> >>> -- >>> 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]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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]. For more options, visit https://groups.google.com/d/optout.
