Your message dated Fri, 17 May 2013 11:34:02 +0000 with message-id <[email protected]> and subject line Bug#707949: Removed package(s) from unstable has caused the Debian Bug report #508475, regarding hpodder update/fetch hangs forever if curl dies (fix included). to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 508475: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508475 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: hpodder Version: 1.1.5.0 Severity: normal I run hpodder in a cronjob to download podcasts overnight. About once a week or so, I notice that hpodder is hanging forever. I don't know for sure what causes these hangs, but I can produce the same behavior by running "killall curl" while "hpodder update" is running. It looks like what happens is this: when curl fails, the download process (in DownloadQueue.hs) notices this fact and invokes update's callback with the result information from the download. The update callback proceeds to call exitFailure, and according to the ghc documentation: ==== exitWith :: ExitCode -> IO a Computation exitWith code throws ExitException code. Normally this terminates the program, returning code to the program's caller. Before the program terminates, any open or semi-closed handles are first closed. A program that fails in any other way is treated as if it had called exitFailure. A program that terminates successfully without calling exitWith explicitly is treated as it it had called exitWith ExitSuccess. As an ExitException is not an IOError, exitWith bypasses the error handling in the IO monad and cannot be intercepted by catch from the Prelude. However it is an Exception, and can be caught using the functions of Control.Exception. This means that cleanup computations added with Control.Exception.bracket (from Control.Exception) are also executed properly on exitWith. exitFailure :: IO a The computation exitFailure is equivalent to exitWith (ExitFailure exitfail), where exitfail is implementation-dependent. ==== My guess is that either something is catching the ExitError and throwing it away. It could also be that a cleanup computation is deadlocking, but I don't think so. Either way, the result is that the program doesn't exit, but the semaphore is never signaled, so the main thread just hangs. I found a fix that papers over this problem: it breaks the "exit with failure on failure" semantics, but at least it avoids hanging forever. Moreover, it fixes a number of similar potential bugs. I apologize for the lack of a patch, but I don't have time atm to strip out my debugging code and get a clean copy of hpodder, so I'll just describe it. Import Control.Exception(finally) in DownloadQueue. Instead of relying on childthread to tail out and call signalQSem, use Control.Exception.finally to do it: semaphore <- newQSem 0 -- Used by threads to signal they're done mapM_ (\_ -> forkIO (handleSqlError $ finally (childthread dqmvar) (signalQSem semaphore))) [1..maxthreads] mapM_ (\_ -> waitQSem semaphore) [1..maxthreads] and childthread :: MVar (DownloadQueue a) -> IO () childthread dqmvar = do workdata <- getworkdata if length(workdata) == 0 then return () else do processChildWorkData workdata childthread dqmvar -- And look for more hosts where getworkdata = modifyMVar dqmvar $ \dq -> This ensures that no matter how childthread exits, the semaphore is signaled (so exceptions / errors that occur in it don't hang hpodder). On my system, this means that "update" exits successfully and "fetch" proceeds to download any new episodes that it found, which I'm fine with. Daniel -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hpodder depends on: ii curl 7.18.2-7 Get a file from an HTTP, HTTPS or ii id3v2 0.1.11-3 A command line id3v2 tag editor ii libc6 2.7-16 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library ii libsqlite3-0 3.5.9-6 SQLite 3 shared library hpodder recommends no packages. hpodder suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---Version: 1.1.5.0+nmu3+rm Dear submitter, as the package hpodder has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see http://bugs.debian.org/707949 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]. Debian distribution maintenance software pp. Luca Falavigna (the ftpmaster behind the curtain)
--- End Message ---
