Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2326 closed Bug (fixed)

high cpu load when adding unregistered torrents

Reported by: AVI Owned by:
Priority: High Milestone: 1.75
Component: libtransmission Version: 1.74
Severity: Normal Keywords: backport-1.5x
Cc:

Description

I'm using transmission-daemon (transmission 1.73) on Ubuntu 8.04 bug occurs: in handling through the webui (or transmission-remote) interface is not shown (transmission-remote -- "timeout error"), but the list of transmission-daemon starts to load CPU and memory to hold 90%.

It seems this happens when a torrent is removed from the tracker This helps the removal of unregistered torrent from "/var/lib/transmission-daemon/info/resume" and "/var/lib/transmission-daemon/info/torrents"

Sorry for my english

Attachments (4)

1.png (40.3 KB) - added by AVI 12 years ago.
2.png (47.7 KB) - added by AVI 12 years ago.
3.png (43.4 KB) - added by AVI 12 years ago.
n1.png (52.0 KB) - added by AVI 12 years ago.

Download all attachments as: .zip

Change History (33)

comment:1 Changed 12 years ago by charles

Thank you for taking the time to report this bug and helping to make Transmission better. Please answer these questions:

  • Is this reproducible?
  • If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

Changed 12 years ago by AVI

Changed 12 years ago by AVI

Changed 12 years ago by AVI

comment:2 Changed 12 years ago by AVI

Yes this reproducible:

  1. Create a torrent, and do not register it to the tracker. (pic. 1)
  1. Add the torrent in transmission. (pic. 2)
  1. Epic fail (pic. 3)

same thing happens if the torrent is removed from the tracker

comment:3 Changed 12 years ago by charles

I've just walked through these steps as described and, unfortunately, I'm not able to reproduce this.

Are you familiar with using gdb? If so what I'd like to do is get you to run transmission-daemon inside of gdb so that, when the process spikes to 100% cpu, you can get a series of backtraces and we can try to figure out what's making Transmission go crazy.

I can give you step-by-step instructions on how to do this, if you like. It's only a few steps and is relatively painless.

comment:4 Changed 12 years ago by AVI

Please give me step-by-step instructions.

comment:5 Changed 12 years ago by AVI

in Transmission 1.74 Beta 1 also has this bug :(

comment:6 Changed 12 years ago by charles

Ah, sorry for not getting back to you sooner.

Okay, so the step-by-step instructions. gdb is a pretty blunt instrument for doing profiling, but in extreme cases like the CPU spiking to a consistent 100%, it should be sufficient.

What we're going to try to do is run transmission inside of gdb, wait until the CPU use spikes to 100%, and then take a couple of "samples" to see what the program is doing. These samples take the form of backtraces, which show which function called which function called which function leading to the high CPU use.

To do this, first start gdb and tell it we're going to run transmission-daemon. From a terminal prompt, type:

% gdb transmission-daemon

And you'll get a (gdb) prompt. The next thing to do is turn off sigpipe, which gdb handles oddly. Long story, short workaround:

(gdb) handle SIGPIPE nostop noprint nopass

Now you're ready to run transmission-daemon in the foreground. "r" means run, and the arguments after that (-f here, for foreground) are passed along to transmission-daemon. If you use other arguments, add them along with the -f.

(gdb) r -f

And let the daemon run as usual until you hit the 100% cpu load. When you get there, type ctrl-c to get the (gdb) prompt again, and from there you can get the backtrace we're after:

(gdb) backtrace

and copy the output to a text editor somewhere. Once you have it, tell gdb to continue running:

(gdb) continue

wait a few seconds, then repeat the ctrl-c, backtrace, continue process a few times to get a few more backtraces. This way we'll know whether or not transmission-daemon is stuck in one place.

That's all there is to it. If you have any questions don't hesitate to ask. :)

comment:7 Changed 12 years ago by AVI

I did as you wrote, I received the following

(transmission-daemon starts with the following parameters: --config-dir "/var/lib/transmission-daemon/info" -f):

1 backtrace:

#0  0xb7f6e410 in __kernel_vsyscall ()
#1  0xb7b19cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b541dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x0804be9c in ?? ()
#5  0xb7a9a450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804b401 in ?? ()

2 backtrace:
#0  0xb7f6e410 in __kernel_vsyscall ()
#1  0xb7b19cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b541dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x0804be9c in ?? ()
#5  0xb7a9a450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804b401 in ?? ()

3 backtrace:
#0  0xb7f6e410 in __kernel_vsyscall ()
#1  0xb7b19cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b541dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x0804be9c in ?? ()
#5  0xb7a9a450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804b401 in ?? ()

4 backtrace:
#0  0xb7f6e410 in __kernel_vsyscall ()
#1  0xb7b19cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b541dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x0804be9c in ?? ()
#5  0xb7a9a450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804b401 in ?? ()

...

comment:8 Changed 12 years ago by charles

that's on the right track, but I'm afraid I misstated one of the steps. If you could, please rerun the test but use

(gdb) thread apply all bt

instead of

(gdb) backtrace

comment:9 Changed 12 years ago by AVI

It is now as follows:

1:
(gdb) thread apply all bt

Thread 3 (Thread 0xb7141b90 (LWP 7027)):
#0  0xb7f3b410 in __kernel_vsyscall ()
#1  0xb7ae6cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b211dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x08065ebe in ?? ()
#5  0x080653c2 in ?? ()
#6  0x08052833 in ?? ()
#7  0xb7ba54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7b27e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb7942b90 (LWP 7026)):
#0  0x080a386e in ?? ()
#1  0x080a3932 in ?? ()
#2  0x0804ee12 in ?? ()
#3  0x0804e36d in ?? ()
#4  0x0804f37e in ?? ()
#5  0x08094f58 in ?? ()
#6  0x08095140 in ?? ()
#7  0x080869e0 in ?? ()
#8  0x08086e95 in ?? ()
#9  0x080a6b67 in ?? ()
---Type <return> to continue, or q <return> to quit---
#10 0x080a6c89 in ?? ()
#11 0x080a6f43 in ?? ()
#12 0x080a2d94 in ?? ()
#13 0x080a30ba in ?? ()
#14 0x080a30d2 in ?? ()
#15 0x0806692f in ?? ()
#16 0x08052833 in ?? ()
#17 0xb7ba54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb7b27e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb79436d0 (LWP 7023)):
#0  0xb7f3b410 in __kernel_vsyscall ()
#1  0xb7ae6cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b211dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x0804be9c in ?? ()
#5  0xb7a67450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804b401 in ?? ()

2:
(gdb) thread apply all bt

Thread 3 (Thread 0xb7141b90 (LWP 7027)):
#0  0xb7f3b410 in __kernel_vsyscall ()
#1  0xb7ae6cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b211dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x08065ebe in ?? ()
#5  0x080653c2 in ?? ()
#6  0x08052833 in ?? ()
#7  0xb7ba54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7b27e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb7942b90 (LWP 7026)):
#0  0x0804ee22 in ?? ()
#1  0x0804e36d in ?? ()
#2  0x0804f37e in ?? ()
#3  0x08094f58 in ?? ()
#4  0x08095140 in ?? ()
#5  0x080869e0 in ?? ()
#6  0x08086e95 in ?? ()
#7  0x080a6b67 in ?? ()
#8  0x080a6c89 in ?? ()
#9  0x080a6f43 in ?? ()
---Type <return> to continue, or q <return> to quit---
#10 0x080a2d94 in ?? ()
#11 0x080a30ba in ?? ()
#12 0x080a30d2 in ?? ()
#13 0x0806692f in ?? ()
#14 0x08052833 in ?? ()
#15 0xb7ba54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#16 0xb7b27e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb79436d0 (LWP 7023)):
#0  0xb7f3b410 in __kernel_vsyscall ()
#1  0xb7ae6cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b211dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x0804be9c in ?? ()
#5  0xb7a67450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804b401 in ?? ()


3:
(gdb) thread apply all bt

