On Thu, 25 Mar 2021 at 23:22:48 +0000, Simon McVittie wrote:
> On Thu, 25 Mar 2021 at 22:22:33 +0100, Bernhard Übelacker wrote:
> > In the end it looks like in refresh_combo_devices [2] it
> > is attempted to load a harddisk icon.
> >
> > This failed for some reason in [3], therefore a local variable
> > "theme_icon" contains a null pointer, which gets unconditionally
> > called member function get_width on and therefore
> > crashes a few lines later.
>
> This looks like a gparted bug, rather than a libgtkmm-3.0-1v5 bug.
> GParted::Utils::mk_pixbuf calls Gtk::Widget::render_icon_pixbuf,
> presumably a wrapper around gtk_widget_render_icon_pixbuf(), which
> is documented to return NULL if the "stock ID" is not known (as it
> presumably is in this case); but then it calls theme_icon->get_width()
> and theme_icon->get_height() without first checking whether theme_icon is
> a null pointer.
This might have been triggered by not having librsvg2-common installed?
GTK has a Recommends on librsvg2-common, but it is not a hard dependency,
because not all GTK applications strictly need the ability to draw SVG
icons.
The drive-harddisk icon in the Breeze icon theme is a SVG, so it won't
load successfully into GTK unless librsvg2-common is installed.
Adding Depends: librsvg2-common to gparted might resolve this, at the
cost of making gparted not installable on the non-release architectures
that don't have a Rust compiler available.
The other possible solution is to improve gparted's error handling so that
it does not assume that loading an icon will always succeed.
smcv
