I have a Linux program that starts out with one thread, and it uses 88 kB of RAM.

It then spawns a 2nd thread for a TCP connection, and a 3rd thread for sending digital audio samples to ALSA.

When the 2nd and 3rd thread start together, the memory usage jumps from 88 kB to 157 MB. I don't know where this extra memory is being allocated.

So next I run my program under Valgrind Massif, but my program no longer spikes from 88 kB to 157 MB. My program runs fine under Valgrind Massif without any memory spike -- it stays constant at about 88 kB.

Anyone seen this kind of thing before?

On Thursday, June 3, 2021 at 1:19:23 PM UTC+1, Frederick Gotham wrote:
> I have a Linux program that starts out with one thread, and it uses 88 kB of RAM.
>
> It then spawns a 2nd thread for a TCP connection, and a 3rd thread for sending digital audio samples to ALSA.
>
> When the 2nd and 3rd thread start together, the memory usage jumps from 88 kB to 157 MB. I don't know where this extra memory is being allocated.
>
> So next I run my program under Valgrind Massif, but my program no longer spikes from 88 kB to 157 MB. My program runs fine under Valgrind Massif without any memory spike -- it stays constant at about 88 kB.
>
> Anyone seen this kind of thing before?

I used 'pmap' just now on the process when it has jumped up to 157 MB, and I see:

0000007f80021000 65404K ---p [ anon ]
0000007f88021000 65404K ---p [ anon ]

There are two allocations of ~64 MB each. I wonder if it's 64 MB for each thread I spawn? I have one guy telling me it's probably glib.

On 2021-06-03, Frederick Gotham <cauldwell.thomas@gmail.com> wrote:
> On Thursday, June 3, 2021 at 1:19:23 PM UTC+1, Frederick Gotham wrote:
>> I have a Linux program that starts out with one thread, and it uses 88 kB of RAM.
>>
>> It then spawns a 2nd thread for a TCP connection, and a 3rd thread for sending digital audio samples to ALSA.
>>
>> When the 2nd and 3rd thread start together, the memory usage jumps from 88 kB to 157 MB. I don't know where this extra memory is being allocated.
>>
>> So next I run my program under Valgrind Massif, but my program no longer spikes from 88 kB to 157 MB. My program runs fine under Valgrind Massif without any memory spike -- it stays constant at about 88 kB.
>>
>> Anyone seen this kind of thing before?
>
>
> I used 'pmap' just now on the process when it has jumped up to 157 MB, and I see:
>
> 0000007f80021000 65404K ---p [ anon ]
> 0000007f88021000 65404K ---p [ anon ]
>
> There are two allocations of ~64 MB each. I wonder if it's 64 MB for each thread I spawn? I have one guy telling me it's probably glib.

Run it under strace; you will likely see anonymous mmap calls.

Use an ordinary debugger, gdb, and put a breakpoint on that mmap.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Thu, 03 Jun 2021 06:19:29 -0700, Frederick Gotham wrote:

> On Thursday, June 3, 2021 at 1:19:23 PM UTC+1, Frederick Gotham wrote:
>> I have a Linux program that starts out with one thread, and it uses 88 kB of RAM.
>>
>> It then spawns a 2nd thread for a TCP connection, and a 3rd thread for sending digital audio samples to ALSA.
>>
>> When the 2nd and 3rd thread start together, the memory usage jumps from 88 kB to 157 MB. I don't know where this extra memory is being allocated.
>>
>> So next I run my program under Valgrind Massif, but my program no longer spikes from 88 kB to 157 MB. My program runs fine under Valgrind Massif without any memory spike -- it stays constant at about 88 kB.
>>
>> Anyone seen this kind of thing before?
>
>
> I used 'pmap' just now on the process when it has jumped up to 157 MB, and I see:
>
> 0000007f80021000 65404K ---p [ anon ]
> 0000007f88021000 65404K ---p [ anon ]
>
> There are two allocations of ~64 MB each. I wonder if it's 64 MB for each thread I spawn? I have one guy telling me it's probably glib.

According to the Valgrind Massif webpage at
https://www.valgrind.org/docs/manual/ms-manual.html#ms-manual.not-measured,
"[B]y default Massif measures only heap memory, i.e. memory allocated with
malloc, calloc, realloc, memalign, new, new[], and a few other, similar
functions. (And it can optionally measure stack memory, of course.)
This means it does not directly measure memory allocated with lower-level
system calls such as mmap, mremap, and brk. ... Furthermore, a client
program may use these lower-level system calls directly to allocate memory.
By default, Massif does not measure these. Nor does it measure the size of
code, data and BSS segments. Therefore, the numbers reported by Massif may
be significantly smaller than those reported by tools such as top that measure
a program's total size in memory."

So, we know that Valgrind Massif DOESN'T measure memory directly allocated by
mmap(2) calls, /and/ the difference between what /you/ measure as memory usage,
and what Valgrind Massif measures as memory usage can be accounted for by a
couple of mmapped memory blocks.

My guess is that the Valgrind Massif numbers are off, and that your process
uses 157Mb whether run on it's own /or/ under Valgrind Massif. And, that memory
difference comes from something in your execution chain (your code, the TCP/IP
stack code, the ALSA stack code, or other support code) performing naked mmap(2)
calls.

HTH
--
Lew Pitcher
"In Skills, We Trust"