Thread 3 (Thread 0xb7141b90 (LWP 7027)):
#0  0xb7f3b410 in __kernel_vsyscall ()
#1  0xb7ae6cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b211dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x08065ebe in ?? ()
#5  0x080653c2 in ?? ()
#6  0x08052833 in ?? ()
#7  0xb7ba54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7b27e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb7942b90 (LWP 7026)):
#0  0xb7aba082 in ?? () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7ab3bee in vsnprintf () from /lib/tls/i686/cmov/libc.so.6
#2  0x080a3c7c in ?? ()
#3  0x080a388b in ?? ()
#4  0x080a3932 in ?? ()
#5  0x0804ee12 in ?? ()
#6  0x0804e36d in ?? ()
#7  0x0804f37e in ?? ()
#8  0x08094f58 in ?? ()
#9  0x08095140 in ?? ()
---Type <return> to continue, or q <return> to quit---
#10 0x080869e0 in ?? ()
#11 0x08086e95 in ?? ()
#12 0x080a6b67 in ?? ()
#13 0x080a6c89 in ?? ()
#14 0x080a6f43 in ?? ()
#15 0x080a2d94 in ?? ()
#16 0x080a30ba in ?? ()
#17 0x080a30d2 in ?? ()
#18 0x0806692f in ?? ()
#19 0x08052833 in ?? ()
#20 0xb7ba54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#21 0xb7b27e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb79436d0 (LWP 7023)):
#0  0xb7f3b410 in __kernel_vsyscall ()
#1  0xb7ae6cb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7b211dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x080684f6 in ?? ()
#4  0x0804be9c in ?? ()
#5  0xb7a67450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804b401 in ?? ()

comment:10 Changed 12 years ago by AVI

any ideas? :)

comment:11 Changed 12 years ago by ais77

I have the same problem. Headless Ubuntu 8.04, Transmission 1.73 from repo.

How any .torrent file could cause Transmission to overload system? Something's wrong in the code now...

Please, pay attention to this bug - problem occured after upgrading to 1.73, for YEAR before everything was fine. You can guess how many .torrents became unregistered or absolete for such a long time - no problems were.

Let's make Transmission the best one again.

comment:12 Changed 12 years ago by charles

  • Summary changed from Bug transmission-daemon with unregistered torrent to high cpu load when adding unregistered torrents

Could either or both of you please install the transmission-debug or transmission-debuginfo packages and re-run the sampling described in comments 6 and 8?

comment:13 Changed 12 years ago by charles

  • Keywords needinfo worksforme added

comment:14 Changed 12 years ago by AVI

Where can I find these packages?

comment:15 Changed 12 years ago by AVI

I installed a package transmission-dbg:

Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb7a176d0 (LWP 11892)]
0xb7fb2410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 3 (Thread 0xb7215b90 (LWP 11896)):
#0  0xb7fb2410 in __kernel_vsyscall ()
#1  0xb7d1bcb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d561dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x08066685 in dht_bootstrap (closure=0x80dfbf0) at tr-dht.c:286
#4  0xb7ddb4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d5ce5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb7a16b90 (LWP 11895)):
#0  0xb7cedfd7 in _IO_default_xsputn () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7ce207b in _IO_padn () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7cc502d in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7ce8c04 in vsnprintf () from /lib/tls/i686/cmov/libc.so.6
#4  0x080a3fac in evutil_vsnprintf (buf=0x9f0ddffd "\\u0", buflen=125927435,
    format=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at evutil.c:241
#5  0x080a3bbb in evbuffer_add_vprintf (buf=0x9f0ddffd,
    fmt=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at buffer.c:158
#6  0x080a3c62 in evbuffer_add_printf (buf=0x8a08b70, fmt=0x80aa10f "\\u%04x")
    at buffer.c:184
#7  0x0804e300 in jsonStringFunc (val=0x8841fd8, vdata=0xb7a16004)
    at bencode.c:1345
#8  0x0804cd42 in bencWalk (top=<value optimized out>, walkFuncs=0x80aa20c,
    user_data=0xb7a16004) at bencode.c:1039
