Programs using gdk_pixbuf 2.38 crash with 2.36 loaders from system #54278
Comments
hedning
added
the
0.kind: regression
|
Hmm, I'm unable to reproduce (tested at 088cb13 via |
|
It crashes for me with a segfault, when I run it from a NixOS 18.09 installation but works fine on NixOS unstable. I observed that problem with other packages while reviewing PRs (e.g. gparted). |
|
I have seen the same segmentation fault on other pixbuf-using software running on an 18.09 system using unstable-built software. This is because pixbuf 2.38 tries to use a 2.36 library. Just before segfault in dbeaver, Just before segfault in (unreleased) netsurf update Looks like the same class of bug than #24256. |
|
I have always expected gdk-pixbuf loaders to have stable ABI? Is it declared anywhere though? |
|
No idea, I know I'm currently being bitten left and right by this, when doing anything on 18.09 which then uses gdk-pixbuf. The crashes aren't necessarily at start. google-chrome-beta (on plasma, not in a clean environment) will crash sometimes in the open/save dialog (haven't straced it), but will crash reproducibly here on the print dialog. (Makes sense, a gtk-based thing.) qemu, e.g. starting a build-vm on 18.09 from an unstable checkout, will crash when opening a menu, still on the same plasma machines. This is fixed using wrapGAppsHook. These are not exhaustive, and I have made a small list of the intersection of the "using gdk_pixbuf" and "not wrapped" package set. I don't know what to do about it though... (The list obviously has false positives in.) Finally, it seems the spotify segfault could be unrelated, or at least, the strace should show it loading a 2.36 object, not failing to open locale files. I probably should figure out an automated reproducible test case to validate or invalidate the issue. |
|
The gdk-pixbuf is used for loading icons by GTK.
I do not think @hyperfekt choose the right segment of the strace. If there is no further output before the crash, it is probably due to output buffer not being flushed. |
Yes, (obvious in the trace section, where a png icon is being loaded, and the png module for 2.36 is being loaded).
Yeah, hence the could, right now it's inconclusive, but it is likely. |
|
Here is a simple repro: let
nixpkgs = import (fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/f2a1a4e93be2d76720a6b96532b5b003cc769312.tar.gz";
sha256 = "1yjk6ffnm6ahj34yy2q1g5wpdx0m1j7h8i4bzn4x78g9chb0ppy4";
}) {};
nixpkgs_old = import (fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/10dbdd30d199146bf9b41c029127ffe7b92caff2.tar.gz";
sha256 = "1mabavzzxbcxr9isk5k9ylr060prgflyaikfk41grb3b4x105na1";
}) {};
in
with nixpkgs.pkgs;
let
testSrc = writeText "test.c" ''
#include <gdk-pixbuf/gdk-pixbuf.h>
#include <glib.h>
int main(int argc, char const *argv[]) {
GError* err = NULL;
if (gdk_pixbuf_new_from_file("${nixos-artwork.wallpapers.gnome-dark}/share/artwork/gnome/nix-wallpaper-simple-dark-gray_bottom.png", &err) == NULL) {
g_error("%s", err->message);
return 1;
}
return 0;
}
'';
in runCommand "gdk-pixbuf-loading-test" {
buildInputs = [ gdk_pixbuf pkgconfig gcc makeWrapper ];
} ''
mkdir -p $out
cc \
$(pkg-config --cflags gdk-pixbuf-2.0) \
$(pkg-config --libs gdk-pixbuf-2.0) \
${testSrc} -o $out/test
wrapProgram $out/test --set GDK_PIXBUF_MODULE_FILE "${nixpkgs_old.gdk_pixbuf}/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache"
$out/test
'' |
|
|
|
Building with debug info Nix expressionlet
nixpkgs = import (fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/f2a1a4e93be2d76720a6b96532b5b003cc769312.tar.gz";
sha256 = "1yjk6ffnm6ahj34yy2q1g5wpdx0m1j7h8i4bzn4x78g9chb0ppy4";
}) {};
nixpkgs_old = import (fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/10dbdd30d199146bf9b41c029127ffe7b92caff2.tar.gz";
sha256 = "1mabavzzxbcxr9isk5k9ylr060prgflyaikfk41grb3b4x105na1";
}) {};
gdk-pixbuf = nixpkgs.enableDebugging (nixpkgs.gdk_pixbuf.overrideAttrs (attrs: {
mesonBuildType = "debug";
}));
gdk_pixbuf_old = nixpkgs.enableDebugging (nixpkgs_old.gdk_pixbuf.overrideAttrs (attrs: {
mesonBuildType = "debug";
}));
in
with nixpkgs.pkgs;
let
testSrc = writeText "test.c" ''
#include <gdk-pixbuf/gdk-pixbuf.h>
#include <glib.h>
int main(int argc, char const *argv[]) {
GError* err = NULL;
if (gdk_pixbuf_new_from_file("${nixos-artwork.wallpapers.gnome-dark}/share/artwork/gnome/nix-wallpaper-simple-dark-gray_bottom.png", &err) == NULL) {
g_error("%s", err->message);
return 1;
}
return 0;
}
'';
in runCommand "gdk-pixbuf-loading-test" {
buildInputs = [ gdk-pixbuf pkgconfig gcc makeWrapper ];
} ''
mkdir -p $out
cc -ggdb \
$(pkg-config --cflags gdk-pixbuf-2.0) \
$(pkg-config --libs gdk-pixbuf-2.0) \
${testSrc} -o $out/test
wrapProgram $out/test --set GDK_PIXBUF_MODULE_FILE "${gdk_pixbuf_old}/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache"
# $out/test
''shows some more details Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f3268bc39ff in __memmove_avx_unaligned_erms () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
(gdb) bt
#0 0x00007f3268bc39ff in __memmove_avx_unaligned_erms () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
#1 0x00007f3266530225 in png_combine_row () from /nix/store/73bda0a26bda42v22y9fj051r44wsyma-libpng-apng-1.6.35/lib/libpng16.so.16
#2 0x00007f3266523438 in png_read_row () from /nix/store/73bda0a26bda42v22y9fj051r44wsyma-libpng-apng-1.6.35/lib/libpng16.so.16
#3 0x00007f3266524faa in png_read_image () from /nix/store/73bda0a26bda42v22y9fj051r44wsyma-libpng-apng-1.6.35/lib/libpng16.so.16
#4 0x00007f326674d0f1 in gdk_pixbuf__png_image_load (f=0x1299260, error=0x7ffcc62a5568) at ../gdk-pixbuf/io-png.c:331
#5 0x00007f32693cb469 in _gdk_pixbuf_generic_image_load (module=module@entry=0x12aa630, f=f@entry=0x1299260, error=error@entry=0x7ffcc62a5568) at ../gdk-pixbuf/gdk-pixbuf-io.c:1000
#6 0x00007f32693cb577 in gdk_pixbuf_new_from_file (filename=0x400868 "/nix/store/wv6f93xfgbzpgi1jnj6rzh0c01nmvxil-simple-dark-gray-2018-08-28/share/artwork/gnome/nix-wallpaper-simple-dark-gray_bottom.png",
error=0x7ffcc62a5568) at ../gdk-pixbuf/gdk-pixbuf-io.c:1071
#7 0x000000000040079f in main (argc=1, argv=0x7ffcc62a5658) at /nix/store/9syiafxf5219n2l37ymjnhss81c3l303-test.c:6Line #4 comes from 2.36, rest from 2.38, perhaps the different libpng or libc versions are the culprit. |
|
Using the same set of libraries did not help Nix expressionlet
nixpkgs = import (fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/f2a1a4e93be2d76720a6b96532b5b003cc769312.tar.gz";
sha256 = "1yjk6ffnm6ahj34yy2q1g5wpdx0m1j7h8i4bzn4x78g9chb0ppy4";
}) {};
nixpkgs_old = fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/10dbdd30d199146bf9b41c029127ffe7b92caff2.tar.gz";
sha256 = "1mabavzzxbcxr9isk5k9ylr060prgflyaikfk41grb3b4x105na1";
};
gdk-pixbuf = nixpkgs.enableDebugging (nixpkgs.gdk_pixbuf.overrideAttrs (attrs: {
mesonBuildType = "debug";
}));
gdk_pixbuf_old = nixpkgs.enableDebugging ((nixpkgs.callPackage "${nixpkgs_old}/pkgs/development/libraries/gdk-pixbuf/default.nix" {}).overrideAttrs (attrs: {
mesonBuildType = "debug";
}));
in
with nixpkgs.pkgs;
let
testSrc = writeText "test.c" ''
#include <gdk-pixbuf/gdk-pixbuf.h>
#include <glib.h>
int main(int argc, char const *argv[]) {
GError* err = NULL;
if (gdk_pixbuf_new_from_file("${nixos-artwork.wallpapers.gnome-dark}/share/artwork/gnome/nix-wallpaper-simple-dark-gray_bottom.png", &err) == NULL) {
g_error("%s", err->message);
return 1;
}
return 0;
}
'';
in runCommand "gdk-pixbuf-loading-test" {
buildInputs = [ gdk-pixbuf pkgconfig gcc makeWrapper ];
} ''
mkdir -p $out
cc -ggdb \
$(pkg-config --cflags gdk-pixbuf-2.0) \
$(pkg-config --libs gdk-pixbuf-2.0) \
${testSrc} -o $out/test
wrapProgram $out/test --set GDK_PIXBUF_MODULE_FILE "${gdk_pixbuf_old}/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache"
# $out/test
''#0 0x00007f9f3ec639ff in __memmove_avx_unaligned_erms () from /nix/store/fivq0nbggp4y8mhy3ixprqd7qyn1hy2j-glibc-2.27/lib/libc.so.6
#1 0x00007f9f3c5d0275 in png_combine_row () from /nix/store/lk79kfxzf7b1j5yrsmv0z7bmrvfcb9gc-libpng-apng-1.6.35/lib/libpng16.so.16
#2 0x00007f9f3c5c343f in png_read_row () from /nix/store/lk79kfxzf7b1j5yrsmv0z7bmrvfcb9gc-libpng-apng-1.6.35/lib/libpng16.so.16
#3 0x00007f9f3c5c4fba in png_read_image () from /nix/store/lk79kfxzf7b1j5yrsmv0z7bmrvfcb9gc-libpng-apng-1.6.35/lib/libpng16.so.16
#4 0x00007f9f3c7ed0c5 in gdk_pixbuf__png_image_load (f=0x15a4260, error=0x7ffde6a15768) at /build/source/build/../gdk-pixbuf/io-png.c:331
#5 0x00007f9f3f46b469 in _gdk_pixbuf_generic_image_load (module=module@entry=0x15b5630, f=f@entry=0x15a4260, error=error@entry=0x7ffde6a15768)
at /build/gdk-pixbuf-2.38.0/build/../gdk-pixbuf/gdk-pixbuf-io.c:1000
#6 0x00007f9f3f46b577 in gdk_pixbuf_new_from_file (filename=0x400868 "/nix/store/wv6f93xfgbzpgi1jnj6rzh0c01nmvxil-simple-dark-gray-2018-08-28/share/artwork/gnome/nix-wallpaper-simple-dark-gray_bottom.png",
error=0x7ffde6a15768) at /build/gdk-pixbuf-2.38.0/build/../gdk-pixbuf/gdk-pixbuf-io.c:1071
#7 0x000000000040079f in main (argc=1, argv=0x7ffde6a15858) at /nix/store/9syiafxf5219n2l37ymjnhss81c3l303-test.c:6 |
|
FWIW I used a tweaked version of @jtojnar's expression to run a bisect against gdk-pixbuf which narrowed things down to changes introduced in https://gitlab.gnome.org/GNOME/gdk-pixbuf/commit/c60ffd502cf84ca67777ebf4aa87e65057bd46e0 which, to my very superficial understanding, make the older loader feed garbage to libpng because the layout of some internal data structure has changed. |
|
The list was generated by doing an intersection and subtraction of the list of packages depending on |
|
Ah, so that's why I get a segfault in when trying to run UMLet ( I can confirm that (like in #56145 & #55048) this happens also on b9d77e9, but not on |
|
Should I file a separate NixOS/nixpkgs issue about UMLet? If not, should the title of one of the existing issues be changed to indicate that more than a single application is affected? |
jtojnar
changed the title
|
Renamed this one since it has the most detail. |
|
I think what I am experiencing could be related to this bug (because of the reference to libgtk-3.so.0.2404.0 in journalctl): Since I updated to the 19.03 channel, this happens. However, I have now rolled back to 18.09. All open MATE terminals crash when one tab or a window is closed (via the GUI X button) and if the option Menu > Edit > Profiles > Default > Edit > Title and Command > When command exists == "Hold the terminal open". I have attached straces of multiple cases of workflow for comparison, and some journalctl entries. |
|
Is there a solution or workaround for this? I have a user of Termonad that is running into this: Is setting the |
|
Chatting with @jtojnar on IRC, I found that if I |
|
I've tested @fare's solution with GnuCash and it also works correctly! I've only needed to unset the This also fixes unstable's Inkscape that has been segfaulting like GnuCash. Thank you for the temporary fix! |
|
With NixOS 19.03 released, is this still an issue? Is something still to be done for it not becoming an issue again? |
|
My impression is that this is no longer an issue but nothing has been done to avoid this issue to arise again. |
|
I still have this issue on NixOS 19.09.1806.b047b7315d8c9bee05e3b2d7daf0a357099180fa (Loris) x86_64, like described before: comment. |
|
@alex-giusi-tiri If you unset |
|
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them. Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel. |
stale
bot
added
the
2.status: stale
This resolves a problem when the wrapped Factor binary is executed with `GDK_PIXBUF_MODULE_FILE` set to an incompatible version. This happens if e.g. Factor is run from within an Emacs that uses newer gdk versions. Related NixOS issue: NixOS/nixpkgs#54278 In the long run, this should be replaced by a derivation which correctly runs through all the phases correctly to set up `wrapGAppsHook` correctly.
This resolves a problem when the wrapped Factor binary is executed with `GDK_PIXBUF_MODULE_FILE` set to an incompatible version. This happens if e.g. Factor is run from within an Emacs that uses newer gdk versions. Related NixOS issue: NixOS/nixpkgs#54278 In the long run, this should be replaced by a derivation which correctly runs through all the phases correctly to set up `wrapGAppsHook` correctly. Even then, the correct behavior would probably be to have the surrounding environment (e.g. Emacs) restore the default variable value in it's sub-environments.
This resolves a problem when the wrapped Factor binary is executed with `GDK_PIXBUF_MODULE_FILE` set to an incompatible version. This happens if e.g. Factor is run from within an Emacs that uses newer gdk versions. Related NixOS issue: NixOS/nixpkgs#54278 In the long run, this should be replaced by a derivation which correctly runs through all the phases correctly to set up `wrapGAppsHook` correctly. Even then, the correct behavior would probably be to have the surrounding environment (e.g. Emacs) restore the default variable value in it's sub-environments.
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
stale
bot
removed
the
2.status: stale
stale
bot
added
the
2.status: stale
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/failing-to-run-old-version-of-gnu-cash/33128/2 |
stale
bot
removed
the
2.status: stale
Issue description
Since the update from 3.3 to 3.4, GnuCash hasn't been able to open, and instead crashes with a segmentation fault. I don't know if this is a Nix or an upstream issue.
Steps to reproduce
I have tried changing to a more common locale, moving my GnuCash data files to "simulate" a fresh install, but to no avail.
Technical details
"x86_64-linux"Linux 4.14.93, NixOS, 18.09.1922.97e0d53d669 (Jellyfish)yesyesnix-env (Nix) 2.1.3"nixos-18.09.1922.97e0d53d669""unstable-19.03pre166683.088cb13aee0"/nix/var/nix/profiles/per-user/root/channels/nixosGDB stacktrace (click to expand)
/tmp/gnucash.trace log when running with
--debug --extra(click to expand)The text was updated successfully, but these errors were encountered: