Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#3980 closed Bug (fixed)

segfault when adding many torrents remotely

Reported by: ijuxda Owned by: jordan
Priority: Normal Milestone: 2.20
Component: GTK+ Client Version: 2.13
Severity: Normal Keywords: segfault crash add torrent gtk
Cc:

Description

When adding many torrents one by one via transmission-remote -a the gtk client crashed with the following console output:

(transmission-gtk:4737): Gtk-CRITICAL **: gtk_tree_model_sort_get_value: assertion `VALID_ITER (iter, tree_model_sort)' failed

(transmission-gtk:4737): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.18.2/gobject/gtype.c:3940: type id `0' is invalid

(transmission-gtk:4737): GLib-GObject-WARNING **: can't peek value table for type `<invalid>' which is not currently referenced
Segmentation fault

This was while I was selectively adding magnet links from a list and the segfault happened once there had already been approximately 30 torrents added.

When I set ulimit -c unlimited and produced a crash following the same steps I did not get any console output (besides the segfault message). The attached backtrace.txt contains a full gdb backtrace from the core file.

Tested with r11829.

Attachments (2)

backtrace.txt (3.5 KB) - added by ijuxda 11 years ago.
gdb --batch -ex 'bt full' ./gtk/transmission-gtk ./core > backtrace.txt
test-remote-magnet-add.pl (580 bytes) - added by ijuxda 11 years ago.

Download all attachments as: .zip

Change History (7)

Changed 11 years ago by ijuxda

gdb --batch -ex 'bt full' ./gtk/transmission-gtk ./core > backtrace.txt

comment:1 Changed 11 years ago by jordan

Thanks for the backtrace.

The symptom would be easy enough to fix by adding

if( gtor == NULL ) return FALSE;

after gtk_tree_model_get() in update_foreach(). And that probably should be added, just to be safe. But I'm wondering how we get a row with a NULL pointer in MC_TORRENT to begin with.

Does it have to be magnet links to trigger the crash, or can it be done with .torrent files too?

Are you able to reproduce this behavior with a consistent set of public domain .torrent files, that I could test with?

comment:2 Changed 11 years ago by jordan

I see a likely suspect. Does r11831 fix the problem for you?

r11831

(trunk libT) #3980 "segfault when adding many torrents remotely" -- possible fix.

gtk/main.c's onRPCChanged() is called from inside the libtransmission thread, yet it still made GTK+ calls to modify the GTK+ client's tr-core object when a torrent was added. This caused a race condition inside of the GTK+ internals. onRPCChanged() already knows to delegate work back to the GTK+ thread when a torrent is removed via RPC. This commit uses the same kind of mechanism to delegate work back to the GTK+ thread when a torrent is added via RPC.

comment:3 Changed 11 years ago by jordan

  • Milestone changed from None Set to 2.20
  • Status changed from new to assigned
  • Version changed from 2.13+ to 2.13

This bug seems to exist in 2.13 if you rapidly add enough torrents, whether as files or magnet links.

r11831 seems to have fixed it -- I can't make it crash anymore.

If you can still trigger this crash, please reopen this bug with more information. Thank you!

comment:4 Changed 11 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

Changed 11 years ago by ijuxda

comment:5 Changed 11 years ago by ijuxda

I am unable to trigger the crash or any gtk warnings after r11831, so it would appear that the changes resolved this problem case. I do not have a list of public domain torrents, but for testing I used a script (attached), since it was quite tiresome to trigger by hand after the second crash.

Note: See TracTickets for help on using tickets.