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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org