100% cpu, probably infinit loop in Cache::flushOldest

[tsukasagenesis]

What is the issue?

It seems we found a bug in Cache::flushOldest() where it seems to infinite loop, and the coup usage stuck at 100%, after reboot it seems fine

See the FlameGraph when it append, you can clearly see: Cache::flushOldest (182,479,566,503 samples, 93.94%)

See the perf bellow if needed.

perf.data.zip

It could be due to this error if related:

[2023-02-17 12:28:50.671] ERR retracted_filename': File name too long (36) (/var/www/transmission/4.00/libtransmission/inout.cc:143)
[2023-02-17 12:28:50.671] ERR open-files.cc:183 Couldn't open '/retracted_filename': File name too long (36) (/var/www/transmission/4.00/libtransmission/open-files.cc:183)
[2023-02-17 12:28:50.671] ERR retracted_filename': File name too long (36) (/var/www/transmission/4.00/libtransmission/inout.cc:143)
[2023-02-17 12:28:50.671] ERR open-files.cc:183 Couldn't open '/retracted_filename': File name too long (36) (/var/www/transmission/4.00/libtransmission/open-files.cc:183)
[2023-02-17 12:28:50.671] ERR retracted_filename': File name too long (36) (/var/www/transmission/4.00/libtransmission/inout.cc:143)
[2023-02-17 12:28:50.671] ERR open-files.cc:183 Couldn't open '/retracted_filename': File name too long (36) (/var/www/transmission/4.00/libtransmission/open-files.cc:183)
[2023-02-17 12:28:50.671] ERR open-files.cc:183 Too many messages like this! I won't log this message anymore this session. (/var/www/transmission/4.00/libtransmission/open-files.cc:183)

The file seems to have Chinese character, possibly UTF-16 and exceeded the 255 limit on filesystem, maybe truncate the filename ?

Which application of Transmission?

transmission-daemon

Which version of Transmission?

4.00

[ckerr]

Hi @tsukasagenesis thanks for reporting this.

Would you be able to run transmission in a debugger and get a backtrace from where it starts looping?

[ckerr]

Also if it's a public torrent, could you mail me a copy to ${firstname}@${firstname}${lastname}?

[tsukasagenesis]

hi @ckerr

I send you the email with some magnets with this issue. I will try with a debugger but i'm scrarred it will be too much data.

[tsukasagenesis]

My guess the issue could be that the torrent was generated on windows in exfat or ntfs where the filename is limited to 255 but in utf-16

https://www.baeldung.com/linux/bash-filename-limit

for the tested torrent with issue, the filename size is 89 in mb_strlen and 261 en strlen ... The "fix" could be cut the filename before extention or just reject the magnet if it doesn't fit on the filesystem.

[ckerr]

I don't understand why that would cause the system CPU to spike though or cause an infinite loop.

When I test out a torrent that has a filename that's too long it just gives me a "filename too long" error and pauses the torrent; the CPU doesn't go crazy :dizzy:

[ckerr]

@tsukasagenesis can you give me any more clues on how to make the CPU spike?

Does it spike for a short period of time, or does it just lock up forever and never return?

[tsukasagenesis]

does it just lock up forever and never return, cpu stay at 100% until reboot

[ckerr]

OK so run it in a debugger and when cpu goes to 100% get a backtrace

$ gdb transmsision-daemon
(gdb) handle SIGPIPE nostop noprint pass
(gdb) r -f
... wait for CPU to spike and then ctrl-c
(gdb) thread apply all bt

[ckerr]

I will try with a debugger but i'm scrarred it will be too much data.

I don't understand this comment? Attaching a backtrace to this ticket will not be too much data.

[ckerr]

@tsukasagenesis any progress on this?

[tsukasagenesis]

hello,

sorry was in holiday

the thing is I have a script who handle the spawn of many transmission in same time (and reboot if error). Do you have a way to lunch gdb with your setting and transmission in one line and a way to get the backtrace of running process ?

the problem is still there; it seems to be also a memory leak:

Best regards

[ckerr]

This is preferably done with a debug build. If the debugging symbols have been stripped out it's not going to be as useful:

gdb /path/to-transmission-daemon
(gdb) handle SIGPIPE noprint nostop pass
(gdb) r -f -g /home/trans65
# ... wait for it to freeze ...
# hit ctrl-c to get the`(gdb)` prompt again
(gdb) thread apply all bt

[ckerr]

Still waiting for debugger info @tsukasagenesis

[ckerr]

Closing due to lack of response + lack of actionable info.

If this is still an issue, please open a new ticket with updated information. Thank you!