Daniel Burrows wrote:
Well, that eliminates the processor variable. I don't think it's the
testing libc6-i686 either -- I've tried this on some testing machines
and they work just fine, and nothing in the changelog suggests that it
would impact this bug.
Yeah, you're right. I installed glibc 2.5-11 from unstable and the same
thing happened as well. So the glibc version seems irrelevant. And some
people I know don't suffer from this either, even if they have
libc6-i686 installed.
It looks to me like the problem is that the input thread isn't being
restarted. Either that, or that curses isn't reinitializing the terminal
for some reason, but the code to bring curses back up is 'obviously
right' and hasn't changed recently, whereas the input thread was
rewritten recently.
Daniel
I've rebuilt aptitude without being stripped and got 2 backtraces when
'g' is finished, one is the "bad" one with lib6-i686 and the other is
the "good" one without it. I've attached them below. The first 2 threads
are basically identical despite the corrupted stack, whilst the last 2
in the "bad" seems indicating something was wrong after calling
"pthread_mutex_lock()", which looks like a race condition or something.
I guess that could be a lead of why the inputs from the keyboard were
kept in buffer until aptitude is SIGINT-ed and then put through, and an
evidence of the input-thread-issue you've mentioned. Hope these could help.
(gdb) info threads
4 Thread -1231754352 (LWP 12871) 0xb7c1e897 in select () from /lib/libc.so.6
3 Thread -1223365744 (LWP 12872) 0xb7dc1d09 in do_sigwait ()
from /lib/libpthread.so.0
2 Thread -1255924848 (LWP 12874) 0xb7dbe351 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
1 Thread -1212877104 (LWP 12806) 0xb7dbe351 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) thread 1
[Switching to thread 1 (Thread -1212877104 (LWP 12806))]#0 0xb7dbe351 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1 0x08199ff7 in vscreen_mainloop (synch=0)
at ../../src/generic/util/threads.h:454
#2 0x0810c128 in ui_main () at ui.cc:2630
#3 0x08053ca9 in main (argc=Cannot access memory at address 0x0
) at main.cc:581
(gdb) thread 2
[Switching to thread 2 (Thread -1255924848 (LWP 12874))]#0 0xb7dbe351 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0 0xb7dbe351 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1 0x08235329 in resolver_manager::background_thread_execution (
this=0x85ab328) at ../../../src/generic/util/threads.h:454
#2 0x082568dc in
threads::thread::bootstrap<resolver_manager::background_thread_bootstrap>
(p=0x84523f8) at resolver_manager.cc:232
#3 0xb7dba183 in start_thread () from /lib/libpthread.so.0
#4 0xb7c25a7e in clone () from /lib/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread -1223365744 (LWP 12872))]#0 0xb7dc1d09 in
do_sigwait () from /lib/libpthread.so.0
(gdb) bt
#0 0xb7dc1d09 in do_sigwait () from /lib/libpthread.so.0
#1 0xb7dc1daf in sigwait () from /lib/libpthread.so.0
#2 0x0819bc83 in threads::thread::bootstrap<signal_thread> (p=0x843f4f8)
at vscreen.cc:456
#3 0xb7dba183 in start_thread () from /lib/libpthread.so.0
#4 0xb7c25a7e in clone () from /lib/libc.so.6
(gdb) thread 4
[Switching to thread 4 (Thread -1231754352 (LWP 12871))]#0 0xb7c1e897 in
select () from /lib/libc.so.6
(gdb) bt
#0 0xb7c1e897 in select () from /lib/libc.so.6
#1 0x0819bd4d in
threads::thread::bootstrap<threads::bootstrap_proxy<input_thread> >
(p=0x841efa8) at vscreen.cc:370
#2 0xb7dba183 in start_thread () from /lib/libpthread.so.0
#3 0xb7c25a7e in clone () from /lib/libc.so.6
(gdb) info threads
4 Thread -1231680624 (LWP 13071) 0xb7f0a410 in ?? ()
3 Thread -1223287920 (LWP 13072) 0xb7f0a410 in ?? ()
2 Thread -1255822448 (LWP 13074) 0xb7f0a410 in ?? ()
1 Thread -1212795184 (LWP 12982) 0xb7f0a410 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread -1212795184 (LWP 12982))]#0 0xb7f0a410 in ?? ()
(gdb) bt
#0 0xb7f0a410 in ?? ()
#1 0xbfc7e1a8 in ?? ()
#2 0x0000011d in ?? ()
#3 0x0810c128 in ui_main () at ui.cc:2630
#4 0x08053ca9 in main (argc=Cannot access memory at address 0x0
) at main.cc:581
(gdb) thread 2
[Switching to thread 2 (Thread -1255822448 (LWP 13074))]#0 0xb7f0a410 in ?? ()
(gdb) bt
#0 0xb7f0a410 in ?? ()
#1 0xb525a3a8 in ?? ()
#2 0x00000001 in ?? ()
#3 0xb7dd25d6 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/i686/cmov/libpthread.so.0
#4 0x08235329 in resolver_manager::background_thread_execution (
this=0x83cce48) at ../../../src/generic/util/threads.h:454
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread 3
[Switching to thread 3 (Thread -1223287920 (LWP 13072))]#0 0xb7f0a410 in ?? ()
(gdb) bt
#0 0xb7f0a410 in ?? ()
#1 0xb71612f4 in ?? ()
#2 0x00000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread -1231680624 (LWP 13071))]#0 0xb7f0a410 in ?? ()
(gdb) bt
#0 0xb7f0a410 in ?? ()
#1 0xb69602f8 in ?? ()
#2 0x00000002 in ?? ()
#3 0xb7dd4dbe in __lll_mutex_lock_wait () from /lib/i686/cmov/libpthread.so.0
#4 0xb7dd0abc in _L_mutex_lock_88 () from /lib/i686/cmov/libpthread.so.0
#5 0xb7dd04ad in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
