Bug 142291 - Sun Java (both 1.3.1 and 1.4.2) throws out of memory errors
Summary: Sun Java (both 1.3.1 and 1.4.2) throws out of memory errors
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 3.0
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-08 19:46 UTC by James Bottomley
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-25 11:12:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description James Bottomley 2004-12-08 19:46:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
When our java application server runs, after a certain amount of
activity it eventually throws an OutOfMemory exception and dies.  This
only happens on the ia64 platform (the same application is fine on
ia32) and only on Update3 (the application runs fine on Update2 of RHEL3).

I'm still trying to formulate a simpler case than our entire java
application, but so far we haven't been able to reproduce it more simply.

Object tracing seems to indicate that garbage collection occurs
correctly, so I don't understand what exactly is causing the out of
memory errors.

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

How reproducible:

Steps to Reproduce:
1.  Start LifeKeeper java GUI server
2.  Begin administration of the server
3.  wait for the crash

Actual Results:  Java server throws OutOfMemory exception

Expected Results:  Server should operate with no exceptions

Additional info:

Comment 1 Jakub Jelinek 2004-12-09 14:44:05 UTC
Can you try mtracing the application?
I.e. run it under debugger with MALLOC_TRACE=/tmp/app.mtrace in the environment,
put a breakpoint on java's main, call mtrace () there and continue.
Then run mtrace utility on the log file to see whether there are any memory
leaks and where.

If this doesn't show anything, we need a (small) reproducer.

Comment 2 Jakub Jelinek 2005-03-25 11:12:43 UTC
If you have details, please reopen.

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