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

[Manuel A. Fernandez Montecelo]

Hi,

2016-04-05 14:41 GMT+01:00 Axel Beckert <abe at debian.org>:
> Hi Manuel,
>
> Manuel A. Fernandez Montecelo wrote:
>> I was trying to say that the functions whose name appear
>> (vsnprintf_chk and the other _chk) are not part of
>> aptitude/apt/cwidget, and other of the functions in the backtrace
>> don't show names, so if you have of you have dbgsym of aptitude
>> installed (as the message of "loading symbols" indicate), it's not
>> part of aptitude.
>>
>> If you install libcwidget*-dbg, libapt*-dbg and any other -dbg of the
>> "aptitude software stack" (sigc++, boost, libc6...) maybe something
>> appears in that backtrace.
>
> aptitude-dbgsym and libc6-dbgsym was already installed. I've installed
> libcwidget*-dbg, libapt*-dbg, libsigc++-*-dbgsym and libboost-dbg
> today.
>
> But now I can't reproduce the segfault anymore, at least on amd64. And
> the backtrace from the existing segfaults hasn't changed much -- if at
> all -- since then:
>
> (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 cwidget::toplevel::eventq () 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)
>
> Will try the same at home on the Raspberry Pi's console again, too.

Seeing that cwidget's events are involved, with the hairiness of
cwidget's own threads implementation and sigc++ mixed, and seeing that
libsigc++-2.0 was updated recently, I am wondering if it has something
to do with that.

I have the same versions, though, so I should be able to reproduce it
if it's happening often -- altough this kind of weirdness is typical
of issues involving threads.

I very rarely use Linux virtual consoles and aptitude.  I don't know
if you use them enough to be able to tell if it's a behaviour that
only started recently while not happening for years, or simply you
don't use it often enough to see if it was only present since
recently?


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