| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The code value after a reset wasn't being validated, which means we would
accept invalid codes. This could cause an infinite loop in the decoder.
Fixes CVE-2020-29385
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/164
|
|
|
|
| |
GIF support is always built in.
|
|
|
|
| |
The former can be disabled at build time.
|
| |
|
|
|
|
| |
Regression introduced in e3adcf0c86dbd56b01d0d55f29a95065cbd95eb8.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libjasper is not really maintained any more, and has been dropped by
various Linux distributions over the years.
GdkPixbuf has not enabled the JPEG2000 loader by default in many years,
relying on downstream distributors to do so if they also shipped
libjasper. This means that it's unlikely anybody has relied on GdkPixbuf
to load a JPEG2000 image for the past 3 to 5 years, if at all.
The only other option for loading JPEG2000 images is to use OpenJPEG,
and for that there is an out of tree GdkPixbuf module available:
https://notabug.org/necklace/jp2-pixbuf-loader
Fixes: #152, #137
|
|
|
|
|
|
| |
mmap does not return NULL on failure, but rather MAP_FAILED.
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/158
|
|
|
|
|
| |
Add test for the issue fixed by commit
35dcd72bbe7a9349861ff14389a38525fe9c949f.
|
|
|
|
| |
From https://bugs.launchpad.net/inkscape/+bug/1746054/comments/5
|
|
|
|
|
|
|
|
| |
Some tests depend on build options—like the ability to load certain
images. There's no point in compiling things that we know will fail,
so might as well skip them.
Fixes: #123
|
| |
|
|
|
|
|
| |
We must skip the reference test when both the source and reference files
are unsupported.
|
|
|
|
|
| |
There's no point in failing the test when we know we don't support the
file format.
|
|
|
|
|
|
| |
This test data was added for the pixbuf-gif-circular-table test (added October
2018 in 0b9d004) but because the file was never actually installed the installed
test suite never passes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If one does a plain
GdkPixbuf *pixbuf = g_object_new (GDK_TYPE_PIXBUF, NULL);
Then all the construct properties use their default values. This
means that both "pixels" and "pixel-bytes" get passed as NULL to
gdk_pixbuf_set_property().
Later, trying to get the property for "pixel-bytes" would assert,
incorrectly, because it was trying to create a GBytes from a NULL
pixels storage.
This commit adds a test for that construction case, and tests for
constructing with g_object_new() in general.
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/91
|
| |
|
|
|
|
|
|
|
|
|
| |
There's no reason to use g_memmove() instead of memmove().
The `g_memmove()` wrapper was a symbol internal to GLib between 2004 and
2013, when it was exposed as a plain C pre-processor symbol around C90's
memmove(). Starting from GLib 2.61, using g_memmove() is going to raise
a deprecation warning from the compiler.
|
| |
|
|
|
|
| |
A laaaarge XPM file.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=793470
|
|
|
|
| |
An example image that generates the "Circular table entry in GIF file" error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following was occurring:
1. A clear code is detected in the LZW stream
2. The first code is detected as a clear.
3. The following code is returned as a color index, this breaks if it is a
clear.
There were two codepaths in use, one for handling the first clear in the LZW
sequence and another for handling clears within the sequence. The former
handled sequential clears correctly, the latter did not.
The solution is to the correct codepath and remove the other one. This
simplification should not affect other decoding (as confirmed by the test
suite).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following was occurring:
1. Code words would be read from the LZW data blocks.
2. If there was exactly enough space for one more codeword in the block, more
blocks were read. This is the off by one error. It should have read the
last code before doing this.
3. If the next block was the terminating block the code would be marked as
complete.
4. Another block would be attempted to be read, because the decoder was still
in the same state as step 2.
5. An error was generated because the decoder was trying to read blocks after it
had determined the stream had ended.
This fixes the GIF decoder failing to decode images without an
end-of-information code.
|
|
|
|
|
|
|
|
|
| |
Add tests that exert many different types of GIF files. Some of the tests are
disabled as the current gdk-pixbuf GIF implementation doesn't handle them
correctly. Future commits will fix these issues and enable the tests.
The test suite is generated in the PyGIF project
(https://github.com/robert-ancell/pygif)
|
|
|
|
|
|
|
| |
When building without GDK_PIXBUF_USE_GIO_MIME detect the format based on the
fill extension and not the mime type.
This makes these tests pass on Windows.
|
|
|
|
|
|
|
|
| |
When cloning the repo with git on Windows the symlinks end up being
normal files which contain the target path as text.
Make this kinda work by detecting if the files contain ascii only
and then treating the content as a filename in the parent directory.
|
|
|
|
|
|
|
| |
So we use the right path encoding on Windows and don't interpret the content
as text.
This makes the pixbuf-threads run on Windows.
|
|
|
|
|
|
| |
It already takes about 20 seconds on my Core i7, and it can get worse
when running multiple tests in parallel, so it's a prime candidate for
timeouts on our CI infrastructure.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=775229
|
|\
| |
| |
| |
| | |
Run the test suite on the CI pipeline
See merge request GNOME/gdk-pixbuf!7
|
| |
| |
| |
| |
| |
| |
| |
| | |
Meson allows us to classify each test in the test suite using one or
more tags; this allows us to specify what kind of tests we want to run
inside our CI infrastructure, for instance by tagging the "slow" tests
that should have a special time out value, or that should only be run on
demand to avoid hammering the build server.
|
|/ |
|
|
|
|
|
|
| |
We use Meson, now. The Meson build has been tested for almost a year in
our continuous integration pipeline, and it's functionally equivalent to
the Autotools one.
|
|
|
|
|
|
| |
Like the Autotools build allows us to decide whether the tests should be
installed in a known location, we should have this option for the Meson
build.
|
|
|
|
|
| |
Same as commit fc2d02ed908c524cc2831e5404d5f06b02e3f9fd, but for the
Meson build.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=795210
|
|
|
|
|
|
|
|
| |
We're currently installing the test launchers and parts of the test
data, but we're not installing the binaries and the whole suite of
image data we have.
https://bugzilla.gnome.org/show_bug.cgi?id=795527
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=779016
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=753605
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=778584
|
|
|
|
|
|
| |
Provided by Ariel Zelivansky <ariel.zelivans@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779012
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=786306
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=785973
|
|
|
|
|
|
|
|
|
|
|
| |
The pixbuf-area-updated and pixbuf-randomly-modified tests are
particularly taxing on the CPU, and though modern desktop machines
shouldn't have a problem dealing with those under 30 seconds, tests
are run in parallel, and busy build machines might fail those tests
because of timeouts.
Bump the timeouts to 300 seconds for those long tests to avoid test
failures.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=787050
|
|
|
|
| |
This is an interactive test program, not an automated one.
|
|
|
|
|
|
|
| |
When the test fails, let's first give it the chance to print the error
message in order to help debugging failures.
https://bugzilla.gnome.org/show_bug.cgi?id=786259
|
|
|
|
|
|
| |
Ensure variables are declared at the top of the block.
https://bugzilla.gnome.org/show_bug.cgi?id=785767
|
|
|
|
|
|
|
|
|
| |
sys/time.h is not a header that is provided by all compilers that we
support, so we need to check for it and include it conditionally so that
things will build normally, especially as Meson builds will build all
the test programs as well.
https://bugzilla.gnome.org/show_bug.cgi?id=785767
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=785964
|