search

linuxmint / bulky

Bulk Renamer
75 stars 16 forks source link

Crashing if large number of files added (BadAlloc) #31

Open State-Of-Joshing-Gentle-Peevishness opened 2 years ago

State-Of-Joshing-Gentle-Peevishness commented 2 years ago

Linux Mint 20.2 Cinnamon 5.0.7 on 5.11.0-41-generic. Bulky crashes for me instantly if more than 1424 files are selected in nemo and right-clicked for rename or when more than 1424 files are selected from bulky itself:

(bulky.py:152074): Gdk-ERROR **: 10:51:32.027: The program 'bulky.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 32734 error_code 11 request_code 130 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)

When I load 1424 exactly, bulky works as intended. When adding just one more file bulky crashes. My memory usage is never even close to maxing out (15GB), but maybe it's my system anyway?

In anyway there should be a warning message if too many files to handle are tried to be loaded.

State-Of-Joshing-Gentle-Peevishness commented 2 years ago

Linux Mint 20.3 Cinnamon 5.2.7 on 5.13.0-27-generic. Bulky 2.1 (previous crashing occurred in 1.8) Bulky crashes now in a similar way when ~8000 files are selected added. 7000 worked, but I did not try to find out the exact number this time. When ~7000 are added, bulky gets unresponsive and is very sluggish. Error on crashing:

(bulky.py:28593): Gdk-ERROR **: 12:18:06.882: The program 'bulky.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 24193 error_code 11 request_code 130 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)

I still believe that bulky shouldn't just crash, but give a warning message that explains what is going on (the above is console-output on crashing).

Here is the error on crashing of journalctl | grep bulky

Jan 19 12:50:03 kernel: traps: bulky[28974] trap int3 ip:7f409bf48295 sp:7ffef82bdf50 error:0 in libglib-2.0.so.0.6400.6[7f409bf0c000+84000] Jan 19 12:50:06 systemd-coredump[29634]: Process 28974 (bulky) of user 1000 dumped core.

In the meanwhile, if someone runs into the same problems: I tried the file-renamers Krename, CoreRenamer and Szyszka for my purposes (renaming large amount (~10.000) of picture files). Szyszka is hands down the best, while the two others also had problems with the file-amount and crashed or were unresponsive for several minutes. Szyszka is super fast in both loading and renaming (basically instantly). I was seriously impressed.