Bug 101968 - shmat dumps core on RHL 7.2 when mapping is not possible
shmat dumps core on RHL 7.2 when mapping is not possible
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-08-08 09:33 EDT by Need Real Name
Modified: 2015-01-04 17:02 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:41:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A C test case to reproduce the problem (1.61 KB, text/plain)
2003-08-08 09:38 EDT, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2003-08-08 09:33:57 EDT
Description of problem:
The call to shmat dumps core when shmaddr is specified and the mapping is not
I have specified the address where the shared memory segment is to be mapped
(0x18000000). As the shared libraries are loaded from address 0x40000000, shared
memory segments upto 640M. If I try to attach more than 640M, instead of
returning an error, shmat dumps core which is undesirable during the run of the
The case is applicable to  RHL 7.2 . On RHL 8.0 it returns an error and exits
Is any patch available on RHL 7.2??

Version-Release number of selected component (if applicable): RHL 7.2

How reproducible: 
It is reproducible with a test case attached to this bugreport.

Steps to Reproduce:
1.  Compile the test case.
2.  Pass the parameter (no. of bytes to create a shared memory segment as
680000000 (Any figure greater than 640M). 

Actual results:
core dump

Expected results:
It should return a error when mapping is not possible.

Additional info:
Please let me know if any patch is available on RHL7.2 or not. Our product is
getting affected because of this.
Comment 1 Need Real Name 2003-08-08 09:38:14 EDT
Created attachment 93520 [details]
A C test case to reproduce the problem
Comment 2 Jakub Jelinek 2003-08-10 10:52:21 EDT
glibc passes shmat directly to the kernel ipc multiplexer; changing component.
Comment 3 Arjan van de Ven 2003-08-19 09:10:11 EDT
the 7.2 and 8.0 kernels are basically the same. Just use the erratum.
Comment 4 Need Real Name 2003-08-19 09:13:57 EDT
What do you mean by this?? What is to be done so as to avoid the core dump on
RHL 7.2??

Please help,
Sayali Surve
Comment 5 Arjan van de Ven 2003-08-19 09:40:34 EDT
which kernel are you using on RHL7.2 ?
Comment 6 Need Real Name 2003-08-19 09:44:56 EDT
The kernel used for RHL 7.2 is :

Here is the output of `uname -a`:

golf{ssurve:/homes/ssurve}<NONE> uname -a
Linux golf 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown
Comment 7 Need Real Name 2003-09-01 07:11:41 EDT
Could you please let me know the status of this bug ?? This is very important
for our customers. 
Comment 8 Arjan van de Ven 2003-09-01 07:14:28 EDT
sounds like you really need to upgrade to a more recent kernel erratum, a large
amount of severe security issues has been resolved, as well as numerous bugfixes.
Comment 9 Need Real Name 2003-09-01 07:21:49 EDT
Could you please let me know the location from where the kernel patches can be
downloaded so as I can refer that to our customers.
Comment 10 Bugzilla owner 2004-09-30 11:41:25 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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