Re: Bug#624170: [hurd] cupt update: E: internal error: download client: wrong parameter count
Hi Jonathan, hello Hurd porters,
On 2011-04-26 19:33, Eugene V. Lyubimkin wrote:
> - thing which hangs is most probably that background download process
> (worker()), would be nice to know where it hangs.
I tried to investigate this on strauss.debian.net, and this is what I got when
it hangs (it hangs in random places, sometimes presumably garbage is received
from a socket and then it hangs, sometimes it just exists out of internal
checks after a garbage is received):
-8<-
(gdb) bt
#0 0x018232bc in _hurd_intr_rpc_msg_in_trap (msg=0x1dfec5c, option=3, send_size=44, rcv_size=2092, rcv_name=19, timeout=0, notify=0) at intr-msg.c:134
#1 0x01a371f5 in __io_read (io_object=49, data=0x1dff568, dataCnt=0x1dff56c, offset=-1, amount=2)
at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.11.2/build-tree/hurd-i386-xen/hurd/RPC_io_read.c:138
#2 0x01827cf1 in readfd (port=49) at fd-read.c:34
#3 0x0182ec61 in _hurd_ctty_input (port=49, ctty=0, rpc=0x1dff574) at ctty-input.c:32
#4 0x01827675 in _hurd_fd_read (fd=0x27d88, buf=0x1dff632, offset=-1) at fd-read.c:39
#5 0x018e5f20 in __libc_read (fd=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece.
) at ../sysdeps/mach/hurd/read.c:27
#6 0x01463949 in receiveSocketMessage (socket=8) at /home/jackyf/cupt/cpp/lib/src/download/manager.cpp:85
#7 0x01468cdd in cupt::internal::ManagerImpl::download (this=0x8284950, entities=...) at /home/jackyf/cupt/cpp/lib/src/download/manager.cpp:1100
#8 0x014697ea in cupt::download::Manager::download (this=0x1dff9dc, entities=...) at /home/jackyf/cupt/cpp/lib/src/download/manager.cpp:1249
#9 0x013e0078 in cupt::internal::MetadataWorker::__update_index (this=0x8283b7c, downloadManager=..., indexEntry=..., releaseFileChanged=false,
indexFileChanged=@0x1dff94e) at /home/jackyf/cupt/cpp/lib/src/internal/worker/metadata.cpp:351
#10 0x013e0db9 in cupt::internal::MetadataWorker::__update_release_and_index_data (this=0x8283b7c, downloadManager=..., indexEntry=...)
at /home/jackyf/cupt/cpp/lib/src/internal/worker/metadata.cpp:430
#11 0x013e192b in cupt::internal::MetadataWorker::updateReleaseAndIndexData (this=0x8283b7c, downloadProgress=...)
at /home/jackyf/cupt/cpp/lib/src/internal/worker/metadata.cpp:557
#12 0x0146174c in cupt::system::Worker::updateReleaseAndIndexData (this=0x1dffb60, progress=...) at /home/jackyf/cupt/cpp/lib/src/system/worker.cpp:83
#13 0x081cb5d6 in updateReleaseAndIndexData (context=...) at /home/jackyf/cupt/cpp/console/handlers/managepackages.cpp:892
#14 0x0816337e in std::_Function_handler<int ()(Context&), int (*)(Context&)>::_M_invoke(std::_Any_data const&, Context&) (__functor=..., __args#0=...)
at /usr/include/c++/4.5/functional:1699
#15 0x08152496 in std::function<int ()(Context&)>::operator()(Context&) const (this=0x1dffc5c, __args#0=...) at /usr/include/c++/4.5/functional:2116
#16 0x0814fc9e in mainEx (argc=8, argv=0x1dffd78, context=..., command=...) at /home/jackyf/cupt/cpp/console/cupt.cpp:78
#17 0x0814fb84 in main (argc=8, argv=0x1dffd78) at /home/jackyf/cupt/cpp/console/cupt.cpp:63
->8-
A source code at frame 6 is 'read(socket, &len, sizeof(len))', reading 2 bytes
from a unix socket.
A search for '_hurd_intr_rpc_msg_in_trap' showed that GHC and ps have/had
some similar "hangs" problems with similar backtraces: [1] and [2].
@porters: Does it look like a bug in application or libc?
[1] http://lists.debian.org/debian-hurd/2011/04/msg00060.html
[2] http://lists.debian.org/debian-hurd/2000/01/msg00093.html
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
Reply to: