Description of problem: The call to shmat dumps core when shmaddr is specified and the mapping is not possible. 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 program. The case is applicable to RHL 7.2 . On RHL 8.0 it returns an error and exits gracefully. 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.
Created attachment 93520 [details] A C test case to reproduce the problem
glibc passes shmat directly to the kernel ipc multiplexer; changing component.
the 7.2 and 8.0 kernels are basically the same. Just use the erratum.
What do you mean by this?? What is to be done so as to avoid the core dump on RHL 7.2?? Please help, Thanks, Sayali Surve
which kernel are you using on RHL7.2 ?
The kernel used for RHL 7.2 is : 2.4.7-10smp 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
Could you please let me know the status of this bug ?? This is very important for our customers.
2.4.7-10smp 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.
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.
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 persists. 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/