gef invoked oom-killer for core file from a mem-leak process

[jqguo367]

I have a core file which is from a 32-bit process which has memory leak issue. The core file is 3G+ in size. I'd like to dump the heap chunks to infer which memory allocations were leaked.

But gdb 8.1 (+ gef) would be oom-killed after a couple of minues after I issue command "heap chunks".

From the /var/log/messages: Oct 17 17:16:29 USSP04-0-0-1 kernel: [13741673.479615] Out of memory: Kill process 15272 (gdb-8.1) score 789 or sacrifice child Oct 17 17:16:29 USSP04-0-0-1 kernel: [13741673.481768] Killed process 15272 (gdb-8.1), UID 0, total-vm:16854184kB, anon-rss:15290676kB, file-rss:1496kB, shmem-rss:0kB

Is there GEF configuration settings which can avoid OOM ?

[hugsy]

Is there GEF configuration settings which can avoid OOM ?

It's impossible for us to know what causes your issue, because it's too vague. So we cannot answer your question.

If you want us to consider examining this situation, file another issue and properly fill the template with a reproduction case.

[jqguo367]

The reason why gdb+gef was oom-killed is because "heap chunks" command was using a lot of memory. The command seems output the result only after the scaning of the whole heap completed. To reduce memory consupmtion, It shoud output what already got while it perform scanning.

You can easily reproduce the issue with the following program.

` #include <stdlib.h> #include <stdio.h>

int main() {

for (int i = 0; i< 10000000; i++) { char *p = (char* )malloc(1); p[0] = 0x1; } abort(); return 0; } `

With the core file generated, then analyse it using "heap chunks" command. Of course, whether OOM killer can be triggered or not immediately depends on the RAM avaiable on the machine.

[jqguo367]

With a coredump from a memory leak process, there are vast number of heap chunks inside the process space. So GEF OOM issue can occur.

[jqguo367]

Can this be improved ?

[hugsy]

Can this be improved ?

GEF wasn't build for strong support for coredumps because it massively relies on information from the procfs. So it probably can be improved, but no timeline. Feel free to send us a PR.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. You can reopen it by adding a comment to this issue.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. If you are the owner of this issue, you can either re-open it and provide a more complete description; or create a new issue. Thank you for your contributions.