Bug 822676
| Summary: | [abrt] tcsh-6.17-18.fc17: __GI_raise: Process /usr/bin/tcsh was killed by signal 6 (SIGABRT) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brian Johnson <voyager.106> | ||||||
| Component: | ncurses | Assignee: | Miroslav Lichvar <mlichvar> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 17 | CC: | mlichvar, phil_g | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | abrt_hash:885c5a8dd539942c5f0f2223ae158219e9f6d8cc | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-04-15 12:35:28 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Brian Johnson
2012-05-17 18:21:13 UTC
Created attachment 585296 [details]
File: environ
Created attachment 585297 [details]
File: backtrace
There appears to be a bug in tcsh or ncurses that triggers when you set
$TERM from the shell's initscript (.cshrc or .tcshrc). This particular
problem was generated (and can be reproducrd) by starting tcsh with a
.cshrc containing one line:
setenv TERM vt100
The problem does not occur when using bash, sh, ksh, or zsh. It does not
occur when setting $TERM from the interactive command line. The problem
does not seem to be specific to the new value of $TERM; I have reproduced
it with "vt100", "xterm", "screen", "xterm-256color", and "xterm-color".
It only occurs if the value of $TERM actually changes, so if $TERM is
already set to "vt100", you'll have to use a different value in your
.cshrc, like "xterm".
Here's an strace of tcsh in the time period around the problem:
open("/users/phil/.tcshrc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/users/phil/.cshrc", O_RDONLY) = 0
dup(0) = 1
dup(1) = 2
dup(2) = 3
dup(3) = 4
dup(4) = 5
dup(5) = 6
close(5) = 0
close(4) = 0
close(3) = 0
close(2) = 0
close(1) = 0
close(0) = 0
fcntl(6, F_SETFD, FD_CLOEXEC) = 0
fstat(6, {st_mode=S_IFREG|0600, st_size=18, ...}) = 0
ioctl(6, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffedc14ee0) = -1 ENOTTY (Inappropriate ioctl for device)
read(6, "setenv TERM xterm\n", 4096) = 18
lseek(6, 0, SEEK_CUR) = 18
alarm(0) = 0
close(0) = -1 EBADF (Bad file descriptor)
dup(19) = 0
fcntl(0, F_SETFD, 0) = 0
close(1) = -1 EBADF (Bad file descriptor)
dup(17) = 1
fcntl(1, F_SETFD, 0) = 0
close(2) = -1 EBADF (Bad file descriptor)
dup(18) = 2
fcntl(2, F_SETFD, 0) = 0
rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
access("/etc/terminfo/x/xterm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/terminfo/x/xterm", R_OK) = 0
open("/usr/share/terminfo/x/xterm", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3358, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff3c300c000
read(3, "\32\0010\0&\0\17\0\235\1l\5xterm|xterm terminal"..., 4096) = 3358
read(3, "", 4096) = 0
brk(0) = 0x1af9800
brk(0) = 0x1af9800
brk(0x1afa800) = 0x1afa800
brk(0) = 0x1afa800
brk(0) = 0x1afa800
brk(0x1afb000) = 0x1afb000
close(3) = 0
munmap(0x7ff3c300c000, 4096) = 0
write(1, "free(19eb811) bad block. (memtop"..., 65) = 65
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(6116, 6116, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=6116, si_uid=1639} ---
+++ killed by SIGABRT (core dumped) +++
backtrace_rating: 4
Package: tcsh-6.17-18.fc17
Architecture: x86_64
OS Release: Fedora release 17 (Beefy Miracle)
As a further note, this problem is definitely related to ncurses. If I install the ncurses-libs package from Fedora 16 (version 5.9-2.20110716), tcsh works as expected with "setenv TERM ..." in its .cshrc. The ncurses version in Fedora 17 (5.9-4.20120204) is the only one that shows the problem. I still don't know whether this should be classified as a tcsh or ncurses bug, as I've only seen it so far from tcsh and not from anything else that uses ncurses. Also (and sorry for the extra messages), if I have the Fedora 17 ncurses libraries installed every Fedora-packaged tcsh 6.17 package exhibits the problem, all the way back to Fedora 12's 6.17-5. The tcsh 6.15-9 package in Fedora 11 does not have this problem. Furthermore, I've just discovered that the problem only appears to manifest on 64-bit systems. I cannot reproduce on a Fedora 17 32-bit install I just did. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This bug is probably caused by ncurses. I have tested this issue and it occurs only if cache_expired() is called. It crashes inside ncurses with bad free. It was probably fixed meanwhile, because I cannot reproduce this problem on f18+. The bug can be reproduced on f17 x86_64 (with setenv TERM vt100 in ~/.cshrc), i686 looks ok for me. Thanks for the analysis. It looks identical to bug #854351. *** This bug has been marked as a duplicate of bug 854351 *** |