Your message dated Fri, 25 Sep 2026 13:34:16 +0200
with message-id <[email protected]>
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 [email protected]
immediately.)
--
1146373: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146373
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Wed, 16 Sep 2026 20:40:58 +0200 Uwe Kleine-König
<[email protected]> wrote:
[...]
> 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.
Indeed this is the expected default behaviour, not a bug. The behaviour
can be changed through the vm.overcommit_* sysctls:
<https://docs.kernel.org/admin-guide/sysctl/vm.html#overcommit-kbytes>.
These articles may help you to make a decision whether to change the
overcommit behaviour or to set other memory limits:
- https://utcc.utoronto.ca/~cks/space/blog/linux/LinuxVMOvercommit
- https://utcc.utoronto.ca/~cks/space/blog/linux/StrictOvercommitNoLongerUsing
Ben.
--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.
signature.asc
Description: This is a digitally signed message part
--- End Message ---