#9  0x0804ce26 in tr_bencToBuf (top=0xb7a16054, mode=<value optimized out>,
    buf=0x8a08b70) at bencode.c:1512
#10 0x08093b42 in request_exec (session=0x80c2530, request=0xb7a160c0,
    callback=0x80860e0 <rpc_response_func>, callback_user_data=0x85c6e58)
    at rpcimpl.c:1364
#11 0x08093d7b in tr_rpc_request_exec_json (session=0x80c2530,
    request_json=0x859a918, request_len=404,
    callback=0x80860e0 <rpc_response_func>, callback_user_data=0x85c6e58)
    at rpcimpl.c:1401
#12 0x08086a62 in handle_request (req=0x871b4a0, arg=0x80c8eb0)
    at rpc-server.c:531
#13 0x080a6e87 in evhttp_connection_done (evcon=0x852d8b0) at http.c:763
#14 0x080a6fa9 in evhttp_read_body (evcon=0x852d8b0, req=0x871b4a0)
    at http.c:893
#15 0x080a7263 in evhttp_get_body (evcon=0x852d8b0, req=0x871b4a0)
    at http.c:1591
#16 0x080a30c4 in event_base_loop (base=0x80c3660, flags=0) at event.c:392
#17 0x080a33ea in event_loop (flags=0) at event.c:468
#18 0x080a3402 in event_dispatch () at event.c:406
#19 0x08066c7d in libeventThreadFunc (veh=0x80c21c8) at trevent.c:239
#20 0xb7ddb4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#21 0xb7d5ce5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb7a176d0 (LWP 11892)):
#0  0xb7fb2410 in __kernel_vsyscall ()
#1  0xb7d1bcb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d561dc in usleep () from /lib/tls/i686/cmov/libc.so.6
---Type <return> to continue, or q <return> to quit---
#3  0x0804ba8b in main (argc=Cannot access memory at address 0x0
) at daemon.c:347
(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.
0xb7fb2410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 3 (Thread 0xb7215b90 (LWP 11896)):
#0  0xb7fb2410 in __kernel_vsyscall ()
#1  0xb7d1bcb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d561dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x08066685 in dht_bootstrap (closure=0x80dfbf0) at tr-dht.c:286
#4  0xb7ddb4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d5ce5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb7a16b90 (LWP 11895)):
#0  0xb7cc4230 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7ce8c04 in vsnprintf () from /lib/tls/i686/cmov/libc.so.6
#2  0x080a3fac in evutil_vsnprintf (buf=0xa107f33f "\\u0000", buflen=92761289,
    format=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at evutil.c:241
#3  0x080a3bbb in evbuffer_add_vprintf (buf=0xa107f33f,
    fmt=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at buffer.c:158
#4  0x080a3c62 in evbuffer_add_printf (buf=0x8a08b70, fmt=0x80aa10f "\\u%04x")
    at buffer.c:184
#5  0x0804e300 in jsonStringFunc (val=0x8841fd8, vdata=0xb7a16004)
    at bencode.c:1345
#6  0x0804cd42 in bencWalk (top=<value optimized out>, walkFuncs=0x80aa20c,
    user_data=0xb7a16004) at bencode.c:1039
#7  0x0804ce26 in tr_bencToBuf (top=0xb7a16054, mode=<value optimized out>,
    buf=0x8a08b70) at bencode.c:1512
#8  0x08093b42 in request_exec (session=0x80c2530, request=0xb7a160c0,
    callback=0x80860e0 <rpc_response_func>, callback_user_data=0x85c6e58)
    at rpcimpl.c:1364
#9  0x08093d7b in tr_rpc_request_exec_json (session=0x80c2530,
    request_json=0x859a918, request_len=404,
    callback=0x80860e0 <rpc_response_func>, callback_user_data=0x85c6e58)
    at rpcimpl.c:1401
#10 0x08086a62 in handle_request (req=0x871b4a0, arg=0x80c8eb0)
    at rpc-server.c:531
