Transmission doesn't notice when users delete downloaded files manually

[smmalis]

If a file is deleted that Transmission is uploading, the message log reports "generic i/o errno from errno: No such file or directory". Upon receiving this message, Transmission should automatically run a "Verify local data", because something obviously went wrong.

[smmalis]

now that generic i/o errno has been eliminated, nothing shows up in the message log.

[charles]

smmalis: what is the use case for this? did you delete a file from a torrent that you were still seeding?

[smmalis]

That's exactly it. Not sure if this applies to any file you're uploading or only when seeding, but that's when I've seen it.

[charles]

Why on earth would you delete a file in a torrent that you're still seeding?

[smmalis]

It could be an accident, and you don't even realize it. If that's the case, the file wouldn't redownload or anything.

[smmalis]

The cases where it happens may be few, but think about it. The bottom line is that if something causes an error while Transmission happens to be uploading a file, Transmission should automatically run a Verify Local Data.

[Gimp]

Its not up to transmission to automatically verify the file if there is an error. What if its on an external hard drive and you just unplugged it? you don't want it to verify, then you have to verify again when you plug it back in.

Besides, verifying then, would make the torrent start at 0 and begin downloading. This ticket is invalid.

Transmission should report a simple "File not found" to the end user, and PERHAPS pause the torrent. but thats all.

[charles]

smmalis: could you give r6880 try and see what the results are?

[smmalis]

I'm downloading a torrent now. When it finishes, I'll delete the file and see what happens.

[smmalis]

Transmission crashed as soon as I deleted the file.

[smmalis]

Running in a terminal gives:

transmission: ptrarray.c:102: tr_ptrArrayNth: Assertion `i < t->n_items' failed.
Aborted

[smmalis]

Gimp makes some valid points, and I agree with his proposed solution. It seems now when the file disappears while seeding that Transmission crashes (see above), but on restart the torrent is paused.

[charles]

smmalis: could you attach a valgrind or gdb trace of the crash?

[smmalis]

I will as soon as this torrent finishes.

[smmalis]

Here you go. I was receiving a lot of SIGPIPEs at first, so I told GDB to handle them.

[smmalis]

gdb log

[charles]

smmalis: I apprecate the log, but it appears to have been made from an executable with the debugging information stripped out, like you'd see from a "make install".

Could you rebuild the libtransmission/ and gtk/ directories for better debugging (change the -O and -g arguments in CFLAGS to -O0 -ggdb3 in their respective Makefiles, then "make" again) and attach a gdb log from the executable that's created in the gtk/ directory?

I tried this myself by deleting from disk a torrent that Transmission was seeding. Unfortunately(?) for me Transmission did the Right Thing and just stopped the torrent instead of crashing...

[charles]

For example, this is from the previous log:

118 	No symbol table info available.
119 	#4  0x0808c75d in tr_ptrArrayNth ()
120 	No symbol table info available.
121 	#5  0x080a8d85 in ?? ()
122 	No symbol table info available.
123 	#6  0x08097d18 in ?? ()
124 	No symbol table info available.

We can see that tr_ptrArrayNth() is in the call stack at level #4, but because #5 is empty we don't know who called it before it crashed... basically all we know is that someone somewhere in the program called tr_ptrArrayNth() right before the crash. That function is called 11 places in libtransmission, so getting that function name in #5 will eliminate over 90% of the suspects... :)

[smmalis]

Torrent is downloading now with a debugging version of libT and gtk. Is it possible (or a good idea) to put those flags in automatically? I don't know much about makefiles, but could it be changed so automake does that for everyone building from svn? Seems like it would be helpful for bug reports.

[smmalis]

#4  0x08086903 in tr_ptrArrayNth ()
No symbol table info available.
#5  0x0809f5e6 in ?? ()
No symbol table info available.

Doesn't seem to have worked.

[charles]

Could you walk me through the exact steps you're doing to trigger this bug?

[smmalis]

Start up Transmission (current state doesn't matter). Add a torrent or use one already downloaded (it doesn't matter). Seed the torrent. Wait until actually uploading something. Delete/Move/Eject? file from the torrent. Crash.

Maybe this only happens with single file torrents? Or if you move everything the torrent downloaded (not just one file)?

[charles]

forum user jh has ​come to the rescue:

0   libSystem.B.dylib                0x93392fa4 __semwait_signal_nocancel + 8
1   libSystem.B.dylib                0x93392a70 nanosleep$NOCANCEL$UNIX2003 + 176
2   libSystem.B.dylib                0x93383c08 usleep$NOCANCEL$UNIX2003 + 68
3   libSystem.B.dylib                0x933a92bc abort + 92
4   org.m0k.transmission             0x0007615c __eprintf + 76
5   org.m0k.transmission             0x000577c4 tr_ptrArrayNth + 100
6   org.m0k.transmission             0x0005dde8 pumpAllPeers + 88
7   org.m0k.transmission             0x0005ea9c bandwidthPulse + 672
8   org.m0k.transmission             0x00058124 timerCallback + 40
9   org.m0k.transmission             0x00071474 event_base_loop + 1332
10  org.m0k.transmission             0x00058318 libeventThreadFunc + 140
11  libSystem.B.dylib                0x932c4658 _pthread_start + 316

[charles]

possible fix in r6940.

[smmalis]

IT WORKS!!! YAY!!! Now then, part 2: Upon hitting Resume, if the torrent was paused for that reason, it should Verify.

[charles]

about "part 2", I'm more in agreement with Gimp in comment 8.

[smmalis]

I am too, but the problem now is that after this pause occurs, if the user hits Resume without verifying, the old behavior returns.

[charles]

If a red torrent saying "no such file or directory" isn't enough of a clue to the general user then nothing that we do is ever going to be enough.

[smmalis]

The problem is though, that the old behavior still exists. Here's an idea: Don't let the torrent resume until it has been verified after this error?

[charles]

smmalis: If you reopen this ticket for a fifth time I will delete your account.

[sim]

(deleted spam)