| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Instead of duplicating code to free the superclass all over the place,
use a single function.
Also, remove a bit of the 'upself' idiom - it's unreadable.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=761728
|
| |
|
|
|
|
| |
We're almost there resolving everything lazily...
|
|
|
|
|
|
| |
This function does proper recursion checks when looking up resources
from URLs and thereby helps avoiding infinite loops when cyclic
references span multiple types of elements.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=630732
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=700911
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In order to support building under Visual Studio and other C89 compilers,
we need to avoid using VLAs, especially that VLAs are:
-Most probably not going to be supported under any Visual Studio
-It is now optional under C11, and there are concerns regarding its
implementations in other C99-capable compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=753555
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=748608
|
|
|
|
|
|
| |
The convolution matrix on the Y axis is leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=748608
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=748608
|
|
|
|
| |
Otherwise the cairo_t, and the surface it's created on are leaked.
|
| |
|
|
|
|
|
|
|
| |
This replaces the blurring machinery with a real gaussian blur for small radiuses,
and fixes box blurs for large radiuses.
Based on a patch by Eduard Braun.
|
| |
|
|
|
|
|
|
|
|
| |
rsvg_filter_primitive_displacement_map_render()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=744270
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the convolution matrix filter code, we read the orderx and ordery for the convolution
matrix. However, multiplying them as gints may overflow.
Found by fuzz testing when orderx = ordery = 65536
Fuzz testing kindly provided by Atte Kettunen <attekett@gmail.com>
From librsvg-fuzz case rsvgconvert-060-3ef-705-f72.svg
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
|
|
|
|
|
|
|
|
|
|
| |
The source offsets were not being validated correctly, so we could easily do a read or write
outside the bounds of the image surface. We now use a generic function to clip rectangles
instead of doing it by hand.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=703102
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=731182
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=731182
|
|
|
|
| |
We've already dereferenced name at this point.
|
|
|
|
| |
Yikes. Just select R/G as defaults.
|
| |
|
| |
|
|
|
|
|
|
| |
Fix warnings when building with -Wuninitialized.
Bug #672725.
|
|
|
|
|
|
| |
Wrap _rsvg_io_acquire_* in _rsvg_handle_acquire_* that first
checks whether the load should be allowed. For the moment, always allow
the load; more restricted policies will be introduced in a follow-up commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==9147== 691,200 bytes in 1 blocks are possibly lost in loss record 5,494 of 5,494
==9147== at 0x4029467: calloc (vg_replace_malloc.c:467)
==9147== by 0x518BB09: _pixman_bits_image_init (pixman-bits-image.c:1437)
==9147== by 0x518BBD7: pixman_image_create_bits (pixman-bits-image.c:1503)
==9147== by 0x499CD4E: _cairo_image_surface_create_with_pixman_format (cairo-image-surface.c:329)
==9147== by 0x499CE14: cairo_image_surface_create (cairo-image-surface.c:379)
==9147== by 0x403EA89: _rsvg_image_surface_new (rsvg-filter.c:160)
==9147== by 0x404112B: rsvg_filter_primitive_offset_render (rsvg-filter.c:1618)
==9147== by 0x4049D6F: rsvg_filter_render (rsvg-filter.c:86)
==9147== 460 (288 direct, 172 indirect) bytes in 1 blocks are definitely lost in loss record 5,205 of 5,494
==9147== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==9147== by 0x4999F1A: _cairo_image_surface_create_for_pixman_image (cairo-image-surface.c:158)
==9147== by 0x499CD60: _cairo_image_surface_create_with_pixman_format (cairo-image-surface.c:335)
==9147== by 0x499CE14: cairo_image_surface_create (cairo-image-surface.c:379)
==9147== by 0x403EA89: _rsvg_image_surface_new (rsvg-filter.c:160)
==9147== by 0x404112B: rsvg_filter_primitive_offset_render (rsvg-filter.c:1618)
==9147== by 0x4049D6F: rsvg_filter_render (rsvg-filter.c:86)
|
| |
|
|
|
|
|
| |
Need to reference the source surface put into the results stack. This fixes
a regression introduced in commit 1b3d2ea55a1be67e0548bf76903ff905888e2e18.
|
| |
|
|
|
|
| |
... not afterwards!
|
|
|
|
| |
... instead of GdkPixbufs to store the filter results.
|
| |
|
| |
|
|
|
|
| |
... instead of into a GdkPixbuf.
|
|
|
|
| |
Two for-loops was missing their initial expression in the box_blur function.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This created lots and lots of critical warnings when rendering
tests/svg1.1/svg/filters-displace-01-f.svg:
GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion `width > 0' failed
g_logv() [gmessages.c:779]
g_log() [gmessages.c:826]
g_return_if_fail_warning() [gmessages.c:838]
gdk_pixbuf_new() [gdk-pixbuf.c:338]
rsvg_filter_primitive_image_render_ext() [rsvg-filter.c:3376]
|
|
|
|
|
|
| |
The image will now not crash librsvg, but doesn't render at all.
https://bugzilla.gnome.org/show_bug.cgi?id=624835
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I've checked this quite carefully, but it still might contain
stupid typo bugs ;-)
|
| |
|
|
|
|
| |
Otherwise we get an invalid read when freeing this node.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The node name (formerly RsvgNode:type) cannot be used to infer
the sub-type of RsvgNode that we're dealing with, since for unknown
elements we put type = node-name. This lead to a (potentially exploitable)
crash e.g. when the element name started with "fe" which tricked
the old code into considering it as a RsvgFilterPrimitive.
CVE-2011-3146
https://bugzilla.gnome.org/show_bug.cgi?id=658014
|