gparted crash at start: glibmm-ERROR **

[Lito]

TEST CASE:

1. Start gparted from a terminal (starting from the menu works too):
2. The gparted window appears and gparted is scanning the hard disks
3. The gparted window disappears again and the terminal contains the following crash output:

=====================
libparted : 2.3
======================

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_create

aborting...

4. Update to the fixed package and try again
5. Gparted finishes scanning without crash and is ready for use

[bbordwell (benbordwell)]

When opening programs with root privileges you should use gksu. Do 'gksu gparted' and see if this bug is still there.

[Lito (lito-eordes)]

Now gparted start correctly:

$ apt-cache policy gparted
gparted:
  Instalado: 0.6.0-1ubuntu1
  Candidato: 0.6.0-1ubuntu1
  Táboa de versións:
 *** 0.6.0-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

Thanks!

[nh2 (nh2)]

@Lito: Could you please check if this bug is really gone for you? I could start up gparted successfully one time, but any other time I get:

ubuntu@ubuntu:~$ gksu gparted
======================
libparted : 2.3
======================

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_create

aborting...

ubuntu@ubuntu:~$ apt-cache policy gparted
gparted:
  Installiert: 0.6.0-1ubuntu1
  Kandidat: 0.6.0-1ubuntu1
  Versionstabelle:
 *** 0.6.0-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

System is today's Maverick i386 desktop live.

[Lito (lito-eordes)]

Yes, I can execute all times the gparted using gksu:

$ gksu gparted
======================
libparted : 2.3
======================

$ gksu gparted
======================
libparted : 2.3
======================

 $ gksu gparted
======================
libparted : 2.3
======================

$ gksu gparted
======================
libparted : 2.3
======================

$ apt-cache policy gparted
gparted:
  Instalado: 0.6.0-1ubuntu1
  Candidato: 0.6.0-1ubuntu1
  Táboa de versións:
 *** 0.6.0-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

$ uname -a
Linux lito-ubuntu 2.6.35-16-generic #22-Ubuntu SMP Tue Aug 17 02:19:50 UTC 2010 i686 GNU/Linux

:)

[Seth (bugs-sehe)]

I still have this on maverick beta fresh install of today. How come?

I must admit I cannot use gksu, because it will never accept my password (other bug?...) but sudo has always worked and it will be hard to explain to users why it doesn't and they need to type other cryptic characters instead of sudo

[Seth (bugs-sehe)]

Attaching a trace.

This is not related to sudo. I get the exact same trace when using gksu[1].

It seems that it might be crashing while recognizing filesystems during disk scan.
The crash is in GParted::GParted_Core::get_filesystem.

I get the crash with the following root-on lvm2 situation (exporting some unneeded vgs did not alleviate the situation) [2 see below]:

I was able to get a trace by doing:

bash$ apt-get source --compile gparted
bash$ cd gparted-0.6.2/src
bash$ sudo gdb ./gpartedbin
(gdb) break main
(gdb) run
(gdb) catch throw
(gdb) c
...
(gdb) bt full

Detailed output attached

[1] after using 'sudo passwd' to set a root passwd... that is another bug
[2] situation
bash$ mount
/dev/mapper/maverick-root on / type ext4 (rw,relatime,errors=remount-ro,commit=0)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)

bash$ blkid
/dev/sda1: UUID="c9PPRc-17Du-rDa3-esD9-jyj3-W4Sr-dDeWf3" TYPE="LVM2_member"
/dev/sda2: UUID="ISzoCa-R8MQ-Tx9N-8cTY-ANF1-LeBW-7V92lE" TYPE="LVM2_member"
/dev/sda3: UUID="5ixnXP-QUQZ-awQK-Ds0F-XfC2-3EtW-T1a50p" TYPE="LVM2_member"
/dev/sdb1: UUID="LNyV14-uXsI-u3bW-qFYJ-4fRf-17k6-nZPUwS" TYPE="LVM2_member"
/dev/sdb2: UUID="KUjcsT-BfVv-zSJh-2jM2-TD6T-AlEW-FwOPQR" TYPE="LVM2_member"
/dev/sdb3: UUID="NgXnRC-5WEZ-SWk1-Sft6-jAH5-svxW-im8Oon" TYPE="LVM2_member"
/dev/mapper/maverick-root: LABEL="MAV" UUID="cf1053fe-4d18-4a42-8413-41d2d6f0d935" TYPE="ext4"
/dev/mapper/gentoo-root: UUID="7b67ab2b-d835-4de1-9af4-e8b00ebf7b20" TYPE="ext4"
/dev/mapper/ssd-root: LABEL="lucidroot" UUID="2bab86bb-63f7-49e9-aac9-6d4fcbdb5e45" TYPE="ext4"
/dev/mapper/ssd-home: UUID="8206c3b0-54cd-4016-ad97-417de8e2a322" TYPE="ext4"
/dev/mapper/ssd-rescue: LABEL="RESCUEROOT" UUID="591f158a-a30d-49dc-a3a9-3e63ef8a43be" TYPE="ext2"

