After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 467925 - gparted: add progress bar during operation
gparted: add progress bar during operation
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: application
GIT HEAD
Other All
: Normal enhancement
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
: 572783 589713 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-08-18 10:32 UTC by Alan Baghumian
Modified: 2016-01-18 17:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-Display-progress-during-resize-467925.patch (5.93 KB, patch)
2013-04-22 23:08 UTC, Phillip Susi
none Details | Review
0002-Display-progress-for-mke2fs-467925.patch (2.05 KB, patch)
2013-04-22 23:09 UTC, Phillip Susi
none Details | Review
0003-Display-progress-for-e2fsck-467925.patch (2.49 KB, patch)
2013-04-22 23:09 UTC, Phillip Susi
none Details | Review
GParted renames (v1) (8.70 KB, patch)
2013-05-02 21:08 UTC, Mike Fleetwood
none Details | Review
GParted renames (v2) (8.74 KB, patch)
2013-05-06 13:16 UTC, Mike Fleetwood
none Details | Review
Progress bars (v2) (11.06 KB, patch)
2013-05-11 11:25 UTC, Mike Fleetwood
none Details | Review
0001-Display-progress-during-resize-467925.patch (5.98 KB, patch)
2013-10-29 23:54 UTC, Phillip Susi
none Details | Review
0002-Display-progress-for-mke2fs-467925.patch (2.05 KB, patch)
2013-10-29 23:55 UTC, Phillip Susi
none Details | Review
0003-Display-progress-for-e2fsck-467925.patch (1.85 KB, patch)
2013-10-29 23:55 UTC, Phillip Susi
none Details | Review
details file when cancelling grow operation (0.17 + 3patches) (3.86 KB, text/html)
2014-01-13 16:08 UTC, Laurent de Trogoff
  Details
cancelled operation, but successfully run (149.38 KB, image/jpeg)
2014-01-14 08:04 UTC, Laurent de Trogoff
  Details
0.17.0 grow ext2 operation cancel-force-cancel-cancel-operation at end of grow XXX line (5.02 KB, text/html)
2014-01-14 17:23 UTC, Curtis Gedak
  Details
cancelled operation, but successfully run (56.73 KB, image/jpeg)
2014-01-14 18:28 UTC, Laurent de Trogoff
  Details
gparted_details : cancelled operation, but successfully run (3.37 KB, text/html)
2014-01-14 18:30 UTC, Laurent de Trogoff
  Details
Progress bars (v4) (10.02 KB, patch)
2014-01-21 18:32 UTC, Curtis Gedak
none Details | Review
Progress bars (v5) (10.24 KB, patch)
2014-01-23 23:26 UTC, Mike Fleetwood
none Details | Review
0001-Fix-cancel-path.patch (2.85 KB, patch)
2014-02-25 16:42 UTC, Phillip Susi
none Details | Review
Progress bars (v6) (12.81 KB, patch)
2014-03-25 17:36 UTC, Curtis Gedak
none Details | Review
Progress bars (v7) (9.95 KB, patch)
2014-03-25 17:40 UTC, Curtis Gedak
none Details | Review
0001-Refactor-OperationDetail-to-not-store-complex-object.patch (7.02 KB, patch)
2014-04-02 02:06 UTC, Phillip Susi
none Details | Review
Progress bars (v8) (10.15 KB, patch)
2015-12-02 12:32 UTC, Mike Fleetwood
none Details | Review
0001-Display-progress-during-resize-467925.patch (5.76 KB, patch)
2015-12-12 21:27 UTC, Phillip Susi
none Details | Review
0002-Display-progress-for-mke2fs-467925.patch (2.27 KB, patch)
2015-12-12 21:28 UTC, Phillip Susi
none Details | Review
0003-Display-progress-for-e2fsck-467925.patch (2.10 KB, patch)
2015-12-12 21:28 UTC, Phillip Susi
none Details | Review
Progress bars (v10) (10.51 KB, patch)
2015-12-14 11:07 UTC, Mike Fleetwood
none Details | Review

Description Alan Baghumian 2007-08-18 10:32:10 UTC
Checking/resizing can be very long operation. It would be pleasant if it
is possible to see the progress of these operations.

The 'details' view only provides the command running. However, e2fsck and
resize2fs have support for progress bar. If gparted can use them, it
would be great.


The progress is correctly shown for the 'move' operation : the first bar
of the 'applying pending operation' dialog grow from 0% to 100%. The
same thing for checking and resizing would be great.

Original Debian Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432141
Comment 1 Curtis Gedak 2009-02-23 16:10:59 UTC
*** Bug 572783 has been marked as a duplicate of this bug. ***
Comment 2 Curtis Gedak 2009-10-21 21:13:17 UTC
*** Bug 589713 has been marked as a duplicate of this bug. ***
Comment 3 Johan Walles 2010-01-21 06:54:21 UTC
This is a problem for Ubuntu users as well:
https://bugs.launchpad.net/gparted/+bug/295337

"
When running partition check in GParted (Hardy) on my 1.5TB disk partition,
it takes about 3 hours to complete and all the time I can see only "0 of 1 operations completed".

It would be nice to see % number of that operation. User cannot guess if it would take minutes, hours or days.
"
Comment 4 Johan Walles 2010-01-21 08:42:57 UTC
Personally I'd be fine with just seeing stdout of the e2fsck or whatever it is that's taking so long.

Even if that wouldn't always tell me how much time is left, it at least does tell me that something is still happening.
Comment 5 Owen 2011-12-08 15:24:01 UTC
I agree that having some indication of progress is very important. Has there been any movement on this issue?

I am using the new rescue option on a 1.5TB USB HDD. I have no idea how long this will take or even if it is working at all. I'm stuck on a message stating 'Searching for file systems', with the bar bouncing back and forth for several hours now.

As Johan says, it doesn't have to be a bar, just any indication that we can be sure that work is being done.

Thanks
Comment 6 Kurt Bigler 2012-02-22 07:28:10 UTC
I'm doing a search-for-file-systems operation on a 2tb drive.  It has been running for almost 12 hours. Having never done this before I really have no idea whether it might take the rest of the week, also whether it is likely to survive sleep/wake cycles for several days in a row.  Yes, a progress indication would be "pleasant" ;)

I guess the shuttle is at least encouraging, i.e something is probably actually happening,  Gpartedbin and gpart are each using about 7% of the cpu, on the very nice on-the-desktop process list (Parted Magic), which I guess is also encouraging.

I see Owen's comment is very similar.  So for now I can only offer more encouragement.

If you have an offset available from the underlying utility you could use that to display a moving current position indicator right on the existing linear graphic representing the disk.  That might be tricky to design right (graphically) but might also be more helpful in evaluating the nature of the progress through a disk on which ostensible partitions are already visible even if not functioning or mountable.  It might in some cases give someone enough information to know when to give up.
Comment 7 ein 2012-03-15 00:24:52 UTC
I also stack without progress bar on resizing partition. Big question appears: kill it or not to kill it. :) 

Top only show ~ 100% usage by resize2fs process.

I have lucky and while reading this post everything goes fine and gparted jumps to moving data where progress bar is.

Gparted NEEDs to ADD A indication of resizing progress.
Comment 8 Phillip Susi 2013-04-22 23:08:43 UTC
Created attachment 242183 [details] [review]
0001-Display-progress-during-resize-467925.patch
Comment 9 Phillip Susi 2013-04-22 23:09:13 UTC
Created attachment 242184 [details] [review]
0002-Display-progress-for-mke2fs-467925.patch
Comment 10 Phillip Susi 2013-04-22 23:09:33 UTC
Created attachment 242185 [details] [review]
0003-Display-progress-for-e2fsck-467925.patch
Comment 11 Mike Fleetwood 2013-05-02 21:08:51 UTC
Created attachment 243098 [details] [review]
GParted renames (v1)

Hi Curtis and Phillip,

I'd like to rename a few identifiers related to capturing command output
for the purpose of improving consistency and readability and therefore
code maintainability.  I'd like these renames to be applied ahead of
Phillip's patches in this bug report if that's OK.

I've done an initial review of Phillip's patches and they look pretty
good.  Definitely better than just enabling updating command output I
did in bug #697662 "Do not hide the progress of the tools used".  Before
we close that as a duplicate though I would like Phillip's patches here
committed and then we can review if of the other pseudo type progress
information can be processed to produce progress bars too.

Thanks,
Mike

P.S. Phillip you can upload multiple git patches as a single file.  If
     you require the git command line see http://www.gparted.org/git.php
     for details.
Comment 12 Curtis Gedak 2013-05-03 15:52:39 UTC
Thank you Mike for discovering some inconsistency in the class and method names and creating a patch to bring the names more in line with the rest of GParted.

The changes in comment #11 look good to me and should help increase readability and hence maintainability of the code.

Phillip,

Do you have any further suggestions on the patch in comment #11 to improve naming consistency?

If not, then I will commit the patch in comment #11.

Following that we can look at the patches in comments 8, 9, and 10.
Comment 13 Mike Fleetwood 2013-05-06 13:16:53 UTC
Created attachment 243381 [details] [review]
GParted renames (v2)

Hi,

I've been through both sets of patches again looking at the signals and
callbacks and as a result I have my updated my patchset slightly.  The
only change from "GParted renames (v1)" is to update the naming of
callback functions in patch number 3.


After my patchset and Phillip's I would like to see the following names
used for Signals and callbacks:

PipeCapture::signal_update
--------------------------
connected in FileSystem::execute_command()
outputcapture.signal_update -> (FileSystem::)update_command_output()
                            -> (FileSystem::)update_command_progress()
errorcapture.signal_update  -> (FileSystem::)update_command_output()

update_command_progress()
    signal_progress.emit(...)

FileSystem::signal_progress
---------------------------
connected in ext2::resize()
signal_progress -> ext2::resize_progress()

connected in ext2::create()
signal_progress -> ext2::create_progress()
...


Thanks,
Mike
Comment 14 Mike Fleetwood 2013-05-06 13:28:48 UTC
For comparison without any renaming the signals and callbacks would be
called:

PipeCapture::update
-------------------
connected in FileSystem::execute_command()
outputcapture.update -> (FileSystem::)relay_update()
                     -> (FileSystem::)relay_outputupdate()
errorcapture.update  -> (FileSystem::)relay_update()

relay_outputupdate()
    outputupdated(...)

FileSystem::outputupdated
-------------------------
connected in ext2::resize()
outputupdated -> ext2::resize_update()

connected in ext2::create()
outputupdated -> ext2::mkfs_update()
Comment 15 Curtis Gedak 2013-05-07 21:39:15 UTC
Hi Mike,

I have successfully tested the patch in comment #13.  If there are no changes and I do not hear any objections in the next few days, then I will commit this patch.

After that we can proceed with the review and any updates needed for the patches in comments 8, 9, and 10.
Comment 16 Curtis Gedak 2013-05-10 16:11:12 UTC
Hi Mike and Phillip,

The class and method renames in the patch from comment #13 have been committed to the git repository for inclusion in the next release of GParted.

The relevant git commits can be viewed at the following links:

Rename class utils_execute_command_status
https://git.gnome.org/browse/gparted/commit/?id=30946cb812e2c745968773c756d715713824c8e2

Rename signals update and eof
https://git.gnome.org/browse/gparted/commit/?id=0d52cd19d7ead3aaca39caf79ecaec87866f5224

Rename function relay_update
https://git.gnome.org/browse/gparted/commit/?id=d6260e17b377a0146fc690f7689c48f80dc8b9aa


Mike, since you initiated the class and method renames, perhaps you could make any necessary updates to Phillips patches in comments 8, 9, and 10?
Comment 17 Mike Fleetwood 2013-05-11 11:25:24 UTC
Created attachment 243846 [details] [review]
Progress bars (v2)

Hi Phillip and Curtis,

Here's Phillip's patch set updated with the discussed renaming.  Also
added c.disconnect() missing from ext2::check_repair().

I'll review this over the next day or two.

Phillip,

One initial question.  On which OS and with which version of e2fsprogs
did you get ascii 0x01 and 0x02 characters being outputted by e2fsck?
I've not seen them myself on an initial check.

Thanks,
Mike
Comment 18 Mike Fleetwood 2013-05-12 09:08:40 UTC
e2fsck deliberately brackets the progress bar with control-A (ASCII 001,
Start of Header) and control-B (ASCII 002, Start of Text) when it
detects that it is not being run from a terminal so that logsave(8) can
exclude the progress bar from being written to a log file.  As GParted
doesn't run e2fsck via a pty it receives these control characters.

