search

Treferwynd / transmission-remote-gtk

Automatically exported from code.google.com/p/transmission-remote-gtk
GNU General Public License v2.0
0 stars 0 forks source link

Server returned nothing (no headers, no data) #256

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Server: Gentoo 64 bits
Client: Ubuntu 13.10 64 bits
transmission-remote-gtk git version:
   commit f90a22358df1da6bafdc6783bade8b4202bdf212
   Author: Alan F <ajf@eth0.org.uk>
   Date:   Sat Mar 15 00:08:31 2014 +0000
-----------------------------------------------------

I try to add one torrent file of 200 kB but transmission-remote-gtk doesn't add 
it and it shows the error "Server returned nothing (no headers, no data)".

If I add the torrent with transmission-remote it works: 
   trans-server:9999/transmission/rpc/ responded: "success"

Original issue reported on code.google.com by decedion on 3 Apr 2014 at 10:04

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
This error occurs from revision 37d2c80cfa0b, with the implementation of RSS 
viewer.
The revision 98eb06aaeb6e works right.

Original comment by decedion on 5 Apr 2014 at 11:19

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks for the report, I'll look into this.

I can't reproduce with that file. Here's a few bits of information which could 
be useful:

 * Is the options dialog enabled and are any changes made? Does the file show up in there properly?
 * Are you using any of the new RSS features at all?
 * Try compiling with ./configure --enable-debug, then running with the env var TRG_CURL_VERBOSE=1 and send the output. It might be obvious from this what's wrong.

Original comment by a...@eth0.org.uk on 6 Apr 2014 at 8:17

GoogleCodeExporter commented 9 years ago 
The options dialog is enabled (without changes) and the torrent and its content 
are shown properly. I attach two screenshots.
No, I don't use any RSS feature.
I attach the log output with "TRG_CURL_VERBOSE=1". I hope this helps you to 
find the problem. 
If you need that I do any other test, just let me know. :-)

Original comment by decedion on 6 Apr 2014 at 11:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Can you try the below patch? Looks like the server is sending a HTTP 100 
(Continue), I guess because this is a large file and we need to wait for 
Transmission to process it. I've never seen this behaviour before, it could be 
a relatively new feature in Transmissoin, but I'm also not exactly sure why it 
would have only started with the refactoring I did recently.

We seem to be sending a Expect: header in the request, so I think if this is 
unset Transmission might not reply with a 100 Continue.

diff --git a/src/trg-client.c b/src/trg-client.c
index d69ee24..d299ef9 100644
--- a/src/trg-client.c
+++ b/src/trg-client.c
@@ -594,6 +594,7 @@ trg_http_perform_inner(TrgClient * tc, trg_request * 
request,
     response->size = 0;
     response->raw = NULL;

+    headers = curl_slist_append(headers, "Expect:");
     curl_easy_setopt(curl, CURLOPT_POSTFIELDS, request->body);
     curl_easy_setopt(curl, CURLOPT_WRITEDATA, (void *) response);

Original comment by a...@eth0.org.uk on 7 Apr 2014 at 6:50

GoogleCodeExporter commented 9 years ago 
Same error with this patch. I attach the log file.
The Transmission server version is 2.82 (14160) on Gentoo 64 bits.

Original comment by decedion on 7 Apr 2014 at 10:03

Attachments:

GoogleCodeExporter commented 9 years ago 
Remember, the revision 98eb06aaeb6e works well.

Original comment by decedion on 7 Apr 2014 at 10:28

GoogleCodeExporter commented 9 years ago 
There was a bug in it, try this:

diff --git a/src/trg-client.c b/src/trg-client.c
index d69ee24..dd372fc 100644
--- a/src/trg-client.c
+++ b/src/trg-client.c
@@ -594,12 +594,13 @@ trg_http_perform_inner(TrgClient * tc, trg_request * reque
     response->size = 0;
     response->raw = NULL;

+    headers = curl_slist_append(headers, "Expect:");
     curl_easy_setopt(curl, CURLOPT_POSTFIELDS, request->body);
     curl_easy_setopt(curl, CURLOPT_WRITEDATA, (void *) response);

        session_id = trg_client_get_session_id(tc);
        if (session_id)
-               headers = curl_slist_append(NULL, session_id);
+               headers = curl_slist_append(headers, session_id);

        curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);

Original comment by a...@eth0.org.uk on 7 Apr 2014 at 5:45

GoogleCodeExporter commented 9 years ago 
The patch file doesn't correspond with my trg-client.c (updated from git last 
version).