[Seth (bugs-sehe)]

Disregard my comments about gksu. I was confusing gksu and gksudo

[Jan Claeys (janc)]

$ ls -l /usr/bin/gksudo
lrwxrwxrwx 1 root root 4 2010-03-19 10:02 /usr/bin/gksudo -> gksu*

So, gksu & gksudo are the same application... ;)

----

I won't be surprised if this were related to e.g. bug #609447 and maybe other threading bugs for applications that use GObject.

[Seth (bugs-sehe)]

On 09/15/2010 07:06 AM, Jan Claeys wrote:
> $ ls -l /usr/bin/gksudo
> lrwxrwxrwx 1 root root 4 2010-03-19 10:02 /usr/bin/gksudo -> gksu*
>
> So, gksu & gksudo are the same application... ;)
>
> ----
>
> I won't be surprised if this were related to e.g. bug #609447 and maybe
> other threading bugs for applications that use GObject.
>
>
Yes but they can behave in different ways (and they do).

Example script:

# apple.sh
#!/bin/bash
echo "Eat more $(basename $0)s to stay fit!"
exit 0

Run it and you get

"Eat more apples to stay fit"

Copy or (sym)link it as pear.sh (or donut.sh...?) and the output would
be different

$0.02

[Ignacio Larrain (ilarrain)]

I have the same problem with the last version available in the repositories.

$ apt-cache policy gparted
gparted:
  Instalados: 0.6.2-1ubuntu1
  Candidato: 0.6.2-1ubuntu1
  Tabla de versión:
 *** 0.6.2-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status
$ gksu gparted
======================
libparted : 2.3
======================
glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_create

aborting...

[Andrew France (andrew-avito)]

I had the same problem but cannot reproduce it now since rebooting. I don't recall changing anything. Gparted works fine now!

apt-cache policy gparted
gparted:
  Installed: 0.6.2-1ubuntu1
  Candidate: 0.6.2-1ubuntu1
  Version table:
 *** 0.6.2-1ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

[Seth (bugs-sehe)]

debian/patches/02-btrfs.patch is to blame, attaching a fix that works for me.

Disabling it (by removing the patch or passing --disable-btrfs to configure) might also remove the problem.
Attaching steps to reproduce in next post.

CODE ANALYSIS
==============
GParted_Core.cc contains a glaring in the 'new' Btrfs detection code:

1139 if ( Glib::ustring( buf+64, strlen(BTRFS_SIGNATURE) ) == BTRFS_SIGNATURE)

buf is at that point either NULL or freed (valgrind confirms this). However, simply fixing it into buf_btrfs does not remove all of the problem... so:

$ sudo apt-get install libglibmm-2.4-dbg
(gdb) break GParted_Core.cc:1139
(gdb) dir ../glibmm2.4-2.25.5/glib/glibmm
(gdb) run /dev/loop0
etc.