Refs:
Change e2fsck to bracket its progress bar output with ctrl-A and ctrl-B
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=bc34d6be65cb93a65451ad209cfea2f98b03fd22

Don't print ^A and ^B chars when e2fsck is talking directly to a tty
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=54a31a3b2e432c124aa03442f2983c4f4d4a974c

Debian Bug #204137 - fsck.ext2: "-C 0" prints junk on an xterm
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204137
Comment 19 Curtis Gedak 2013-05-13 22:35:05 UTC
The patch in comment #17 looks good to me.

Using the patch I have successfully tested resizing ntfs and ext4, and checking ext4 on the following distros:

   kubuntu  12.04
   openSUSE 11.2
   Fedora   16
   Debian    6


Mike,

   Would you be able to test on a supported version of Red Hat or CentOS?
Comment 20 Mike Fleetwood 2013-05-14 13:29:38 UTC
Initial code review comments:
(Cosmetic in nature)

1) In PipeCapture::OnReadable() change integer constants 1 & 2 to char
   constants '\x01' and '\x02' and add code comment:
	//Skip Ctrl-A and Ctrl-B chars e2fsck uses to bracket the progress bar
   Add a shortened version of comment #18 to the commit message.
   --
   This avoids mental discontinuity between OnReadable() checking for
   characters at one moment and integers at another.  It also explains
   why it's going on.

2) In ext2::check_repair_progress() and ntfs::resize_progress() rename
   local variable fact to pct/pctage/percentage.  Another mental
   discontinuity between a variable called faction but storing a
   percentage.

Moving on to realistic testing now ...
Mike
Comment 21 Mike Fleetwood 2013-05-14 20:29:25 UTC
CentOS 5.9:
* Confirmed all commits compile.
* Passed testing.


After my testing I have a question.  Do we want to give users these
progress bars?

Normally a progress bar goes from 0 to 100% percent possibly with
varying speed, but these progress bars aren't that simple to the users.
Take the single GParted operation of shrinking an ext2/3/4 file system
as an example.  The user will see the progress bar pulsing back and
forth, interspersed most of the time with at least 4 periods of it
growing from 0 to 100%.  Will the users understand this behaviour?  Will
they appreciate this behaviour and thank us or complain and want a
simple progress bar?

For example why is this style of progress bar better than the pulse bar,
when both probably required the user to look at the details to
understand what is happening?

I just want us to make a positive choice that this is good and know how
to explain it to our users before we commit it.


Thanks,
Mike
Comment 22 Curtis Gedak 2013-05-14 22:27:58 UTC
Hi Mike,

In the GNOME Human Interface Guidelines, one of the usability principles is to "keep the user informed".

I believe progress bars fall under this guideline.  The previous progress bar for these tasks would simply bounce back and forth.  This at least let the user know that the application had not froze, but provided little else.

With the code refactoring, we added more progress feedback by tracking and displaying the live output from the command details.  This certainly helps to keep users informed, but does require the user to expand the details to see what is occurring.


> Do we want to give users these progress bars?

I think this progress bar is an improvement, though I do agree that it is not as simple to understand as a single bar that progresses _once_ from left to right.


> Will the users understand this behaviour?

I believe many will understand the behaviour because GParted lists the running task near the progress bar (e.g., "check file system on ...").


> Will they appreciate this behaviour and thank us or complain and want
> a simple progress bar?

I believe the ultimate goal is to have a single progress bar.   However, I do not know how we can provide this level of simplicity.  I think that everything we've done so far helps improve feedback so is in the correct direction.


> For example why is this style of progress bar better than the pulse
> bar, when both probably required the user to look at the details to
> understand what is happening?

With these new progress bars for ntfs and ext2/3/4 resizing and ext2/3/4 file system checking, the user will see the progress bar build across the screen without needing to expand the details.  For small file systems there is almost no difference from the previous bouncing bar.  With large file systems that take a long time to process, then I think the progress bar will be preferred.

An example of multiple displays of the bar progressing from left to right occurs when we copy or move a file system.  Each stage of trying a different block size (1 MiB up to 16 MiB) grows a complete progress bar.  We have not had complaints about this to date. 

I think that most users will see this as an improvement.


Mike, is there an issue with these progress bars that you have come across in your testing?
Comment 23 Curtis Gedak 2013-05-14 22:39:22 UTC
One quote that I can find from the GNOME HIG that might suggest we should stay with the bounce left and right progress bar is as follows:

https://developer.gnome.org/hig-book/stable/principles-feedback.html.en

   It is critical that feedback be accurate and precise. If you display a
   determinate progress indicator to display the state of completion of a
   task and it is inaccurate, the user will lose faith in progress
   indicators, and they will find the environment less usable.

To make the progress bar more accurate, we would need to know how many subtasks the operation would take, and then divide the bar into sectors for each of the tasks.

For example, when growing a partition, the following steps are used:

 1.  Calibrate            fast
 2.  Check file system    slow
 3.  Grow partition       fast
 4.  check file system    slow        (this step looks redundant)
 5.  grow file system     slow

We could consider a single progress bar that consists of 5 parts for these 5 steps.  However, the growth of the bar would vary greatly from step to step.

Hmmm.... what to do?


Phillip, any thoughts?
Comment 24 Johan Walles 2013-05-16 04:49:28 UTC
(In reply to comment #23)
> For example, when growing a partition, the following steps are used:
> 
>  1.  Calibrate            fast
>  2.  Check file system    slow
>  3.  Grow partition       fast
>  4.  check file system    slow        (this step looks redundant)
>  5.  grow file system     slow
> 
> We could consider a single progress bar that consists of 5 parts for these 5
> steps.  However, the growth of the bar would vary greatly from step to step.

Not that I'm Phillip, but in this case the single progress bar should be divided into three; one part for each slow step.

During the fast steps the progress bar can just as well stand still.  Assuming the steps are actually fast, the progress bar won't pause for long anyway, and the user will better see the progress of the slow steps.

Just my €0.02.
Comment 25 Phillip Susi 2013-05-16 19:35:14 UTC
Oh boy, for some reason I wasn't on the Cc list so I've got some catching up to do.  Let's see...

The first renames look fine.  My brain just knows a character is an integer, just a small one, and has no trouble flipping back and forth, but I suppose you can change that if you like.  I'm not sure what you mean about the percentage vs fraction... they are the same thing?

On the progress bars, the problem with trying to divide it to account for the sub operations is that we can't tell how long each sub operation will take.  For instance, fsck on ext2/3 takes a while, but is almost instant on ext4, so if we divide the check/grow/check into 3 equal parts, we'd spend almost all of our time in the 33-66% range, and blast through the first and last third.

I think we just should identify the worst instances of this problem, and see if we can promote the slower sub operations to top level operations so they will each get their own bar all to themselves.  I think that should work for the check/grow/check.  As long as the vast majority of the time we spend showing one slow operation, with a few very fast ones, it's a little sub optimal, but not too bad.  Certainly much better than not showing any progress at all.
Comment 26 Mike Fleetwood 2013-05-19 11:11:32 UTC
Hi Phillip,

Initially can you submit your patch set with just the changes required
to turn on the progress bars from the e2fs and ntfs commands and have
them appear in the text details.  Leave updating of the GParted progress
bar out.  This is a useful first step we can easily commit upstream.


Afterwards we can work on a method for updating the GParted progress bar
and optionally talk to the GNOME Design Team https://live.gnome.org/Design/
for suggestions or a review.

Thanks,
Mike
Comment 27 Phillip Susi 2013-05-20 13:14:29 UTC
I don't understand.  You mean show "50% done" as text, but not visually?  That doesn't make sense to me.

Are there any other problem spots besides the check/resize/check, and the block size calculation?
Comment 28 Mike Fleetwood 2013-05-20 17:21:43 UTC
Just add the flags to the resize2fs, ntfsresize, mkfs.ext* and e2fsck
commands with the required change to OnReadable() to skip Ctrl-A and
Ctrl-B chars.  (This gives useful output visible when by expanding the
details).
Comment 29 Phillip Susi 2013-05-20 17:59:48 UTC
Oh.  I'd really rather update the progress bars since that was the whole point of this.

I think I'll take a crack at getting rid of the block size tests and moving the pre/post fscks on resize to their own top level operation and see if that takes care of everything.
Comment 30 Curtis Gedak 2013-05-21 15:56:41 UTC
Hi Phillip,

I think Mike's intention in comment #28 is that we could commit the flag changes immediately because these would help with the details pane.  The concern with the whole progress bar improvement is to get better alignment with the GNOME HIG which requires some more thought and work.

If you prefer, we could place the flag changes in:
   Bug #697662 - Do not hide the progress of the tools used
since I believe that this is what 697662 was to address.

Curtis
Comment 31 Phillip Susi 2013-05-21 16:47:01 UTC
I don't think there's a rush to get another release out in the next day or two is there?  The fixes shouldn't take long so I don't see a reason to rush a half solution.
Comment 32 Curtis Gedak 2013-05-21 16:58:58 UTC
Presently there is no rush.  We try to target a new release every two months or so.  If we discover anything that can cause a loss of data then we will work to get out a release much sooner, like we did with 0.16.1.
Comment 33 Phillip Susi 2013-05-22 23:59:57 UTC
The more I look at this, the more I think it's fine the way it is.  Having the bar *sometimes* restart is much better at "keeping the user informed" than uselessly ping ponging back and forth all the time.  Getting it perfect would be nice, but looks like it will take a lot more work than it's worth.

I still think the unneeded block size calibration in the copy operation should be removed, and maybe the automatic fscks as well?
Comment 34 Curtis Gedak 2013-05-23 16:12:27 UTC
Hi Phillip,

Regarding the code enhancements in the patch, I am 100% on board with the flag changes to permit the commands to output progress which is tracked in the details.

The area where it gets grey is not the progress bar bar itself, but the multiple progress bars that occur with a single operating.  This appears to be in contradiction with the GNOME HIG as quited in comment #23.

Having said that, GParted already contains another contradiction to the GNOME HIG with the progress bars while the optimal block size is determined.

Since we have not had users complaining about the optimal block size determination, I would be okay with committing this patch and then see how it is accepted.  We can always roll back the change in a subsequent release.


Mike,

What do you think?  Do you feel strongly one way or the other on this topic?


Phillip and Mike,

> I still think the unneeded block size calibration in the copy operation
> should be removed, and maybe the automatic fscks as well?

I agree that the block size calibration adds less value now that recent drives contain caches, often larger than the 16 MiB maximum block size used by GParted.

Regarding the automatic fscks, I believe these add value and help to ensure the integrity of data.  For example, when resizing, GParted will ensure that a file system check passes before trying to run the resize command.  If the file system check failed, then I think it is unwise to try to continue to resize the file system.
Comment 35 Curtis Gedak 2013-05-23 16:18:28 UTC
Phillip,

To enable ease of potential rollback, it would help to have the flag changes to the commands in a separate commit.
Comment 36 Mike Fleetwood 2013-05-23 18:22:02 UTC
Phillip,

Yes please to separate commits.  Makes rolling back individual changes
much easier.


Curtis,

For me the problem case is resize2fs which has 3 or 4 progress bars for
a single command.  I'll go with your decision though.  (The other
commands with a few seconds of pulsing before and after a single
progress bar taking most of the time are OKish).

The internal copy calibration falls into the OKish category in my view.
All 5 tests take < ~6 seconds and the progress bars flash past very
quickly so don't really register as such.
Comment 37 Curtis Gedak 2013-05-23 18:33:24 UTC
Often thinking on a problem for while can produce a better solution.  As such I would be in favour of committing only the command flag changes now.  We would then hold off on the progress bar changes while we let our subconscious mull over other possible solutions.
Comment 38 Curtis Gedak 2013-10-02 16:28:17 UTC
*** Bug 709276 has been marked as a duplicate of this bug. ***
Comment 39 Phillip Susi 2013-10-29 23:54:24 UTC
Created attachment 258499 [details] [review]
0001-Display-progress-during-resize-467925.patch
Comment 40 Phillip Susi 2013-10-29 23:55:01 UTC
Created attachment 258500 [details] [review]
0002-Display-progress-for-mke2fs-467925.patch
Comment 41 Phillip Susi 2013-10-29 23:55:58 UTC
Created attachment 258501 [details] [review]
0003-Display-progress-for-e2fsck-467925.patch
Comment 42 Phillip Susi 2013-10-29 23:56:43 UTC
I have rebased the patches onto current master.
Comment 43 Curtis Gedak 2013-11-30 20:14:50 UTC
Hi Phillip,