#11 0x080a6e87 in evhttp_connection_done (evcon=0x852d8b0) at http.c:763
#12 0x080a6fa9 in evhttp_read_body (evcon=0x852d8b0, req=0x871b4a0)
    at http.c:893
#13 0x080a7263 in evhttp_get_body (evcon=0x852d8b0, req=0x871b4a0)
    at http.c:1591
#14 0x080a30c4 in event_base_loop (base=0x80c3660, flags=0) at event.c:392
#15 0x080a33ea in event_loop (flags=0) at event.c:468
#16 0x080a3402 in event_dispatch () at event.c:406
#17 0x08066c7d in libeventThreadFunc (veh=0x80c21c8) at trevent.c:239
#18 0xb7ddb4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#19 0xb7d5ce5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb7a176d0 (LWP 11892)):
#0  0xb7fb2410 in __kernel_vsyscall ()
#1  0xb7d1bcb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d561dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x0804ba8b in main (argc=Cannot access memory at address 0x0
) at daemon.c:347
(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.
0xb7fb2410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 3 (Thread 0xb7215b90 (LWP 11896)):
#0  0xb7fb2410 in __kernel_vsyscall ()
#1  0xb7d1bcb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d561dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x08066685 in dht_bootstrap (closure=0x80dfbf0) at tr-dht.c:286
#4  0xb7ddb4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d5ce5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb7a16b90 (LWP 11895)):
#0  0xb7cc47cf in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7ce8c04 in vsnprintf () from /lib/tls/i686/cmov/libc.so.6
#2  0x080a3fac in evutil_vsnprintf (buf=0xa208bd6d "\\u0000", buflen=75932315,
    format=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at evutil.c:241
#3  0x080a3bbb in evbuffer_add_vprintf (buf=0xa208bd6d,
    fmt=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at buffer.c:158
#4  0x080a3c62 in evbuffer_add_printf (buf=0x8a08b70, fmt=0x80aa10f "\\u%04x")
    at buffer.c:184
#5  0x0804e300 in jsonStringFunc (val=0x8841fd8, vdata=0xb7a16004)
    at bencode.c:1345
#6  0x0804cd42 in bencWalk (top=<value optimized out>, walkFuncs=0x80aa20c,
    user_data=0xb7a16004) at bencode.c:1039
#7  0x0804ce26 in tr_bencToBuf (top=0xb7a16054, mode=<value optimized out>,
    buf=0x8a08b70) at bencode.c:1512
#8  0x08093b42 in request_exec (session=0x80c2530, request=0xb7a160c0,
    callback=0x80860e0 <rpc_response_func>, callback_user_data=0x85c6e58)
    at rpcimpl.c:1364
#9  0x08093d7b in tr_rpc_request_exec_json (session=0x80c2530,
    request_json=0x859a918, request_len=404,
    callback=0x80860e0 <rpc_response_func>, callback_user_data=0x85c6e58)
    at rpcimpl.c:1401
#10 0x08086a62 in handle_request (req=0x871b4a0, arg=0x80c8eb0)
    at rpc-server.c:531
#11 0x080a6e87 in evhttp_connection_done (evcon=0x852d8b0) at http.c:763
#12 0x080a6fa9 in evhttp_read_body (evcon=0x852d8b0, req=0x871b4a0)
    at http.c:893
#13 0x080a7263 in evhttp_get_body (evcon=0x852d8b0, req=0x871b4a0)
    at http.c:1591
#14 0x080a30c4 in event_base_loop (base=0x80c3660, flags=0) at event.c:392
#15 0x080a33ea in event_loop (flags=0) at event.c:468
#16 0x080a3402 in event_dispatch () at event.c:406
#17 0x08066c7d in libeventThreadFunc (veh=0x80c21c8) at trevent.c:239
#18 0xb7ddb4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#19 0xb7d5ce5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb7a176d0 (LWP 11892)):
#0  0xb7fb2410 in __kernel_vsyscall ()
#1  0xb7d1bcb6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d561dc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0x0804ba8b in main (argc=Cannot access memory at address 0x0
) at daemon.c:347
(gdb)

