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:
Created attachment 115812 [details] Strace of executing bash. Attachment of the strace -s 256 -o bash.strace bash, when executed under the described conditions.
This bug is similar to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150764
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.
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.
Do you get a core dump if you 'ulimit -c unlimited'?
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.
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 ?
No response from reporter, closing.