Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 62451 - Application containing huge BSS section (~1G) causes segmentation fault
Application containing huge BSS section (~1G) causes segmentation fault
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
high Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-04-01 00:59 EST by Grigory Zagorodnev
Modified: 2016-11-24 10:01 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-17 11:59:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The failing test-case (209 bytes, text/plain)
2002-04-01 01:00 EST, Grigory Zagorodnev
no flags Details

  None (edit)
Description Grigory Zagorodnev 2002-04-01 00:59:04 EST
The problem

In case of an application contains a lot* of uninitialized data (mapping to the 
BSS), kernel fails to load it into the memory.

It looks like just out of memory, but the kernel does not control result of bss 
allocation. So, BSS'a pages become overlapped with the executable pages.

Finally, kernel tries to run the application. It causes segmentation fault.
* "a lot" - actuall size of BSS may vary. Usually it is about 1G.

Version-Release number
    2.4.2-2smp (Red Hat 7.1)
    2.4.18-0.1 (Red Hat 7.3b2)

How reproducible:

Steps to Reproduce
1. Take attached test-case
2. Build it using any C compiler. For instance:
    gcc main.c
3. Execute ./a.out
Actual Results
Given application failed to run:
    $ ./a.out
    Segmentation fault (core dumped)

The basic GDB's information is:
    $ gdb a.out core
    Program terminated with signal 11, Segmentation fault.
    #0  0x40001dc0 in var ()
    (gdb) bt
    #0  0x40001dc0 in var ()

We see that the kernel passed control to the variable (var) defined onthe BSS. 
It's definitely wrong!

Expected Results
Expected result is just an unambiguous behaviour of kernel:
   - run executable in case memory allocated successfully (then you will 
see "Passed" message from the given test-case);
   - kernel's error message showing that the application could not be loaded 
into the memory.
Comment 1 Grigory Zagorodnev 2002-04-01 01:00:58 EST
Created attachment 51604 [details]
The failing test-case
Comment 2 Arjan van de Ven 2002-06-17 11:59:22 EDT
looks like ld.so overlaps libs with the bss...
Comment 3 Jakub Jelinek 2002-06-17 12:14:03 EDT
Yes, this is an expected result. Don't do that, use malloc or mmap instead...
The kernel is loading the dynamic linker first and the default mmap address
is 0x40000000.
Red Hat Linux Advanced Server 2.1 allows to tweak that address at runtime
for a process and all its future children, or you can prelink(8) the dynamic linker
to some other address, so that kernel doesn't mmap it at address 0 (which means
choose any), but at some specific address.

Note You need to log in before you can comment on or make changes to this bug.