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 161332 - bash crashes with glibc detected *** free(): invalid next size
Summary: bash crashes with glibc detected *** free(): invalid next size
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-22 14:43 UTC by Walter Francis
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-04-27 22:05:02 UTC

Attachments (Terms of Use)
Strace of executing bash. (deleted)
2005-06-22 14:45 UTC, Walter Francis
no flags Details

Description Walter Francis 2005-06-22 14:43:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
bash is crashing with the following error when trying to execute it:

*** glibc detected *** free(): invalid next size (normal): 0x080ec5b8 ***

My default shell is tcsh.  If I want to adjust ulimits, or view my ulimits, I'll execute bash and do ulimit -a or what not, this is when I am seeing the problem.

I have figured out that my .bash_history file, when moved out of the way, eliminates this problem.  Editing the file also seems to fix the problem.  At this time I'm going to attach a strace, but not the history file.  If the history file is necessary, I'll attach it.

Creating a new user and copying my .login, .bashrc, .bash_history, etc, to that new user, and performing the same routine does not seem to cause this problem, so I'm not sure how to provide more information on how to recreate it.  

One thing to note:  LONG LONG ago on this machine I was messing with a fork bomb to see how the machine handled it, and adjusted some limit settings to fix the problem, so the first few lines that show up as the .bash_history is read are these lines.  Removing them 'fixes' the problem, but so does leaving them and editing other lines in the history, so I don't think it's related, but wanted to mention it since they stand out in the strace.

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

How reproducible:

Steps to Reproduce:
1. Login to system under default shell of tcsh
2. Execute bash

Actual Results:  wally@psi 10:30 ~> bash
*** glibc detected *** free(): invalid next size (normal): 0x080ec5b8 ***
wally@psi 10:42 ~>

Expected Results:  Bash executes without failure.

Additional info:

Comment 1 Walter Francis 2005-06-22 14:45:35 UTC
Created attachment 115812 [details]
Strace of executing bash.

Attachment of the strace -s 256 -o bash.strace bash, when executed under the
described conditions.

Comment 2 Walter Francis 2005-06-22 14:47:03 UTC
This bug is similar to

Comment 3 Tim Waugh 2005-06-22 15:18:25 UTC
This bug is certainly not related to bug #150764.

The strace is not really very useful.  A stack trace from gdb would be a bit
more useful, and most useful of all would be a .bash_history I can use to see
the problem myself.

Comment 4 Walter Francis 2005-06-23 02:16:03 UTC
The problem does not recreate when adding the appropriate files to a new user,
I'm not sure why, but I tried it in order to try to create a reproducable
scenario to see.  I added my .tcshrc, .login, .bashrc, .bash_history, and
.aliases files to the new user, set their shell to tcsh (same as the user with
the glibc problem), and logged in, ran bash, no crash.

I tried a gdb stack but there was no error when doing so, it simply ran without

And other bizarre thing I just noticed, the failure occurs from one shell, but
not another.  I shell in from my server (running screen all the time) into the
workstation (the problematic box) and this happens.  I shell into it from my
laptop, and it doesn't.  Why this is the case?  Must be environment, that's all
I can think of.  However both shells are using the same .tcshrc and .aliases, so
they should be pretty close to the same.

I didn't think the bug was a duplicate of #150764, just similar as stated.

I know that it's difficult or impossible to diagnose the problem without a
reproducable scenario, but since it is happening here 100% I decided to file the
bug.  If there's anything I can provide that will help, I can do it, but I don't
think my .bash_history will help, it doesn't fail inside of gdb, etc.

Comment 5 Tim Waugh 2005-06-23 08:18:20 UTC
Do you get a core dump if you 'ulimit -c unlimited'?

Comment 6 Walter Francis 2005-09-08 15:34:36 UTC
Not sure how to execute ulimit if I can't enter bash at all.  As soon as I
execute bash, it segfaults.  

Again, without my history file it's fine..  So it's something in there, but even
selectively deleting stuff in it I never quite figured out if it's some specific

Comment 7 Tim Waugh 2005-09-08 15:50:08 UTC
Well, how about if you edit /etc/profile so that this line:

ulimit -S -c 0 > /dev/null 2>&1


ulimit -S -c unlimited > /dev/null 2>&1


Comment 8 John Thacker 2006-04-27 22:05:02 UTC
No response from reporter, closing.

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