Bug 101968 - shmat dumps core on RHL 7.2 when mapping is not possible
Summary: shmat dumps core on RHL 7.2 when mapping is not possible
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-08 13:33 UTC by Need Real Name
Modified: 2015-01-04 22:02 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2004-09-30 15:41:25 UTC

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

Description Need Real Name 2003-08-08 13:33:57 UTC
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 13:38:14 UTC
Created attachment 93520 [details]
A C test case to reproduce the problem

Comment 2 Jakub Jelinek 2003-08-10 14:52:21 UTC
glibc passes shmat directly to the kernel ipc multiplexer; changing component.

Comment 3 Arjan van de Ven 2003-08-19 13:10:11 UTC
the 7.2 and 8.0 kernels are basically the same. Just use the erratum.

Comment 4 Need Real Name 2003-08-19 13:13:57 UTC
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 13:40:34 UTC
which kernel are you using on RHL7.2 ?

Comment 6 Need Real Name 2003-08-19 13:44:56 UTC
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 11:11:41 UTC
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 11:14:28 UTC
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 11:21:49 UTC
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 15:41:25 UTC
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.