[Aptitude-devel] Bug#838560: aptitude: "aptitude -u" hangs indefinitely at "Loading cache" if an APT repo results in a 404 (maybe APT 1.3 related)
Axel Beckert
abe at debian.org
Thu Sep 22 10:56:56 UTC 2016
Package: aptitude
Version: 0.8.3-1
Severity: normal
As every day, I ran "aptitude -u". But for one or two days (not sure if
before or after the APT 1.3 final upload), all Opera APT repos gave a
404. (They no more do, so I can't reproduce it anymore with these repos,
but will later try to get a working and persistent example with a dummy
repo.)
The interesting effect was that if and only if I started "aptitude -u",
it hung at "Loading cache" (no more percentage numbers shown, CPU
idle). I had one aptitude instance "running" in that state for over 12
hours.
strace looked like this with stanzas coming in ca. half-second
intervals:
# strace -p 758
strace: Process 758 attached
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169063, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541081, 517219}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336914) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169065, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541082, 17926}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336918) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169067, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541082, 518295}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336922) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169069, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541083, 19306}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336926) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169071, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541083, 519664}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336930) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169073, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541084, 20029}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336934) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169075, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541084, 520395}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336938) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169077, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541085, 20771}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336942) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169079, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541085, 521132}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336946) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169081, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541086, 21843}, NULL) = 0
futex(0x7f4351978264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f4351978238, 336950) = 1
futex(0x7f4351978238, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f43519785d4, FUTEX_WAIT_PRIVATE, 169083, NULL) = 0
futex(0x7f4351978600, FUTEX_WAKE_PRIVATE, 1) = 0
gettimeofday({1474541086, 522212}, NULL) = 0
[...]
What still worked more or less:
* Pressing "q": It prompted me (inside the mini buffer) with y[n], but
pressing "n" did not make the prompt (nor the line it's on) to go away
and the instance then was completely locked. Only Ctrl-C helped then.
* Pressing "q" and then "y" IIRC worked, but not immediately.
* Pressing Ctrl-C and then starting "aptitude" without "-u" worked as
usual (even with new packages and updates) and is what I consider a
workaround.
* Removing or commenting out the broken repositories worked as well and
"aptitude -u" worked as before.
I killed that instance with kill -SEGV to get a core dump. Here's the
backtrace (after pressing "qn" and getting the non-vanishing prompt in
the minibuffer):
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `aptitude -u'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
183 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
[Current thread is 1 (Thread 0x7f4352560780 (LWP 758))]
(gdb) bt
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
#1 0x00007f43516ca663 in cwidget::threads::condition::wait<cwidget::threads::mutex::lock> (l=<synthetic pointer>,
this=0x7f43519785d0 <cwidget::toplevel::eventq+80>) at ../../src/cwidget/generic/threads/threads.h:508
#2 cwidget::threads::condition::wait<cwidget::threads::mutex::lock, cwidget::threads::event_queue<cwidget::toplevel::event*>::not_empty> (p=...,
l=<synthetic pointer>, this=0x7f43519785d0 <cwidget::toplevel::eventq+80>) at ../../src/cwidget/generic/threads/threads.h:527
#3 cwidget::threads::event_queue<cwidget::toplevel::event*>::get (this=0x7f4351978580 <cwidget::toplevel::eventq>)
at ../../src/cwidget/generic/threads/event_queue.h:94
#4 cwidget::toplevel::mainloop (synch=synch at entry=0) at toplevel.cc:1167
#5 0x000056238bd5a89a in ui_main () at ../../src/ui.cc:3134
#6 0x000056238bc7d825 in main (argc=<optimized out>, argv=<optimized out>) at ../../src/main.cc:1427
-- Package-specific info:
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20160922/490e180c/attachment.ksh>
-------------- next part --------------
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (400, 'stable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.0-trunk-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages aptitude depends on:
ii aptitude-common 0.8.3-1
ii libapt-pkg5.0 1.3
ii libboost-filesystem1.61.0 1.61.0+dfsg-2.1+b1
ii libboost-iostreams1.61.0 1.61.0+dfsg-2.1+b1
ii libboost-system1.61.0 1.61.0+dfsg-2.1+b1
ii libc6 2.24-3
ii libcwidget3v5 0.5.17-4+b1
ii libgcc1 1:6.2.0-4
ii libncursesw5 6.0+20160910-1
ii libsigc++-2.0-0v5 2.9.3-1
ii libsqlite3-0 3.14.2-1
ii libstdc++6 6.2.0-4
ii libtinfo5 6.0+20160910-1
ii libxapian22v5 1.2.23-1
Versions of packages aptitude recommends:
ii libparse-debianchangelog-perl 1.2.0-10
ii sensible-utils 0.0.9
Versions of packages aptitude suggests:
ii apt-xapian-index 0.48
ii aptitude-doc-en [aptitude-doc] 0.8.3-1
ii debtags 2.1.2
ii tasksel 3.36
-- no debconf information
More information about the Aptitude-devel
mailing list