After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 712773 - tile-backend doesn't seem to work
tile-backend doesn't seem to work
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: core
git master
Other Linux
: Normal major
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2013-11-20 22:06 UTC by Téo Mazars
Modified: 2013-11-28 20:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tiles lost (338.23 KB, image/png)
2013-11-24 11:50 UTC, Téo Mazars
  Details
proposed patch (2.28 KB, patch)
2013-11-27 11:54 UTC, Massimo
none Details | Review

Description Téo Mazars 2013-11-20 22:06:09 UTC
Using GIMP with a low image-chache size (eg 100MB) and with a large image (eg 3k x 3k), it will likely crash inside GEGL (or do something else crazy)

After several tries, GEGL doesn't segfault in the same place... The current hypothesis is that the tile-backend doesn't work as it should.

I don't have much information currently, attaching a stack trace won't really help since it changes each time, but I fill the bug so we don't forget it.
Comment 1 Téo Mazars 2013-11-23 13:17:02 UTC
As suggested by Massimo, trying:

diff --git a/gegl/buffer/gegl-buffer-linear.c b/gegl/buffer/gegl-buffer-linear.c
index b57ab6f..ed5066b 100644
--- a/gegl/buffer/gegl-buffer-linear.c
+++ b/gegl/buffer/gegl-buffer-linear.c
@@ -45,6 +45,7 @@ gegl_buffer_linear_new2 (const GeglRectangle *extent,
                        "tile-width", rowstride,
                        "tile-height", extent->height,
                        "format", format,
+                       "path", "RAM",
                        NULL);
 
   g_object_set_data (G_OBJECT (buffer), "is-linear", (void*)0xf00);


GIMP still crashes while painting...

Though, this time, it crashes always at the same place:

  • #0 waitpid
    from /lib64/libpthread.so.0
  • #1 g_on_error_stack_trace
  • #2 g_on_error_query
    from /lib64/libglib-2.0.so.0
  • #3 gimp_eek
  • #4 gimp_fatal_error
  • #5 gimp_sigfatal_handler
  • #6 <signal handler called>
  • #7 gegl_resample_boxfilter_float
  • #8 gegl_buffer_get_unlocked
  • #9 gimp_display_shell_render
  • #10 gimp_display_shell_draw_image
  • #11 gimp_display_shell_canvas_draw_image
  • #12 gimp_display_shell_canvas_expose
  • #13 _gtk_marshal_BOOLEAN__BOXED
  • #14 g_closure_invoke
    from /lib64/libgobject-2.0.so.0
  • #15 signal_emit_unlocked_R
  • #16 g_signal_emit_valist
  • #17 g_signal_emit
    from /lib64/libgobject-2.0.so.0
  • #18 gtk_widget_event_internal
  • #19 gtk_main_do_event
    from /lib64/libgtk-x11-2.0.so.0
  • #20 _gdk_window_process_updates_recurse
  • #21 _gdk_window_process_updates_recurse
  • #22 gdk_window_process_updates_internal
  • #23 gdk_window_process_updates
  • #24 gimp_display_flush_whenever
  • #25 gimp_paint_tool_button_press
  • #26 gimp_tool_button_press
  • #27 gimp_display_shell_canvas_tool_events
  • #28 _gtk_marshal_BOOLEAN__BOXED
  • #29 g_closure_invoke
    from /lib64/libgobject-2.0.so.0
  • #30 signal_emit_unlocked_R
  • #31 g_signal_emit_valist
  • #32 g_signal_emit
    from /lib64/libgobject-2.0.so.0
  • #33 gtk_widget_event_internal
  • #34 gtk_propagate_event
  • #35 gtk_main_do_event
    from /lib64/libgtk-x11-2.0.so.0
  • #36 gdk_event_dispatch
    from /lib64/libgdk-x11-2.0.so.0
  • #37 g_main_context_dispatch
  • #38 g_main_context_iterate.isra.24
  • #39 g_main_loop_run
    from /lib64/libglib-2.0.so.0
  • #40 app_run
  • #41 main
    at main.c line 438

Comment 2 Téo Mazars 2013-11-23 13:20:03 UTC
Also it sometimes behaves strangely: painting seems to make gegl lose tiles as they became transparent. Also, applying a gegl filter makes the image disappear forever (even with canceling)
Comment 3 Téo Mazars 2013-11-24 11:50:36 UTC
Created attachment 261348 [details]
tiles lost

When zoomed at 50%, and with the "path", "RAM", it doesn't always crashes, the screenshot attached shows what happens, something like losing tiles.
Comment 4 Massimo 2013-11-27 11:54:31 UTC
Created attachment 262931 [details] [review]
proposed patch

these are two patches trying to fix the crashes and the artifacts:

1) creating the linear buffer in RAM explicitely mark the tile as
   not yet stored (a new tile is by default considered stored)

2) when inserting a tile in the cache explicitely initialize tile's
   members used when the tile is successively stored by the backend
Comment 5 Téo Mazars 2013-11-27 20:51:09 UTC
Review of attachment 262931 [details] [review]:

It fixes the issue here. Now it works flawlessly with a low image-cache size. Nice :)
Comment 6 Téo Mazars 2013-11-28 20:50:38 UTC
Fixed in master, thanks!

commit 9a13353487a8e19f30ab9806a68188a303657ff2
Author: Massimo Valentini <mvalentini@src.gnome.org>
Date:   Thu Nov 28 18:45:02 2013 +0100

    gegl: use RAM backend for linear buffers

 gegl/buffer/gegl-buffer-linear.c | 41 ++++++++++++++++++++++++----------------
 1 file changed, 25 insertions(+), 16 deletions(-)

commit 9d2b618ea925e132668bb8b43bbb3c4cef19ec2b
Author: Massimo Valentini <mvalentini@src.gnome.org>
Date:   Thu Nov 28 18:23:34 2013 +0100

    gegl: initialize tile's members before inserting in the cache

 gegl/buffer/gegl-tile-handler-cache.c | 5 +++++
 1 file changed, 5 insertions(+)