Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory leak related to emscripten_fetch #8152

Closed
paulli2017 opened this issue Feb 22, 2019 · 3 comments
Closed

memory leak related to emscripten_fetch #8152

paulli2017 opened this issue Feb 22, 2019 · 3 comments
Labels

Comments

@paulli2017
Copy link

Hi,

I am debugging a memory leaking issue in Firefox nightly build, which ran our test application. In our test application we used emscripten_fetch API to get chunk from HLS streaming server(test running at LAN server 10.73.82.177). After several hours running, I noticed that Firefox NightlyCP web content used double size memory as those of the chunks downloaded from server, which seems that the memory used to store the chunk content is never released.

Actually I read this issue:
#6359
and from the discussion the memory leaking issue should be solved. Unfortunately I still can reproduce the issue with the almost same test application written by me: (My test is based on latest emscripten code release: 1.38.27. Compiling command is: emcc -s fetch.c -s WASM=1 -s FETCH=1 -o fetch.html)

Is there still anything missing here when I used emscripten_fetch API to fetch HLS chunks?
Thanks for your help!

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <emscripten/fetch.h>

void downloadSucceeded(emscripten_fetch_t *fetch) {
printf("Finished downloading %llu bytes from URL %s time=%u\n", fetch->numBytes, fetch->url);
emscripten_fetch_close(fetch);
}

void downloadFailed(emscripten_fetch_t *fetch) {
printf("Downloading %s failed, HTTP failure status code: %d.\n", fetch->url, fetch->status);
emscripten_fetch_close(fetch);
}

int main(int argc, char* argv[])
{
printf("Test started\n");
int time = 20000;
while(time >= 0) {
emscripten_fetch_attr_t attr;
emscripten_fetch_attr_init(&attr);
strcpy(attr.requestMethod, "GET");
attr.attributes = EMSCRIPTEN_FETCH_LOAD_TO_MEMORY;
attr.onsuccess = downloadSucceeded;
attr.onerror = downloadFailed;
emscripten_fetch(&attr, "http://10.73.82.177/test1M.ts");
time--;
}
printf("End of test\n");
return 0;
}

@kripken
Copy link
Member

kripken commented Feb 25, 2019

cc @juj

@paulli2017
Copy link
Author

Further investigating this issue, I used memory profiling tool provided by Firefox browser when I ran the test application on MacOS. I noticed that the most memory used were from ArrayBuffer type data, which were the memory allocated by the javascript to store the HLS chunk(video file) downloaded from server.
You can get this from the screen shot I got while the test application was running.
memory_usage

As I searched from internet, it seems the release of ArrayBuffer type data memory should be taken cared by GC of javascript( I am from c/c++ background). From this test, however, it seems that the GC never kicks in to collect those memory after the video chunk was decoded and displayed on browser, which leads to the total memory usage keep growing up. Later I found this memory leaking discussion in Nodejs used by Emscripten, nodejs/node#21021
From the discussion, there is memory leaking issue in Node.js V8.*, but it is already fixed in Node.js V9. * , however, current emscripten still used V8.9.1.
Does it really mean the current memory leaking issue in my test come from Node.js? Do I need to run my test with latest version of Node.js? If so, how should I update the current Node.js in emscripten?
Really appreciate your help with this!

@stale
Copy link

stale bot commented Feb 29, 2020

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Feb 29, 2020
@stale stale bot closed this as completed Mar 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants