0

I am running some calculations in a program written in C++. For some input parameters I am running out of memory and my program is killed. I tried to spot the problematic part of my program using gdb (which usually works if I have other issues such as accessing memory at the wrong location), but my program is killed by the OS (Linux) when running out of memory, which makes it impossible to use backtrace on it.

Using valgrind and massif does not help either, after there is no massif-log if the program is killed due to being out of memory.

Therefore, are there other approaches I could use? One approach I can see is to simply print the current function name each time I call it (and then check the log to see which function I called last before I ran out of memory), but that would add a lot of code I don't want to write by hand. Are there "automated" methods doing that for me?

EvilTeach
  • 28,120
  • 21
  • 85
  • 141
arc_lupus
  • 3,942
  • 5
  • 45
  • 81
  • Are you using new to allocate the memory? you might be able to overload it to log the size and location of each allocation. That might give you a clue as to where it is happening. – EvilTeach Mar 18 '21 at 15:17
  • Generate a core file. Then you can start gdb on the core and debug tha application at the point it crashed. https://stackoverflow.com/questions/17965/how-to-generate-a-core-dump-in-linux-on-a-segmentation-fault Core generation is off by default on linux systems but if this is a development machine it is a good idea to have it turned on all the time for debugging purposes. – Martin York Mar 18 '21 at 15:24
  • @MartinYork: I get a core dump, but when looking at it using gdb I get ": Cannot access memory at address 0x...> – arc_lupus Mar 18 '21 at 15:46
  • Can you reproduce the problem consistently? If yes, just log all invocations of your functions and you will know set of parameters which cause crash. Than you can run under valgrind and see what is happening there. – SergeyA Mar 18 '21 at 16:00

0 Answers0