thave some more insight: GLib::ustring is interpreting the 'random' (i.e. unknown, tainted) data in buffer read from the block device as a supposedly legal utf8 sequence. That borks some of the time (hey my random blocks don't always contain utf8 characters at the exact offset +64, sorry). It seems a lot wiser to substitute a strncmp or even memcmp with that?

My patch below fixes just that, and it works for my disks.

A signature is a signature by it's nature and it might even be used to detect endianness and stuff like that, so interpreting it as utf8 is a bit like playing with fire.

Perhaps GLib::ustring should handle invalid utf sequences robustly. I don't know whether the real bug is in glibmm (throwing because of improper UTF sequences might be ok, but callling a std::string(0) constructor is probably _not_ be intended). Also, this calls to review a lot more ustring operations on raw input buffers, because things could blow up in more places where it is being used on unknown data (raw input buffers).

[Seth (bugs-sehe)]

Steps to reproduce as promised

Using sparse loop devices on /tmp for brevity.

[Seth (bugs-sehe)]

Arg my ubuntu/debian noobness is catching me out.
For some reason including the patch to the file mentioned does not work as advertised. So instead, I went and modified the source manually, after which a pdebuild generates a new patch file

      debian/patches/debian-changes-0.6.2-1ubuntu1

which I attach for ease of reference. The content of the fix is _not_ changed. Remember to register the extra patch in debian/patches/series if you want to actually use the attached file...

      bash$ echo debian-changes-0.6.2-1ubuntu1 >> debian/patches/series

Sorry for the cruft, but I don't know which way you prefer to receive patches

[Aurimas (vinaur)]

This bug seems to be fixed (at least on my machine) in the HEAD revision from git repo as well as source available at sourceforge.net (0.6.4).

[Seth (bugs-sehe)]

@Aurimas: I'd like to verify that but I don't know what repo you refer to

Did you mean upstream (sf.net)? In that case, how would you know it is fixed for ubuntu since the current problem lives exactly in the debian patches (i.e. _not_ in upstream)?

If you have simply taken the latest from the upstream repo, that seems like comparing apples and oranges to me, and has hardly anything to do with the Ubuntu package.

In other words, if you meant HEAD from

     http://git.gnome.org/browse/gparted/

then how can I be sure this fixes it for any distribution? It would hardly be a given that the HEAD revision will end up in any stable distro (normally, the latest stable will be used); besides, packagers might not 'get it right' in dropping/fixing the
02_btrfs.patch as required.

Which loops back to my question: where / how can I test this for Ubuntu?

[Seth (bugs-sehe)]

For background, I have just analysed the history in the git.gnome.org repo I mention. There hasn't been a change recently there, a.f.a.i.c.t. More specifically, their BTRFS detection code has been in there since Feb 23, 2009 (!!!) unaltered. So that makes it a part of upstream ever since GParted 0.4.4.

That gives me little reason to expect that packagers would change anything about the patch that is wreaking havoc at this point.
Let me add: I have only done a targeted history search, there might be other reasons why the patch would be removed/changed (and
 Aurimas might have concrete information on the debianized version that I don't have available), but this is what I _do have_ at the moment:

$ git remote -v
origin git://git.gnome.org/gparted (fetch)
origin git://git.gnome.org/gparted (push)

$ git log -i --grep=BTRFS --pickaxe-all
commit dc1ab54d8f2c40d628df01f48f6773bfe5fdab34
Author: Curtis Gedak <email address hidden>
Date: Mon Feb 23 20:22:30 2009 +0000

    Added detection of btrfs file system

    svn path=/trunk/; revision=1075

$ git describe dc1ab54d8f2c40d628df
GPARTED_0_4_3-10-gdc1ab54
$ git tag --contains dc1ab54d8f2c40d628df
GPARTED_0_4_4
GPARTED_0_4_5
GPARTED_0_4_6
GPARTED_0_4_7
GPARTED_0_4_8
GPARTED_0_5_0
GPARTED_0_5_1
GPARTED_0_5_2
GPARTED_0_6_0
GPARTED_0_6_1
GPARTED_0_6_2
GPARTED_0_6_3
GPARTED_0_6_4

[Aurimas (vinaur)]

@Seth: Yes, I did mean git://git.gnome.org/gparted

My apologies for the noobness. I was not aware there were ubuntu specific patches applied to the packages. Live and learn.

Your patch did prevent gparted from crashing on my setup.

[Seth (bugs-sehe)]

On 10/03/2010 12:32 AM, Aurimas wrote:
> @Seth: Yes, I did mean git://git.gnome.org/gparted
>
> My apologies for the noobness. I was not aware there were ubuntu
> specific patches applied to the packages. Live and learn.
>

I'm pretty much the noob myself :)
> Your patch did prevent gparted from crashing on my setup.
>
>
Thanks for reporting back

By the way, the patch in debian seems largely based on the topic branch
lucab/btrfs
 (If I'm not wrong, 'lucab' is Luca Bruno, who seems to be a debian
developer). So it might actually be fixed when the patch is regenerated
from the topic branch _if_ it had been fixed there.

I'm not too sure. Anyways, I cannot really find the 'bigger' bug (with
the buf var instead of buf_btrfs) in there anyway, so perhaps there was
a manual cherry-pick involved. THe tip of the btrfs branch seems to
include the ustring comparison yet, so it is prone to break in the same
fashion as the current Ubuntu version.

I might check to see whether I can get Luca Bruno in contact directly

Cheers,
Seth

[Luca Bruno (lucab)]

Thanks Seth for drawing my attention on this.
Firstly, I was not aware of this ubuntu patching, and I would suggest to refresh the patch with the "lucab/btrfs" branch, which is currently much healthier :)
Regarding the buf/buf_btrfs issue, it's certainly my fault and it slopped through when Cedric adopted parts of the original patch.
Regarding memcmp, it may sound safer to do so, but when writing btrfs discovery I just adopted previous checking style; I will ask Cedric about it.

I'm now opening an upstream bug regarding both issues, in the meantime I believe you can safely integrate your patch.

[Seth (bugs-sehe)]

On 10/03/2010 05:23 PM, Luca Bruno wrote:
> Thanks Seth for drawing my attention on this.
> Firstly, I was not aware of this ubuntu patching, and I would suggest to refresh the patch with the "lucab/btrfs" branch, which is currently much healthier :)
> Regarding the buf/buf_btrfs issue, it's certainly my fault and it slopped through when Cedric adopted parts of the original patch.
> Regarding memcmp, it may sound safer to do so, but when writing btrfs discovery I just adopted previous checking style; I will ask Cedric about it.
>
> I'm now opening an upstream bug regarding both issues, in the meantime I
> believe you can safely integrate your patch.
>
>
Thanks for the heads up! And also thanks for coordinating with the
gparted devs

Cheers,
Seth

[Curtis Gedak (gedakc)]

Thanks Seth for doing the hard work of finding the root cause of the problem and for developing a patch to resolve the problem.

