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 603711 - Crashes when using path tool.
Crashes when using path tool.
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
2.6.7
Other Windows
: Normal major
: 2.6
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2009-12-03 17:30 UTC by James
Modified: 2010-05-16 08:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Quick hack to limit the effects of uninitialized variables (563 bytes, patch)
2009-12-04 12:58 UTC, Massimo
rejected Details | Review

Description James 2009-12-03 17:30:37 UTC
Recently I have started seriously using paths in images.

Starting a month ago odd things have happened when using ans manipulating large amounts of paths.

First whilst working on an image GIMP crashed completely, showing the following error message:

GLib-ERROR **: gmem.c:136: failed to allocate 1618733314 bytes aborting...

Somehow this also corrupted the saved .xcf file (wasn't saving at the time) and the same message now appears when trying to open the file with GIMP.

Three or four times after this GIMP has crashed without displaying error messages when editing images with large amounts of paths.
GIMP exits completely during these crashes and the save files are okay.
Comment 1 Martin Nordholts 2009-12-03 17:33:45 UTC
Hi and thanks for the bug report! We need a step-by-step instruction on how to reproduce the problem.
Comment 2 James 2009-12-03 22:35:09 UTC
The problem always occurs when editing and creating multiple large paths. Images have always been in .xcf format and have multiple layers.

There is often quite a large time delay between opening the file and the crash can range from 15 minutes to an hour.

A repeat of the first incident has not yet occurred. Though the second kind of crash did not occur until it happened.

More than that I don't know what to tell you. 
There may be some connection to trying to stroke the path or convert it to selection, but I don't know for sure and it definitely doesn't do it all the time when using those features.
Comment 3 Sven Neumann 2009-12-03 23:07:05 UTC
I am afraid without a stack trace from the crash there is nothing we can do.
Comment 4 Massimo 2009-12-04 12:58:36 UTC
Created attachment 149082 [details] [review]
Quick hack to limit the effects of uninitialized variables

A short run under valgrind reveals usages of uninitialized values.

Step to reproduce (with version 2.6.7):

Ctrl+N Enter             (New Image)
B                        (Path tool)
click the left button of the mouse
move the mouse
click the left button of the mouse
move the mouse
Press Shift


The problem is that in gimp_display_shell_canvas_tool_events 
(in file 'app/display/gimpdisplayshell-calllbacks.c')

'display_coords' is declared uninitialized.

Its initialization occurs in 'gimp_display_shell_get_event_coords'
but the member 'velocity' is left uninitialized.

Several execution paths successively access the content of this 
variable.

With the attached patch, that explicitly initializes it to 0., 
valgrind does not report these errors.
Comment 5 Tobias Mueller 2010-01-25 10:18:04 UTC
Reopening as requested information has (almost) been provided.
Comment 6 Michael Natterer 2010-01-31 16:28:18 UTC
Initialize stuff in master and 2-6. James, can you check whether this
fixes the crash in the next stable release?

commit 353ef2037dfbcda8aec8507f8aa7ce5619d3fed0
Author: Michael Natterer <mitch@gimp.org>
Date:   Sun Jan 31 17:19:51 2010 +0100

    Bug 603711 - Crashes when using path tool
    
    gimp_display_shell_get_*_coord(): initialize the coords with
    GIMP_COORDS_DEFAULT_VALUES allGimpCoords members get initialized.
    (cherry-picked from 74bf91cb63ec9ee64d7f2ab2c1b58f118b0f61e1)

 app/display/gimpdisplayshell-coords.c |   47 +++++++++++---------------------
 1 files changed, 16 insertions(+), 31 deletions(-)
Comment 7 Martin Nordholts 2010-05-16 08:36:18 UTC
Review of attachment 149082 [details] [review]:

Well, the initialization of velocity should happen where the other members are initialized.
Comment 8 Martin Nordholts 2010-05-16 08:36:57 UTC
No further reports about this, let's assume it's FIXED now until proven otherwise.