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
signature.asc
Description: PGP signature