Also thank you Luca Bruno for subscribing me to this bug report.

I think that this problem is the same as the bug #609477:
     gpartedbin crashed with signal 5 in Glib::exception_handlers_invoke()
     https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/609447

For GParted 0.7.0, we (upstream) plan to include BTRFS support, so the patches from Seth are very timely. :-)

Development Plans for the Next Release of GParted (0.7.0)
http://gparted-forum.surf4.info/viewtopic.php?id=14331

[Luca Bruno (lucab)]

> I think that this problem is the same as the bug #609477:

I think it too.
Are you going to replace all those ustring objects for next release cycle?

> For GParted 0.7.0, we (upstream) plan to include BTRFS support, so the patches from Seth are very timely. :-)

Curtis, as the discovery part is already in master, will you take care of s/buf/buf_btrfs/ in master or should I commit on btrfs branch?
Regarding other comments about btrfs support, I'll follow up on gnome bugzilla.

[Curtis Gedak (gedakc)]

> Are you going to replace all those ustring objects for next release cycle?

To clarify, are you referring to all of the ustring objects in the GParted_Core::get_filesystems() method?

For example the following line of code to detect LUKS encryption:

  if ( Glib::ustring( magic1 ) == "LUKS\xBA\xBE" )

Or did you mean just the code to work with BTRFS?

> Curtis, as the discovery part is already in master, will you take care of s/buf/buf_btrfs/ in master or should I commit on btrfs branch?

Yes, I will take care of this change in master, and plan to roll your lucab/btrfs branch into master soon.

[Luca Bruno (lucab)]

> For example the following line of code to detect LUKS encryption:
>
> if ( Glib::ustring( magic1 ) == "LUKS\xBA\xBE" )

Yes. If I'm reading comment #12 correctly, Seth is saying that ustring constructor is often unhappy when fed with raw-from-disk data (invalid utf-8?). In particular, he wrote:

> > Also, this calls to review a lot more ustring operations on raw input
> > buffers, because things could blow up in more places where it is
> > being used on unknown data (raw input buffers).

Seth, care to comment?
My opinion is that it may be safer to do a plain memcmp, but I suspect the issue Seth was experiencing was just due to buf_btrfs being not NUL-terminated.

[Seth (bugs-sehe)]

On 10/05/2010 10:52 AM, Luca Bruno wrote:
> Seth, care to comment?
> My opinion is that it may be safer to do a plain memcmp, but I suspect the issue Seth was experiencing was just due to buf_btrfs being not NUL-terminated.
>
>
The nul termination was in order.
The problem is with the GLib::ustring(const char*) constructor not
accepting invalid utf8 sequences[1]. Somewhere down the road this leads
to a std::basic_string<char>(const char* initializer) call, where
initializer is invalid (probably NULL), causing the
basic_string::_S_create exception.

So, in effect there should be an analysis:

(a) whether there is a constructor to GLib::ustring that won't try to
interpret the param as utf8 (treating it as any single-byte char
codepage will do, allthough the conversion to unicode is really only
overhead here)

(b) whether there is a bug in the GLib::ustring constructor making it
fail in this manner. Perhaps report upstream.

(c) In last instance, not depending on upstream glibmm could be
simplest. I think it is not the best tool for the job, especially when
treating disk block data. There is no sense in interpreting that as
unicode text off-hand, because there really is no telling what the block
contains (it could be AES encrypted device, for all we know!).

My personal preference would be to discontinue use of ustring where it
isn't appropriate (like when comparing binary disk blobs, as in the case
of finding filesystem/partition type signatures). But I understand that
the impact is high and requires human analysis. So there might be a more
efficient solution this time around.

[1] This, in it's own right, might make it 'jump' the null-terminator,
but that's hardly relevant

[Curtis Gedak (gedakc)]

Thank you Luca and Seth for clarifying the problem for me.

If I understand this correctly, one of the best ways to avoid this problem is to not use Glib::ustring when reading data directly from the disk.

Luca,

I will investigate removing the Glib::ustring stuff from the GParted_Core::get_filesystem() method to avoid this potential problem for other file system types.

Seth,

I was about to apply the patch from comment #12 but noticed there might be an undesired side effect. It appears to me that if a match is found for the BTRFS_SIGNATURE, then the method will exit returning FS_BTRFS, but that the following line to close the device will not be executed.

Have I interpreted the patch code correctly?

If so, would you like to rework the patch to permit closing of the device?
If not, I can rework the patch. I would still give credit to you though since you found the underlying problem. :-)

[Seth (bugs-sehe)]

I have taken the time to review all usage of ustring in gparted

This resulted in a patch against master (30efae4), which I attach. This patch can be cleanly cherry-picked onto the btrfs branch.

You can also get the resulting revisions from my git repo

git remote add --fetch sehe.nl git://git.sehe.nl/git/gparted
git pull --ff-only sehe.nl master

[Seth (bugs-sehe)]

