starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Application log window memory usage is unlimited #7487

New issue

Closed

opened 2026-02-21 19:00:00 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-21 19:00:00 -05:00

Owner

Originally created by @zeule on GitHub (Jul 6, 2018).

qBittorrent version and Operating System

master, Linux/amd64

If on linux, libtorrent and Qt version

master, 5.11.1

What is the problem

There is no limit for the log messages, therefore qBt can eat unlimited amount of memory. Found it with 31GiB used after a few weeks (log full of network change messages).

What is the expected behavior

Unimportant messages like "qBittorrent is successfully listening on interface %1 port: %2/%3" are not kept forever.

Steps to reproduce

Leave qBt working in a changing environment.

Originally created by @zeule on GitHub (Jul 6, 2018). ### qBittorrent version and Operating System master, Linux/amd64 ### If on linux, libtorrent and Qt version master, 5.11.1 ### What is the problem There is no limit for the log messages, therefore qBt can eat unlimited amount of memory. Found it with 31GiB used after a few weeks (log full of network change messages). ### What is the expected behavior Unimportant messages like "qBittorrent is successfully listening on interface %1 port: %2/%3" are not kept forever. ### Steps to reproduce Leave qBt working in a changing environment.

deekerman

2026-02-21 19:00:00 -05:00

closed this issue
added the
GUI
label

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@glassez commented on GitHub (Jul 6, 2018):

Unimportant messages like "qBittorrent is successfully listening on interface %1 port: %2/%3" are not kept forever.

Why not just limit it and drop oldest messages?
Can't it become too long having only "important" messages?

@glassez commented on GitHub (Jul 6, 2018): >Unimportant messages like "qBittorrent is successfully listening on interface %1 port: %2/%3" are not kept forever. Why not just limit it and drop oldest messages? Can't it become too long having only "important" messages?

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@zeule commented on GitHub (Jul 6, 2018):

I would submit a PR if I knew the answers, but I can't decide.

@zeule commented on GitHub (Jul 6, 2018): I would submit a PR if I knew the answers, but I can't decide.

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@glassez commented on GitHub (Jul 6, 2018):

@Chocobo1, @thalieht, @sledgehammer999, what do you say?

@glassez commented on GitHub (Jul 6, 2018): @Chocobo1, @thalieht, @sledgehammer999, what do you say?

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Jul 6, 2018):

@zeule older messages could be saved to the log instead of entirely discarded, since qbittorrent already has some basic logrotating functionality built-in.

Also, I assume this problem is only present on the GUI version?

@FranciscoPombal commented on GitHub (Jul 6, 2018): @zeule older messages could be saved to the log instead of entirely discarded, since qbittorrent already has some basic logrotating functionality built-in. Also, I assume this problem is only present on the GUI version?

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@zeule commented on GitHub (Jul 6, 2018):

All the messages are copied to the log file already, AFAIK.

@zeule commented on GitHub (Jul 6, 2018): All the messages are copied to the log file already, AFAIK.

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@ghost commented on GitHub (Jul 7, 2018):

@Chocobo1, @thalieht, @sledgehammer999, @FranciscoPombal and @zeule.
In my opinion each day should have a separate file (ex: qbittorrent-06_07_2018, qbittorrent-07_07_2018) and about the option to delete older logs (changing the default value from 1 month to 1 week) could be like this example:
We have the logs of one week(qbittorrent-01_07_2018 to 07_07_2018) and tomorrow the log of the day 01_07 should be automatically discarded because it's a new week.
Something like that.

@ghost commented on GitHub (Jul 7, 2018): @Chocobo1, @thalieht, @sledgehammer999, @FranciscoPombal and @zeule. In my opinion each day should have a separate file (ex: qbittorrent-06_07_2018, qbittorrent-07_07_2018) and about the option to delete older logs (changing the default value from 1 month to 1 week) could be like this example: We have the logs of one week(qbittorrent-01_07_2018 to 07_07_2018) and tomorrow the log of the day 01_07 should be automatically discarded because it's a new week. Something like that.

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@Piccirello commented on GitHub (Aug 14, 2019):

I think we should limit the log lines to a high value (is 10000 too high?). That way it's not likely to be a burden but also not unbounded.

@Piccirello commented on GitHub (Aug 14, 2019): I think we should limit the log lines to a high value (is 10000 too high?). That way it's not likely to be a burden but also not unbounded.

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Aug 15, 2019):

IMO, since those are logged to a file then a limit should exist in the widget view. Now, if the user has disabled logging to file, an bigger limit should exist. (or maybe filter based on logline importance).

@sledgehammer999 commented on GitHub (Aug 15, 2019): IMO, since those are logged to a file then a limit should exist in the widget view. Now, if the user has disabled logging to file, an bigger limit should exist. (or maybe filter based on logline importance).

deekerman commented

2026-02-21 19:00:06 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Mar 18, 2025):

This ticket has been closed.

Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.

If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.
A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Thank you for your contribution(s).

@xavier2k6 commented on GitHub (Mar 18, 2025): ### This ticket has been closed. ____ **Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.** ____ * If you experience the reported problem or similar in the **latest** version, please open a new issue report with the requested information in the issue template. * Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar. * Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression. * A new issue report with relevant updated data gathered from the **latest** version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression. * Thank you for your contribution(s).

deekerman referenced this issue

2026-02-22 00:54:56 -05:00

I/O error on skipped files #14302