In case it is related to the crash: I have a 4GB iso in download queue, and
"compact allocation" is selected in preferences.
Version-Release number of selected component (if applicable):
Created attachment 160557 [details]
Thanks for your bug report, and the stacktrace.
Unfortunately, the stacktrace alone is not enough to tell me where it is
failing. How did you create this stacktrace with GDB? Please try again with
"thread apply all bt full" to give me the variables and other data items which
would allow me to further debug this.
Also, your stacktrace is missing a few items which _might_ help further. If it's
not too much trouble for you, please install the pygtk2 and boost debuginfo
packages. This can be done by installing the 'yum-utils' package and running
"debuginfo-install pygtk2 boost" as root.
Addendum to my previous comment: Can you provide a sample torrent that would
allow me to reproduce this? I'll try it with the Fedora-7-x86_64 torrent (3.4
GB) but I don't know if that's large enough to cause the problem. Thanks.
Boost and pygtk are pulling over 130MB debuginfo, will be hard to download
today. But what I'm seeing is probably http://dev.deluge-torrent.org/ticket/444
(see thread #5 from my trace). Also there are better traces at libtorrent bug
tracker which are linked on the URL above.
btw, it crashes with with f7-i386 (2.8G) torrent too. So annoying that I'm
running it in a while loop :)
Yeah, I understand about the huge debuginfo dependencies; that's acceptable.
Thanks for the upstream ticket link; It seems that it's fixed in upstream
rb_libtorrent SVN r1417; so I'll use that as a base and try to patch the
Deluge-internal copy which may fix this.
Hello again. :)
I've added the patch from the the upstream libtorrent Subversion ticket and it
seems to cause no regressions. However, I can't reproduce your original issue
anyway, so I can't tell if this indeed fixes it.
Would you please try it out and let me know if it fixes it for you? The binary
(x86_64, i386) and source RPMs are on my webspace:
(If you are using PPC or another arch, you'll need to rebuild it from the source
RPM, as I only have access to x86-capable hardware currently. Apologies for any
inconvenience that this may cause.)
The packages are signed with my GPG key, which is also on my webspace:
If it does indeed fix the segfaults, I'll push it as an update through the build
Created attachment 160614 [details]
same segfault with more debuginfo
Thanks for the prompt response!
It still crashes, though not as often.
Thanks for the new backtrace; it helps a bit.
Maybe it's a plugin that causes this? Which ones do you have enabled and what
non-default settings are you using that might be suspect in this?
This will help me configure mine in a similar fashion, and hopefully make this
far more reproducible on my machine.
I'm using only the network graph plugin. Network related settings are the
defaults, only the compact storage allocation option set.
I'll try with the changes here: http://code.rasterbar.com/libtorrent/changeset/1429
That should fix this according to libtorrent ticket 94.
Hmm. Yes, please let me know if that changeset fixes your issue. If so I'll add
that as a patch to the package in Fedora CVS.
FYI: applying above changeset to the rpm you provided fixed the crashes.
Great, thanks for the confirmation, SertaÃ§. I'll add that as a patch in new update.
On further investigation, Deluge 0.5.5 already includes this patch; so I'll
close this bug as RESOLVED since that's already in testing (should be pushed to
Thanks for the bug report; please reopen this if the problem persists.