On 10/05/2010 05:40 PM, Curtis Gedak wrote:
> Thank you Luca and Seth for clarifying the problem for me.
>
> If I understand this correctly, one of the best ways to avoid this
> problem is to not use Glib::ustring when reading data directly from the
> disk.
>
>
> Luca,
>
> I will investigate removing the Glib::ustring stuff from the
> GParted_Core::get_filesystem() method to avoid this potential problem
> for other file system types.
>
>
> Seth,
>
> I was about to apply the patch from comment #12 but noticed there might
> be an undesired side effect. It appears to me that if a match is found
> for the BTRFS_SIGNATURE, then the method will exit returning FS_BTRFS,
> but that the following line to close the device will not be executed.
>
> Have I interpreted the patch code correctly?
>
> If so, would you like to rework the patch to permit closing of the device?
> If not, I can rework the patch. I would still give credit to you though since you found the underlying problem. :-)
>
>
I have just posted a patch that does The Right Thing in get_filesystems
and it does so by mimimal edits from master [1]
I guess that should obsolete the question.

Cheers,
Seth

[Curtis Gedak (gedakc)]

Wow, that was fast! Thank you Seth.

I will look into applying these patches to master. I appreciate you supplying the git commands for your git repo too. Though I use git frequently I am by no means an expert with git.

[Seth (bugs-sehe)]

On 10/05/2010 06:09 PM, Curtis Gedak wrote:
> Wow, that was fast! Thank you Seth.
>
It wasn't! Your question just crossed my post at launchpad

I spent all afternoon fiddling with the codebase and eclipse CDT.
Eclipse rocks big time, fyi. I might be dropping vim for c++ development
after all some day

> I will look into applying these patches to master. I appreciate you
> supplying the git commands for your git repo too. Though I use git
> frequently I am by no means an expert with git.
>
>
No problem

[Curtis Gedak (gedakc)]

Thanks again for the patch Seth. My preliminary testing went well so I have committed the patch to the Gnome git repository for GParted for inclusion in the next release of GParted (0.7.0).

For those curious, the plans for GParted 0.7.0 can be viewed at the following link:
http://gparted-forum.surf4.info/viewtopic.php?id=14331

[nh2 (nh2)]

Just to make sure: Is gparted in today's 10.10 release broken?

[Hutter-matthias (hutter-matthias)]

It is broken for me

[Shaggy (bdmason)]

I'm using maverick amd64 livecd final release and this is broken for me.

[Ignacio Larrain (ilarrain)]

I've just runned an upgrade and it's still brolen for me.

On Mon, Oct 11, 2010 at 4:02 PM, Shaggy <email address hidden> wrote:

> I'm using maverick amd64 livecd final release and this is broken for me.
>
> --
> gparted crash at start: glibmm-ERROR **
> https://bugs.launchpad.net/bugs/617885
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Saludos
Ignacio

[vyncere (vyncere)]

Still broken with Ubuntu 10.10 Final amd64. parted (on console) does not crash.

[DavidL (w-launchpad-larochelle-name)]

Present in Ubuntu 10.10

Here's how I triggered the bug.

Use the shred command to zero out a partition:

shred -vz -n 1 /dev/sda2

Running gparted then results in:

dlarochelle@sileo:~$ sudo gparted
======================
libparted : 2.3
======================

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_create

aborting...

After manually formatting the partition using mkfs.ntfs

gparted starts up fine.

--

This bug is important because:
Zeroing out a partition for security reasons and then wanting to reformat it is perfectly common behavior.
SInce gparted is the default tool for formatting a partition I would expect this to work.

[Ryan Karl (rawrmage)]

As DavidL reported, my partition was zeroed out, and gparted also crashed.
Once I ran mkfs.ext3 on it, gparted ran correctly.

[Seth (bugs-sehe)]

about using a zeroed image to reproduce, see my comment #13 (#12) for analysis.

Also note a fix has been contributed both here (patch attached) and upstream (see http://gparted.sehe.nl/?p=gparted.git;a=commitdiff;h=2190bcfba4b), so analysis can be safely considered complete, IMHO

Do we need to update bug status to avoid people doing double efforts?

[psl (slansky)]

U10.10, i386

$ sudo gparted
======================
libparted : 2.3
======================

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_create

aborting...

$ dpkg -la | grep gparted
ii gparted 0.6.2-1ubuntu1

[nh2 (nh2)]

@Seth: So the question is actually if the fix can be brought into Ubuntu repositories. Would be quite sensible for me because gparted seems completely broken.

[Seth (bugs-sehe)]

@nh2: +1. I would say, for many intents and purposes, gparted appears to be broken.

[Mathieu Simon (mathieu-simon)]

@Seth
Yup seems so.

In meantime since I really needed it I was able to build 0.64 from source. Runs without problems but ?d prefer to use the distro packaged gparted. Seems the gparted in maverick was patched to death? ;)

[Seth (bugs-sehe)]