Original comment by decedion on 7 Apr 2014 at 5:54

Attachments:

GoogleCodeExporter commented 9 years ago 
I apply the patch with "patch -p1 < trg-client.patch"

Original comment by decedion on 7 Apr 2014 at 5:56

GoogleCodeExporter commented 9 years ago 
Weird, here's a new .patch which seems to work.

Original comment by a...@eth0.org.uk on 7 Apr 2014 at 6:05

Attachments:

GoogleCodeExporter commented 9 years ago 
Now it works worst: the transmission server crashes when 
transmission-remote-gtk sends the torrent.

Original comment by decedion on 7 Apr 2014 at 6:28

Attachments:

GoogleCodeExporter commented 9 years ago 
Unfortunately I am unable to reproduce. With the same version of transmission, 
same file, and same version of transmission-remote-gtk.

Is there anything in the transmission logs to indicate why the upload doesn't 
work (before and after the patch), and perhaps attach a core dump from 
Transmission from when it crashes? I might be able to make sense of it. 

I guess you could also try setting TRG_SHOW_OUTGOING=1 and include that in the 
output.. To show if the JSON sent looks correct.

Looking at the changes after the revision you mentioned, I can't yet see what 
would cause this for you.

Original comment by a...@eth0.org.uk on 8 Apr 2014 at 7:39

GoogleCodeExporter commented 9 years ago 
The problem is in last versions of transmission-remote-gtk because it works 
well if I send the file with transmission-remote and if I send the file with 
transmission-remote-gtk (revision 98eb06aaeb6e).
I've executed transmission-daemon with gdb and this is the error:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x681914b50700 (LWP 6505)]
0x0000016f3d4512d2 in tr_torrentInitFilePriority (
    tor=tor@entry=0x68191150c160, fileIndex=1278, 
    priority=priority@entry=0 '\000') at torrent.c:2240
2240        tor->info.pieces[i].priority = calculatePiecePriority (tor, i, 
fileIndex);

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x6dca4d51c700 (LWP 7648)]
0x00000d8f183712d2 in tr_torrentInitFilePriority (tor=0x6dca156bfd10, 
    fileIndex=35, priority=<optimized out>) at torrent.c:2240
2240        tor->info.pieces[i].priority = calculatePiecePriority (tor, i, 
fileIndex);

I've tested several torrent of different sizes (all above 200 kB) and not all 
of them fail.
I attach another torrent files (public tracker) that fail too.

Original comment by decedion on 8 Apr 2014 at 9:13

Attachments:

GoogleCodeExporter commented 9 years ago 
I forgot to attach the log file of transmission-remote-gtk.

Original comment by decedion on 8 Apr 2014 at 9:18

Attachments:

GoogleCodeExporter commented 9 years ago 
I have recompiled transmission-daemon but same problem.
I attach my compiled transmission-daemon (64 bits).

Original comment by decedion on 8 Apr 2014 at 9:34

Attachments:

GoogleCodeExporter commented 9 years ago 
By the crash log seems the problem is in priority vector.

Original comment by decedion on 8 Apr 2014 at 9:36

GoogleCodeExporter commented 9 years ago 
I think I see the problem, have put a fix into git.

Original comment by a...@eth0.org.uk on 8 Apr 2014 at 4:54

GoogleCodeExporter commented 9 years ago 
Great, now it works. Thank you.

Original comment by decedion on 8 Apr 2014 at 10:50

GoogleCodeExporter commented 9 years ago

Original comment by a...@eth0.org.uk on 9 Apr 2014 at 7:51