bash crashed with SIGABRT in programming_error()

Bug #1294669 reported by Colin Ian King on 2014-03-19
82
This bug affects 13 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
High
Matthias Klose
Trusty
High
Matthias Klose

Bug Description

[Test Case]
bdmurray@blacklightning:~$ x!
x!: command not found
bdmurray@blacklightning:~$ x!

malloc: .././parse.y:2314: assertion botched
realloc: start and end chunk sizes differ
last command: x!
Aborting...Aborted (core dumped)

[Regression Potential]
Low, this patch has been applied upstream.

bash just died under me, I think I was just doing cursor up to get a previous command and it segfaulted. This has happened several times this week and is getting annoying

ProblemType: CrashDistroRelease: Ubuntu 14.04
Package: bash 4.3-2ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-16.36-lowlatency 3.13.5
Uname: Linux 3.13.0-16-lowlatency x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CrashCounter: 1
CurrentDesktop: Unity
Date: Wed Mar 19 14:08:22 2014
EcryptfsInUse: Yes
ExecutablePath: /bin/bash
InstallationDate: Installed on 2013-12-09 (99 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20131209)
ProcCmdline: bash
Signal: 6SourcePackage: bash
StacktraceTop:
 programming_error ()
 ?? ()
 sh_xrealloc ()
 ?? ()
 ?? ()
Title: bash crashed with SIGABRT in programming_error()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sbuild sudo

Colin Ian King (colin-king) wrote :

StacktraceTop:
 programming_error (format=<optimized out>) at .././error.c:176
 xbotch (s=<optimized out>, file=file@entry=0x4b5520 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314, e=8, mem=0x12bddd8) at ../../.././lib/malloc/malloc.c:319
 internal_realloc (mem=mem@entry=0x12bddd8, n=n@entry=257, file=file@entry=0x4b5520 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314, flags=1) at ../../.././lib/malloc/malloc.c:1026
 sh_realloc (ptr=ptr@entry=0x12bddd8, size=size@entry=257, file=file@entry=0x4b5520 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314) at ../../.././lib/malloc/malloc.c:1197
 sh_xrealloc (pointer=0x12bddd8, bytes=257, file=file@entry=0x4b5520 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314) at .././xmalloc.c:206

Changed in bash (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bash (Ubuntu):
status: New → Confirmed
Steve Langasek (vorlon) on 2014-03-19
Changed in bash (Ubuntu):
status: Confirmed → Triaged
Steve Langasek (vorlon) on 2014-03-19
Changed in bash (Ubuntu):
importance: Medium → Critical
assignee: nobody → Matthias Klose (doko)
Matthias Klose (doko) wrote :

is this reproducible with the recent update? if yes, please could you (privately) send me your .bash_history file?

Colin Ian King (colin-king) wrote :

Since reporting this bug I have pulled in updates and I try as I may, I cannot reproduce this bug now. Not that I'm saying it's fixed, but it does seem to not bite me now. And when I first reported it the bug had occurred several times that day. Not sure we should do now.

Matthias Klose (doko) wrote :

lowering importance to high, and making the bug report public. would be good to know if somebody else can reproduce this.

information type: Private → Public
Changed in bash (Ubuntu):
importance: Critical → High
Colin Ian King (colin-king) wrote :

I did a clean install of Trusty yesterday and I will keep track to see if this issue occurs again. It seemed to happen only when I had been very busy in bash and had done a bunch of cursor-up repeated commands and somehow it just died under me.

Brian Murray (brian-murray) wrote :

I was able to recreate this crash by performing the following:

bdmurray@blacklightning:~$ x!
x!: command not found
bdmurray@blacklightning:~$ x!

malloc: .././parse.y:2314: assertion botched
realloc: start and end chunk sizes differ
last command: x!
Aborting...Aborted (core dumped)

Brian Murray (brian-murray) wrote :

For further details see the duplicates of this bug.

Colin Ian King (colin-king) wrote :

Yes, that's a reproducer for me too.

Colin Ian King (colin-king) wrote :

so it appears the ! token is the culprit at a guess:

ps = {parser_state = 524288, token_state = 0x1629768, token = 0x11f4008 "!", token_buffer_size = 1520, input_line_terminator = 0, eof_encountered = 0, prompt_string_pointer = 0x6fc920 <ps1_prompt>, current_command_line_count = 0, remember_on_history = 1, history_expansion_inhibited = 0, last_command_exit_value = 1, pipestatus = 0x11fd588, last_shell_builtin = 0x0, this_shell_builtin = 0x0, expand_aliases = 1, echo_input_at_read = 0}
#14 0x0000000000420e43 in parse_command () at .././eval.c:231

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bash - 4.3-4ubuntu2

---------------
bash (4.3-4ubuntu2) trusty; urgency=medium

  * Fix a display issue when a multiline command is aborted with ^C.
  * Fix a crash after a failed history expansion. LP: #1294669.
 -- Matthias Klose <email address hidden> Fri, 28 Mar 2014 19:56:55 +0100

Changed in bash (Ubuntu):
status: Triaged → Fix Released
Brian Murray (brian-murray) wrote :

The test case still causes a crash with bash version 4.3-6ubuntu1.

Changed in bash (Ubuntu):
status: Fix Released → Triaged
Changed in bash (Ubuntu):
milestone: none → trusty-updates
KDEUSER56 (kdeuser56) wrote :
Download full text (33.4 KiB)

/bin/bash crashes everytime calling "q!" followed by "sudo su"

Bash crashed during the following sequence:

user@LINUXPC:~$ q!
q!: command not found
user@LINUXPC:~$ sudo su

malloc: /usr/homes/chet/src/bash/src/parse.y:2314: assertion botched
realloc: start and end chunk sizes differ
last command: q!
Aborting...

Warning: Program '/bin/bash' crashed.

Backtrace:

--- stack trace ---
#0 0x00007f7a3ec39f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
        resultvar = 0
        pid = 11591
        selftid = 11591
#1 0x00007f7a3ec3d4c8 in __GI_abort () at abort.c:118
        act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {18446744073709551615 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0x0}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x000000000044052f in programming_error (format=<optimized out>) at .././error.c:176
        args = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fff422267b0, reg_save_area = 0x7fff422266f0}}
        h = <optimized out>