On 10/18/2010 04:25 PM, Mathieu Simon wrote:
> @Seth
> Yup seems so.
>
> In meantime since I really needed it I was able to build 0.64 from
> source. Runs without problems but ?d prefer to use the distro packaged
> gparted. Seems the gparted in maverick was patched to death? ;)
>
>
I don't really know what you mean by that, but in case you are
suggesting a debian patch causes the problem, this is only marginally
so: mainly the version is just behind upstream. The btfs patch
originates from the upstream lucab/btrfs branch

[Mateusz Marzantowicz (mmarzantowicz)]

I would like to report that gaprted is still broken on Ubuntu 10.10 both amd64 and x86 (I have tested this on both architectures).

On both machines it dies during start up. Here goes mysterious result form gparted:

$ gksu gparted
======================
libparted : 2.3
======================
glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_create

aborting...

I'm using LVM and have ext4, ntfs and swap partitions on my hard drive (in case it helps you diagnose the problem).

[Curtis Gedak (gedakc)]

In follow up to comment #32, the patch by Seth will be included in the upstream release of GParted 0.7.0 on October 29, 2010.

For anyone interested in testing GParted 0.7.0-beta1 prior to the release date, this version is currently available on the beta version of the System Rescue CD:
http://www.sysresccd.org/Beta-x86

[Curtis Gedak (gedakc)]

Thanks go to Seth for providing a patch to resolve this problem.

The enhancements to address this bug report have been included upstream in GParted 0.7.0
which was released on October 29, 2010.

[jayseye (jayseye)]

How long does it typically take for a new upstream version to be packaged for Ubuntu?

Having the same problem on PowerPC under Maverick, and may build from source if there will be more than a few days of lag time.

Thanks to all who have helped trace and fix this issue!

Regards,
jaysye

[Marco Lackovic (marco-lackovic)]

I am still having this problem on Ubuntu 10.10 64.

gksu gparted
======================
libparted : 2.3
======================

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_create

aborting...

[Mathieu Simon (mathieu-simon)]

@seth - Sorry for forgetting to answer:

I just meant that in case there are people who don't need your patch can build and use gparted from source - while not having all the functionality. I'm looking forward to see your patch integrated. Thank you for your work.

[Etienne Neveu (neveue)]

Another data point:

I was encountering this bug when using an Ubuntu 10.10 Live CD (on multiple machines).

Using the beta version of the System Rescue CD, GParted works.

Seth, Curtis: thanks a lot!

[Michael Bienia (geser)]

Here is a debdiff for a Ubuntu 10.10 SRU based on the patch from Seth.

Note to sponsors:
I've tested this debdiff with gparted in natty (which is currently the same as in maverick) as I don't have a maverick installation to test it.
The fix for natty is to sync gparted 0.7.0 from Debian unstable (bug 669826).

[Stephan (stephan-stephanx)]

