This is the mail archive of the
mailing list for the elfutils project.
Re: Bugzilla component missing and another (minor) fuzzing-related bug report
- From: Florian Weimer <fweimer at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 21 Oct 2015 22:18:56 +0200
- Subject: Re: Bugzilla component missing and another (minor) fuzzing-related bug report
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