#3 0x00000000004b3fbc in xbotch (s=<optimized out>, file=file@entry=0x4b5760 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314, e=8, mem=0x102ce08) at ../../.././lib/malloc/malloc.c:319
No locals.
#4 0x00000000004b4bb0 in internal_realloc (mem=mem@entry=0x102ce08, n=n@entry=258, file=file@entry=0x4b5760 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314, flags=1) at ../../.././lib/malloc/malloc.c:1026
        p = 0x102ce00
        tocopy = 3
        nbytes = <optimized out>
        nunits = 1
        m = 0x102ce0f ""
        z = <synthetic pointer>
        mg = <optimized out>
#5 0x00000000004b4d95 in sh_realloc (ptr=ptr@entry=0x102ce08, size=size@entry=258, file=file@entry=0x4b5760 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314) at ../../.././lib/malloc/malloc.c:1197
No locals.
#6 0x0000000000472ba6 in sh_xrealloc (pointer=0x102ce08, bytes=258, file=file@entry=0x4b5760 "/usr/homes/chet/src/bash/src/parse.y", line=line@entry=2314) at .././xmalloc.c:206
        temp = <optimized out>
#7 0x0000000000423879 in shell_getc (remove_quoted_newline=1) at /usr/homes/chet/src/bash/src/parse.y:2314
        i = <optimized out>
        uc = <optimized out>
        truncating = 0
        remove_quoted_newline = 1
        c = <optimized out>
#8 0x0000000000426612 in read_token (command=0) at /usr/homes/chet/src/bash/src/parse.y:3013
        character = <optimized out>
        peek_char = <optimized out>
        result = <optimized out>
#9 0x0000000000429bf4 in yylex () at /usr/homes/chet/src/bash/src/parse.y:2622
No locals.
#10 yyparse () at y.tab.c:2015
        yystate = <optimized out>
        yyn = 296
        yyresult = <optimized out>
        yyerrstatus = 0
        yytoken = <optimized out>
        yyssa = {0, 51, 123, 0, 17836, 75, 0, 0, 27532, 16930, 32767, 0, 27216, 16930, 32767, 0, -15750, 215, 0, 0, 17836, 75, 0, 0, -14760, 215, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 17836, 75, 0, 0, 8304, 216, 0, 0, 27272, 16930, 32767, 0, 27072, 16930, 32767, 0, 27056, 16930, 32767, 0, 0, 0, 0, 0, 27304, 16930, 32767, 0, 27104, 16930, 32767, 0, 27088, 16930, 32767, 0, 0, 0, 0, 0, 2...

KDEUSER56 (kdeuser56) wrote :

Ah sorry for the long paste ... Backtrace is in the attached file.

Matthias Klose (doko) on 2014-04-16
Changed in bash (Ubuntu):
status: Triaged → In Progress
siggy1 (siggy1) on 2014-04-21
tags: added: bash i386
siggy1 (siggy1) wrote :

This bug can be reproduced in both amd64 and ia386 Ubuntu 14.04 release versions.
1. Boot to Live Ubuntu
2. Open a Terminal
3. Enter the following commands:
    $ bash
    $ ls
    $ !
    $ <ENTER >

Result is a crashed bash as described above:

malloc: /usr/homes/chet/src/bash/src/parse.y:2314: assertion botched
realloc: start and end chunk sizes differ
last command: !
Aborting...Aborted (core dumped)

tags: added: assertion botched malloc
siggy1 (siggy1) wrote :

Core dump generated by bash after a fresh 32bit Desktop installation of Ubuntu 14.04 LTS with empty home directory.
Bash ! also crashes shells on both Ubuntu Live Installer CDs 32+64 bit

siggy $ gdb /bin/bash core
GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7
...
Reading symbols from /bin/bash...(no debugging symbols found)...done.
[New LWP 19996]
Core was generated by `bash'.
Program terminated with signal SIGABRT, Aborted.
#0 0xb7706424 in __kernel_vsyscall ()
(gdb) backtrace
#0 0xb7706424 in __kernel_vsyscall ()
#1 0xb7545827 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2 0xb7548d24 in __GI_abort () at abort.c:118
#3 0x08084733 in programming_error ()
#4 0x080fb4ed in ?? ()
#5 0x080fc083 in ?? ()
#6 0x080b9358 in sh_xrealloc ()
#7 0x0806660b in ?? ()
#8 0x08069472 in ?? ()
#9 0x0806c836 in yyparse ()
#10 0x08063b9e in parse_command ()
#11 0x08063c72 in read_command ()
#12 0x08063e5b in reader_loop ()
#13 0x0806218f in main ()
(gdb)

siggy1 (siggy1) wrote :

Bug still exists in bash version 4.3.8(1)-release

siggy $ bash --version
GNU bash, version 4.3.8(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

siggy $ uname -a
Linux netbook 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:08:14 UTC 2014 i686 i686 i686 GNU/Linux

siggy1 (siggy1) wrote :

This bug can also be produced with compiled original version 4.3 retrieved from:
http://archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.3.orig.tar.gz

bash-4.3$ ./bash
bash-4.3$ echo $BASH_VERSION
4.3.0(1)-release

bash-4.3$ ls
bash-4.3$ !
bash-4.3$

malloc: /usr/homes/chet/src/bash/src/parse.y:2314: assertion botched
realloc: start and end chunk sizes differ
last command: !
Aborting...Aborted (core dumped)

Brian Murray (brian-murray) wrote :

There appears to already be an upload fixing this in the unapproved queue for Trusty proposed. The bug report is just missing SRU information - test case, etc.....

Bernie Innocenti (codewiz) wrote :

The crash takes some time to reproduce on my laptop, so I attached gdb to an interactive bash process and got this stacktrace when it finally crashed:

Program received signal SIGABRT, Aborted.
0x00007ffff761df79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff761df79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff7621388 in __GI_abort () at abort.c:89
#2 0x000000000044052f in programming_error ()
#3 0x00000000004b403f in ?? ()
#4 0x00000000004ae5ac in _rl_revert_all_lines ()
#5 0x0000000000494df5 in readline_internal_teardown ()
#6 0x0000000000495d26 in readline ()
#7 0x00000000004215aa in ?? ()
#8 0x0000000000423736 in ?? ()
#9 0x0000000000426612 in ?? ()
#10 0x0000000000429bf4 in yyparse ()
#11 0x0000000000420ebb in parse_command ()
#12 0x0000000000420f8c in read_command ()
#13 0x0000000000421189 in reader_loop ()
#14 0x000000000041f729 in main ()

I installed readline-gdb and will follow up when I see another crash.

Am 22.04.2014 00:54, schrieb Brian Murray:
> There appears to already be an upload fixing this in the unapproved
> queue for Trusty proposed. The bug report is just missing SRU
> information - test case, etc.....

the test case always was in the bug report. the bug number #1294669 is mentioned
in the upload.

Hello Colin, or anyone else affected,

Accepted bash into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/bash/4.3-7ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

description: updated
Changed in bash (Ubuntu):
milestone: trusty-updates → none
Changed in bash (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Colin Ian King (colin-king) wrote :

Tested with bash 4.3-7ubuntu1, and I can't reproduce the issue now, hence fixed for me. Thanks!

tags: added: verification-done
removed: verification-needed
scytlae (scytale-gmail) wrote :

bash from trusty-proposed fixed the issue for me too

siggy1 (siggy1) wrote :

The trusty-proposed patch works for me, too.

Testcase:
1. Fresh install of 32bit Ubuntu 14.04

Before the patch:
$ bash
$ echo $BASH_VERSION
4.3.8(1)-release

$ ls
$ !
$ <ENTER>

malloc: /usr/homes/chet/src/bash/src/parse.y:2314: assertion botched
realloc: start and end chunk sizes differ
last command: !
Aborting...Aborted (core dumped)

To install the fix:
1. Enable trusty-proposed
2. apt-get install bash

After the patch installation: Start a new bash process:
$ bash
$ echo $BASH_VERSION
4.3.11(1)-release

$ ls
$ !
$ <ENTER>
$ <ENTER>
$ <ENTER>

Stable - no more crash :-)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bash - 4.3-7ubuntu1

---------------
bash (4.3-7ubuntu1) trusty-proposed; urgency=medium

  * Merge with Debian, replacing local with upstream patches. LP: #1294669.

bash (4.3-7) unstable; urgency=medium

  * Apply upstream patches 009 - 011 (replacing local patches):
    - Fix a problem with unsigned sign extension when attempting to reallocate
      the input line when it is fewer than 3 characters long and there has been
      a history expansion. The sign extension causes the shell to not
      reallocate the line, which results in a segmentation fault when it writes
      past the end.
    - Change the behavior of programmable completion to compensate for two
      assumptions made by the bash-completion package.
    - The signal handling changes to bash and readline (to avoid running any
      code in a signal handler context) cause the cursor to be placed on the
      wrong line of a multi-line command after a ^C interrupts editing.
 -- Matthias Klose <email address hidden> Wed, 16 Apr 2014 23:22:21 +0200

Changed in bash (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for bash has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bash - 4.3-7ubuntu1

---------------
bash (4.3-7ubuntu1) trusty-proposed; urgency=medium

  * Merge with Debian, replacing local with upstream patches. LP: #1294669.

bash (4.3-7) unstable; urgency=medium

  * Apply upstream patches 009 - 011 (replacing local patches):
    - Fix a problem with unsigned sign extension when attempting to reallocate
      the input line when it is fewer than 3 characters long and there has been
      a history expansion. The sign extension causes the shell to not
      reallocate the line, which results in a segmentation fault when it writes
      past the end.
    - Change the behavior of programmable completion to compensate for two
      assumptions made by the bash-completion package.
    - The signal handling changes to bash and readline (to avoid running any
      code in a signal handler context) cause the cursor to be placed on the
      wrong line of a multi-line command after a ^C interrupts editing.
 -- Matthias Klose <email address hidden> Wed, 16 Apr 2014 23:22:21 +0200

Changed in bash (Ubuntu):
status: In Progress → Fix Released
Bernie Innocenti (codewiz) wrote :

I'm still seeing this exact same crash with bash_4.3-7ubuntu1. In fact, I also see it with a bash binary built from the upstream git (bash 4.3 patch 18).

This is the stack trace I'm getting:

codewiz@xyzzy:~$

malloc: unknown:0: assertion botched
free: called with unallocated block argument
last command: ll webserver/sffe/config/sffe_config.proto
Aborting...
Program received signal SIGABRT, Aborted.
0x00007ffff761df79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff761df79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff7621388 in __GI_abort () at abort.c:89
#2 0x000000000044051f in programming_error ()
#3 0x00000000004b3bff in internal_free.isra ()
#4 0x00000000004ae1ac in _rl_revert_all_lines ()
#5 0x0000000000495035 in readline_internal_teardown ()
#6 0x0000000000495f56 in readline ()
#7 0x000000000042158a in yy_readline_get ()
#8 0x0000000000423716 in shell_getc ()
#9 0x00000000004265f2 in read_token.constprop ()
#10 0x0000000000429bd4 in yyparse ()
#11 0x0000000000420e9b in parse_command ()
#12 0x0000000000420f6c in read_command ()
#13 0x0000000000421169 in reader_loop ()
#14 0x000000000041f749 in main ()
(gdb)

Bernie Innocenti (codewiz) wrote :

Confirming that the bash binary from the trace *does* include patches 9 through 11.
Now trying to get a better trace from a binary compiled with -g

Please reopen this bug.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers