-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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
Investigate flaky parallel/test-http-pipeline-regr-3332 on smartos15-64 #15418
Comments
There should be a core file on the machine where that test ran. @nodejs/build: Is it possible to grab that core file and upload it somewhere people can download it? |
/cc @nodejs/platform-smartos |
Do you have a link to the job that failed? Couldn't see it with a quick check. @misterdjules what's the easiest way to get you a core file? Is there any sensitive data on there, or can it just go on ci.nodejs.org/downloads (see nodejs/build#871 (comment)) ? |
@misterdjules or we could just put your key on the machine and you could scp it off. |
@gibfahn There should be no sensitive data in the core file. ci.nodejs.org/downloads is fine for now, but it'd be good to think about a cleaner long term approach for storing and cleaning up those files. |
@misterdjules I think it's this one https://expirebox.com/download/7c459d040bf2d407ddd80908463fc665.html |
The test started at 5:17pm and took 22 minutes so it's hard to say which core file it is. Perhaps we should either start including the child process pid in error output (wouldn't work for some situations with cluster tests for example) or we could change the coredump handler to include the pid and the test filename? I know for the latter you can accomplish that pretty easily in Linux by setting |
Times are in UTC, so 5:17pm => 21:40UTC, but that's when the tests ended (the rest of the suite continued)
|
@refack Thank you very much for uploading the core file! After downloading it, I was able to verify that it was generated from a node process running the test mentioned in this issue with:
Looking at the stacks:
It seems that the optimizing compiler tried to allocate memory and failed. At the same time, the main thread that runs the libuv event loop was also allocating memory. Looking at the cumulated size of anonymous segments (JS heap), we find:
So the process was using ~51MBs of memory for the JS heap, and about the same of the native heap:
Which seems consistent with the small size (144MBs) of the core file itself. This looks a lot like the processes running when this test was running were using all the memory available to the VM. |
I'm going to close this as it hasn't shown up recently, and it seems like a lack of available memory was the underlying cause. |
The text was updated successfully, but these errors were encountered: