Bug 161332 - bash crashes with glibc detected *** free(): invalid next size
bash crashes with glibc detected *** free(): invalid next size
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-22 10:43 EDT by Walter Francis
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-27 18:05:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Strace of executing bash. (45.34 KB, text/plain)
2005-06-22 10:45 EDT, Walter Francis
no flags Details

  None (edit)
Description Walter Francis 2005-06-22 10:43:12 EDT
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 ***
Abort

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):
bash-3.0-18

How reproducible:
Always

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 ***
Abort
wally@psi 10:42 ~>


Expected Results:  Bash executes without failure.

Additional info:
Comment 1 Walter Francis 2005-06-22 10:45:35 EDT
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 10:47:03 EDT
This bug is similar to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150764
Comment 3 Tim Waugh 2005-06-22 11:18:25 EDT
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-22 22:16:03 EDT
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
failure.

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 04:18:20 EDT
Do you get a core dump if you 'ulimit -c unlimited'?
Comment 6 Walter Francis 2005-09-08 11:34:36 EDT
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
line.
Comment 7 Tim Waugh 2005-09-08 11:50:08 EDT
Well, how about if you edit /etc/profile so that this line:

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

reads:

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

?
Comment 8 John Thacker 2006-04-27 18:05:02 EDT
No response from reporter, closing.

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