Had the same bug, and this thread helped point me in the right direction. I'm not sure if my response is appropriate, as I'm sure more than a handful of less technical users will find this thread (it's the first few hits for 'gparted crash' search results.) If not, I apologize in advance. I solved the issue by using git to pull the current version of gparted, and building it. From a stock Maverick desktop 64 bit, system, I ran (as root):

# aptitude install git gnome-common libglib2.0.dev uuid-dev libparted-dev libgtkmm-2.4-dev

Then changed to the /tmp directory, ran

# git clone git://git.gnome.org/gparted

# make

# make install

[Юрий Чудновский (fqc)]

Got this bug on scan of my flash drive. Without on that flash it's working.

~$ LC_ALL=C sudo fdisk -l /dev/sdb

Disk /dev/sdb: 4022 MB, 4022337536 bytes
124 heads, 62 sectors/track, 1021 cylinders
Units = cylinders of 7688 * 512 = 3936256 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d9db4

   Device Boot Start End Blocks Id System
/dev/sdb1 1 25 96069 c W95 FAT32 (LBA)
/dev/sdb2 * 26 247 853368 83 Linux
/dev/sdb3 248 1021 2975256 83 Linux

parted works on this flash drive correctly.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gparted - 0.7.0-1

---------------
gparted (0.7.0-1) unstable; urgency=high

  * New upstream release
    Fix gparted crash at start with glibmm-ERROR
      Closes: 601818
      LP: #609477, #617885
    Fix crash moving more than one logical partition right
      Closes: 601817
    Skip move/copy action because linux swap contains no data
      LP: #401228
    Fix several memory leaks and valgrind errors
    Remove unnecessary null pointer checks
    Fix partitions moved or copied are 1 MiB larger
    Insert additional translator comments
    Add initial support for btrfs
 -- Michael Bienia <email address hidden> Thu, 04 Nov 2010 00:16:34 +0000

[jayseye (jayseye)]

Have yet to find a binary package available in the repositories, at least for PowerPC. However, .deb builds may be downloaded through the source package page, under the word Builds:

> https://launchpad.net/ubuntu/+source/gparted/0.7.0-1

While these probably still need testing, they at least save the work of building from source.

Regards,
jayseye

[Arto Jääskeläinen (ajaaskel)]

Just installed gparted_0.7.0-1_i386.deb from

http://launchpadlibrarian.net/58607123/gparted_0.7.0-1_i386.deb

That fixed my gparted 0.6.2 crashing problem at Ubuntu 10.10.

Thanks !

[jayseye (jayseye)]

Yes I can also confirm that the .deb which I mentioned above fixes the problem on PowerPC. Here's a direct link:

> https://launchpad.net/ubuntu/+source/gparted/0.7.0-1/+build/2030806/+files/gparted_0.7.0-1_powerpc.deb

It would be really great to see this version actually released and showing up in Synaptic. I'd be willing to contribute some time / effort if there's anything I could do to expedite that. Any useful advice on how to proceed?

Regards,
jayseye

[D. Hugh Redelmeier (hugh-mimosa)]

I experienced this gparted failure with the 10.10 i386 live-cd. I could work around it with the .deb in message number 58.

[DSutton (dsutton)]

Agreed, gparted did not work for me on the amd64 Maverick live cd until I downloaded the gparted 0.7.0 .deb. This needs to get into Maverick and if possible Maverick live cd as soon as possible. I usually carry around the latest Ubuntu live cd to do rescue on any computer that needs it, often without internet available to download the fix, due to missing wireless drivers,

[psl (slansky)]

As a workaround, I can recommend LiveCD Parted Magic, distribution focused to disk manipulation. Gparted is the main application on the disk; it is ready to go distribution, it is easier to run gparted from PartedMagic LiveCD than to install some DEB packages to "broken" Ubuntu.

http://partedmagic.com/

[Arenlor (arenlor)]

Per #38 I checked and realized I had some zeroed filesystems, did mkfs.ext4 on them, and now gparted works.

[Seth (bugs-sehe)]

A last checkback: I may note that where Arenlor refers to #38, I had this analyzed with steps to reproduce back in #13 (patch in #12 from september 29th...).
It pains me to see that the general public is still not helped with that. I can only hint at the new package for 0.7.0 (god knows where) if you are not up to compiling it from (upstream) source.

I understand that there will be delays, especially with upstream fixes, incubation and distribution release schedules and such. It is just that I sort of expected this to be merged downstream a bit more efficiently because of it's central position in the gnome desktop and the high level of stopping-problem-ness for the end-user.

People who can tell me how else [1] I could expedite this process a next time around, are very much invited to share their knowledge so I can be more effective next time.

[1] I since also contributed this fix directly to the upstream repo for the 0.7.0 version

[Michael Bienia (geser)]

gparted 0.7.0 is in Ubuntu natty (the current Ubuntu development version). And the links from other comments point to debs from natty.

Comment #53 contains a ready patch for a possible Ubuntu maverick SRU and it just awaits review and sponsoring from an Ubuntu core-dev. This bug is listed on the overview page with pending sponsoring requests but nobody picked it up till now :(

[Seth (bugs-sehe)]

On 11/21/2010 09:29 PM, Michael Bienia wrote:
> gparted 0.7.0 is in Ubuntu natty (the current Ubuntu development
> version). And the links from other comments point to debs from natty.
>
> Comment #53 contains a ready patch for a possible Ubuntu maverick SRU
> and it just awaits review and sponsoring from an Ubuntu core-dev. This
> bug is listed on the overview page with pending sponsoring requests but
> nobody picked it up till now :(
>
>
Thanks for the update. It would appear I donot know my way around the
versioning labyrinth. My reasoning is simple: if severe bug, fix swift.
Natty isn't swift by any stretch of imagination.

[Seth (bugs-sehe)]

Barring build problems 0.7.0 should be available for Lucid/Maverick users in a few minutes from my own ppa

The simplest way to add it is

    sudo add-apt-repository ppa:bugs-sehe/gparted

[Note that 0.7.0 is officially deemed unstable with respect to ubuntu. I venture that it is more useful to have potential issues mainly with new functionality (btrfs?) than to have no working gparted at all. This is the best I can do at the moment because I could leverage the existing natty debsrc. Backporting it to the older version(s) failed for me in the past. I'm not a debian dev guru as it appears.]

[jayseye (jayseye)]

Michael, thanks for the explanation. Re Comment #59 I am using that .deb under Maverick, based on your info in Comment #53 stating that Natty was equivalent to Maverick at that time. The .deb installed and worked flawlessly.

Perhaps this info may also be useful to you, Seth. In any case, thanks again for the patch.

WRT GParted Live CD: the .zip version works fine when booted from a USB stick. However the .ISO version reports some errors while booting from CD, on several different PCs. The MD5 matches and the CD is error-free (zero c2 errors), so I felt more confident using the USB version. Planning to report this to the GParted project when I can assemble a complete bug report. Just mentioning it here re Comment #62.

Regards,
jayseye

[Seth (bugs-sehe)]

@jayseye: thanks for reporting that the existing deb works on Maverick

However, it didn't work on Lucid (1) which is the reason I created the ppa. Perhaps other people are helped with that too.

Cheers,
Seth

(1) unresolvable missing dependencies

[Michael Vogt (mvo)]

I will sponsor this upload (and removed ubuntu-sponsors therefore).

[Martin Pitt (pitti)]

Accepted gparted into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Srecko Toroman (sreckotoroman)]

Tested, it works now for me. Thanks!

[Jussi Schultink (jussi01)]

Tested also, works for me.

[jayseye (jayseye)]

Is this an x86-only build? It has yet to show up in Synaptic under PowerPC, though many other packages *are* available from maverick-proposed.

The .deb mentioned above in comments #57 and #59 is still available, and still dated November 4.

It's been made very clear that PowerPC is officially unsupported; however with that .deb automatically built and working for Natty, wouldn't it take extra effort to exclude that build from maverick-proposed?

Or does someone from the PowerPC team need to do something to accept it into Ports? It would really help to understand the process: even just a link to a specific doc would do.

Thanks,
jayseye

[Brian Rogers (brian-rogers)]

The status of the gparted powerpc build is here:
https://launchpad.net/ubuntu/+source/gparted/0.6.2-1ubuntu1.1/+build/2060530

There's just a backlog, and the build will start in about 10 hours.

[Michael Bienia (geser)]

The powerpc build is still pending as the powerpc buildds are currently pretty loaded. It should hopefully build within the next days. You can watch its status at https://launchpad.net/ubuntu/+source/gparted/0.6.2-1ubuntu1.1/+build/2060530

The debs in maverick-proposed are different from those in natty. They just share the same fix which got included upstream and the gparted version in natty contains that version already.

[jayseye (jayseye)]

Thank you Brian, Michael -

Great to hear that PowerPC will be included. However a backport from Natty would be preferable because one other critical fix is also included from upstream, along with other bug fixes (quoted below from their release notes).

Is there a procedure for an end-user to request a backport?

Thanks again,
jayseye

From gparted-0.7.0-notes.txt:

> http://sourceforge.net/projects/gparted/files/gparted/gparted-0.7.0/gparted-0.7.0-notes.txt/download

GPARTED 0.7.0 RELEASE

NOTES

 This release of GParted adds initial support for the btrfs
 file system, and fixes two critical bugs. Also included are
 other bug fixes and language translation updates.

 Key changes include:
   - Add initial support for btrfs
   - Fix crash at start with glibmm-ERROR
   - Fix crash moving more than one logical partition right

BUG FIXES
 * Add initial support for btrfs (#571170)
   - Thanks go to Luca Bruno for this big patch
 * Fix gparted crash at start with glibmm-ERROR
   - Crash due to using ustring for file system signature recognition
   - Ubuntu launchpad #609477
   - Ubuntu launchpad #617885
   - Thanks go to Seth Heeren for this small patch
 * Fix crash moving more than one logical partition right (#628863)
 * Fix several memory leaks and valgrind errors (#631201)
   - Thanks go to Seth Heeren for this small patch
 * Remove unnecessary null pointer checks (#539092)
   - Thanks go Markus Elfring for this small patch
 * Insert additional translator comments (#631684)
 * Fix partitions moved or copied are 1 MiB larger (#632478)
 * Skip move/copy action because linux swap contains no data (#589555)
   - Ubuntu launchpad #401228
 * Ensure 1 MiB reserved when moving partition to start of disk

[Michael Bienia (geser)]

See https://help.ubuntu.com/community/UbuntuBackports for how to request a backport of gparted 0.7.0-1 from natty to maverick-backports.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gparted - 0.6.2-1ubuntu1.1

---------------
gparted (0.6.2-1ubuntu1.1) maverick-proposed; urgency=low

  * debian/patches/04_remove-misuse-of-ustring-in-get_filesystem.patch:
    Apply patch from Seth Heeren to fix crash at startup (lp: #617885).
 -- Michael Bienia <email address hidden> Tue, 02 Nov 2010 10:39:06 +0100

[MsG (mathijs-groothuis)]

Still having the bug with a Live USB stick made from unetbootin which downloaded the latest 10.10 live-cd image.

Apt-cache fix didn't work here.

[Seth (bugs-sehe)]

MsG: i'm pretty sure your confusing things. There is no fix involving apt-cache

There is a fixed package for maverick, just update it from the repo (enable proposed updates), comment #79, e.g.

[Mark Ballenger (mark-ballenger)]

Running netbook 10.10 from a live cd. Gparted starts then crashes immediately. running sudo gparted outputs
glibmm-ERROR **;
unhandled exception (type std::exception) in signal handler:
what: basic_string::_S_Create

This started happening after I tried to backup a hd with PartImage is not Ghost (PING). The backup failed somehow, and really borked my partitions in some way.

[Curtis Gedak (gedakc)]

Mark Ballenger, can you confirm the version of GParted that you are using?