gdk-pixbuf issueshttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues2018-05-22T13:25:35Zhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/74qtif loader: fails when loading from a file2018-05-22T13:25:35ZBugzillaqtif loader: fails when loading from a file## Submitted by Christoph Reiter `@creiter`
**[Link to original bug (#794019)](https://bugzilla.gnome.org/show_bug.cgi?id=794019)**
## Description
Created attachment 369220
testcase
Executing the test case results in an error. Load...## Submitted by Christoph Reiter `@creiter`
**[Link to original bug (#794019)](https://bugzilla.gnome.org/show_bug.cgi?id=794019)**
## Description
Created attachment 369220
testcase
Executing the test case results in an error. Loading the file from memory with a PixbufLoader works.
**Attachment 369220**, "testcase":
[gdk-pixbuf-qtif.py](/uploads/aaa6b6462c5b860532f5158c40dec470/gdk-pixbuf-qtif.py)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/71Test failure in pixbuf-jpeg on Raspberry Pi2018-06-30T11:05:04ZBugzillaTest failure in pixbuf-jpeg on Raspberry Pi## Submitted by Sergey Kachanovskiy `@kachanovskiy`
**[Link to original bug (#793974)](https://bugzilla.gnome.org/show_bug.cgi?id=793974)**
## Description
Linux raspberrypi 4.14.22-v7+ #1096 SMP Mon Feb 26 19:14:22 GMT 2018 armv7l G...## Submitted by Sergey Kachanovskiy `@kachanovskiy`
**[Link to original bug (#793974)](https://bugzilla.gnome.org/show_bug.cgi?id=793974)**
## Description
Linux raspberrypi 4.14.22-v7+ #1096 SMP Mon Feb 26 19:14:22 GMT 2018 armv7l GNU/Linux
gcc 7.3.0 (native build)
gdk-pixbuf 2.36.11
error running tests:
```
ERROR:pixbuf-jpeg.c:74:test_type9_rotation_exif_tag: assertion failed (error == NULL): Image data at 13x0 is #A69B9F, but should be #A69C9D (gdk-pixbuf-error-quark, 0)
```
this is the only failing test out of 240 (2 skipped)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/66gif: Explicitly check for integer bounds before conversion to char2018-05-30T13:52:42ZBugzillagif: Explicitly check for integer bounds before conversion to char## Submitted by Tobias Mueller `@tobiasmue`
**[Link to original bug (#786489)](https://bugzilla.gnome.org/show_bug.cgi?id=786489)**
## Description
I'm not entirely convinced that g_warn_if_fail is the right thing to do.
Maybe g_retu...## Submitted by Tobias Mueller `@tobiasmue`
**[Link to original bug (#786489)](https://bugzilla.gnome.org/show_bug.cgi?id=786489)**
## Description
I'm not entirely convinced that g_warn_if_fail is the right thing to do.
Maybe g_return_val_if_fail (..., -1) is more appropriate.
That, however, would change the behaviour of the program,
so I went for the former.https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/65Make it easier to split loaders installation2018-12-14T14:10:20ZBugzillaMake it easier to split loaders installation## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#786035)](https://bugzilla.gnome.org/show_bug.cgi?id=786035)**
## Description
.## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#786035)](https://bugzilla.gnome.org/show_bug.cgi?id=786035)**
## Description
.https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/63Various miscellaneous bounds checking fixes2018-05-22T13:22:19ZBugzillaVarious miscellaneous bounds checking fixes## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#778943)](https://bugzilla.gnome.org/show_bug.cgi?id=778943)**
## Description
None of these fix any real bugs — they’re all to pacify the static analyser, or are ...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#778943)](https://bugzilla.gnome.org/show_bug.cgi?id=778943)**
## Description
None of these fix any real bugs — they’re all to pacify the static analyser, or are in tests or utilities. Still, they can’t hurt.https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/60unreasonably long runtime for a crafted file2022-02-26T09:33:55ZBugzillaunreasonably long runtime for a crafted file## Submitted by Tobias Mueller `@tobiasmue`
**[Link to original bug (#776817)](https://bugzilla.gnome.org/show_bug.cgi?id=776817)**
## Description
The attached file takes unreasonably long time to load with pixbuf-read. I tried to p...## Submitted by Tobias Mueller `@tobiasmue`
**[Link to original bug (#776817)](https://bugzilla.gnome.org/show_bug.cgi?id=776817)**
## Description
The attached file takes unreasonably long time to load with pixbuf-read. I tried to profile with gprof, but it shows an empty profile for me. I guess I'm just doing things wrongly. callgrind eventually decided to commit suicide:
```
==28814== brk segment overflow in thread #1: can't grow to 0x4a7e000
success
==28814==
==28814== Process terminating with default action of signal 27 (SIGPROF)
==28814== at 0x54D321F: write_gmon (gmon.c:354)
==28814== by 0x54D3999: _mcleanup (gmon.c:422)
==28814== by 0x5404FF7: __run_exit_handlers (exit.c:82)
==28814== by 0x5405044: exit (exit.c:104)
==28814== by 0x53EB836: (below main) (libc-start.c:325)
==28814==
==28814== Events : Ir
==28814== Collected : 610590616710
==28814==
==28814== I refs: 610,590,616,710
fish: “valgrind --tool=callgrind ./te…” terminated by signal SIGPROF (Profiling timer expired)
```
It still showed this, though:
```
>callgrind_annotate callgrind.out.28814
--------------------------------------------------------------------------------
Profile data file 'callgrind.out.28814' (creator: callgrind-3.11.0)
--------------------------------------------------------------------------------
I1 cache:
D1 cache:
LL cache:
Timerange: Basic block 0 - 106893912868
Trigger: Program termination
Profiled target: ./tests/.libs/pixbuf-read longfile (PID 28814, part 1)
Events recorded: Ir
Events shown: Ir
Event sort order: Ir
Thresholds: 99
Include dirs:
User annotated:
Auto-annotation: off
--------------------------------------------------------------------------------
Ir
--------------------------------------------------------------------------------
610,582,991,394 PROGRAM TOTALS
--------------------------------------------------------------------------------
Ir file:function
--------------------------------------------------------------------------------
258,203,389,650 gdk-pixbuf/pixops/pixops.c:scale_line [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0]
206,236,767,397 gdk-pixbuf/pixops/pixops.c:0x000000000006a7b0 [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0]
95,011,180,723 gdk-pixbuf/pixops/pixops.c:pixops_process [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0]
47,350,361,178 gdk-pixbuf/pixops/pixops.c:process_pixel [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0]
```
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/59bmp: left shift by 24 bits does not always fit in an "int" (clrUsed)2019-02-13T17:34:23ZBugzillabmp: left shift by 24 bits does not always fit in an "int" (clrUsed)## Submitted by Tobias Mueller `@tobiasmue`
**[Link to original bug (#776695)](https://bugzilla.gnome.org/show_bug.cgi?id=776695)**
## Description
```
io-bmp.c:335:28: runtime error: left shift of 222 by 24 places cannot be represen...## Submitted by Tobias Mueller `@tobiasmue`
**[Link to original bug (#776695)](https://bugzilla.gnome.org/show_bug.cgi?id=776695)**
## Description
```
io-bmp.c:335:28: runtime error: left shift of 222 by 24 places cannot be represented in type 'int'
io-bmp.c:337:26: runtime error: shift exponent 32 is too large for 32-bit type 'int'
(process:20881): GLib-GObject-WARNING **: value "-2147352580" of type 'gint' is invalid or out of range for property 'rowstride' of type 'gint'
fish: “./tests/pixbuf-read /tmp/comput…” terminated by signal SIGTRAP (Trace or breakpoint trap)
```
We can see the offending shift here:
```cpp
if (State->Header.size == 12)
clrUsed = 1 <`< State->`Header.depth;
else
clrUsed = (BIH[35] << 24) + (BIH[34] << 16) + (BIH[33] << 8) + (BIH[32]);
if (clrUsed > (1U <`< State->`Header.depth))
{
g_set_error_literal (error
```
The values get promoted to (signed) ints. If you shift by 24 digits and the high bit is set, then you overflow the range of the signed int. So the BIH[35], which gets promoted to an int, should be marked as unsigned before shifting. But also, n_colors is assigned the value of clrUsed later and n_colors seems to be an unsigned type:
```
struct headerpair {
guint32 size;
gint32 width;
gint32 height;
guint depth;
guint Negative; /* Negative = 1 -> top down BMP,
Negative = 0 -> bottom up BMP */
guint n_colors;
};
```
So I guess that clrUsed should also be unsigned. That would allow a shift of 1 by up to 31 digits.
We cannot shift a 1 by 32 places in a regular 32bit int, being it unsigned or not. So I think the pragmatic approach is to check for the depth being strictly less than 31. I don't know whether this breaks some images. I guess it doesn't, though.
This seems to also be CID 1388521.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/56Some windows icons display as garbage2020-10-26T13:49:03ZBugzillaSome windows icons display as garbage## Submitted by Jonas Thiem `@JonasT`
**[Link to original bug (#768463)](https://bugzilla.gnome.org/show_bug.cgi?id=768463)**
## Description
Created attachment 330927
Windows icon file that shows up corrupted in nautilus and eye of ...## Submitted by Jonas Thiem `@JonasT`
**[Link to original bug (#768463)](https://bugzilla.gnome.org/show_bug.cgi?id=768463)**
## Description
Created attachment 330927
Windows icon file that shows up corrupted in nautilus and eye of gnome
Some windows icons display as garbage. An example is attached. It is supposed to show a green circle - open it up in GIMP to see how it is actually meant to look like.
The .ico file contains the following sizes:
16x16 1bpp, 1bit-alpha, 2 color palette, uncompressed
32x32 8bpp, 1bit-alpha, 256 color palette, uncompressed
128x128 32bit, 8bit-alpha, no palette, compressed (PNG)
Some of the settings must be throwing nautilus off. Eye of Gnome/EOG has the same problem.
**Attachment 330927**, "Windows icon file that shows up corrupted in nautilus and eye of gnome":
[test.ico](/uploads/3a6cef6ba590995bb64f98ac8baa95a4/test.ico)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/55valid GIF images rejected by gdk-pixbuf2018-12-04T08:48:27ZBugzillavalid GIF images rejected by gdk-pixbuf## Submitted by Nigel Tao
**[Link to original bug (#765705)](https://bugzilla.gnome.org/show_bug.cgi?id=765705)**
## Description
Created attachment 326914
Tarball of three .gif images that eog (incorrectly) rejects
The Go program b...## Submitted by Nigel Tao
**[Link to original bug (#765705)](https://bugzilla.gnome.org/show_bug.cgi?id=765705)**
## Description
Created attachment 326914
Tarball of three .gif images that eog (incorrectly) rejects
The Go program below generates two .gif files (attached as a tar.bz2). Both of these files are viewable with Firefox, Google Chrome and ImageMagick just fine, but not in Eye-of-Gnome, which AFAICT uses gdk-pixbuf.
The "GIF-image-loader-cannot-understand-this-image.gif" file triggers the code path at https://github.com/GNOME/gdk-pixbuf/blob/master/gdk-pixbuf/io-gif.c#L634 for which the comment immediately above says that: "FIXME - we should handle this case".
The "internal-error-in-the-GIF-loader.gif" file triggers the code path at https://github.com/GNOME/gdk-pixbuf/blob/master/gdk-pixbuf/io-gif.c#L500 and while I am not overly familiar with the gdk-pixbuf code, at the very least, untrusted image input should not trigger "internal errors", in my opinion.
A larger GIF image, lissajous.gif, is also in the tarball. It is the output of this Go program: https://github.com/adonovan/gopl.io/blob/master/ch1/lissajous/main.go
Once again, Firefox, Google Chrome and ImageMagick are all happy with this lissajous.gif file; Eye-of-Gnome is not, saying "Circular table entry in GIF file".
```js
package main
import (
"image"
"image/color"
"image/gif"
"log"
"os"
)
var palette = make([]color.Color, 256)
func main() {
for i := range palette {
palette[i] = color.Gray{byte(i)}
}
do(4, "GIF-image-loader-cannot-understand-this-image.gif")
do(16, "internal-error-in-the-GIF-loader.gif")
}
func do(n int, filename string) {
out, err := os.Create(filename)
if err != nil {
log.Fatal(err)
}
defer out.Close()
// img is an n x n paletted image where every pixel is initialized to the
// 0th entry in the palette.
img := image.NewPaletted(image.Rect(0, 0, n, n), palette)
// Change false to true in order to make each pixel have a distinct palette
// index, so that the LZW compression step doesn't compress anything.
//
// Either way, this program should generate valid images, but when this is
// false, it seems that eog cannot read the resultant GIF images, even
// though Firefox, Google Chrome and ImageMagick can.
if false {
for i := range img.Pix {
img.Pix[i] = byte(i)
}
}
if err := gif.Encode(out, img, nil); err != nil {
log.Fatal(err)
}
}
```
**Attachment 326914**, "Tarball of three .gif images that eog (incorrectly) rejects":
[eog-rejects.tar.bz2](/uploads/c72a1ceaa1781792f6a15cf06260edc6/eog-rejects.tar.bz2)
Version: git master
### Depends on
* [Bug 739202](https://bugzilla.gnome.org/show_bug.cgi?id=739202)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/53Add a warning message with MIME type if no matching loader found2018-05-22T13:18:53ZBugzillaAdd a warning message with MIME type if no matching loader found## Submitted by Chris Mayo `@chrism`
**[Link to original bug (#759786)](https://bugzilla.gnome.org/show_bug.cgi?id=759786)**
## Description
Created attachment 317794
Patch adding warning message
Would make it easier to debug MIME d...## Submitted by Chris Mayo `@chrism`
**[Link to original bug (#759786)](https://bugzilla.gnome.org/show_bug.cgi?id=759786)**
## Description
Created attachment 317794
Patch adding warning message
Would make it easier to debug MIME database problems that prevent images loading.
Patch attached.
~~**Patch 317794**~~, "Patch adding warning message":
[Output-warning-with-MIME-type.patch](/uploads/45a68b84f9a0dfa44b73face180200e0/Output-warning-with-MIME-type.patch)
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/50ico: Parses compressed data as BMP if compressed entry is last2023-11-11T08:39:32ZBugzillaico: Parses compressed data as BMP if compressed entry is last## Submitted by Dominique Leuenberger
**[Link to original bug (#743862)](https://bugzilla.gnome.org/show_bug.cgi?id=743862)**
## Description
I have an .ico file which gimp opens just fine, but eog fails to load it.
NOTE: I don't th...## Submitted by Dominique Leuenberger
**[Link to original bug (#743862)](https://bugzilla.gnome.org/show_bug.cgi?id=743862)**
## Description
I have an .ico file which gimp opens just fine, but eog fails to load it.
NOTE: I don't think the fault is at EOG, but I use it as an entry point to find a more suitable compoent.
The same 'noisy output' is seen in nautilus by means of the preview created (so hopefully this is something shared between eog and whatever creates the thumbnail for nautilus).
I attach an Icon for reference
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/49eog displaces BMP file2021-09-30T19:33:36ZBugzillaeog displaces BMP file## Submitted by Dimitri Papadopoulos
**[Link to original bug (#742689)](https://bugzilla.gnome.org/show_bug.cgi?id=742689)**
## Description
Created attachment 294208
BMP file - created by ImageMagick if I recall correctly
The atta...## Submitted by Dimitri Papadopoulos
**[Link to original bug (#742689)](https://bugzilla.gnome.org/show_bug.cgi?id=742689)**
## Description
Created attachment 294208
BMP file - created by ImageMagick if I recall correctly
The attached BMP file is not properly displayed by eog. I have just noticed shotwell is broken as well. Gimp and ImageMagick display the BMP file properly - therefore the bug might be in some Gnome library.
Steps to Reproduce:
1. Download the attached file myoung.bmp.
2. Display it in eog. Notice how the image is shifted.
**Attachment 294208**, " BMP file - created by ImageMagick if I recall correctly":
![myoung](/uploads/04eb91fb6b103eb8087dbb4f45c7b692/myoung.bmp)
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/47doc: Clarify that the colors in composite_color* should not include the alpha2018-05-22T13:16:59ZBugzilladoc: Clarify that the colors in composite_color* should not include the alpha## Submitted by Debarshi Ray `@debarshir`
**[Link to original bug (#740760)](https://bugzilla.gnome.org/show_bug.cgi?id=740760)**
## Description
Some methods like gdk_pixbuf_fill take a guint32 parameter that represents a pixel as a...## Submitted by Debarshi Ray `@debarshir`
**[Link to original bug (#740760)](https://bugzilla.gnome.org/show_bug.cgi?id=740760)**
## Description
Some methods like gdk_pixbuf_fill take a guint32 parameter that represents a pixel as a RGBA value, while gdk_pixbuf_composite_color* expects the guint32 color parameters to be a RGB value without the alpha.
It took me a while to realize this. The fact that it particularly says guint32 led me to assume that it is a RGBA value. It might be worth clarifying this a bit.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/46Use nsgif instead of home-made loader2018-12-04T22:16:33ZBugzillaUse nsgif instead of home-made loader## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#739202)](https://bugzilla.gnome.org/show_bug.cgi?id=739202)**
## Description
This could cut down on the number of bugs in the GIF loader.
### Blocking
* [Bug 6472...## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#739202)](https://bugzilla.gnome.org/show_bug.cgi?id=739202)**
## Description
This could cut down on the number of bugs in the GIF loader.
### Blocking
* [Bug 647251](https://bugzilla.gnome.org/show_bug.cgi?id=647251)
* [Bug 735422](https://bugzilla.gnome.org/show_bug.cgi?id=735422)
* [Bug 765705](https://bugzilla.gnome.org/show_bug.cgi?id=765705)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/45gdk_pixbuf_new_from_file_at_scale is broken for animated GIFs2018-05-30T14:04:08ZBugzillagdk_pixbuf_new_from_file_at_scale is broken for animated GIFs## Submitted by Will Greenberg
**[Link to original bug (#735422)](https://bugzilla.gnome.org/show_bug.cgi?id=735422)**
## Description
If an animated gif is loaded via `gdk_pixbuf_new_from_file_at_scale()`, GdkPixbuf throws "GIF imag...## Submitted by Will Greenberg
**[Link to original bug (#735422)](https://bugzilla.gnome.org/show_bug.cgi?id=735422)**
## Description
If an animated gif is loaded via `gdk_pixbuf_new_from_file_at_scale()`, GdkPixbuf throws "GIF image was truncated or incomplete".
This happens seemingly independent of the scale provided, and would appear to be because the `GdkPixbufLoader` for the gif is being closed before the gif has been fully read (i.e. its state is `GIF_LZW_FILL_BUFFER` at Loader closing time). Perhaps the check for an existing animation at gdk-pixbuf/gdk-pixbuf-io.c:L1361 isn't a reliable tell for when the image is ready to be closed?
Here's a tiny script to reproduce. Sample image is SFW adorable cat gif:
```sh
$ curl http://i.imgur.com/psu515W.gif -o catbee.gif
$ gjs -c "imports.gi.GdkPixbuf.Pixbuf.new_from_file_at_scale('catbee.gif', -1, -1, true);"
```
Version: git master
### Depends on
* [Bug 739202](https://bugzilla.gnome.org/show_bug.cgi?id=739202)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/38.ani files fail to load when using GDI+ loaders2018-05-22T13:14:40ZBugzilla.ani files fail to load when using GDI+ loaders## Submitted by Chun-wei Fan `@fanc999`
**[Link to original bug (#704730)](https://bugzilla.gnome.org/show_bug.cgi?id=704730)**
## Description
Hi,
When I was running the test programs, animation and pixbuf-read (when using .ani fil...## Submitted by Chun-wei Fan `@fanc999`
**[Link to original bug (#704730)](https://bugzilla.gnome.org/show_bug.cgi?id=704730)**
## Description
Hi,
When I was running the test programs, animation and pixbuf-read (when using .ani files), I get an assertion error indicating that the .ani files couln't be loaded:
ERROR:animation.c:11:test_animation: assertion failed (error == NULL): InvalidParameter (gdk-pixbuf-error-quark, 5)
(A similar error is given when I run pixbuf-read on test-animation.ani)
This occurs when I built gdk-pixbuf with the GDI+ image loaders, but these tests ran fine when I used the "traditional" image laders (i.e. those that made use of libtiff, jpeg-turbo/libjpeg and optionally libjasper).
So, after some investigation it seems that this is caused by GDI+ being unable to support the decoding and reading of .ani files directly.
As I was poking around the code, it seems that although the ANI module was loaded to load the .ani file, the GDI+ module was loaded (and and took over the ANI loader) as the ANI module processed an ICO during the loading process.
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/37invalid offset used when decoding certain BMP images2018-05-30T13:44:32ZBugzillainvalid offset used when decoding certain BMP images## Submitted by Andreas Oberritter
**[Link to original bug (#700952)](https://bugzilla.gnome.org/show_bug.cgi?id=700952)**
## Description
There's a testsuite for BMP images available under the following URL:
http://entropymine.com/j...## Submitted by Andreas Oberritter
**[Link to original bug (#700952)](https://bugzilla.gnome.org/show_bug.cgi?id=700952)**
## Description
There's a testsuite for BMP images available under the following URL:
http://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html
Gdk-pixbuf fails to decode the following picture classified as "good" correctly:
http://entropymine.com/jason/bmpsuite/bmpsuite/g/rgb16-565pal.bmp
Of those pictures classified as "questionable", decoding the following fails:
http://entropymine.com/jason/bmpsuite/bmpsuite/q/pal8offs.bmp
My guess is that the "bfOffBits" field at offset 10 of the "BITMAPFILEHEADER" gets ignored. You could validate its value based on the total file size.
Regards,
Andreas
Version: git masterhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/36can't load some MPF JPEG images2018-05-30T13:44:18ZBugzillacan't load some MPF JPEG images## Submitted by Lucas Beeler
**[Link to original bug (#694832)](https://bugzilla.gnome.org/show_bug.cgi?id=694832)**
## Description
A consortium of digital camera manufacturers has introduced the MPF (multi-picture format) extension...## Submitted by Lucas Beeler
**[Link to original bug (#694832)](https://bugzilla.gnome.org/show_bug.cgi?id=694832)**
## Description
A consortium of digital camera manufacturers has introduced the MPF (multi-picture format) extension to the standard JPEG/EXIF file format. The standard is described here: http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf. A variety of Samsung, Sony, and Fuji digital cameras now write MPF JPEG files. The gdk-pixbuf library errors out when attempting to load at least some of these files.
Version: 2.26.x
### Blocking
* [Bug 718123](https://bugzilla.gnome.org/show_bug.cgi?id=718123)https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/34Resolve a relative path in the module file relative to the module file2018-05-22T13:13:36ZBugzillaResolve a relative path in the module file relative to the module file## Submitted by Anselm Kruis
**[Link to original bug (#678703)](https://bugzilla.gnome.org/show_bug.cgi?id=678703)**
## Description
Created attachment 217112
Resolve a relative path in the module file relative to the module file
Pr...## Submitted by Anselm Kruis
**[Link to original bug (#678703)](https://bugzilla.gnome.org/show_bug.cgi?id=678703)**
## Description
Created attachment 217112
Resolve a relative path in the module file relative to the module file
Problem: currently the ".../libpixbufloader-*.so" lines in the module file must be absolute file names. This renders gdk-pixbuf non relocatable.
I use this path to build a fully relocatable application.
The patch changes gdk-pixbuf to resolve a relative path in the module file relative to the module file itself.
**Patch 217112**, "Resolve a relative path in the module file relative to the module file":
[gdk-pixbuf-2.22.0-relative-module-path.patch](/uploads/1d84df66c33a47e56db52ae612864681/gdk-pixbuf-2.22.0-relative-module-path.patch)
Version: 2.24.xhttps://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/33crash on loading gif image when using gdk-pixbuf with gdi+ backend in gdb env...2019-03-28T08:42:55ZBugzillacrash on loading gif image when using gdk-pixbuf with gdi+ backend in gdb environment## Submitted by A.M
**[Link to original bug (#674337)](https://bugzilla.gnome.org/show_bug.cgi?id=674337)**
## Description
Created attachment 212299
code of sample program and gdb backtrace
I attached code of sample program.i used ...## Submitted by A.M
**[Link to original bug (#674337)](https://bugzilla.gnome.org/show_bug.cgi?id=674337)**
## Description
Created attachment 212299
code of sample program and gdb backtrace
I attached code of sample program.i used binary files i downloaded from gtk.org. program only crashes when using gdb. without gdb it works normally
**Attachment 212299**, "code of sample program and gdb backtrace":
[main.tar.gz](/uploads/199264c53d04152e748543862b087b5a/main.tar.gz)
Version: 2.24.x