GNOME Bugzilla – Bug 747131
GParted windows unresponsive while resizing FAT32
Last modified: 2015-04-01 10:30:41 UTC
Created attachment 300699 [details] gparted-applying-pending-operations-gray-screen.png Version: 0.19.0-2 - Started a repartition - After 10 minutes screenlock starts (slock) - After unlocking, all gparted windows are gray The same problem is described by another user here, http://gparted-forum.surf4.info/viewtopic.php?id=16863 quote: === The "Applying pending operations" screen is completely grey along with the main "GParted" window. This happened after an hour, up until then the progress meter was displaying correctly. I had left the machine to do its thing, the screen went to sleep during this time. Its when I woke the screen backup that it was greyed out. === iotop showed that gpartedbin was still running and using 90% IO. pstree showed: gparted---gpartedbin---{gmain} Image of the windows is attached. The windows did come back after all the parted operations were completed, so this is a "window redraw not being handled after screen lock" issue rather than a crash/hang issue.
Hi Chris, I just tried this on my CentOS 6 desktop with GParted 0.22.0 and it worked perfectly. After unlocking my desktop the UI was continuing to update the progress of the 200 GiB partition copy I was performing as a test. What distribution, flavour and version are you running? Thanks, Mike
Debian Jessie XFCE desktop gparted 0.19.0-2 Disk was an external USB 2TB drive I have a reproducible test case: - Create a FAT32 partition and cp some directories to it - In gparted expand it to the right and apply - fsck.fat will run - gpartedbin will then take over - the gui will freeze - run `slock` and log back in - bug: the gui is gray - when operations complete the gui comes back The original report was similarly caused by a long operation to reduce the size of a FAT32 partition. I see some notes in the changelog about the updates to the progress bar being asynchronous. Do the FAT32 resize operations send any progress updates? The only other unusual thing is that systemd-udevd seemed to be utilising IO at the same time as gpartedbin: 2676 be/4 root 28.93 M/s 19.40 M/s 0.00 % 90.20 % gpartedbin 2797 be/4 root 950.94 K/s 0.00 B/s 0.00 % 83.21 % systemd-udevd 2795 be/4 root 1682.43 K/s 0.00 B/s 0.00 % 73.12 % systemd-udevd 2796 be/4 root 2.64 M/s 0.00 B/s 0.00 % 68.88 % systemd-udevd Don't know if that is related to the problem but it seems to stop as soon as gparted finishes. I took a screenshot of the hung GUI (with progess bar, not gray) which also shows iotop with the systemd-udevd activity. In this state the gui is hung and will go grey when slock is run.
Created attachment 300721 [details] gparted-hung-progress-bar.png
The attached image shows systemd-udevd reads of about 13MB/sec while gparted is active, perhaps it is an unrelated issue but it seems odd.
Hi Chris, With the extra information you have provided I can identify this as a duplicate of an existing bug. Bug 737022 - UI hangs while running libparted operations such as FAT16/FAT32 resizing https://bugzilla.gnome.org/show_bug.cgi?id=737022 Unfortunately too much threading was removed in GParted 0.15.0 resulting in all libparted operations being performed in the main UI thread. Specifically the whole of the resize a FAT32 file system is a blocking call into libparted and GParted UI is unresponsive for as long as it takes to resize the file system. Udating summary from: GParted windows gray after screenlock while "Applying pending operations" to: GParted windows unresponsive while resizing FAT32 Closing this bug as a duplicate of 737022. Thanks, Mike *** This bug has been marked as a duplicate of bug 737022 ***
> all libparted operations being performed in the main UI thread I have previously wondered why GTK does not use an Android-style GUI responsivity timeout so that this kind of problem is caught early in development. I just opened bug #747166 to request it.