Bug 26948 - Setting XDG_DATA_DIRS to a list of paths that does not include "/usr/share" causes gtk+3.x apps to abort / segfault / crash
Summary: Setting XDG_DATA_DIRS to a list of paths that does not include "/usr/share" c...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-14 13:31 CEST by Shlomi Fish
Modified: 2020-08-14 08:21 CEST (History)
3 users (show)

See Also:
Source RPM: gtk+3.0-3.24.21-2.mga8.src.rpm
CVE:
Status comment:


Attachments

Description Shlomi Fish 2020-07-14 13:31:19 CEST
Description of problem:

Setting XDG_DATA_DIRS to a list of paths that does not include "/usr/share" causes gtk+3.x apps to abort / segfault / crash.

E.g:


[shlomif@telaviv1 ~]$ ( export XDG_DATA_DIRS=/notexist ; eom )     

(eom:1888748): GLib-GIO-ERROR **: 14:28:47.952: No GSettings schemas are installed on the system
[1]    1888748 trace trap (core dumped)  ( export XDG_DATA_DIRS=/notexist ; eom; )
[shlomif@telaviv1 ~]$ ( export XDG_DATA_DIRS=/notexist ; gvim -f ) 

(gvim:1888762): Gtk-WARNING **: 14:28:56.851: Could not find the icon 'document-open-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
        http://icon-theme.freedesktop.org/releases

(gvim:1888762): Gtk-WARNING **: 14:28:56.852: Could not load a pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognised image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognised image file format (gdk-pixbuf-error-quark, 3)
Vim: Caught deadly signal ABRT
Vim: Finished.
[1]    1888762 abort (core dumped)  ( export XDG_DATA_DIRS=/notexist ; gvim -f; )
[shlomif@telaviv1 ~]$ ( export XDG_DATA_DIRS=/notexist:/usr/share ; gvim -f )


it also happens in a mostly new user in icewm-over-startx.

Version-Release number of selected component (if applicable):

Cauldron.

How reproducible:


Steps to Reproduce:


( export XDG_DATA_DIRS=/notexist ; gvim -f )
Comment 1 Shlomi Fish 2020-07-14 13:49:19 CEST
Note that KDE's "gwenview" starts fine in that case, but doesn't display previews for directories/folders.
Comment 2 Jani Välimaa 2020-07-14 19:08:12 CEST
It's de facto standard to have at least /usr/local/share and /usr/share in $XDG_DATA_DIRS. Basically you're shooting yourself in the foot if you're not having /usr/share in it.

So, the fix would be adding /usr/share to $XDG_DATA_DIRS. :P
Comment 3 Shlomi Fish 2020-07-14 20:57:45 CEST
(In reply to Jani Välimaa from comment #2)
> It's de facto standard to have at least /usr/local/share and /usr/share in
> $XDG_DATA_DIRS. Basically you're shooting yourself in the foot if you're not
> having /usr/share in it.
> 
> So, the fix would be adding /usr/share to $XDG_DATA_DIRS. :P

I see. I don't mind adding it to my .bashrc/etc., but I don't recall needing to do it explicitly on mageia in the past. Did something change? Thanks!
Comment 4 Olav Vitters 2020-07-16 15:05:37 CEST
Did you have it like this before? Meaning, it is a recent change in behaviour (regression)?

CC: (none) => olav

Comment 5 Shlomi Fish 2020-07-16 15:27:53 CEST
(In reply to Olav Vitters from comment #4)
> Did you have it like this before? Meaning, it is a recent change in
> behaviour (regression)?

Yes, it is a regression. I recall that in the past, after I filled $XDG_DATA_DIRS with some paths, (not including "/usr/share") the gtk+ apps worked well enough as before. So it is a recent change in behaviour.
Comment 6 Lewis Smith 2020-07-21 12:43:57 CEST
Well, on Mageia 7, without fiddling it at all:
 $ echo $XDG_DATA_DIRS
/usr/share/gdm:/var/lib/menu-xdg:/home/lewis/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share

Need to try this on Mageia 8. If 'out of the box' this path variable does include the necessary (comment 2), I would say this is not a bug.
If it worked in the past, comment 5, could that have been just been by luck?

CC: (none) => lewyssmith

Comment 7 Aurelien Oudelet 2020-08-13 11:26:03 CEST
In Mageia 8 Cauldron (Beta1) Plasma, freshly installed.

$ echo $XDG_DATA_DIRS

return:

/home/aurelien/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share

CC: (none) => ouaurelien

Comment 8 Lewis Smith 2020-08-13 21:40:43 CEST
I had forgotten to check M8; thanks for doing so.
Thus it look as if 'out of the box', Mageia does include /usr/local/share & /usr/share in $XDG_DATA_DIRS.

@Shlomi : can you say how you created an installation that did not?
In your original comment, to make the point, you explicitly set XDG_DATA_DIRS not to have the share paths; which does not count. You also cite: 
> it also happens in a mostly new user in icewm-over-startx
which is cryptic.
A bug would be if a standard Mageia installation got it wrong; for which the exact circumstance needs stating, please.
Comment 9 Shlomi Fish 2020-08-14 08:21:59 CEST
Seems like it is fine now in a new user as well as my main one:

kdetest@telaviv1:~ # echo $XDG_DATA_DIRS 
/home/kdetest/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share

I'm closing this ticket for now - thanks all for your help.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.