Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #93951 > unrolled thread

Bug#1146373: linux-libc-dev: sbrk(2) allocates more than memory + swap space

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1146373: linux-libc-dev: sbrk(2) allocates more than memory + swap space Carl Wuebker <office@wuebker.com> - 2026-08-31 23:40 +0200
    Bug#1146373: linux-libc-dev: sbrk(2) allocates more than memory + swap space Uwe Kleine-König <ukleinek@debian.org> - 2026-09-16 20:50 +0200
    Bug#1146373: linux-libc-dev: sbrk(2) allocates more than memory + swap space Uwe Kleine-König <ukleinek@debian.org> - 2026-09-23 16:30 +0200
    Bug#1146373: marked as done (linux-libc-dev: sbrk(2) allocates  more than memory + swap space) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-09-25 13:40 +0200

#93951 — Bug#1146373: linux-libc-dev: sbrk(2) allocates more than memory + swap space

Package: linux-libc-dev
Version: 6.12.107-1
Severity: normal
Dear Maintainer,

   The problem is that sbrk(2) checks each new request against the 
machine's total RAM + swap space.  It should check each new request 
against total RAM + swap space - memory that has already been allocated 
to the current process.

Steps to reproduce:
1. Compile & run the program below on a machine with 32 GiB memory & 24 
GiB swap

--- eatmem_bad.c
#include <stdio.h>
#include <unistd.h>

intptr_t bigMem = (intptr_t) 128LL*1024*1024*1024;

int main(int argc,char *argv[]) {
     intptr_t i;
     unsigned long long mem;

     if (argc != 1)
         { (void) fprintf(stderr,"Usage: %s\n", argv[0]); return 2; }

     mem=0;
     for (i = bigMem; i >= 16; i /= 2)
         if (sbrk(i) != (void *) -1)
             mem |= i;

     (void) printf("Memory=%llu MiB\n",mem / (1024*1024));

     return 0;
     }
---

Expected (and correct) result:
Memory=56718 MiB

Actual result:
Memory=65535 MiB

-- System Information:
Debian Release: 13.6
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.107+deb13-amd64 (SMP w/14 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

[toc] | [next] | [standalone]

#94104

[Multipart message — attachments visible in raw view] — view raw

Hello Carl,

On Mon, Aug 31, 2026 at 12:23:35PM -0700, Carl Wuebker wrote:
> Package: linux-libc-dev
> Version: 6.12.107-1
> Severity: normal
> Dear Maintainer,
> 
>   The problem is that sbrk(2) checks each new request against the machine's
> total RAM + swap space.  It should check each new request against total RAM
> + swap space - memory that has already been allocated to the current
> process.
> 
> Steps to reproduce:
> 1. Compile & run the program below on a machine with 32 GiB memory & 24 GiB
> swap
> 
> --- eatmem_bad.c
> #include <stdio.h>
> #include <unistd.h>
> 
> intptr_t bigMem = (intptr_t) 128LL*1024*1024*1024;
> 
> int main(int argc,char *argv[]) {
>     intptr_t i;
>     unsigned long long mem;
> 
>     if (argc != 1)
>         { (void) fprintf(stderr,"Usage: %s\n", argv[0]); return 2; }
> 
>     mem=0;
>     for (i = bigMem; i >= 16; i /= 2)
>         if (sbrk(i) != (void *) -1)
>             mem |= i;
> 
>     (void) printf("Memory=%llu MiB\n",mem / (1024*1024));
> 
>     return 0;
>     }
> ---
> 
> Expected (and correct) result:
> Memory=56718 MiB
> 
> Actual result:
> Memory=65535 MiB

I wonder what your actual problem is.

It's quite usual that a process can get more memory assigned than there
is physically available. That's called "overcommitting" if you want to
research about that.

Unless there is a real problem to solve I suggest to either ignore it or
discuss with upstream what to do.

Best regards
Uwe

[toc] | [prev] | [next] | [standalone]

#94188

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Wed, Sep 16, 2026 at 01:32:09PM -0700, Carl Wuebker wrote:
>   Thanks for your reply.  The "real problem" comes from the current
> situation in CAD, AI & other single programs running on a Linux machine. 
> Some programs need a way to find out how much RAM is available and might use
> a technique similar to this one, which might report that almost 2x the
> available RAM is available because, as the man page says:

Sounds too hypothetical to me to spend my time on debugging that.

> "On success, sbrk() returns the previous program break.  (If the break  was 
> increased,  then this  value is a pointer to the start of the newly
> allocated memory).  On error, (void *) -1 is returned, and errno is set to
> ENOMEM."
> 
> When I read this, I think "if the memory allocation was unsuccessful, I'll
> get an error."  But that's not the case -- I guess that if I ask it to
> allocate 128 GBy and get no error, I still need to check the brk(2) value to
> see if the memory was allocated.

brk() doesn't allocate memory, that's done lazily once the program hits
a page fault. 

> So, in my mind (but maybe not obvious to others), there is a problem with 2
> solutions -- one is to return an error if the last memory allocation fails,
> the other is to update the sbrk(2) documentation to tell the user that --
> even if the sbrk(2) doesn't return an error -- they need to compare the
> sbrk(2) return value with the last sbrk(2) value to see if it moved -- if it
> didn't move, the allocation failed.

This is not practical. Please research about "linux overcommit memory"
to learn why the situation is as it is.
 
> Where can I find a reasonably up-to-date copy of Linux's sbrk(2) code?  I
> might be better able to understand your comments and/or recommend a solution
> if I read that code.

Check the libc and kernel source.

Best regards
Uwe

[toc] | [prev] | [next] | [standalone]

#94214 — Bug#1146373: marked as done (linux-libc-dev: sbrk(2) allocates more than memory + swap space)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Fri, 25 Sep 2026 13:34:16 +0200
with message-id <882bfd22b7c6c705ea917463d0379fee95e8c520.camel@decadent.org.uk>
and subject line Re: Bug#1146373: linux-libc-dev: sbrk(2) allocates more than memory + swap space
has caused the Debian Bug report #1146373,
regarding linux-libc-dev: sbrk(2) allocates more than memory + swap space
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1146373: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146373
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web