Bleachbit unresponsive on Arch linux

[prorounak2005]

Describe the bug Bleachbit gets unresponsive when I do my system clean with all the checkboxes ticked on. Here is the screenshot ( https://0x0.st/om1d.png , https://0x0.st/om1n.png , http://0x0.st/om15.png)

To Reproduce Steps to reproduce the behavior:

1. Open bleachbit
2. Click on all the checkboxes
3. Wait for 3 to 4 minutes
4. Try to move the application with ur mouse.
5. It becomes unresponsive and then after waiting for like 20 minutes I have to kill the bleachbit process with a task manager like "htop" , "top" or "bashtop"

The error happens (sometimes/every time). Everytime I open bleachbit and do a system clean

Expected behavior I expected the application will not become unresponsive.

Screenshots N/A

Desktop (please complete the following information):

• OS: [e.g., Windows 10, Ubuntu 20.04] Arch Linux x86_64 ; 5.17.5-zen1-1-zen
• BleachBit version [e.g., 4.2.0] 4.4.2

Additional context I downloaded bleachbit from from pacman package manager in arch - https://archlinux.org/packages/community/any/bleachbit/ sudo pacman -S bleachbit

[abitrolly]

What does the log show?

[ghost]

What does the log show?

Can you tell me in which directory bleachbit dumps the log so that I can share it with you ?

[abitrolly]

@prorounak2005 try to run it with --debug-log=bleachbit.log

[ghost]

@abitrolly Here is the link to the raw paste - http://0x0.st/omfL.txt When I ran bleachbit as sudo - https://paste.rs/l0I

[ghost]

@abitrolly Ok so I did a system clean with bleachbit today and here is the full log - https://0x0.st/omxh.txt Whever I do a system clean my bleachbit becomes unresponsive like I said , I cannot move the application and it gets stuck.

[abitrolly]

So it took 40 minutes, but in the end cleanup was completed successfully? And during that time the BleachBit was frozen, but got unstuck in the end?

[ghost]

So it took 40 minutes, but in the end cleanup was completed successfully? And during that time the BleachBit was frozen, but got unstuck in the end?

Yup absolutely. This is annoying and this needs to be fixed because system cleaner usually take 10 to 15 minutes but it is taking almost 45 minutes. :(

[abitrolly]

Should be some blocking operation in the main thread. Timestamps could help to detect it. Not sure if --debug option enables timestamps, but that's quite easy to add. There is also a lot of exceptions in the log, and it may happen that it is not one operation that blocks the GUI, but 19046 exception handler calls that freeze BleachBit.

[ghost]

@abitrolly I never cleaned my system with "sudo bleachbit" I never gave it the admin priviledge so I think thats why it is taking a lot of time to clean the trash. Should I run bleachbit as sudo and then clean the system with it ?

[abitrolly]

It is not a good idea to run BleachBit with sudo unless you want to clean some root files. I am not sure what is the best decision here. Probably BleachBit should not propose to clean up files it can not delete. @az0 wdyt?

[ghost]

I use stacer it works perfectly It asks for my password I give it my password and it cleans everything within 2 seconds. I think I am going to stick with it for now.

[az0]

Please uncheck System - Free Disk Space. Does this help? If not, uncheck Deep Scan too. Did that help? Let me know.

I am guessing it's stuck during Free Disk Space.This is not uncommon because sometimes the writing or deleting steps take a while to complete, and the GUI runs in the same thread, so the GUI becomes unresponsive.

In normal use, deleting a single file (the most common scenario) is fast, so the GUI can run too.

The solution is to make the "worker" always run in a separate thread, so the GUI never freezes.

[eleius]

I use BleachBit on all of my ArchLinux machines and never got this issue, so I guess OP must have the disk cleaning checkbox enabled.

[ghost]

Please uncheck System - Free Disk Space. Does this help? If not, uncheck Deep Scan too. Did that help? Let me know.

I am guessing it's stuck during Free Disk Space.This is not uncommon because sometimes the writing or deleting steps take a while to complete, and the GUI runs in the same thread, so the GUI becomes unresponsive.

In normal use, deleting a single file (the most common scenario) is fast, so the GUI can run too.

The solution is to make the "worker" always run in a separate thread, so the GUI never freezes.

I use BleachBit on all of my ArchLinux machines and never got this issue, so I guess OP must have the disk cleaning checkbox enabled.

Umm yeah it was the disk cleaning checkbox because sometimes I need to clean my disk too. I can do it through the cli but it is time taking. So is it possible to make a seperate thread for the worker. It would mean a lot to me. :)