Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1290 closed Bug (fixed)

Removing torrent in web/remote interface crashes GTK+ client

Reported by: naddy Owned by: charles
Priority: Normal Milestone: 1.40
Component: GTK+ Client Version: 1.34
Severity: Major Keywords:
Cc:

Description

If you run the GTK+ client, access it through the web interface or with transmission-remote and remove a torrent there, the GTK+ client sometimes crashes. Here's a backtrace:

(gdb) bt                                                                        
#0  0x0000000000153b98 in tr_globalLock (handle=0xdfdfdfdfdfdfdfdf)             
    at session.c:343                                                            
#1  0x0000000000156878 in tr_torrentLock (tor=0x42292000) at torrent.c:125      
#2  0x000000000015a894 in tr_torrentRecheckCompleteness (tor=0x42292000)        
    at torrent.c:1203                                                           
#3  0x000000000015897c in tr_torrentGetStatus (tor=0x42292000) at torrent.c:686 
#4  0x0000000000137b78 in update_foreach (model=0x4d470f10, path=0x4aa0a690,    
    iter=0xfffffffffffdd090, data=0x0) at tr-core.c:891                         
#5  0x000000004ee01858 in gtk_tree_model_rows_reordered ()                      
   from /usr/local/lib/libgtk-x11-2.0.so.1200.10                                
#6  0x000000004ee019ac in gtk_tree_model_foreach ()                             
   from /usr/local/lib/libgtk-x11-2.0.so.1200.10                                
#7  0x0000000000137c88 in tr_core_update (self=0x4225d5b0) at tr-core.c:916     
#8  0x0000000000127fc4 in updatemodel (gdata=0x4a9a6200) at main.c:1060         
#9  0x00000000543cc0b8 in g_main_context_is_owner ()                            
   from /usr/local/lib/libglib-2.0.so.1600.1                                    
#10 0x00000000543c8798 in g_source_is_destroyed ()                              
   from /usr/local/lib/libglib-2.0.so.1600.1                                    
#11 0x00000000543c8798 in g_source_is_destroyed ()                              
   from /usr/local/lib/libglib-2.0.so.1600.1            

The immediate problem is that *tor is all 0xdf bytes. Why 0xdf? Because I run with OpenBSD's "J" malloc() debugging option, which causes newly allocated as well as free()ed memory to be initialized to 0xdf. I suspect that this uncovers a case of "use after free()".

Attachments (1)

valgrind.log (12.7 KB) - added by charles 12 years ago.
Partial valgrind log of this error

Download all attachments as: .zip

Change History (9)

comment:1 follow-up: Changed 12 years ago by charles

Your assessment sounds right, but I can't reproduce this, even inside of valgrind. Is there a particular recipe needed to trigger the bug?

comment:2 in reply to: ↑ 1 Changed 12 years ago by naddy

No particular recipe, as far as I can tell. It doesn't matter if the torrent is complete or was just added without ever transferring a byte. For me it happens maybe half the time I remove a torrent by way of the web/remote interface. If this is due to a race, it might be much rarer or even never trigger on different platforms.

comment:3 follow-up: Changed 12 years ago by charles

Do multiple torrents have to be removed to trigger it, or can you trigger it by deleting a single torrent on its own?

Can you ever make it happen if there is only one torrent loaded, and you remove it?

comment:4 in reply to: ↑ 3 Changed 12 years ago by naddy

Replying to charles:

Do multiple torrents have to be removed to trigger it, or can you trigger it by deleting a single torrent on its own?

A single torrent.

Can you ever make it happen if there is only one torrent loaded, and you remove it?

Yes.

Changed 12 years ago by charles

Partial valgrind log of this error

comment:5 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.40
  • Status changed from new to assigned

comment:6 Changed 12 years ago by charles

  • Keywords backport-candidate added
  • Resolution set to fixed
  • Status changed from assigned to closed

Looks like a race condition between the libtransmission thread and the gtk+ thread. I think r6834 fixes it but, as usual with threads, we'll need more testing to make sure.

Please reopen this ticket if you have any further problems along these lines...

comment:7 Changed 12 years ago by charles

  • Severity changed from Normal to Major

comment:8 Changed 12 years ago by charles

  • Keywords backport-candidate removed
Note: See TracTickets for help on using tickets.