I have to admit that I have not tested the new patches starting with comment #39.  Has the behaviour of the status bars changed from the earlier patches?

Back before you improved the internal GParted move operation, I used to receive complaints about the full read of the partition before the full move of the partition.  Users would say that they thought the operation was almost done, but it would only have completed reading the sectors and would proceed to take at least as long to move the partition to the new location.  If possible I would like to avoid these types of complaints.

Curtis
Comment 44 Phillip Susi 2013-12-01 00:15:39 UTC
No, the behaviour has not changed.  Time to think on it has not changed my opinion: we can't get the bar perfect, but spending an hour slowly filling up and then spending 1 minute racing through another full bar is a lot better than spending 61 minutes bouncing back and forth.

We got rid of the read-only pass already didn't we?
Comment 45 Curtis Gedak 2013-12-01 20:34:32 UTC
(In reply to comment #44)
> No, the behaviour has not changed.  Time to think on it has not changed my
> opinion: we can't get the bar perfect, but spending an hour slowly filling up
> and then spending 1 minute racing through another full bar is a lot better than
> spending 61 minutes bouncing back and forth.

I agree.  If there is only one long running action (and however many fast running actions) in an operation then the long running progress bar is representative of the time the operation takes to complete.

The challenge is that some operations a user queues are actually compound actions.  Further, more than one of these actions might take a long time.  If there is more than one action taking a long time then the progress bars can be misleading to the user.

For example, if a user chooses Partition -> Move/Resize, shrinks a partition and moves it to the left, a single GParted operation is queued.

This operation actually involves several steps.

1)  calibrate partition                   (fast)
2)  check file system for errors          (potentially slow)
3)  shrink file system                    (potentially slow)
4)  shrink partition                      (fast)
5)  check file system for errors          (probably faster check)
6)  grow partition to be all-encompassing (fast)
7)  move file system left                 (slow)
8)  shrink partition                      (fast)

As can be seen, there is more than one potentially long running step, because each of the check file system, shrink file system, and move file system actions can take a long time.  This is the problem that I see conflicting with the GNOME HIG.

The root of the problem is that GParted only shows the user the queued operation, and then each successive sub-action as they occur.  If instead these sub-actions were all displayed earlier, or somehow the total number of sub-actions were shown and progress through these, then we could eliminate the progress bar confusion for the user.

My thoughts are that tracking the number of sub-actions might be one way to address this confusion.  The reason being that when the operation is queued, we will know at that time how many sub-actions are required.  Of course we will also need to take into account merging operations when the user keeps changing the same partition.


> We got rid of the read-only pass already didn't we?

Yes, the read-only pass is now gone.  :)

Before that enhanecment there were two long progress bars (and some bounce-back bars).  One long progress bar to do the read-only pass, and a second to perform the actual move/copy of the data.  This is the area where I received complaints from users that thought the operation was done after the read-only pass because the bar had progressed all the way across.  Then all of a sudden it started from scratch again for the move/copy of the file system.  This led to confusion as to when the task was really going to be done.

Curtis
Comment 46 Phillip Susi 2013-12-02 14:30:36 UTC
Oh right... the second progress bar does not count the sub operations.  I suppose that is something that could be improved on, but would require some significant refactoring so I'm not sure why the initial improvement needs to wait on that.

Keep in mind that for every one person that complains that they thought it was almost done and then the bar started over, there are 10 people complaining that it has been running for hours and the stupid bar just keeps bouncing back and forth giving no indication at all, is it stuck?  Should I kill it?
Comment 47 Curtis Gedak 2013-12-02 19:51:55 UTC
You raise a good point Phillip that some people will prefer the progress bar as it works in the patch set and other people will prefer it as is.  This and the HIG are what make the patch set fall into a grey area.  This issue is first raised by Mike in comment #21.

Since this issue is not a simple case of one way being right and another being wrong, and because I do not want to lose the work done in this patch set, I am leaning towards including it in a release after 0.17.0.

One main reason I prefer to skip this for the 0.17.0 release is because the patches include tie-ins to signal handlers and as such should undergo extensive testing.  I want to be sure this is well tested on supported distros before committing this to the master branch.
Comment 48 Kurt Bigler 2013-12-02 20:15:04 UTC
I will inject a reminder here of my original post (following paragraph).  I used gparted only once, in an emergency.  I may use it again if such an emergency comes up, although it did not find my partitions, took a long long time trying, and then threw away all the results when the drive got disconnected after 12 hours due to a USB fluke, rather than detecting that and letting me perhaps reconnect and continue.  (The free version of DMDE worked, found three large FAT32 partitions within a fraction of a second, and let me recover them perfectly.)

"I'm doing a search-for-file-systems operation on a 2tb drive.  It has been
running for almost 12 hours. Having never done this before I really have no
idea whether it might take the rest of the week, also whether it is likely to
survive sleep/wake cycles for several days in a row."

My real point is that gparted, being what it is, is likely to be used by people who have never used gparted before, and even:  have never used unix before.  And many people who are in an emergency situation are likely to be using it, although the converse may not be true.  Finally:  I have a kind of a schtick about participating in communities and giving feedback, and so I did in spite of the fact that it required finding out what bugzilla was and setting up an account.  Many people in an emergency situation do not have spare cycles to give feedback.  If it sucks, you will not hear from them.  After all if it sucks it may not seem worth bothering to communicate, especially if there are weird hurdles involved (joining bugzilla).

Progress bars are one of the primary things that make Windoze look like total crap, and the Mac (in most situations) look, well maybe not great, but certainly not disgusting, not utterly brain-dead and irritating.  So these things make a difference in platform perception and adoption, never mind utilities.

So I think it is good you keep plugging along and working on getting this right.  Thanks!

I can not remember the details of your progress bars after all this time, but what people sometimes miss in trying to get things right is additional modest things that might help an utterly disoriented user makes some sense of it all.  As such, if there is some progress bar behavior that might be misleading, and especially if you have any cues from the operation queue that having such a misleading presentation is likely to come up in the current operation context, it would be helpful if you can in some way just warn the user with a textual status field to that effect, e.g. "such and such progress bar appear to indicate such and such but in fact [whatever, like maybe ...] there are other operations queued that are not being considered in the progress operation [or whatever else].  And finally you might even have some graphical red flag next to the progress bar when there is some information available to you to tell you it may not be a good indicator in the current situation.  Or anything else:  number of operations ahead still not considered in progress bar, etc.

Bottom line:  what can you do that is almost a UI-only thing with no underlying refactoring required, which even if it looks embarrassing, might be vastly helpful to an utterly disoriented user having a godawful emergency on their hands.

Thanks.
Comment 49 Curtis Gedak 2014-01-07 17:15:33 UTC
As a heads up, I plan to begin reviewing the code for the patches contained in comment #39, comment #40, and comment #41.

On another note, I am happy to announce that LarryT (previous GParted live CD maintainer and creator of some of the first GParted documentation) has offered to help out with testing these patches on various GNU/Linux distros.  As such I have added his email address to the CC list on this report.  Welcoming back to the team Larry.  :)

Curtis
Comment 50 Curtis Gedak 2014-01-08 20:55:22 UTC
Hi Phillip and Mike,

I'm still backlogged in email so it's taking me a while to look through these patches.


I noticed that the patch in comment #39 contains whitespace:

$ git am bug467925-progress-bar-1.patch
Applying: Display progress during resize (#467925)
/home/gedakc/workspace/gparted.dev2/.git/rebase-apply/patch:113: trailing whitespace.
                                        partition_new .get_sector_length(), partition_new .sector_size, UNIT_KIB ) ) -1 ) + "K" ; 
warning: 1 line adds whitespace errors.


This is one thing that we will want to clean-up before the final patch is approved.  I still need to look at the method names too because some of these seem different from the patch in comment #17.

Curtis
Comment 51 Laurent de Trogoff 2014-01-13 16:03:28 UTC
Hi all,
I lately made some test with gparted compilled with those three patches Phillip submitted.
And it seems that they introduce a new bug, when an ext2/3/4 ntfs grow operation is cancelled

Current Gparted 0.17.0 behavior without patches:
1. grow partition
2. apply operation
3. cancel when file system is being resized
4. cancel button changes to « force cancel » so force cancel
5. operation cancelled
6. Operation reported as cancelled


New Gparted 0.17.0 + 3 patches  behavior:
1. grow partition
2. apply operation
3. cancel while file system is being resized
4. cancel button changes to « force cancel » so force cancel
5. operation still running, not cancelling
6. Operation reported as succesfully completed
Comment 52 Laurent de Trogoff 2014-01-13 16:08:13 UTC
Created attachment 266173 [details]
details file when cancelling grow operation (0.17 + 3patches)

in addition to my last comment https://bugzilla.gnome.org/show_bug.cgi?id=467925#c51
Comment 53 Phillip Susi 2014-01-13 16:15:45 UTC
That is very strange; they shouldn't have a thing to do with the cancel path.  I'll try to take a look at it tonight.
Comment 54 Curtis Gedak 2014-01-13 17:14:02 UTC
Hi Phillip,

While working with Larry to get up to speed on testing, Larry and I have been conversing on the GParted IRC.  Larry has performed many tests with these three patches on several distros.  So far no crashes have been experienced.  This is good news because with the troubles we encountered implementing asynchronous progress updates I was worried about crashes.

Regarding cancel behaviour I have confirmed Larry's observation that with the 3 patches applied, cancelling a grow ext2 operation leaves the operation still running and then it gets reported as successfully completed.  I performed my test on kubuntu 12.04.

Curtis
Comment 55 Phillip Susi 2014-01-14 04:43:49 UTC
Are you sure these patches introduce that behaviour or was it already there?
Comment 56 Laurent de Trogoff 2014-01-14 07:37:37 UTC
Hi Phillip,
Like I mention in my previous post (comment 51), I made tests with both gparted version, current and patched.
BTW Curtis got the same result when testing.

So i can say this behaviour does not exist without the patches.
But I must admit this is weird.
Please, give it a try your self.

Larry
Comment 57 Laurent de Trogoff 2014-01-14 08:04:13 UTC
Created attachment 266232 [details]
cancelled operation, but successfully run

Screenshot in addition to my previous comment 51
Larry
Comment 58 Laurent de Trogoff 2014-01-14 10:44:43 UTC
Phillip, Curtis,
As I continued to have doubts about this bug I mentioned in comment 51(absolutly no effect when clicking the cancel button), 
I did several tests with the current gparted version compilled without any patch, and also with gparted-patched version compilled, on the same machine, changing directory.

-1- the bug I previously mentioned may happen EVEN with the current version, depending on the moment one clicks the cancel button. If shrinking or growing is already too much committed, then clicking the cancel button does not make anything. FS = ext2/3/4 ntfs

-2- cancelling with the gparted-patched version NEVER perform any cancelling operation, at any time. Either checking for error or growing or shrinking, it does nothing and operation continue just like no cancel order has been sent.

So, IMHO, this could mean that the 3 patches highlight and increase a previous bug in the current version.

Would there be other tests to confirm or deny all this ?

Larry
Comment 59 Phillip Susi 2014-01-14 14:50:52 UTC
I found this difficult to reproduce since resizse often finishes too quickly.  Do you have a good way to make sure it takes a while?  I wonder, is gparted trying to kill resize2fs, and it is just ignoring the signal for some reason?
Comment 60 Laurent de Trogoff 2014-01-14 15:36:06 UTC
(In reply to comment #59)
> I found this difficult to reproduce since resizse often finishes too quickly. 
> Do you have a good way to make sure it takes a while? 

yes : I may use external usb drive. BTW it is 1 tera hdd, so it may take a while.

> I wonder, is gparted
> trying to kill resize2fs, and it is just ignoring the signal for some reason?

So you wish I kill resizing ?
Right ?
Comment 61 Curtis Gedak 2014-01-14 15:59:43 UTC
Hi Phillip and Larry,

When I reproduced the cancel problem Larry discovered, I created an extended partition that spanned my whole 160 GB IDE drive.  Then I created a 20 GB ext2 logical partition at the start of the drive and applied the operation.  From there I grew the 20 GB ext2 partition to use the whole drive.

When applying the grow operation I had sufficient time to watch the results and cancel the operation while it was in the resize2fs step.

Curtis
Comment 62 Phillip Susi 2014-01-14 16:11:28 UTC
You might try manually running resize2fs and hitting ctrl-c and make sure it stops, or insert a printf in FileSystem.cc:cancel_command() to make sure that it is sending the signal.
Comment 63 Curtis Gedak 2014-01-14 17:23:14 UTC
Created attachment 266280 [details]
0.17.0 grow ext2 operation cancel-force-cancel-cancel-operation at end of grow XXX line

Hi Phillip and Larry,

I manually ran the resize2fs command and it cancels when I press
CTRL+C.  Following is the output.  Note that the terminal prompt gets
written in the same line as the progress indicator because the final
line feed is not sent.

gedakc@octo:~/tmp$ sudo resize2fs -p /dev/sdd5
resize2fs 1.42 (29-Nov-2011)
Resizing the filesystem on /dev/sdd5 to 39072000 (4k) blocks.
Begin pass 1 (max = 1033)
Extending the inode table     XXXX^Cgedakc@octo:~/tmp$ ---------------


I have been trying to replicate the situation Larry mentioned in
comment #58 where he was able to get the current 0.17.0 version (no
patches) to fail to cancel properly.  So far I have been unsuccessful
in duplicating this finding.  Every time I cancel a grow ext2
operation in 0.17.0 the operation cancels as expected.

