Bug 117243 - application crashes at _int_malloc when short of memory
Summary: application crashes at _int_malloc when short of memory
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-03-01 22:35 UTC by Alex Ao
Modified: 2016-11-24 15:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-26 05:37:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Alex Ao 2004-03-01 22:35:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
After our application runs for several days, we would get coredump 
with the backtrace _int_malloc from /lib/tls/libc.so.6. 

I checked our errorlog that indicated it "can not spawn new thread, 
out of memory."

I am not sure if it is a bug in the glibc for memory management that 
causes this crash. 

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

How reproducible:
Sometimes

Steps to Reproduce:
1. Design a program that keep spawning threads and allocate large 
memory
2. run this program on linux 9 and you will run into this kind of 
crash.
3.
    

Actual Results:  application crashes with coredump

Expected Results:  backtrace the coredump file with gdb which 
has "_int_malloc() from /lib/tls/libc.so.6" information.

Additional info:

Comment 1 Jakub Jelinek 2004-03-03 09:32:21 UTC
In 99% cases this is an application bug.  glibc-2.3's malloc is more
sensitive to application memory management bugs than previous malloc
implementation.  Try some memory allocation debugger on your application
first (ElectricFence, valgrind, MALLOC_CHECK_=3).
BTW: if it turned out to be a glibc bug, your steps to reproduce are
certainly not sufficient to do anything about it.
We would need a self-contained testcase which reproduces it.

Comment 2 Ulrich Drepper 2004-08-26 05:37:06 UTC
No reply in more than 5 months.  Closing.


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