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).

** Attachment added: "fix utf8 bug in debian/patches/02-btrfs.patch"
   
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/617885/+attachment/1654721/+files/patch

-- 
gparted crash at start: glibmm-ERROR **
https://bugs.launchpad.net/bugs/617885
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to