The steps that occur in the grow operation are as follows:

Grow /dev/sdd5 from 20.00 GiB to 149.05 GiB
  1)  calibrate /dev/sdd5
  2)  check file system on /dev/sdd5 for errors and (if possible) fix them
  3)  grow partition from 20.00 GiB to 149.05 GiB
  4)  check file system on /dev/sdd5 for errors and (if possible) fix them
  5)  grow file system to fill the partition

Steps 1 and 3 run too fast for me to cancel.
Steps 2 and 4 cancel immediately when I press cancel.
Step 5 will display a "Force Cancel" button when I press cancel.  Then
if I press "Force Cancel" and also choose "Cancel Operation", the
operation cancels.  This even happens when I wait for all the
resize2fs XXX's to progress all the way across the screen as
demonstrated in the attached gparted_details.htm log file.

My conclusion so far:

A) 0.17.0 always cancels properly.
B) git head + 3 patches, cancels in any operation never work.

Another change I noticed is that with git head + 3 patches, if I
cancel in steps 2 or 4 then I get a "Force Cancel" button that does
not appear in 0.17.0.

Curtis
Comment 64 Laurent de Trogoff 2014-01-14 18:28:54 UTC
Created attachment 266284 [details]
cancelled operation, but successfully run

After many test, I found one way to get the bug when cancelling with current version. But it is very difficult to reproduce.

If cancelling during check file system after growing (or shrinking). And even I had to cancel twice : the first time it really cancels and the second time I run a check operation taht I cancel !

AFAIK, it is the only way to get this error.
I add gparted_details too
Comment 65 Laurent de Trogoff 2014-01-14 18:30:22 UTC
Created attachment 266285 [details]
gparted_details : cancelled operation, but successfully run

add to my previous comment 64
Comment 66 Mike Fleetwood 2014-01-14 20:03:17 UTC
Hi All,

On a different issue, it looks like patch number 1/3 from comment #39
was miss-rebased because it is changing the following line in
ext2::resize() which will re-introduce fault fixed by bug #701075, where
ext[234] file systems were being resize 1 KiB too small.

- partition_new .get_sector_length(), partition_new .sector_size, UNIT_KIB ) ) ) + "K" ;
+ partition_new .get_sector_length(), partition_new .sector_size, UNIT_KIB ) ) -1 ) + "K" ;

Thanks,
Mike
Comment 67 Mike Fleetwood 2014-01-14 20:22:52 UTC
For a really simple way to test the bug, temporarly rename resize2fs out
of the way and create a replacement script which just sleeps for 30
seconds.  Like this:

cd /sbin
mv resize2fs resize2fs.save
echo sleep 30 > resize2fs
chmod a+x resize2fs
Comment 68 Mike Fleetwood 2014-01-14 21:00:09 UTC
I haven't understood all the signals and callbacks involved, but
removing the second call to outputcapture.signal_update.connect() added
by patch number 1/3 from comment #39 allows resize to be cancelled
again.  But it's probably also going to stop the GUI progress bar
being updated.

--- a/src/FileSystem.cc
+++ b/src/FileSystem.cc
@@ -122,17 +126,14 @@ int FileSystem::execute_command( const Glib::ustring & command, OperationDetail
        std::vector<OperationDetail> &children = operationdetail.get_last_child().get_childs();
        outputcapture.signal_update.connect( sigc::bind( sigc::ptr_fun( update_command_output ),
                                                         &(children[children.size() - 2]),
                                                         &output ) );
        errorcapture.signal_update.connect( sigc::bind( sigc::ptr_fun( update_command_output ),
                                                        &(children[children.size() - 1]),
                                                        &error ) );
-       outputcapture.signal_update.connect( sigc::bind(
-                                                       sigc::mem_fun( *this, &FileSystem::relay_outputupdate ),
-                                                       operationdetail ) );
        outputcapture.connect_signal();
        errorcapture.connect_signal();
        operationdetail.get_last_child().signal_cancel.connect(
                sigc::bind(
                        sigc::ptr_fun( cancel_command ),
                        pid,
                        cancel_safe ));
Comment 69 Curtis Gedak 2014-01-14 21:18:41 UTC
Hi Larry,

In comments #64 and #65 it looks like you cancelled when the resize2fs action was virtually complete.  Did you get a chance to press the "Force Cancel" and then "Cancel Operation" buttons before the entire operation completed?

My thoughts are that the 5 second delay before the "Force Cancel" button is activated might have been enough time for the grow operation to complete.

If this is the situation then it is indeed a fringe case that not many would encounter.  The one plus is that no data would be lost.


Mike,

Good catch on the re-introduction of an off-by-one problem in comment #66.  Also I like your suggestion in comment #67 for how to test resize2fs by substituting a sleep script for this resize executable.  Hopefully Phillip can now reproduce the problem and investigate further.

Curtis
Comment 70 Phillip Susi 2014-01-14 21:31:15 UTC
Good catch Mike, my eyes must have just glossed right over that -1.

That is really fubar.  All that call does is set it up so that the PipeCapture::OnReadable() callback is run whenever there is input to read from the pipe coming from the child.  That callback reads from the pipe into a ustring, then emits the signal_update() signal, which changes the description in the OperationDetail to reflect the new progress.

None of that should have anything to do with the cancel signal...
Comment 71 Phillip Susi 2014-01-18 03:39:50 UTC
It looks like the problem is that the OperationDetails are copied around by the vector they are in, and the dtor in the original disconnects the signal.  Removing the disconnect call in the OperationDetails dtor seems to fix it for me, how about you guys?  I do not understand what that has to do with these patches though; it should have been a problem before.
Comment 72 Laurent de Trogoff 2014-01-18 19:14:44 UTC
(In reply to comment #71)
> It looks like the problem is that the OperationDetails are copied around by the
> vector they are in, and the dtor in the original disconnects the signal. 
> Removing the disconnect call in the OperationDetails dtor seems to fix it for
> me, how about you guys?  I do not understand what that has to do with these
> patches though; it should have been a problem before.

Hi Phillip.
If you have time to set and post a patch I may test it...

Larry
Comment 73 Phillip Susi 2014-01-18 20:47:36 UTC
You just delete the only line that is in OperationDetail::~OperationDetail ;)
Comment 74 Laurent de Trogoff 2014-01-18 21:26:09 UTC
(In reply to comment #73)
> You just delete the only line that is in OperationDetail::~OperationDetail ;)

In which file ?
Comment 75 Mike Fleetwood 2014-01-19 00:16:44 UTC
Hi Larry,

This is the change Phillip is alluding to in file src/OperationDetail.cc:

diff --git a/src/OperationDetail.cc b/src/OperationDetail.cc
index 86b4127..af460a0 100644
--- a/src/OperationDetail.cc
+++ b/src/OperationDetail.cc
@@ -36,7 +36,6 @@ OperationDetail::OperationDetail( const Glib::ustring & description, OperationDe
 
 OperationDetail::~OperationDetail()
 {
-       cancelconnection.disconnect();
 }
 
 void OperationDetail::set_description( const Glib::ustring & description, Font font )


Thanks,
Mike
Comment 76 Mike Fleetwood 2014-01-19 00:19:53 UTC
When I tested this change it didn't go so well.  GParted core dumped as
soon as the cancel button was pressed for the first time.  This was when
cancelling "sleep 30" shell script named /sbin/resize2fs.


[root@rockover ~]# gdb ~mike/programming/c/gparted/src/gpartedbin core.19179 
(gdb) set pagination off
(gdb) list
993	   * @param last An iterator pointing to the last slot in the list.
994	   * @param _A_a1 Argument to be passed on to the slots.
995	   */
996	  static result_type emit(signal_impl* impl, typename type_trait<T_arg1>::take _A_a1)
997	    {
998	      if (!impl || impl->slots_.empty()) return;
999	      signal_exec exec(impl);
1000	      temp_slot_list slots(impl->slots_);
1001	
1002	      for (iterator_type it = slots.begin(); it != slots.end(); ++it)
(gdb) backtrace
  • #0 emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 998
  • #1 emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 2773
  • #2 operator()
    at /usr/include/sigc++-2.0/sigc++/signal.h line 2781
  • #3 GParted::OperationDetail::cancel
    at OperationDetail.cc line 165
  • #4 emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 1006
  • #5 emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 2773
  • #6 operator()
    at /usr/include/sigc++-2.0/sigc++/signal.h line 2781
  • #7 GParted::Dialog_Progress::on_cancel
    at Dialog_Progress.cc line 331
  • #8 Gtk::Dialog_Class::response_callback
    at dialog.cc line 181
  • #9 g_cclosure_marshal_VOID__INT
    at gmarshal.c line 218
  • #10 g_type_class_meta_marshal
    at gclosure.c line 877
  • #11 g_closure_invoke
    at gclosure.c line 766
  • #12 signal_emit_unlocked_R
    at gsignal.c line 3290
  • #13 g_signal_emit_valist
    at gsignal.c line 2983
  • #14 g_signal_emit
    at gsignal.c line 3040
  • #15 IA__gtk_dialog_response
    at gtkdialog.c line 932
  • #16 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 79
  • #17 g_closure_invoke
    at gclosure.c line 766
  • #18 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #19 g_signal_emit_valist
    at gsignal.c line 2983
  • #20 g_signal_emit
    at gsignal.c line 3040
  • #21 IA__gtk_button_clicked
    at gtkbutton.c line 1128
  • #22 gtk_real_button_released
    at gtkbutton.c line 1725
  • #23 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 79
  • #24 g_type_class_meta_marshal
    at gclosure.c line 877
  • #25 g_closure_invoke
    at gclosure.c line 766
  • #26 signal_emit_unlocked_R
    at gsignal.c line 3182
  • #27 g_signal_emit_valist
    at gsignal.c line 2983
  • #28 g_signal_emit
    at gsignal.c line 3040
  • #29 gtk_button_released
    at gtkbutton.c line 1120
  • #30 gtk_button_button_release
    at gtkbutton.c line 1617
  • #31 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 86
  • #32 g_type_class_meta_marshal
    at gclosure.c line 877
  • #33 g_closure_invoke
    at gclosure.c line 766
  • #34 signal_emit_unlocked_R
    at gsignal.c line 3290
  • #35 g_signal_emit_valist
    at gsignal.c line 2993
  • #36 g_signal_emit
    at gsignal.c line 3040
  • #37 gtk_widget_event_internal
    at gtkwidget.c line 4992
  • #38 IA__gtk_propagate_event
    at gtkmain.c line 2460
  • #39 IA__gtk_main_do_event
    at gtkmain.c line 1665
  • #40 gdk_event_dispatch
    at gdkevents-x11.c line 2377
  • #41 g_main_dispatch
    at gmain.c line 2149
  • #42 g_main_context_dispatch
    at gmain.c line 2702
  • #43 g_main_context_iterate
    at gmain.c line 2780
  • #44 g_main_loop_run
    at gmain.c line 2988
  • #45 IA__gtk_main
    at gtkmain.c line 1237
  • #46 Gtk::Main::run_impl
    at main.cc line 520
  • #47 Gtk::Main::run
    at main.cc line 467
  • #48 GParted::FileSystem::execute_command
    at FileSystem.cc line 139
  • #49 GParted::ext2::resize
    at ext2.cc line 231
  • #50 GParted::GParted_Core::resize_filesystem
    at GParted_Core.cc line 2543
  • #51 GParted::GParted_Core::maximize_filesystem
    at GParted_Core.cc line 2583
  • #52 GParted::GParted_Core::apply_operation_to_disk
    at GParted_Core.cc line 686
  • #53 emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 917
  • #54 emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 2773
  • #55 GParted::Dialog_Progress::on_signal_show
    at Dialog_Progress.cc line 215
  • #56 operator()
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h line 440
  • #57 Glib::SignalProxyNormal::slot0_void_callback
    at signalproxy.cc line 97
  • #58 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 79
  • #59 g_closure_invoke
    at gclosure.c line 766
  • #60 signal_emit_unlocked_R
    at gsignal.c line 3322
  • #61 g_signal_emit_valist
    at gsignal.c line 2983
  • #62 g_signal_emit
    at gsignal.c line 3040
  • #63 IA__gtk_widget_show
    at gtkwidget.c line 3221
  • #64 IA__gtk_dialog_run
    at gtkdialog.c line 1065
  • #65 Gtk::Dialog::run
    at dialog.cc line 316
  • #66 GParted::Win_GParted::activate_apply
    at Win_GParted.cc line 2675
  • #67 operator()
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h line 440
  • #68 Glib::SignalProxyNormal::slot0_void_callback
    at signalproxy.cc line 97
  • #69 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 79
  • #70 g_closure_invoke
    at gclosure.c line 766
  • #71 signal_emit_unlocked_R
    at gsignal.c line 3322
  • #72 g_signal_emit_valist
    at gsignal.c line 2983
  • #73 g_signal_emit_by_name
    at gsignal.c line 3077
  • #74 button_clicked
    at gtktoolbutton.c line 773
  • #75 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 79
  • #76 g_closure_invoke
    at gclosure.c line 766
  • #77 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #78 g_signal_emit_valist
    at gsignal.c line 2983
  • #79 g_signal_emit
    at gsignal.c line 3040
  • #80 IA__gtk_button_clicked
    at gtkbutton.c line 1128
  • #81 gtk_real_button_released
    at gtkbutton.c line 1725
  • #82 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 79
  • #83 g_type_class_meta_marshal
    at gclosure.c line 877
  • #84 g_closure_invoke
    at gclosure.c line 766
  • #85 signal_emit_unlocked_R
    at gsignal.c line 3182
  • #86 g_signal_emit_valist
  • #87 g_signal_emit
    at gsignal.c line 3040
  • #88 gtk_button_released
    at gtkbutton.c line 1120
  • #89 gtk_button_button_release
    at gtkbutton.c line 1617
  • #90 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 86
  • #91 g_type_class_meta_marshal
    at gclosure.c line 877
  • #92 g_closure_invoke
    at gclosure.c line 766
  • #93 signal_emit_unlocked_R
    at gsignal.c line 3290
  • #94 g_signal_emit_valist
    at gsignal.c line 2993
  • #95 g_signal_emit
    at gsignal.c line 3040
  • #96 gtk_widget_event_internal
    at gtkwidget.c line 4992
  • #97 IA__gtk_propagate_event
    at gtkmain.c line 2460
  • #98 IA__gtk_main_do_event
    at gtkmain.c line 1665
  • #99 gdk_event_dispatch
    at gdkevents-x11.c line 2377
  • #100 g_main_dispatch
    at gmain.c line 2149
  • #101 g_main_context_dispatch
    at gmain.c line 2702
  • #102 g_main_context_iterate
    at gmain.c line 2780
  • #103 g_main_loop_run
    at gmain.c line 2988
  • #104 IA__gtk_main
    at gtkmain.c line 1237
  • #105 Gtk::Main::run_impl
    at main.cc line 520
  • #106 Gtk::Main::run
    at main.cc line 474
  • #107 main
    at main.cc line 58

Comment 77 Phillip Susi 2014-01-19 00:28:05 UTC
Yikes.. I was just testing with a fsck instead of a resize.  It looks like the problem is that sigc's connection object doesn't do ref counting so isn't suitable for use in objects that are ever copied.  Curtis, I think you have more experience with the sigc library than I do; do you have any insight on how this might be dealt with, or somewhere to discuss it?
Comment 78 Curtis Gedak 2014-01-19 18:33:21 UTC
Hi Phillip, Mike, and Larry,

In response to comment #77, I am certainly not an expert on the sigc library.  What I do know is that this area seems to be really sensitive or touchy.  I base this "touchy" feeling on the many crash problems we encountered while trying to add asynchronous command spawning and detail window updating.

As a suggestion of "somewhere to discuss it", I have created a post in the GParted Forum under General Development.  Feel free to add to the forum post thread at:

Add Progress Bar Discussion
http://gparted-forum.surf4.info/viewtopic.php?id=17079

Curtis
Comment 79 Phillip Susi 2014-01-19 22:28:15 UTC
I meant is there an upstream mailing list for sigc or something?
Comment 80 Curtis Gedak 2014-01-21 18:32:09 UTC
Created attachment 266910 [details] [review]
Progress bars (v4)

In an effort to ensure that we do not lose the suggestions mentioned in comment #50 and comment #66, I have applied these suggestions and rebased the patch set.

The updates in this patch set include:
 1) Remove trailing white space (and clean up some prior white space nearby)
 2) Remove reintroduction of "-1" size calculation problem for ntfs resize

Note that this patch set includes all 3 of the previous patches listed as attachments in comments 39, 40, and 41.

I still need to look more closely at how we are handling signals and asynchronous spawned commands with respect to problems with this patch set.

Curtis
Comment 81 Mike Fleetwood 2014-01-23 23:26:49 UTC
Created attachment 267084 [details] [review]
Progress bars (v5)

Hi,

Here's v5 of the patchset.  The following differences have been made
compared to v4 from comment #80:

Re-apply changed made in v2 from comment #17 and discussed in
comment #13 above:

1) Renamed the functions and signals;
2) Explicitly call signal_progress.emit() rather than just
   signal_progress(), letting operator() map to emit();
