Backtrace attached. 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): deluge-0.5.3-1.fc7
Created attachment 160557 [details] backtrace
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. Thanks.
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: http://pgordon.fedorapeople.org/deluge-rhbz_250694-test/ (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: http://pgordon.fedorapeople.org/pubkey.asc If it does indeed fix the segfaults, I'll push it as an update through the build system. Thanks!
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 stable soon). Thanks for the bug report; please reopen this if the problem persists.