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).
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 Core.cc: 1139 4-2.25. 5/glib/ glibmm
(gdb) break GParted_
(gdb) dir ../glibmm2.
(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).