Closed runfoapp[bot] closed 2 years ago
ghost
commented
2 years ago Tagging subscribers to this area: @dotnet/area-system-io See info in area-owners.md if you want to be subscribed.
| Author: | runfoapp[bot] |
|---|---|
| Assignees: | - |
| Labels: | `area-System.IO`, `untriaged` |
| Milestone: | - |
jkotas
commented
2 years ago Looks like OOM (I do not see any coredumps captured):
[ 5014.009220] Out of memory: Killed process 13259 (dotnet) total-vm:9549292kB, anon-rss:6020812kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12364kB oom_score_adj:0
[ 5014.204711] oom_reaper: reaped process 13259 (dotnet), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
danmoseley
commented
2 years ago My understanding when I looked at this before is that it is not possible to configure Linux to capture a core dump before oom-killing. So next step is probably to run locally, and even if it does not OOM, hopefully it is clear there is excessive memory use and then bisect.
agocke
commented
2 years ago @dotnet/area-system-io Could someone take a look at this please? It's hitting PRs somewhat often
fanyang-mono
commented
2 years ago Should System.IO.Tests be disabled, while being investigated? It is still happening quite often on rolling builds.
danmoseley
commented
2 years ago @jeffhandley is anyone on the IO crew available to look at this? We can't disable all the IO tests en masse, if they can at least narrow down where hte memory usage is, or add some logging ,etc that would be a win.
AraHaan
commented
2 years ago Too bad each test could not run in separate processes so that way the testing lib could just analyzer the working sets on them all to find the test that uses the most memory.
jeffhandley
commented
2 years ago @Jozkee Could you take a look at this within the next couple days please?
Displaying 100 of 118 results