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 438572 - program silently quit
program silently quit
Status: RESOLVED DUPLICATE of bug 470387
Product: gparted
Classification: Other
Component: application
0.3.4
Other All
: Normal major
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2007-05-15 11:35 UTC by Maciej Pilichowski
Modified: 2008-06-16 15:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Maciej Pilichowski 2007-05-15 11:35:05 UTC
Please describe the problem:
0.3.4.6.

Please describe the problem:
Please take a look at:
http://bugzilla.gnome.org/show_bug.cgi?id=438570

After applying it to the disk, after several hours, I don't know in what
circumstances, program quit silently. Luckily Gparted moved the partition
without any corruption, but I was really scared that something went really
badly.

It it was an internal crash, I man bad pointer or something, maybe it would be
good, to run gparted via console by default, so the user could take a look at
last trace, or something. And maybe gparted should be run in debug mode only.
After all, all I/O operations are the bottleneck, not the speed of the code.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Matt 2007-08-29 20:59:32 UTC
Same thing happened to me, but unfortunately, I think it hosed my main data partition.  I didn't get a chance to grab any error logs, but here's what happened:

I needed to shuffle partitions around on a 250 GB Western Digital IDE HDD.  I booted up the latest version of SystemRescueCd (v 0.3.7), which uses version 0.3.4 of GParted.  All of the operations seemed to succeed except for the final partition move & resize.  I had freed ~100 GB in front of a 150GB ext3 partition, so I wanted to expand it to fill all the space.  I left it to run overnight, and when I got up it was still moving data, with an ETA of ~4 hours.  When I checked it again in ~2 hrs the program was no longer running.

When I restarted GParted, it sensed that the partition in question was moved to the beginning of the space (but not resized to use all the free space).  I tried running a check on the partition, but the program crashed silently again.  At this point I'm running e2fsck manually, and it's running into tons of problems.  It's been going for hours already, and I feel that most, if not all, of my data is gone.

If there's any more information I can provide to help fix this, let me know.  However, I don't know what more I can tell.

Matt
Comment 2 Curtis Gedak 2008-06-16 15:38:23 UTC
GParted version 0.3.4 had a bug in which it would crash whenever the device list was refreshed (bug #470387).  A device list refresh would occur after all queued operations were completed.  This problem was fixed in GParted versions 0.3.5 and later.

My suspicion is that this was the problem that was encountered with GParted 0.3.4 silently quitting (e.g., crashing).

Hence I am marking this bug as a duplicate (and effectively closing this bug).

If a problem still persists with the latest version of GParted, then please do feel free to open another bug report.



*** This bug has been marked as a duplicate of 470387 ***