On 10/21/2015 10:17 PM, Alexander Cherepanov wrote: > On 19.10.2015 12:07, Florian Weimer wrote: >> On 10/19/2015 02:50 AM, Alexander Cherepanov wrote: >> >>> gcc doesn't support objects more than half the address space in size -- >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 . So if you are >>> malloc'ing >2GB on 32-bit platforms you should be concerned. >> >> This needs to be fixed in GCC. Even if we artificially fail large >> allocations in malloc, there will be cases where people call mmap or >> shmat directly. And at least for the latter two, there is an >> expectation that this works with larger-than-2-GiB mappings for 32-bit >> processes (to the degree that Red Hat shipped very special 32-bit >> kernels for a while to support this). > > I'm all for fixing it in GCC. It gives more flexibility: you cannot > support huge objects in libc when your compiler doesn't support them but > you can choose if you want to support them in libc when you compiler > support them. But I guess it's not easy to fix. > > OTOH perhaps ability to create huge objects in libc should be somehow > hidden by default? As evidenced by this thread:-)
It's possible to set a virtual address space limit with ulimit. Is this sufficient? Florian