3) Readd missing c.disconnect() in ext2::check_repair().

Extras:

4) Define private functions after the public functions to match what is
   done in every other source file;
5) Drop "Ignore ascii 1 and 2, which e2fsck uses for some reason" from
   the 3rd commit message after that bit was already done by commit:
      Enable %age complete display from e2fsck command (#697662)
      https://git.gnome.org/browse/gparted/commit/?id=59a22673da55eb185b8bd1e25cc9a729e24c24bb
6) Remove white space changes to existing non-white space lines in
   ext2::resize() which would pollute git blame.

NOTE: This still doesn't address the inability to cancel an ext2/3/4 and
ntfs resize first noted in comment #51.

Mike
Comment 82 Phillip Susi 2014-02-25 16:42:54 UTC
Created attachment 270295 [details] [review]
0001-Fix-cancel-path.patch

Ok, so the disconnect is needed because the old OperationDetail goes away, so the parent OperationDetail needs to no longer be connected to it.  The NEW OperationDetail needs to establish a new connection from the parent to itself.  This patch should do it.  Note that it still does not seem to be connected to the progress changes.
Comment 83 Laurent de Trogoff 2014-03-02 20:21:18 UTC
Hi guys,
I gonna make some tests with those two patches, applying both to last gparted release commit from git.
Please let me know if you have any wishes or details about needed tests, or I only run usual test ?

thx
Larry
Comment 84 Laurent de Trogoff 2014-03-02 20:52:06 UTC
When applying the patchv5, it returns an error :

