Richard Atterer wrote: > Hi ael, > > thanks for this! Unfortunately, as you suspect, the backtrace is not useful > without debugging information. :-/
I realise that :-( > I've just uploaded a version of jigdo-file which contains debugging > symbols: <http://atterer.net/jigdo-file_0.7.3-2_i386.deb> > Maybe retry with it and see if you can trigger the problem again. > Please also add "--debug=all" to jigdoOpts in your ~/.jigdo-lite > configuration file to get more information! Oh, good. I was hoping to have time to build one myself with degugging symbols, but these crashes always seem to happen when I am busy. I guess because I usually have a jigdo update running in the background when I am working on other things... I will collect and install your debugging version.... > What exactly is happening during the livelock? Does jigdo-file take up all > CPU time, or does it just appear to hang? How long have you waited before > interrupting it? Yes: top usually reports 80% or 90+% cpu time depending on the other tasks. I have left it running for 30 minutes or more on at least one occasion, and I think it has run far longer on other occasions. As I say, I tend to have jigdo running in the background, and sometimes find it in the hung state which may have lasted an hour or more. I think on that evidence it has to be livelock :-) > The code has not changed significantly in a long time and AFAIR, you're the > first to report this kind of problem. This makes me think that something > must be special about your setup - anything unusual that you can think of? Only that this box is fairly old hardware, but no problems with anything else. It is an etch system with backports, except that I usually run the latest stock kernel (2.6.28 just now) which I compile myself. But I doubt that it has anything to do with the kernel, except I use PREEMPT. The hardware is probably rather slower than most systems, which is why I use that PREMPT sheduling, so if there is a race somewhere, it might show up here rather than on other machines for that reason or just because of the speed compared to the IO devices. Oh, yes, and rather small RAM: 256K, although I haven't noted any swapping during the runs. > Are you running several jigdo downloads in parallel with the same cache > file? No, but the last deadlock *was* cleared by removing the cache file. By "cleared" I mean that if I removed jigdo-file-cache.db and restarted jigdo then the problem did not re-appear. I did wonder whether the jigdo-file-cache.db left from the previous run on the preceeding disc was somehow corrupted and messed up the next run. Do you clear it at the end of each run, or is there no reason to do so? > Please also send me the contents of your ~/.jigdo-lite file. jigdo='' debianMirror='http://the.earth.li/debian/' nonusMirror='' tmpDir='.' jigdoOpts='--cache jigdo-file-cache.db' wgetOpts='--passive-ftp --dot-style=mega --continue --timeout=30' scanMenu='http://the.earth.li/debian http://mirror.ox.ac.uk/debian /dvd ' >> This livelock was *not* cleared by removing temporary files. > > Did you also remove the cache? No I didn't remove jigdo-file-cache.db on that occasion, but suspect that it would have solved the problem had I done so as above. What else was the machine doing at the time, > was any other software apart from the regular desktop stuff running? Can't remember, but quite likely to have been running Thunderbird and/or firefox and maybe a remote ssh session. But I have seen such crashes before, and haven't noticed any correlation with other programs. > What filesystem are you creating your images on? ext3 Hope some of this helps. I have another dvd to update to this week's images: I will try that with the debugging version, but I guess the chances of hitting the bug are pretty slim. Adrian Lawrence -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
