Bug 854351 - SIGABRT on login with TERM set to vt100
SIGABRT on login with TERM set to vt100
Product: Fedora
Classification: Fedora
Component: ncurses (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
: 822676 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-09-04 13:33 EDT by Jason Tibbitts
Modified: 2013-04-30 23:34 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-30 23:34:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jason Tibbitts 2012-09-04 13:33:14 EDT
If a user has a .login file containing just 
  setenv TERM vt100
attempting to su - to that user results in a message of the form:
  free(144936d) bad block. (memtop = 0x14f7800 membot = 0x1440000)

An strace shows:

19778 rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
19778 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
19778 access("/etc/terminfo/v/vt100", R_OK) = -1 ENOENT (No such file or directory)
19778 access("/usr/share/terminfo/v/vt100", R_OK) = 0
19778 open("/usr/share/terminfo/v/vt100", O_RDONLY) = 4
19778 fstat(4, {st_mode=S_IFREG|0644, st_size=1194, ...}) = 0
19778 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff79e356000
19778 read(4, "\32\1,\0&\0\7\0\16\1\"\2vt100|vt100-am|dec v"..., 4096) = 1194
19778 read(4, "", 4096)                 = 0
19778 brk(0)                            = 0x1f63800
19778 brk(0)                            = 0x1f63800
19778 brk(0x1f64800)                    = 0x1f64800
19778 close(4)                          = 0
19778 munmap(0x7ff79e356000, 4096)      = 0
19778 write(1, "free(1ea836d) bad block. (memtop"..., 65) = 65
19778 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
19778 tgkill(19778, 19778, SIGABRT)     = 0

Maybe this is more of a bug down in ncurses; it's tough for me to tell.  I do know that it is new behavior with F17; F16 does not have this issue.

Comment 1 Pavel Raiskup 2012-09-06 02:59:15 EDT
Thanks for the report.  I'm able to reproduce this bug and I'll look what is the

Comment 2 Pavel Raiskup 2013-03-14 10:30:39 EDT
Hi Jason, sorry for the delay, I totaly forgot about this bug.

The problem seems to be really in curses.  The fail is actually in innocent
looking call tgetent():

  #0  0x0000003505835935 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
  #1  0x00000035058370e8 in __GI_abort () at abort.c:91
  #2  0x0000003505874e8b in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x3505978928 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198
  #3  0x000000350587c00e in malloc_printerr (ptr=0x69c725, str=0x35059767b5 "free(): invalid pointer", action=3) at malloc.c:5027
  #4  _int_free (av=0x3505bb0720, p=0x69c715, have_lock=0) at malloc.c:3948
  #5  0x000000351340ee50 in update_getenv (name=<optimized out>, which=which@entry=dbdHome) at ../../ncurses/tinfo/db_iterator.c:110
  #6  0x000000351340ef38 in cache_expired () at ../../ncurses/tinfo/db_iterator.c:153
  #7  _nc_last_db () at ../../ncurses/tinfo/db_iterator.c:208
  #8  0x0000003513417959 in _nc_read_entry (name=name@entry=0x6946f5 "vt100", filename=filename@entry=0x7fffffffae30 "/usr/share/terminfo/v/vt100", tp=tp@entry=0x6ed870) at ../../ncurses/tinfo/read_entry.c:566
  #9  0x00000035134115e9 in _nc_setup_tinfo (tn=tn@entry=0x6946f5 "vt100", tp=tp@entry=0x6ed870) at ../../ncurses/tinfo/lib_setup.c:424
  #10 0x0000003513411967 in _nc_setupterm (tname=0x6946f5 "vt100", Filedes=Filedes@entry=1, errret=errret@entry=0x7fffffffbe8c, reuse=reuse@entry=1) at ../../ncurses/tinfo/lib_setup.c:659
  #11 0x0000003513411d63 in tgetent (bufp=0x66d280 "", name=<optimized out>) at ../../ncurses/tinfo/lib_termcap.c:94
                  __HERE__  ^^^^^^^  (the name="vt100")
  #12 0x0000000000441fef in GetTermCaps () at ed.screen.c:1436
  #13 0x0000000000442e95 in ed_Init () at ed.init.c:321
  #14 0x0000000000416013 in dosetenv (v=0x6ed488, c=0x6ed430) at sh.func.c:1491
  #15 0x0000000000413885 in func (t=0x6ed430, bp=0x457620) at sh.func.c:145
  #16 0x000000000042771e in execute (t=0x6ed430, wanttty=22944, pipein=0x0, pipeout=0x0, do_glob=1) at sh.sem.c:640
  #17 0x0000000000427b79 in execute (t=0x6ed4e0, wanttty=22944, pipein=0x0, pipeout=0x0, do_glob=1) at sh.sem.c:716
  #18 0x000000000040698f in process (catch=0) at sh.c:2131
  #19 0x00000000004060ef in srcunit (unit=6, onlyown=1, hflg=0, av=0x0) at sh.c:1745
  #20 0x0000000000405847 in srcfile (f=0x688050 "vt100", onlyown=1, flag=0, av=0x0) at sh.c:1537
  #21 0x0000000000405788 in srccat (cp=0x690980 L"/home/tcshtest", dp=0x66b4c0 L"/.login") at sh.c:1511
  #22 0x000000000040540d in main (argc=0, argv=0x7fffffffe2d8) at sh.c:1375

I tried to look at the code curses code but I don't understand it much so
reassigning.  I'm also unable to give there some minimum example.  When I do
the pure 'tgetent' call (apart from tcsh) - it is not reproducible.

Probably ncurses guys will give us more info about this.  How to deubug it and
where could be possibly problem from the 'tcsh' side.

Just a note:  The best way how to reproduce this is to build tcsh with
-DSYSMALLOC.  You get the trace very easy.

This behaviour is not present in F18 anymore.  This indicates that the error is
probably not in tcsh -> because I tried F18's tcsh in F17 against the same
ncurses version and both tcsh version have the same behavior.

Comment 3 Pavel Raiskup 2013-03-14 10:40:06 EDT
FWIW, there may be some time specific constraints for reproducing this bug.
When I set the break point in tgetent() and I go sequentially through all
tgetent steps ..  the crash is not reproducible.
Comment 4 Miroslav Lichvar 2013-03-14 11:14:23 EDT
In a quick test I couldn't reproduce it. If upgrading to F18 ncurses-libs (and nothing else) helps, it's probably an ncurses bug. I think it's strange that only su + tcsh + vt100 triggers it. I'd expect there would be more bug reports  as tgetent() is a widely used call.

CCing upstream maintainer.
Comment 5 Thomas E. Dickey 2013-03-14 17:23:24 EDT
If the update helps, then I suppose it's possible that some related
calls (such as the revision of tputs and putp that I did earlier this
year - after the initial changes in 20120825) might be where the
problem lies.  But I don't recognize the scenario shown here.  While
tgetent itself has been fairly stable, I've done work on its callers
as part of the mingw port.

If it's still reproducible with F18, I can dig into it :-)
Comment 6 Miroslav Lichvar 2013-04-15 08:35:29 EDT
*** Bug 822676 has been marked as a duplicate of this bug. ***
Comment 7 Fedora Update System 2013-04-15 08:46:34 EDT
ncurses-5.9-10.20130413.fc18 has been submitted as an update for Fedora 18.
Comment 8 Fedora Update System 2013-04-15 09:04:03 EDT
ncurses-5.9-10.20130413.fc17 has been submitted as an update for Fedora 17.
Comment 9 Miroslav Lichvar 2013-04-15 09:05:44 EDT
The f18 update shouldn't mention this bug, please ignore it (or test it doesn't bring the bug back).
Comment 10 Fedora Update System 2013-04-15 19:52:33 EDT
Package ncurses-5.9-10.20130413.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ncurses-5.9-10.20130413.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 11 Pavel Raiskup 2013-04-16 14:43:15 EDT
This update fixed the problem for me.  Thanks!
Comment 12 Fedora Update System 2013-04-30 23:34:12 EDT
ncurses-5.9-10.20130413.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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