6

A multi-thread process written in C exhausts almost all of system memory. To find out the thread which is consuming most of the memory, I made a core file using gcore [pid] to check the memory usage per threads, but I can't find the way to do that.

ps -eLFlm and top command with -H option shows the total memory consumption, but not per thread.

Is there any useful tip to solve the problem?

OS : Centos6

nabster
  • 1,561
  • 2
  • 20
  • 32
박영길
  • 61
  • 1
  • 1
  • 3
  • Try `$ ps -T -p ` – nabster Oct 02 '18 at 02:13
  • Are you sure about this statement _To find out the thread who consuming the memory_ ? That there are indeed multiple threads spawn off in your process. – nabster Oct 02 '18 at 02:15
  • 1
    ps -T -p does not show memory information. It shows PID of threads. Process I want to examine has 18 threads including LWP. – 박영길 Oct 02 '18 at 04:10
  • What is your program doing? How long does it runs before exhausting system memory? How big is it (hundred thousands lines of C)? What libraries are you using? All these details are important, so you'll better [edit](https://stackoverflow.com/posts/52601090/edit) your question and provide some motivation and context! – Basile Starynkevitch Oct 02 '18 at 05:48

1 Answers1

2

A multi-thread process written in C exhausts almost all of system memory. To find out the thread which is consuming most of the memory....

That question does not make sense. By definition, all threads of the same process share the same virtual address space. You could query it programmatically using proc(5) (e.g. reading /proc/self/maps from your program).

It is possible (and quite common) that some heap memory is allocated (e.g. with malloc) in thread A, and would be released (e.g. free-d) later in some other thread B (often the main thread, just before exiting).

The C dynamic memory management heap is, by definition, a whole program property.

A typical example is the last arg argument to pthread_create(3). It generally should be heap-allocated. You could document and adopt the convention that the calling thread (the one using pthread_create) would malloc it, but that the created thread should free it (you could require that each start_routine passed to pthread_create should free that arg).

Is there any useful tip to solve the problem?

Perhaps valgrind might help you finding your memory leaks. You'll better compile all your program (and perhaps some relevant libraries) with DWARF debug information (e.g. compile with gcc -g) then restart your program. But such bugs are difficult to find, so be prepared to spend several weeks on them.

From the conceptual point of view, the "theory" of garbage collection (and also smart pointers, RAII, perhaps reference counting, etc...) could be helpful. So read the GC handbook (it is introducing the good concepts and terminology, and it explains that memory management is a whole program issue). A lot of concepts there are even relevant for programs in non-GC-ed languages like C or C++.

You need to define and follow some good enough whole program conventions regarding memory management (and that is difficult).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547