Applying: Display progress during resize (#467925)
error: patch failed: src/ext2.cc:193
error: src/ext2.cc: patch does not apply
Patch failed at 0001 Display progress during resize (#467925)
The copy of the patch that failed is found in:
   /home/trog/gparted-467925/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".


Please, let me know what I miss :/
Comment 85 Curtis Gedak 2014-03-03 16:53:53 UTC
Hi Larry,

I discovered the same problem when I tried to apply the patch from comment #81 to the current git master.

When this occurs, usually the git master branch has changed sufficiently that there is now a conflict or missing markers for the patch to be cleanly applied.  This means that the patch needs to be rebased with the current git master branch.

To restore the original branch and stop patching run "git am --abort".

Mike,

If you have time, would you be able to rebase the patches from comment #81 and comment #82?

If not, then let me know and I can take a look into it.

In the meantime I will review and possibly commit the latest patch for:
Bug 721516 - Use e2image to move/copy ext[234] filesystems

Thanks,
Curtis
Comment 86 Curtis Gedak 2014-03-25 15:43:31 UTC
Hi All,

I've some time so I will work on refactoring the patches in comment 81 and comment 82.

Curtis
Comment 87 Curtis Gedak 2014-03-25 17:36:19 UTC
Created attachment 272880 [details] [review]
Progress bars (v6)

Hi All,

Here's v6 of the patch set.  It contains only the rebased v5 patch set.  The changes that caused trouble were due to some move() formatting changes, and the migration of a calculation to an offset variable.

NOTE: This v6 patch set still doesn't address the inability to cancel an ext2/3/4 and ntfs resize first noted in comment #51.


PROBLEMS WITH 0001-Fix-cancel-path.patch FROM COMMENT #82

When I applied 0001-Fix-cancel-path.patch from comment #82 on top of the v6 patch set, I discovered that each operation I queued then applied would result in a GParted crash (most often a segmentation fault, though sometimes memory allocation problems).  Some of the operations I tried were create ext2 or fat16 partition, resize ext2 or ntfs partition, check ext2 or ntfs partition, and label ntfs partition.

I quickly tested some of these operations on Ubuntu GNOME 14.04 beta1 and experienced similar GParted crashes.


Phillip,

Was your intention to apply the 0001-Fix-cancel-path.patch from comment #82 on top of the progress-bar-v# patch sets?

Do you encounter the same GParted crashes with the 0001-Fix-cancel-path.patch from comment #82?

Curtis
Comment 88 Curtis Gedak 2014-03-25 17:40:47 UTC
Created attachment 272884 [details] [review]
Progress bars (v7)

Doh!  My bad.

Patch set v6 accidentally included 0001-Fix-cancel-path.patch from comment #82.

The progress bars (v7) patch excludes 0001-Fix-cancel-path.patch from comment #82.

NOTE: This v7 patch set still doesn't address the inability to cancel an
ext2/3/4 and ntfs resize first noted in comment #51.

Curtis
Comment 89 Phillip Susi 2014-03-25 17:46:05 UTC
I forget whether I had it on top of or under, but it probably should be applied whether or not the progress bar is applied as the bug appears to be unconnected to it.
Comment 90 Curtis Gedak 2014-03-25 18:42:48 UTC
Hi Phillip,

When I apply only the 0001-Fix-cancel-path.patch from comment #82 on top of the currently published git master branch (with no progress-bar-v# patches), then queue and apply an operation, there are no progress bar updates.  In addition if I expand the details pane, then the command line specifics are blank, and the error/output is also blank.  There are some unusual numbers for timing on the right hand side.  when the command supposedly competes, GParted crashes.

Would you be able to test the patch from comment #82 to see if it works for you?

Curtis
Comment 91 Phillip Susi 2014-03-26 02:02:55 UTC
Jesus... while debugging this I did the stupidest thing in the world, then fixed it because I'm a frigging genius ;)

I meant to test on my flash drive in /dev/sde, but I accidentally created a partition table on /dev/md0 instead, which is my sole lvm pv that contains everything on my system.  This of course wiped out my lvm pv.  Fortunately I did not panic ( much ), and was able to wipe the mbr and recreate the lvm pv header and restore the lvm config from the backup in /etc/lvm/backup which, even though it was on the lvm, still worked as long as I didn't reboot.  Whew... dodged a bullet there.  This experience made me realize it would be really nice if gparted recognized an lvm pv on a whole disk instead of saying it was an unpartitioned disk.

I realized that the patch still isn't right since the parent OperationDetail can be moved, thus invalidating the pointer the child has to it.  I think the whole OperationDetail.cc needs to be re-factored to avoid using std::vector to hold its children.  As a general rule, nothing more complex than a built in type or pointer should be stored in STL containers.

In other words, instead of having a std::vector<OperationDetail> children, the class should have std::vector<OperationDetail *>children.
Comment 92 Curtis Gedak 2014-03-26 16:13:53 UTC
Hi Phillip,

Thank you for testing the patch and confirming that more work is needed.

I'm glad that you were able to recover your LVM PV on your RAID.  I also test on my PC and am always worried that I might overwrite the OS accidentally.  To avoid GParted seeing any of my OS or DATA disks as unformatted/unpartitioned, I always create a partition table, even if the table contains only one partition that spans the drive.  Having said that, this is no guarantee of accidentally overwriting the OS or data.

I agree that it would be nice if GParted recognized the format of non-partitioned devices.  Along that line of thinking I'll take a look at the status of
Bug 683643 - Doesn't properly support partitionless drives.

Curtis
Comment 93 Phillip Susi 2014-04-02 02:06:10 UTC
Created attachment 273443 [details] [review]
0001-Refactor-OperationDetail-to-not-store-complex-object.patch

Ok, this should fix the underlying bug.
Comment 94 Curtis Gedak 2014-04-28 20:01:31 UTC
Hi All,

The patch from comment #93 has been moved into it's own bug report to enable it to be tested and committed prior to this report being addressed.  See:

Bug 729139 - Refactor OperationDetail to address random behavior

The bug report for 467925 will remain open to handle the issue mentioned in the title (gparted: add progress bar during operation).


Larry,

If you have a chance, please test the new patch posted in Bug 729139 and report your findings in that report.

Curtis
Comment 95 Phillip Susi 2015-11-30 13:55:21 UTC
Hey Curtis, it looks like this fell off the radar some time ago.  Any chance you can apply it now?
Comment 96 Mike Fleetwood 2015-12-02 12:32:05 UTC
Created attachment 316655 [details] [review]
Progress bars (v8)

Hi All,

Here's v8 of the patchset.  The only difference compared to v7 from
comment #88 is forward port to current published git master and a couple
of trivial white space changes.
  Current git master:
  5b0465e Make about dialog website link non-clickable (#758131)

Unfortunately as soon as operations start being applied GParted core
dumps with heap corruption.  Often/Always affects non-modified
operations too.  At the moment I'm not sure if this is uncovering an
existing bug or whether this patchset is buggy.

Mike


# ~mike/programming/c/gparted/src/gpartedbin
======================
libparted : 2.4
======================
*** glibc detected *** /home/mike/programming/c/gparted/src/gpartedbin: double free or corruption (!prev): 0x00000000025d13b0 ***

# gdb ~mike/programming/c/gparted/src/gpartedbin core.15044 --batch --quiet --ex backtrace -ex quit
[New Thread 15044]
[New Thread 15046]
[Thread debugging using libthread_db enabled]
Core was generated by `/home/mike/programming/c/gparted/src/gpartedbin'.
Program terminated with signal 6, Aborted.
  • #0 raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #0 raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 abort
    at abort.c line 92
  • #2 __libc_message
    at . ./sysdeps/unix/sysv/linux/libc_fatal.c line 198
  • #3 malloc_printerr
  • #4 _int_free
    at malloc.c line 4836
  • #5 GParted::OperationDetail::~OperationDetail
    at OperationDetail.cc line 41
  • #6 sigc::bound_argument<GParted::OperationDetail>::~bound_argument
    at /usr/include/sigc++-2.0/sigc++/adaptors/bound_argument.h line 51
  • #7 sigc::bind_functor<-0x00000000000000001, sigc::bound_mem_functor1<void, GParted::FileSystem, GParted::OperationDetail&>, GParted::OperationDetail, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::~bind_functor
    at /usr/include/sigc++-2.0/sigc++/adaptors/bind.h line 136
  • #8 GParted::FileSystem::execute_command
    at FileSystem.cc line 129
  • #9 GParted::xfs::create
    at xfs.cc line 178
  • #10 GParted::GParted_Core::create_filesystem
    at GParted_Core.cc line 2188
  • #11 GParted::GParted_Core::format
    at GParted_Core.cc line 2210
  • #12 GParted::GParted_Core::apply_operation_to_disk
    at GParted_Core.cc line 771
  • #13 sigc::bound_mem_functor1<bool, GParted::GParted_Core, GParted::Operation*>::operator()
    at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h line 1851
  • #14 sigc::adaptor_functor<sigc::bound_mem_functor1<bool, GParted::GParted_Core, GParted::Operation*> >::operator()<GParted::Operation* const&>
    at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h line 84
  • #15 sigc::internal::slot_call1<sigc::bound_mem_functor1<bool, GParted::GParted_Core, GParted::Operation*>, bool, GParted::Operation*>::call_it
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h line 137
  • #16 sigc::internal::signal_emit1<bool, GParted::Operation*, sigc::nil>::emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 917
  • #17 sigc::signal1<bool, GParted::Operation*, sigc::nil>::emit
    at /usr/include/sigc++-2.0/sigc++/signal.h line 2773
  • #18 GParted::Dialog_Progress::on_signal_show
    at Dialog_Progress.cc line 214
  • #19 sigc::bound_mem_functor0<void, GParted::Dialog_Progress>::operator()
    at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h line 1787
  • #20 sigc::adaptor_functor<sigc::bound_mem_functor0<void, GParted::Dialog_Progress> >::operator()
    at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h line 251
  • #21 sigc::internal::slot_call0<sigc::bound_mem_functor0<void, GParted::Dialog_Progress>, void>::call_it
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h line 103
  • #22 Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*)
    from /usr/lib64/libglibmm-2.4.so.1
  • #23 g_closure_invoke
    at gclosure.c line 767
  • #24 signal_emit_unlocked_R
    at gsignal.c line 3322
  • #25 g_signal_emit_valist
    at gsignal.c line 2983
  • #26 g_signal_emit
    at gsignal.c line 3040
  • #27 IA__gtk_widget_show
    at gtkwidget.c line 3251
  • #28 IA__gtk_dialog_run
    at gtkdialog.c line 1065
  • #29 GParted::Win_GParted::activate_apply
    at Win_GParted.cc line 2847
  • #30 sigc::bound_mem_functor0<void, GParted::Win_GParted>::operator()
    at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h line 1787
  • #31 sigc::adaptor_functor<sigc::bound_mem_functor0<void, GParted::Win_GParted> >::operator()
    at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h line 251
  • #32 sigc::internal::slot_call0<sigc::bound_mem_functor0<void, GParted::Win_GParted>, void>::call_it
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h line 103
  • #33 Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*)
    from /usr/lib64/libglibmm-2.4.so.1
  • #34 g_closure_invoke
    at gclosure.c line 767
  • #35 signal_emit_unlocked_R
    at gsignal.c line 3322
  • #36 g_signal_emit_valist
    at gsignal.c line 2983
  • #37 g_signal_emit_by_name
    at gsignal.c line 3077
  • #38 g_closure_invoke
    at gclosure.c line 767
  • #39 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #40 g_signal_emit_valist
    at gsignal.c line 2983
  • #41 g_signal_emit
    at gsignal.c line 3040
  • #42 gtk_real_button_released
    at gtkbutton.c line 1712
  • #43 g_closure_invoke
    at gclosure.c line 767
  • #44 signal_emit_unlocked_R
    at gsignal.c line 3182
  • #45 g_signal_emit_valist
    at gsignal.c line 2983
  • #46 g_signal_emit
    at gsignal.c line 3040
  • #47 gtk_button_button_release
    at gtkbutton.c line 1604
  • #48 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 86
  • #49 g_closure_invoke
    at gclosure.c line 767
  • #50 signal_emit_unlocked_R
    at gsignal.c line 3290
  • #51 g_signal_emit_valist
    at gsignal.c line 2993
  • #52 g_signal_emit
    at gsignal.c line 3040
  • #53 gtk_widget_event_internal
    at gtkwidget.c line 5025
  • #54 IA__gtk_propagate_event
    at gtkmain.c line 2490
  • #55 IA__gtk_main_do_event
    at gtkmain.c line 1685
  • #56 gdk_event_dispatch
    at gdkevents-x11.c line 2403
  • #57 g_main_dispatch
    at gmain.c line 2441
  • #58 g_main_context_dispatch
    at gmain.c line 3014
  • #59 g_main_context_iterate
    at gmain.c line 3092
  • #60 g_main_loop_run
    at gmain.c line 3300
  • #61 IA__gtk_main
    at gtkmain.c line 1257
  • #62 Gtk::Main::run(Gtk::Window&)
    from /usr/lib64/libgtkmm-2.4.so.1
  • #63 main
    at main.cc line 57

Comment 97 Curtis Gedak 2015-12-06 18:16:15 UTC
Thanks Phillip for the reminder to look at this again.  Also thank you Mike for rebasing the patch set.

I applied patch set v8 from comment #96 and tested on kubuntu 12.04.

I encountered a similar problem to Mike.  I queued an operation to create a 2,048 MiB NTFS partition and then applied the operation.  GParted immediately crashed at the apply step with the error messages listed below.

It looks like there is still more work to do before this enhancement is ready to be committed to the git master.

Curtis


Error messages follow:

$ sudo ./gparted.test.sh /dev/sde
[sudo] password for gedakc: 
======================
libparted : 2.3
======================
*** glibc detected *** src/gpartedbin: free(): invalid pointer: 0x00000000026a5018 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7db26)[0x7f0ce567eb26]
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib7ustringD1Ev+0x39)[0x7f0ce72b89b9]
src/gpartedbin[0x4a1a91]
src/gpartedbin[0x46d15b]
src/gpartedbin[0x4e7873]
src/gpartedbin[0x47ee9b]
src/gpartedbin[0x48adf6]
src/gpartedbin[0x455cea]
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib17SignalProxyNormal19slot0_void_callbackEP8_GObjectPv+0x28)[0x7f0ce72b6e08]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x132)[0x7f0ce6b75ca2]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x20fdd)[0x7f0ce6b86fdd]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd79)[0x7f0ce6b8f069]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_widget_show+0x86)[0x7f0ce772ccb6]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_dialog_run+0x218)[0x7f0ce758fdb8]
src/gpartedbin[0x4c03fa]
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib17SignalProxyNormal19slot0_void_callbackEP8_GObjectPv+0x28)[0x7f0ce72b6e08]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x132)[0x7f0ce6b75ca2]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x20fdd)[0x7f0ce6b86fdd]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd79)[0x7f0ce6b8f069]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_by_name+0x504)[0x7f0ce6b8f724]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0xfeca)[0x7f0ce6b75eca]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x421)[0x7f0ce6b8e711]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8e8e5)[0x7f0ce75628e5]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0xfeca)[0x7f0ce6b75eca]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x421)[0x7f0ce6b8e711]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8d70d)[0x7f0ce756170d]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x136e78)[0x7f0ce760ae78]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x132)[0x7f0ce6b75ca2]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x21339)[0x7f0ce6b87339]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xa5e)[0x7f0ce6b8ed4e]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x251231)[0x7f0ce7725231]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc3)[0x7f0ce7609003]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x283)[0x7f0ce7609363]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5be5c)[0x7f0ce6e10e5c]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x133)[0x7f0ce68b8d13]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x48060)[0x7f0ce68b9060]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f0ce68b945a]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7f0ce7608397]
/usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1(_ZN3Gtk4Main3runERNS_6WindowE+0x106)[0x7f0ce8491326]
src/gpartedbin[0x41b442]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f0ce562276d]
src/gpartedbin[0x41ba65]
======= Memory map: ========
00400000-0053c000 r-xp 00000000 08:03 2621459                            /home/gedakc/workspace/gparted/src/gpartedbin
0073b000-0073c000 r--p 0013b000 08:03 2621459                            /home/gedakc/workspace/gparted/src/gpartedbin
0073c000-0073e000 rw-p 0013c000 08:03 2621459                            /home/gedakc/workspace/gparted/src/gpartedbin
0073e000-00740000 rw-p 00000000 00:00 0 
0229d000-02747000 rw-p 00000000 00:00 0                                  [heap]
7f0cc8000000-7f0cc8089000 rw-p 00000000 00:00 0 
7f0cc8089000-7f0ccc000000 ---p 00000000 00:00 0 
7f0cce9b9000-7f0cce9ba000 rw-p 00000000 00:00 0 
7f0cce9ba000-7f0ccea19000 r--p 00000000 08:03 133796                     /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-RI.ttf
7f0ccea19000-7f0ccea6b000 r--p 00000000 08:03 133790                     /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-B.ttf
7f0ccea6b000-7f0ccea88000 r--p 00000000 08:03 533277                     /usr/share/fonts/truetype/droid/DroidSansMono.ttf
7f0ccea88000-7f0cceae8000 rw-s 00000000 00:04 2785323                    /SYSV00000000 (deleted)
7f0cceae8000-7f0cceae9000 ---p 00000000 00:00 0 
7f0cceae9000-7f0ccf2e9000 rw-p 00000000 00:00 0 
7f0ccf2e9000-7f0ccfb2d000 r--p 00000000 08:03 1200                       /usr/share/icons/gnome/icon-theme.cache
7f0ccfb2d000-7f0cd0000000 r--p 00000000 08:03 5113632                    /usr/local/share/icons/hicolor/icon-theme.cache
7f0cd0000000-7f0cd0022000 rw-p 00000000 00:00 0 
7f0cd0022000-7f0cd4000000 ---p 00000000 00:00 0 
7f0cd4000000-7f0cd8000000 r--p 00000000 08:03 131575                     /usr/share/icons/oxygen/icon-theme.cache
7f0cd8000000-7f0cd8021000 rw-p 00000000 00:00 0 
7f0cd8021000-7f0cdc000000 ---p 00000000 00:00 0 
7f0cdc10a000-7f0cdd959000 r--p 00000000 08:03 133929                     /usr/share/icons/hicolor/icon-theme.cache
7f0cdd959000-7f0cdd95d000 r-xp 00000000 08:03 5051291                    /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f0cdd95d000-7f0cddb5d000 ---p 00004000 08:03 5051291                    /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f0cddb5d000-7f0cddb5e000 r--p 00004000 08:03 5051291                    /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f0cddb5e000-7f0cddb5f000 rw-p 00005000 08:03 5051291                    /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f0cddb5f000-7f0cddb61000 r-xp 00000000 08:03 4981613                    /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f0cddb61000-7f0cddd60000 ---p 00002000 08:03 4981613                    /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f0cddd60000-7f0cddd61000 r--p 00001000 08:03 4981613                    /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f0cddd61000-7f0cddd62000 rw-p 00002000 08:03 4981613                    /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f0cddd62000-7f0cddd63000 ---p 00000000 00:00 0 
7f0cddd63000-7f0cde563000 rw-p 00000000 00:00 0 
7f0cde563000-7f0cde564000 ---p 00000000 00:00 0 
7f0cde564000-7f0cded64000 rw-p 00000000 00:00 0 
7f0cded64000-7f0cdeeb1000 r-xp 00000000 08:03 4981446                    /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
7f0cdeeb1000-7f0cdf0b0000 ---p 0014d000 08:03 4981446                    /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
7f0cdf0b0000-7f0cdf0b6000 r--p 0014c000 08:03 4981446                    /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
7f0cdf0b6000-7f0cdf0b9000 rw-p 00152000 08:03 4981446                    /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
7f0cdf0b9000-7f0cdf0ba000 rw-p 00000000 00:00 0 
7f0cdf0ba000-7f0cdf0c6000 r-xp 00000000 08:03 4720110                    /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f0cdf0c6000-7f0cdf2c5000 ---p 0000c000 08:03 4720110                    /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f0cdf2c5000-7f0cdf2c6000 r--p 0000b000 08:03 4720110                    /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f0cdf2c6000-7f0cdf2c7000 rw-p 0000c000 08:03 4720110                    /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f0cdf2c7000-7f0cdf2d1000 r-xp 00000000 08:03 4718878                    /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f0cdf2d1000-7f0cdf4d1000 ---p 0000a000 08:03 4718878                    /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f0cdf4d1000-7f0cdf4d2000 r--p 0000a000 08:03 4718878                    /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f0cdf4d2000-7f0cdf4d3000 rw-p 0000b000 08:03 4718878                    /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f0cdf4d3000-7f0cdf4ea000 r-xp 00000000 08:03 4724968                    /lib/x86_64-linux-gnu/libnsl-2.15.so
7f0cdf4ea000-7f0cdf6e9000 ---p 00017000 08:03 4724968                    /lib/x86_64-linux-gnu/libnsl-2.15.so
7f0cdf6e9000-7f0cdf6ea000 r--p 00016000 08:03 4724968                    /lib/x86_64-linux-gnu/libnsl-2.15.so
7f0cdf6ea000-7f0cdf6eb000 rw-p 00017000 08:03 4724968                    /lib/x86_64-linux-gnu/libnsl-2.15.so
7f0cdf6eb000-7f0cdf6ed000 rw-p 00000000 00:00 0 
7f0cdf6ed000-7f0cdf6f5000 r-xp 00000000 08:03 4724969                    /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f0cdf6f5000-7f0cdf8f4000 ---p 00008000 08:03 4724969                    /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f0cdf8f4000-7f0cdf8f5000 r--p 00007000 08:03 4724969                    /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f0cdf8f5000-7f0cdf8f6000 rw-p 00008000 08:03 4724969                    /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f0cdf8f6000-7f0cdfd6c000 r--p 00000000 08:03 4593873                    /usr/lib/locale/locale-archive
7f0cdfd6c000-7f0cdfd71000 r-xp 00000000 08:03 4595071                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f0cdfd71000-7f0cdff70000 ---p 00005000 08:03 4595071                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f0cdff70000-7f0cdff71000 r--p 00004000 08:03 4595071                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f0cdff71000-7f0cdff72000 rw-p 00005000 08:03 4595071                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f0cdff72000-7f0cdff74000 r-xp 00000000 08:03 4595060                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f0cdff74000-7f0ce0173000 ---p 00002000 08:03 4595060                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f0ce0173000-7f0ce0174000 r--p 00001000 08:03 4595060                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f0ce0174000-7f0ce0175000 rw-p 00002000 08:03 4595060                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f0ce0175000-7f0ce0181000 r-xp 00000000 08:03 4722301                    /lib/x86_64-linux-gnu/libudev.so.0.13.0
7f0ce0181000-7f0ce0380000 ---p 0000c000 08:03 4722301                    /lib/x86_64-linux-gnu/libudev.so.0.13.0
7f0ce0380000-7f0ce0381000 r--p 0000b000 08:03 4722301                    /lib/x86_64-linux-gnu/libudev.so.0.13.0
7f0ce0381000-7f0ce0382000 rw-p 0000c000 08:03 4722301                    /lib/x86_64-linux-gnu/libudev.so.0.13.0
7f0ce0382000-7f0ce03a9000 r-xp 00000000 08:03 4720130                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f0ce03a9000-7f0ce05a9000 ---p 00027000 08:03 4720130                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f0ce05a9000-7f0ce05ab000 r--p 00027000 08:03 4720130                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f0ce05ab000-7f0ce05ac000 rw-p 00029000 08:03 4720130                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f0ce05ac000-7f0ce05c4000 r-xp 00000000 08:03 4724961                    /lib/x86_64-linux-gnu/libresolv-2.15.so
7f0ce05c4000-7f0ce07c4000 ---p 00018000 08:03 4724961                    /lib/x86_64-linux-gnu/libresolv-2.15.so
7f0ce07c4000-7f0ce07c5000 r--p 00018000 08:03 4724961                    /lib/x86_64-linux-gnu/libresolv-2.15.so
7f0ce07c5000-7f0ce07c6000 rw-p 00019000 08:03 4724961                    /lib/x86_64-linux-gnu/libresolv-2.15.so
7f0ce07c6000-7f0ce07c8000 rw-p 00000000 00:00 0 
7f0ce07c8000-7f0ce07e5000 r-xp 00000000 08:03 4722384                    /lib/x86_64-linux-gnu/libselinux.so.1
7f0ce07e5000-7f0ce09e4000 ---p 0001d000 08:03 4722384                    /lib/x86_64-linux-gnu/libselinux.so.1
7f0ce09e4000-7f0ce09e5000 r--p 0001c000 08:03 4722384                    /lib/x86_64-linux-gnu/libselinux.so.1
7f0ce09e5000-7f0ce09e6000 rw-p 0001d000 08:03 4722384                    /lib/x86_64-linux-gnu/libselinux.so.1
7f0ce09e6000-7f0ce09e7000 rw-p 00000000 00:00 0 
7f0ce09e7000-7f0ce09fd000 r-xp 00000000 08:03 4722407                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f0ce09fd000-7f0ce0bfc000 ---p 00016000 08:03 4722407                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f0ce0bfc000-7f0ce0bfd000 r--p 00015000 08:03 4722407                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f0ce0bfd000-7f0ce0bfe000 rw-p 00016000 08:03 4722407                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f0ce0bfe000-7f0ce0c06000 r-xp 00000000 08:03 4595414                    /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f0ce0c06000-7f0ce0e06000 ---p 00008000 08:03 4595414                    /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f0ce0e06000-7f0ce0e07000 r--p 00008000 08:03 4595414                    /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f0ce0e07000-7f0ce0e08000 rw-p 00009000 08:03 4595414                    /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f0ce0e08000-7f0ce0e0a000 r-xp 00000000 08:03 4595462                    /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f0ce0e0a000-7f0ce1009000 ---p 00002000 08:03 4595462                    /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f0ce1009000-7f0ce100a000 r--p 00001000 08:03 4595462                    /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f0ce100a000-7f0ce100b000 rw-p 00002000 08:03 4595462                    /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f0ce100b000-7f0ce1031000 r-xp 00000000 08:03 4726767                    /lib/x86_64-linux-gnu/libpng12.so.0.46.0
7f0ce1031000-7f0ce1231000 ---p 00026000 08:03 4726767                    /lib/x86_64-linux-gnu/libpng12.so.0.46.0
7f0ce1231000-7f0ce1232000 r--p 00026000 08:03 4726767                    /lib/x86_64-linux-gnu/libpng12.so.0.46.0
7f0ce1232000-7f0ce1233000 rw-p 00027000 08:03 4726767                    /lib/x86_64-linux-gnu/libpng12.so.0.46.0
7f0ce1233000-7f0ce12c3000 r-xp 00000000 08:03 4588682                    /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2
7f0ce12c3000-7f0ce14c2000 ---p 00090000 08:03 4588682                    /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2
7f0ce14c2000-7f0ce14c9000 r--p 0008f000 08:03 4588682                    /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2
7f0ce14c9000-7f0ce14ca000 rw-p 00096000 08:03 4588682                    /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2
7f0ce14ca000-7f0ce14e7000 r-xp 00000000 08:03 4590354                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f0ce14e7000-7f0ce16e6000 ---p 0001d000 08:03 4590354                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f0ce16e6000-7f0ce16e7000 r--p 0001c000 08:03 4590354                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f0ce16e7000-7f0ce16e8000 rw-p 0001d000 08:03 4590354                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f0ce16e8000-7f0ce177f000 r-xp 00000000 08:03 4587930                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0
7f0ce177f000-7f0ce197e000 ---p 00097000 08:03 4587930                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0
7f0ce197e000-7f0ce1984000 r--p 00096000 08:03 4587930                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0
7f0ce1984000-7f0ce1985000 rw-p 0009c000 08:03 4587930                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0
7f0ce1985000-7f0ce19a7000 r-xp 00000000 08:03 4719145                    /lib/x86_64-linux-gnu/libblkid.so.1.1.0
7f0ce19a7000-7f0ce1ba7000 ---p 00022000 08:03 4719145                    /lib/x86_64-linux-gnu/libblkid.so.1.1.0
7f0ce1ba7000-7f0ce1baa000 r--p 00022000 08:03 4719145                    /lib/x86_64-linux-gnu/libblkid.so.1.1.0
7f0ce1baa000-7f0ce1bab000 rw-p 00025000 08:03 4719145                    /lib/x86_64-linux-gnu/libblkid.so.1.1.0
7f0ce1bab000-7f0ce1bcb000 r-xp 00000000 08:03 4719117                    /lib/libdevmapper.so.1.02.1
7f0ce1bcb000-7f0ce1dcb000 ---p 00020000 08:03 4719117                    /lib/libdevmapper.so.1.02.1
7f0ce1dcb000-7f0ce1dcc000 r--p 00020000 08:03 4719117                    /lib/libdevmapper.so.1.02.1
7f0ce1dcc000-7f0ce1dce000 rw-p 00021000 08:03 4719117                    /lib/libdevmapper.so.1.02.1
7f0ce1dce000-7f0ce1dd0000 r-xp 00000000 08:03 4724971                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f0ce1dd0000-7f0ce1fd0000 ---p 00002000 08:03 4724971                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f0ce1fd0000-7f0ce1fd1000 r--p 00002000 08:03 4724971                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f0ce1fd1000-7f0ce1fd2000 rw-p 00003000 08:03 4724971                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f0ce1fd2000-7f0ce1fd9000 r-xp 00000000 08:03 4720117                    /lib/x86_64-linux-gnu/librt-2.15.so
7f0ce1fd9000-7f0ce21d8000 ---p 00007000 08:03 4720117                    /lib/x86_64-linux-gnu/librt-2.15.so
7f0ce21d8000-7f0ce21d9000 r--p 00006000 08:03 4720117                    /lib/x86_64-linux-gnu/librt-2.15.so
7f0ce21d9000-7f0ce21da000 rw-p 00007000 08:03 4720117                    /lib/x86_64-linux-gnu/librt-2.15.so
7f0ce21da000-7f0ce2216000 r-xp 00000000 08:03 4726756                    /lib/x86_64-linux-gnu/libpcre.so.3.12.1
7f0ce2216000-7f0ce2415000 ---p 0003c000 08:03 4726756                    /lib/x86_64-linux-gnu/libpcre.so.3.12.1
7f0ce2415000-7f0ce2416000 r--p 0003b000 08:03 4726756                    /lib/x86_64-linux-gnu/libpcre.so.3.12.1
7f0ce2416000-7f0ce2417000 rw-p 0003c000 08:03 4726756                    /lib/x86_64-linux-gnu/libpcre.so.3.12.1
7f0ce2417000-7f0ce241e000 r-xp 00000000 08:03 4595204                    /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0
7f0ce241e000-7f0ce261d000 ---p 00007000 08:03 4595204                    /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0
7f0ce261d000-7f0ce261e000 r--p 00006000 08:03 4595204                    /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0
7f0ce261e000-7f0ce261f000 rw-p 00007000 08:03 4595204                    /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0
7f0ce261f000-7f0ce2621000 r-xp 00000000 08:03 4595069                    /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0
7f0ce2621000-7f0ce2820000 ---p 00002000 08:03 4595069                    /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0
7f0ce2820000-7f0ce2821000 r--p 00001000 08:03 4595069                    /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0
7f0ce2821000-7f0ce2822000 rw-p 00002000 08:03 4595069                    /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0
7f0ce2822000-7f0ce2824000 r-xp 00000000 08:03 4595065                    /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0
7f0ce2824000-7f0ce2a23000 ---p 00002000 08:03 4595065                    /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0
7f0ce2a23000-7f0ce2a24000 r--p 00001000 08:03 4595065                    /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0
7f0ce2a24000-7f0ce2a25000 rw-p 00002000 08:03 4595065                    /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0
7f0ce2a25000-7f0ce2a2e000 r-xp 00000000 08:03 4596119                    /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f0ce2a2e000-7f0ce2c2d000 ---p 00009000 08:03 4596119                    /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f0ce2c2d000-7f0ce2c2e000 r--p 00008000 08:03 4596119                    /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f0ce2c2e000-7f0ce2c2f000 rw-p 00009000 08:03 4596119                    /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
7f0ce2c2f000-7f0ce2c36000 r-xp 00000000 08:03 4589482                    /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
7f0ce2c36000-7f0ce2e35000 ---p 00007000 08:03 4589482                    /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
7f0ce2e35000-7f0ce2e36000 r--p 00006000 08:03 4589482                    /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
Comment 98 Phillip Susi 2015-12-07 13:31:34 UTC
Can you try building with debug symbols so the stack trace is usable?  Also since it seems to be an allocation error, maybe running it under valgrind would be helpful.
Comment 99 Mike Fleetwood 2015-12-07 13:39:26 UTC
Comment #96 has a stack trace with debug symbols included.
Comment 100 Phillip Susi 2015-12-12 01:15:57 UTC
Somehow an OperationDetail is being created, added to its parent's list of children, then destroyed, while the pointer to it remains in the parent's list of children.
Comment 101 Phillip Susi 2015-12-12 21:25:43 UTC
Ok, I figured it out.  I ran into this back when I did "Change OperationDetail to not store complex objects in STL containers (#729139)".  I have no idea why, but sigc::bind does NOT like it when you pass it a reference.  Changing the references to pointers fixes it.
Comment 102 Phillip Susi 2015-12-12 21:27:12 UTC
Created attachment 317254 [details] [review]
0001-Display-progress-during-resize-467925.patch
Comment 103 Phillip Susi 2015-12-12 21:28:09 UTC
Created attachment 317255 [details] [review]
0002-Display-progress-for-mke2fs-467925.patch
Comment 104 Phillip Susi 2015-12-12 21:28:27 UTC
Created attachment 317256 [details] [review]
0003-Display-progress-for-e2fsck-467925.patch
Comment 105 Curtis Gedak 2015-12-12 22:08:02 UTC
Thanks Phillip for the updated patches.

The new patches in comments 102, 103, and 104 now no longer crash when applying operations.

On kubuntu 12.04 I successfully tested the following:

A) Create ext3 file system of 130 GiB shows progress bar growing from 0 to 100%.
B) Check ext3 file system of 130 GiB shows progress bar growing from 0 to 100%.

However, when I tried growing an ext3 file system from 2 GiB to 130 GiB, the resize step showed only the progress bar at 100%.  It was similar with an NTFS file system, but this ran so fast that I couldn't be sure if the indicator was progressing.

On another note, a small request for future patch sets is to include them in a single patch file.  When I create my patch sets I use:

$ git format-patch origin/master -n --stdout > mypatchset-vX.patch

Thanks,
Curtis
Comment 106 Mike Fleetwood 2015-12-14 11:07:26 UTC
Created attachment 317343 [details] [review]
Progress bars (v10)

Hi All,

As Curtis identified resizing ext2/3/4 progress bar goes to 100% and
stays there while the command outputs more Xs.

Resizing of NTFS progress bar work correctly.


Attached is patchset v10.  The only difference is changes in
ext2::resize_progress() which corrects the progress bar.

(Resize2fs outputs 40 dashes, 40 backspaces and then as progress is made
40 Xs.  However the Gtk text widget doesn't interpret backspaces so
PipeCapture::OnReadable() has to interpret backspace characters as
moving the "cursor" on the line and writing new characters as replacing
existing ones.  Therefore what ext2::resize_progress() sees is always a
progress bar of fixed length with dashes changing to Xs.  The old code
was just counting the length of the progress bar which was always fixed.
The new code counts the length of the progress bar and the number of Xs
in it to calculate the progress).

Thanks,
Mike
Comment 107 Curtis Gedak 2015-12-14 17:51:47 UTC
Thanks Mike for the updated patch set v10.

I tested on kubuntu 12.04 and confirmed that resize2fs progress is now correctly reported with the progress bar growing from 0 to 100%.

Over the next while I plan to test on several distros to see if any other problems arise.

Curtis
Comment 108 Curtis Gedak 2015-12-15 18:55:31 UTC
Hi Phillip and Mike,

Have you ever had that sinking feeling when you planned to run

  sudo rm -rf ./home

but instead ran

  sudo rm -rf  /home
              ^
           Note leading dot is missing!

when intending to delete a partial copy of the actual home directory?
I realized my mistake quickly, but not before some damage was done.

That's what I just did when preparing to test shrinking an NTFS
partition.

I've now just finished comparing files from a month old backup, and
the recent partial copy of /home.  I think I've recovered most
everything, but only time will tell.

It's been a long time since I've done something like this.  The last
time was with GParted testing as well.  Anyways....


Following are my test results of patch set v10 from comment #106.  The
most extensive tests were performed on kubuntu 12.04, and a smaller
set of tests will be later performed on various GNU/Linux
distributions.

Kubuntu 12.04
-------------

EXT2/3/4 TESTS

1)  Grow 2 GiB ext3 partition to 129 GiB.  SUCCESS
    - Progress bar moves from 0 to 100%.
    - Cancel -> Force Cancel selection does stop the running resize2fs
      operation

2)  Check 129 GiB ext3 partition.  SUCCESS.
    - Progress bar moves from 0 to 100%.
    - Cancel selection does stop the the running e2fsck operation

3)  Format 129 GiB partition to ext2.  SUCCESS.
    - Progress bar moves from 0 to 100%.
    - Cancel -> Force Cancel selection does eventually stop the
      running mkfs.ext2 operation (not immediately) *

4)  Shrink 129 GiB ext2 partition to 2 GiB.  SUCCESS
    - Progress bar moves from 0 to 100%.
    - Cancel -> Force Cancel selection does stop the running resize2fs
      operation

5)  Create 129 GiB ext2 partition.  SUCCESS
    - Progress bar moves from 0 to 100%.
    - Cancel -> Force Cancel selection does eventually cancel the
      running mkfs.ext2 operation (not immediately) *

* For some reason the command is not immediately cancelled, but the
  resulting file system operation does appear to indeed be cancelled
  in that the created file system is invalid.

NTFS TESTS

6)  Grow 1 GiB ntfs partition to 149 GiB.  SUCCESS
    - Process is too fast to measure with no time to cancel

7)  13% fill 149 GiB ntfs partition, empty, then shrink to 1 GiB.  SUCCESS
    - Process still too fast to measure with no time to cancel

    (This is where I accidentally deleted some of my /home directory)


I'll try testing on some other distros soon.  Right now I feel a
pressing need to make an immediate backup of my /home directory.  :-)

Curtis
Comment 109 Mike Fleetwood 2015-12-15 20:36:31 UTC
Hi Curtis,

Ouch.  Definitely recommend an automated backup.  I have a cron job run
my backup daily to an old machine.  Even if I completely wipe my desktop
I loose at most 24 hours.  If you want more details please ask.

To slow down an NTFS shrink prepare a file system like this:
1)  Create an NTFS (at least 10 GiB perhaps more) and mount at /mnt/1
2)  Half fill with zeros (5 GiB in this case):
      dd if=/dev/zero bs=1M of=/mnt/1/zeros count=5120
3)  Copy on lots of files:
      cd /mnt/1
      cp -a ~/programming/c/gparted gparted-1
      cp -a ~/programming/c/gparted gparted-2
      ...
4)  Remove zeros:
      cd /mnt/1
      rm zeros

Shrink file system to half size or less.  This forces all the files to
be moved below the half size mark where the zero file was.  Works for
all file systems as they all start allocating from the beginning.  To
make the resize take longer just copy on more files to be moved, making
the initial file system larger if needed.

Thanks,
Mike
Comment 110 Phillip Susi 2015-12-15 21:12:15 UTC
And for ext[234] you can use e2defrag to move files to the right to force resize2fs to have to move them back to the left ;)
Comment 111 Curtis Gedak 2015-12-16 18:24:46 UTC
Hi Phillip and Mike,

Thank you for your tips on preparing file systems for resize tests.

Following are more testing results.

KUBUNTU 12.04 NTFS TEST
=======================

A)  Grow 1 GiB ntfs partition to 149 GiB.  SUCCESS
    - Progress bar moves from 0 to 100%.
    - Cancel -> Force Cancel selection does eventually stop the
      running ntfsresize operation


DISTRO TESTS
============

                OPERATION WORKS AS EXPECTED WITH NO CRASHES
DISTRO          mke2fs   e2fsck   resize2fs   ntfsresize
-------------   ------   ------   ---------   ----------
Debian 7          Yes      Yes         Yes          Yes
Debian 8          Yes      Yes         Yes          Yes
Fedora 12*        Yes      Yes         Yes          Yes
Fedora 22         Yes      Yes         Yes          Yes
Fedora 23         Yes      Yes         Yes          Yes
openSUSE 13.1     Yes      Yes         Yes          Yes
openSUSE 13.2     Yes      Yes         Yes          Yes
kubuntu 12.04     Yes      Yes         Yes          Yes
Ubuntu 14.04      Yes      Yes         Yes          Yes
Ubuntu 15.10      Yes      Yes         Yes          Yes

* Old VM I tested out of curiousity for backward compatibility.

Based on my testing, patch set v10 in comment #106 is ready to be
committed to the git master branch.

If there are no objections then I commit the patch set in the next day
or so.

Curtis
Comment 112 Curtis Gedak 2015-12-18 16:34:37 UTC
Thank you Phillip, Mike, and many others for your work to improve GParted with better progress indicators.

Patch set v10 from comment #106 has been committed to the git repository for inclusion in the next release of GParted.

The relevant git commits can be viewed at the following links:

Display progress during resize (#467925)
https://git.gnome.org/browse/gparted/commit/?id=57b028bb8e7c9fa5e750624f405cc268dfa3b4af

Display progress for mke2fs (#467925)
https://git.gnome.org/browse/gparted/commit/?id=baea186138cc08cac1f13f28300ca0f4b09ae16d

Display progress for e2fsck (#467925)
https://git.gnome.org/browse/gparted/commit/?id=ae434579e160ca2c306921b12d4211bf9abacef7
Comment 113 Curtis Gedak 2016-01-18 17:44:18 UTC
This enhancement was included in the GParted 0.25.0 release on January 18, 2016.