[Aptitude-devel] Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console

[Manuel A. Fernandez Montecelo]

Hi Axel,

2016-04-03 00:29 Axel Beckert:
>Package: aptitude
>Version: 0.7.8-1
>
>Hi,
>
>aptitude segfaults under the following circumstances:
>
>1. Log in as root on a Linux virtual console, i.e. after pressing
>   Ctrl-Alt-F1.
>
>2. Start aptitude in TUI mode, i.e. without any options or parameters.
>
>3. Press Ctrl-Z to suspend aptitude.
>
>4. Enter "fg" on the commandline and press Enter to bring aptitude back
>   to the foreground.
>
>5. Segfault.
>
>This does not happen, if
>
>* if tried inside an xterm
>* if just TERM is set to "linux", but the terminal is no virtual linux
>  console, i.e. "env TERM=linux aptitude" does not exhibit the issue.

What's "TERM" in the vt console?

Mine is "linux", and as you noted, it works fine.  If I "unset TERM" or
set it to the empty string, aptitude refuses to start ("Error opening
terminal: unknown").  If I set it to "linux", "xterm" or
"xterm-256color" it works fine.  "vt100" works fine, but no colours.

In any case, I couldn't get it to crash by suspending and restoring.

I am no expert in TERM, so I'm not sure which other values are possible
and which ones are correct.


>Unfortunately I was not able to reproduce the issue under gdb
>directly. But this is the backtrace I got out of the core dump:
>
>Reading symbols from /usr/bin/aptitude-curses...Reading symbols from /usr/lib/debug/.build-id/17/b0aa382e98a7c74b766fe389e4e2c494dd8cce.debug...done.
>done.
>
>warning: core file may not match specified executable file.
>[New LWP 6201]
>[New LWP 6202]
>[New LWP 6203]
>[New LWP 6204]
>[New LWP 6219]
>[Thread debugging using libthread_db enabled]
>Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>Core was generated by `aptitude'.
>Program terminated with signal SIGSEGV, Segmentation fault.
>#0  0x00007fe2861e5973 in ?? ()
>[Current thread is 1 (Thread 0x7fe28a8d1780 (LWP 6201))]
>(gdb) bt
>#0  0x00007fe2861e5973 in ?? ()
>#1  0x0000ffffffff0000 in ?? ()
>#2  0x0000000100001839 in ?? ()
>#3  0x0000000008000000 in ?? ()
>#4  0x00007fe287fa8b0c in ___vsprintf_chk (s=0x7ffd08eb4380 "", flags=-1416311776, slen=140724753089664, format=0x564aab94cc10 "\260R\266\252JV",
>    args=0x564aa764dc78, args at entry=0x7ffd08eb44c8) at vsprintf_chk.c:85
>#5  0x00007fe287fa8a5d in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:31
>#6  0x0000564aa764dc78 in ?? ()
>#7  0x0000564aab94cc20 in ?? ()
>#8  0x00007fe289d335d4 in ?? () from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
>#9  0x0000000000000080 in ?? ()
>#10 0x00007ffd08eb4b20 in ?? ()
>#11 0x0000564aab94cc10 in ?? ()
>#12 0x000000000000000d in ?? ()
>#13 0xfffffffffffffffc in ?? ()
>#14 0x00007fe288af204f in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
>#15 0x0000000000000000 in ?? ()
>(gdb)

None of the functions which name appears are from aptitude, cwidget or
apt, unfortunately.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>