enough?

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

AVI: yes, very helpful.

If I were to make a test patch for this, would you have a means of testing it by either installing a nightly build from https://launchpad.net/~transmissionbt-nightly/+archive/ppa or by building Transmission from source code?

comment:17 Changed 12 years ago by charles

It looks like libtransmission is getting hung up in encoding a string that's not UTF-8 clean:

#0  0xb7cedfd7 in _IO_default_xsputn () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7ce207b in _IO_padn () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7cc502d in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7ce8c04 in vsnprintf () from /lib/tls/i686/cmov/libc.so.6
#4  0x080a3fac in evutil_vsnprintf (buf=0x9f0ddffd "\\u0", buflen=125927435,
    format=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at evutil.c:241
#5  0x080a3bbb in evbuffer_add_vprintf (buf=0x9f0ddffd,
    fmt=0x80aa10f "\\u%04x", ap=0xb7a15f78 "") at buffer.c:158
#6  0x080a3c62 in evbuffer_add_printf (buf=0x8a08b70, fmt=0x80aa10f "\\u%04x")
    at buffer.c:184
#7  0x0804e300 in jsonStringFunc (val=0x8841fd8, vdata=0xb7a16004)
    at bencode.c:1345

shows up in all three samples, and that's the part of the code that handles converting other charsets to utf-8.

comment:18 in reply to: ↑ 16 Changed 12 years ago by ais77

If I were to make a test patch for this, would you have a means of testing it

With pleasure. Just let know here when it will be done.

comment:19 Changed 12 years ago by charles

comment:20 Changed 12 years ago by charles

  • Keywords needinfo worksforme removed

comment:21 Changed 12 years ago by ais77

Heh, I'm not so cool in coding to apply such kind of patch... Could you provide Debian/Ubuntu? build or complete source code with compilation instructions? And I'll do my best)

comment:22 Changed 12 years ago by charles

The complete source is available in the nightly tarball at http://build.transmissionbt.com/job/trunk-linux-inc/

$ tar xfj transmission-svn9xxx.tar.bz2
$ cd transmission-1.74+
$ ./configure
$ make 
$ ./gtk/transmission

You may need to install some prerequisite packages to build from source. This is secondhand knowledge, but this can reportedly be done by running "sudo apt-get build-dep transmission".

comment:23 Changed 12 years ago by charles

ah, excuse me, you said you're using the daemon. that would be "./daemon/transmission-daemon" instead of "./gtk/transmission"... :)

comment:24 Changed 12 years ago by ais77

On ./configure step I've got an error:

checking for pkg-config... no
checking for OPENSSL... checking for OpenSSL... configure: error: Cannot locate ssl

Doulechecked if OpenSLL is installed - yes, aptitude reports that I have version 0.9.8g-10 installed in the system, no updates available. What could be wrong?

BTW, I see that Transmission 1.74 is available in Ubuntu repos - I will try to upgrade from 1.73 and will post the report here

comment:25 Changed 12 years ago by ais77

  • Resolution set to fixed
  • Status changed from new to closed
  • Version changed from 1.73 to 1.74

You know, everything seems to be ok wuth 1.74.. Ft least - for 10 minutes after start with all old .torrent files (in wich are some buggy ones, causing CPU overloading in the past) - htop shows not more than 25% of CPU load (about 10% is average). It's normal, I guess - I have a lot of HD videos there (high GIGs)), so Transmission is verifying them at the moment, hard work.

Thank you for your help and this really great software! Keep up!

Changed 12 years ago by AVI

comment:26 Changed 12 years ago by AVI

In assemblage transmission-svn9032 demon lag has stopped. Now in the web interface there is such warning: http://trac.transmissionbt.com/attachment/ticket/2326/n1.png

comment:27 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.75

comment:28 Changed 12 years ago by charles

  • Component changed from Daemon to libtransmission

comment:29 Changed 12 years ago by charles

  • Keywords backport-1.5x added

marking r9032 as a backport-1.5x candidate

Note: See TracTickets for help on using tickets.