Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 79491 - Sessions shut down for "Out of Memory" error
Summary: Sessions shut down for "Out of Memory" error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i586
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-12 12:07 UTC by Need Real Name
Modified: 2007-04-18 16:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-03-01 22:23:25 UTC


Attachments (Terms of Use)

Description Need Real Name 2002-12-12 12:07:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
During the operation of Red Hat 8.0, my open sessions will suddenly start to 
close down for what "appears" to be an out of memory issue.  I am running 
512MB of DDRRAM and am not running any memory intensive applications.  I have 
seen some postings in Linux groups that refer to an issue with the vmalloc.c 
file.  Is this the underlying problem?

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


How reproducible:
Sometimes

Steps to Reproduce:
1. Run Linux (sorry that's the only thing that I can think of)
2.
3.
	

Actual Results:  Sessions begin to shut down for out of memory errors.

Expected Results:  Sessions should not shut down.

Additional info:

I receive the following message:

Dec  5 07:15:52 syscon kernel: Out of Memory: Killed process 1436 (gnome- 
terminal). Dec  5 07:15:53 syscon kernel: Trying to vfree() nonexistent vm 
area (e02bd000) Dec  5 07:15:53 syscon kernel: d8513ea4 d859a180 00000025 
c012bd4b d859a180 dc4b9940 00000000 d8512000
Dec  5 07:15:53 syscon kernel:        00000009 c01193f9 dc4b9940 00200202 
dc4b9940 c011e006 dc4b9940 c245a2dc
Dec  5 07:15:53 syscon kernel:        d8512000 00000000 d8513f30 00000009 
c012436c 00000009 c0124554 00000009
Dec  5 07:15:53 syscon kernel: Call Trace: [<c012bd4b>] do_no_page [kernel] 
0xeb (0xd8513eb0)) Dec  5 07:15:53 syscon kernel: [<c01193f9>] mmput [kernel] 
0x39 (0xd8513ec8)) Dec  5 07:15:53 syscon kernel: [<c011e006>] do_exit 
[kernel] 0xa6 (0xd8513ed8)) Dec  5 07:15:53 syscon kernel: [<c012436c>] 
sig_exit [kernel] 0xac (0xd8513ef4)) Dec  5 07:15:53 syscon kernel: 
[<c0124554>] dequeue_signal [kernel] 0x64 (0xd8513efc)) Dec  5 07:15:53 syscon 
kernel: [<c0108ea7>] do_signal [kernel] 0x1f7 (0xd8513f14)) Dec  5 07:15:53 
syscon kernel: [<c01249c1>] deliver_signal [kernel] 0x31 (0xd8513f68)) Dec  5 
07:15:53 syscon kernel: [<c0109c00>] do_general_protection [kernel] 0x0 
(0xd8513fa0)) Dec  5 07:15:53 syscon kernel: [<c01168c0>] do_page_fault 
[kernel] 0x0 (0xd8513fb8)) Dec  5 07:15:54 syscon kernel: [<c0109148>] 
signal_return [kernel] 0x14 (0xd8513fc0)) Dec  5 07:15:55 syscon kernel:

Comment 1 Michael Lee Yohe 2002-12-12 16:49:58 UTC
Ick - it is the behaviour of the kernel to salvage a running system by nixing
off processes to free memory.  This is to prevent complete system instability. 
Could you please provide the output of your /proc/meminfo after having the
system up and running for a while?

Comment 2 Miloslav Trmac 2002-12-12 19:42:53 UTC
Run xdpyinfo, check whether you have a RENDER extension.
If not, gnome-terminal and other GNOME apps leak memory.
The workaround is IIRC to use konsole or xterm instead of
gnome-terminal. Note that other apps reportedly suffer from
the leaks too, but gnome-terminal is usually the most
severe.

Comment 3 Tim Waugh 2002-12-19 19:12:11 UTC
'kernel: Trying to vfree() nonexistent vm area (e02bd000)' is the start of the
kernel running into problems.  That shouldn't normally happen.

Are you 100% sure that the memory in the system is reliable?  If so, and you see
the same behaviour with different memory modules in place as well, please
re-open and submit the entire 'oops' message.  Thanks.

Comment 4 Need Real Name 2002-12-19 20:10:14 UTC
Memory modules have been swapped and replaced.  The intermitent problem 
remains.  We've switched to KDE from GNOME on the advice of Miloslav and are 
waiting to see if this reolves the problem.  We have not been able to capture 
the output of /proc/meminfo yet.  

Comment 5 acount closed by user 2003-03-01 20:55:22 UTC
does the system pass hardware test like memtes86 http://www.memtest86.com/ or
cpuburn http://users.ev1.net/~redelm ?



Comment 6 Need Real Name 2003-03-01 22:23:25 UTC
Switching from GNOME to KDE resolved problem.  There is a meory leak in GNOME 
desktop.


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