GNOME Bugzilla – Bug 589667
GIMP crashes when clicking GEGL Operation on Windows
Last modified: 2009-08-11 16:18:17 UTC
Please describe the problem: When ever there is an open or newly created image loaded in GIMP, GIMP will crash when GEGL Operation is click on in the Tools menu. I have found this to occur for *.bmp, *.jpeg, and *.png image types. It will also occur if a new image is created, even if it is not saved yet. However, it does not occur if there is no image loaded yet into GIMP. Steps to reproduce: 1. Open any *.jpeg file. 2. Access the Tools menu in any way (right clicking on the image, using the top menu bar, ect). 3. Click on GEGL Operation Actual results: You get a Microsoft Error report saying "gimp-2.6.exe has encountered a problem and needs to close. We are sorry for the inconvenience." Expected results: I am new at GIMP and was just exploring the menu options, so I am not really sure what GEGL is or what it is supposed to do (from what I gather it is some sort of new core engine for GIMP). Does this happen every time? Yes Other information:
Hi, what version of Windows are you using? If you move C:\Program Files (x86)\GIMP-2.0\lib\gegl-0.0\load-buffer.dll to your desktop and restart GIMP, does it still crash?
(In reply to comment #1) > Hi, what version of Windows are you using? If you move > > C:\Program Files (x86)\GIMP-2.0\lib\gegl-0.0\load-buffer.dll > > to your desktop and restart GIMP, does it still crash? > Windows XP Profession Service Pack 3 Version 5.1 Build 2006.xpsp_sp3_gdr.090206-1234 I am not really sure what the build means but I hope it is useful. If I mover load-buffer.dll to the desktop GIMP still crashes. Best Regards, Jared
I should also mention that it is 32 bit Genuine Windows XP.
Hi. I have the same problem, on 2 different computers (Windows XP + all fixes), while I am using version 2.6.6. I didn't have this problem with version 2.6.0. It happens always, when I try to call a window with GEGL operations. No matter, what is the initial file format.
I can confirm this problem happening on: Windows XP SP 3 Gimp 2.6.6 Open any file, try to use a GEGL operation through the toolbar, and crash: "Unhandled win32 exception occurred in gimp-2.6.exe [2824]" This does NOT happen in 2.6.5, but does happen in 2.7.0-git-20090507 (i know it's a dev release, but just trying it out and figured i would at least mention it here).
Let's put this on the 2.6 milestone list.
We do not even have a vague idea what is going wrong here. It is very likely just another duplicate of the Color tools problem in 2.6.6 that has been reported every so often.
I have been debugging this and I don't think it's a pure duplicate to the crash of the Color tools. For me, GIMP stopped crashing when I removed "C:\Program Files (x86)\GIMP-2.0\lib\gegl-0.0\load-buffer.dll". When looking at the stack trace, it is corrupt. There is memory corruption going on. I'm currently on my way to further investigate this problem. We definitely should have this on the 2.6 milestone list because it's a problem many people are having, it causes data loss, and we need to fix it.
This commit makes the GEGL Operation work in GIMP built with the mingw32 tool chain in Fedora and run in wine. Hopefully this fixes this problem. The previous code was clearly severely broken. Before closing this as FIXED I would like someone else to confirm the fix. commit d9023a0a88215475e1a1b63f9ffb1f0463f34378 Author: Martin Nordholts <martinn@src.gnome.org> Date: Tue Aug 4 21:51:26 2009 +0200 gegl: Properly build module_path for win32 Don't use deprecated API when building module_path on win32, and construct a dir path, not a path to the GEGL dll. This might fix bug 589667. gegl/gegl-init.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-)
Ok the previous code wasn't at broken as I thought it was on first site... But at least we got rid of deprecated API.
This is only half of the fix. You have to pass the libgegl module handle to this function, not NULL; otherwise libgegl won't find its modules.
With modules, do you mean operations? That works fine for me in Wine when I simulate Windows XP.
You probably got libgegl and gimp.exe in the same directory, and the modules in a lib/ subdirectory of the same tree, right?
This is my layout: $prefix/bin/gimp-2.7.exe $prefix/bin/libgegl-0.1-0.dll $prefix/lib/gegl-0.1/add.dll $prefix/lib/gegl-0.1/affine.dll $prefix/lib/gegl-0.1/...
*** Bug 587148 has been marked as a duplicate of this bug. ***
*** Bug 574584 has been marked as a duplicate of this bug. ***
I have reverted the commit, I was on the wrong track. This currently appears to be an Installer build problem.
Here is the stack trace using a recent installer: gimp-2.6.exe caused an Access Violation at location 601f3162 Reading from location 00000001. Registers: eax=00000001 ebx=602e6ff4 ecx=00000001 edx=00770e10 esi=ffffffff edi=02bc0540 eip=601f3162 esp=0198ed7c ebp=0198edc8 iopl=0 nv up ei pl nz na pe nc cs=0073 ss=007b ds=007b es=007b fs=0033 gs=003b efl=00010202 Call stack: 601F3162 6035E234 ntdll.dll:6035E234 NTDLL_strstr 0049B00F gimp-2.6.exe:0049B00F gimp_gegl_tool_dialog gimpgegltool.c:351 0048E99D gimp-2.6.exe:0048E99D gimp_image_map_tool_dialog gimpimagemaptool.c:466 0048E4B9 gimp-2.6.exe:0048E4B9 gimp_image_map_tool_initialize gimpimagemaptool.c:331 0049AAD3 gimp-2.6.exe:0049AAD3 gimp_gegl_tool_initialize gimpgegltool.c:167 00497C2A gimp-2.6.exe:00497C2A gimp_tool_initialize gimptool.c:428 00480520 gimp-2.6.exe:00480520 tool_manager_initialize_active tool_manager.c:236 00428E74 gimp-2.6.exe:00428E74 tools_select_cmd_callback tools-commands.c:104 63A43955 libgobject-2.0-0.dll:63A43955 g_closure_invoke 63A57E95 libgobject-2.0-0.dll:63A57E95 g_signal_has_handler_pending 63A58C21 libgobject-2.0-0.dll:63A58C21 g_signal_emit_valist 63A58EA6 libgobject-2.0-0.dll:63A58EA6 g_signal_emit 005696FA gimp-2.6.exe:005696FA gimp_string_action_selected gimpstringaction.c:195 00569663 gimp-2.6.exe:00569663 gimp_string_action_activate gimpstringaction.c:186 63A43955 libgobject-2.0-0.dll:63A43955 g_closure_invoke 63A57892 libgobject-2.0-0.dll:63A57892 g_signal_has_handler_pending 63A58C21 libgobject-2.0-0.dll:63A58C21 g_signal_emit_valist 63A58EA6 libgobject-2.0-0.dll:63A58EA6 g_signal_emit 6178CCD4 libgtk-win32-2.0-0.dll:6178CCD4 gtk_action_new 63A43955 libgobject-2.0-0.dll:63A43955 g_closure_invoke 63A57892 libgobject-2.0-0.dll:63A57892 g_signal_has_handler_pending 63A58C21 libgobject-2.0-0.dll:63A58C21 g_signal_emit_valist 63A58EA6 libgobject-2.0-0.dll:63A58EA6 g_signal_emit 6198E3CB libgtk-win32-2.0-0.dll:6198E3CB gtk_widget_activate 6187EFFC libgtk-win32-2.0-0.dll:6187EFFC gtk_menu_shell_activate_item 6187F39A libgtk-win32-2.0-0.dll:6187F39A gtk_menu_shell_activate_item 61869062 libgtk-win32-2.0-0.dll:61869062 gtk_marshal_VOID__UINT_STRING 63A43955 libgobject-2.0-0.dll:63A43955 g_closure_invoke 63A57AC6 libgobject-2.0-0.dll:63A57AC6 g_signal_has_handler_pending 63A5899B libgobject-2.0-0.dll:63A5899B g_signal_emit_valist 63A58EA6 libgobject-2.0-0.dll:63A58EA6 g_signal_emit 6198E554 libgtk-win32-2.0-0.dll:6198E554 gtk_widget_activate 618660B1 libgtk-win32-2.0-0.dll:618660B1 gtk_propagate_event 61867511 libgtk-win32-2.0-0.dll:61867511 gtk_main_do_event 6C374DBE libgdk-win32-2.0-0.dll:6C374DBE gdk_event_get_graphics_expose 685E6FB7 libglib-2.0-0.dll:685E6FB7 g_main_context_dispatch 685E8695 libglib-2.0-0.dll:685E8695 g_main_context_acquire 685E891A libglib-2.0-0.dll:685E891A g_main_loop_run 00401686 gimp-2.6.exe:00401686 app_run app.c:247 004022ED gimp-2.6.exe:004022ED main main.c:426 004010B6 gimp-2.6.exe:004010B6 00401128 gimp-2.6.exe:00401128 6044591F KERNEL32.dll:6044591F WritePrivateProfileSectionA The line with the crash is GeglOperationClass *opclass = GEGL_OPERATION_CLASS (iter->data); >> if (strstr (opclass->categories, "color") || which makes me suspect that the crash is due to GEGL operations with too new/old ABI is included in the installer. Doing a clean installer build with no old build results lying aorund should fix this problem.
This has now been confirmed to be a installer problem. We can close this as FIXED as the 2.6.7 installer will not have this issue.
*** Bug 577581 has been marked as a duplicate of this bug. ***