Pinta crashes frequently with large images

Bug #776346 reported by grofaty on 2011-05-03
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Pinta
Medium
Unassigned

Bug Description

In Pinta 1.0 on Windows XP I have tried to do the opposite from bug 776307 (in bug report it tried to create image with 0 x 0 size), but I tried to create as much big image as possible. I have created a new bug report, because I get different error messages.

1. Open Pinta and click New button from toolbar.
2. Type in very large number like million for both fields Width and Height, when field is left number default to 10000 (so writing 10000 in each field is sufficient).
3. Click on OK button.
4. Click on Image menu and then move mouse to View menu and crash appears:

=========
Unhandled exception:
Object reference not set to an instance of an object.

Details:
System.NullReferenceException: Object reference not set to an instance of an object.
   at Pinta.Gui.Widgets.CanvasRenderer.RenderZoomOut(ImageSurface src, ImageSurface dst, Point offset, Size destinationSize, Boolean checker) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Gui.Widgets\Widgets\Canvas\CanvasRenderer.cs:line 211

  at Pinta.Gui.Widgets.CanvasRenderer.Render(ImageSurface src, ImageSurface dst, Point offset, Boolean checker) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Gui.Widgets\Widgets\Canvas\CanvasRenderer.cs:line 55

   at Pinta.Gui.Widgets.PintaCanvas.OnExposeEvent(EventExpose e) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Gui.Widgets\Widgets\Canvas\PintaCanvas.cs:line 136

   at Gtk.Widget.exposeevent_cb(IntPtr widget, IntPtr evnt)
=========

Another reproduce scenario:
step 4. From zoom drop down list from toolbar select 100% and crash appears:

=========
Unhandled exception:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Details:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

   at Pinta.Gui.Widgets.CanvasRenderer.RenderOneToOne(ImageSurface src, ImageSurface dst, Point offset, Boolean checker) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Gui.Widgets\Widgets\Canvas\CanvasRenderer.cs:line 84

   at Pinta.Gui.Widgets.CanvasRenderer.Render(ImageSurface src, ImageSurface dst, Point offset, Boolean checker) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Gui.Widgets\Widgets\Canvas\CanvasRenderer.cs:line 51

   at Pinta.Gui.Widgets.PintaCanvas.OnExposeEvent(EventExpose e) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Gui.Widgets\Widgets\Canvas\PintaCanvas.cs:line 136

   at Gtk.Widget.exposeevent_cb(IntPtr widget, IntPtr evnt)
=========

Cameron White (cameronwhite91) wrote :

I can't reproduce either of those crashes using Pinta 1.0 or the latest development build on Windows 7, but I do get a crash if I attempt to use the Paint Bucket tool.

Steps:
1) Create a new 10000 x 10000 image
2) Select Paint Bucket tool and attempt to use it (i.e. click on canvas)

======

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.

Parameter name: y

   at Pinta.Core.BitVector2DSurfaceAdapter.Set(Int32 x, Int32 y, Boolean newValue) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Core\Effects\BitVector2DSurfaceAdapter.cs:line 102

   at Pinta.Core.BitVector2DSurfaceAdapter.Set(Rectangle rect, Boolean newValue) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Core\Effects\BitVector2DSurfaceAdapter.cs:line 117

   at Pinta.Tools.FloodTool.FillStencilFromPoint(ImageSurface surface, IBitVector2D stencil, Point start, Int32 tolerance, Rectangle& boundingBox, Region limitRegion, Boolean limitToSelection) in C:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Tools\FloodTool.cs:line 195

   at Pinta.Tools.FloodTool.OnMouseDown(DrawingArea canvas, ButtonPressEventArgs args, PointD point) in C:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Tools\FloodTool.cs:line 135

   at Pinta.Tools.PaintBucketTool.OnMouseDown(DrawingArea canvas, ButtonPressEventArgs args, PointD point) in C:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Tools\PaintBucketTool.cs:line 59

   at Pinta.Core.BaseTool.DoMouseDown(DrawingArea canvas, ButtonPressEventArgs args, PointD point) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Core\Classes\BaseTool.cs:line 97

   at Pinta.Gui.Widgets.PintaCanvas.<.ctor>b__2(Object sender, ButtonPressEventArgs e) in c:\Users\Jonathan\Documents\Visual Studio 2010\Projects\Pinta\Pinta.Gui.Widgets\Widgets\Canvas\PintaCanvas.cs:line 62

   --- End of inner exception stack trace ---

   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)

   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)

   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

   at System.Delegate.DynamicInvokeImpl(Object[] args)

   at GLib.Signal.ClosureInvokedCB(Object o, ClosureInvokedArgs args)

   at GLib.SignalClosure.Invoke(ClosureInvokedArgs args)

   at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data)

=======

Robert Nordan (rpvn) wrote :

I would hazard a guess that Cameron has more RAM on his system than grofaty, since attempting to read or write protected memory is a classic symptom of the program trying to use more memory than is available. (Trying to write to protected memory means its trying to overwrite memory from other programs, which of course is a big no-no.) Still needs fixing of course, "buy a new computer" is not a good workaround. :P

Cameron's error sounds like it's trying to assign a number that is out of range for a 32-bit int, which is weird because 10000^2 should be an order of magnitude less than Int32.MaxValue. It might be something related to looking up the position for painting or something.

grofaty (grofaty) wrote :

In may this year I had 1 GB of RAM, now on the same notebook I have 3 GB of RAM. Now I can't reproduce the first issue in bug report, but I can still reproduce like in second attempt (zoom to 100%) and crash still appears.

But on the other hand I can't reproduce Cameron scenario in step #1. Actually I get a grayed canvas instead of white one and no object like Paintbrash or Paint Bucket has any effect.

I don't think this bug is very likely to happen often, so I think it can be market with low importance. But I still think issues that produces crash should be avoided and instead of crash should report some info message or something.

Robert Nordan (rpvn) on 2012-01-20
summary: - Pinta crashes when 10000 x 10000 pixel image is selected
+ Pinta crashes when RAM is used up
Changed in pinta:
status: New → Confirmed
importance: Undecided → Low

Bumping in priority since I've been seeing crashes happen frequently when working with very large images, particularly with resizing.

I've noticed that they often happen when creating a Cairo.ImageSurface, and the returned ImageSurface has its Status as "NoMemory".

Changed in pinta:
importance: Low → High
summary: - Pinta crashes when RAM is used up
+ Pinta crashes frequently with large images
grofaty (grofaty) on 2012-04-25
tags: added: crash
Jonathan Pobst (jpobst) wrote :

Yep, I see the NoMemory ImageSurface as well. We probably need to add error checking to some place like WorkspaceManager.CreateAndActivateDocument or it's callers to alert the user that the document could not be created or opened.

grofaty (grofaty) wrote :

Pinta v1.4 on Windows XP, I can still reproduce the bug as described in bug description.

grofaty (grofaty) wrote :

Tested on Pinta-1.5-preview-20121121 on Windows XP and problem still appears as in bug report.

Cameron White (cameronwhite91) wrote :

This doesn't seem to be an issue at all for me anymore on Ubuntu 12.10 (64-bit) with the latest development builds. I was able to perform dozens of operations on a 10000x10000 image without any crashes.

With a Windows XP virtual machine (assigning it 4GB of RAM), I get the grey canvas mentioned in one of the previous comments. I haven't get gotten a crash, but none of the tools, etc. do anything.

grofaty (grofaty) wrote :

Cam, maybe you should lower the Windows XP virtual machine specification to something like 1 GB.

Cameron White (cameronwhite91) wrote :

That's actually the setting I originally was using, but I raised it to 4GB to see if that would fix the grey canvas issue.

Don McComb (don-mccomb) wrote :

In my Linux Mint 14 xfce VirtualBox virtual machine, I created a 3000 x 3000 image and drew a big scribble. I then proceeded to fill in the shapes created by my scribble with the flood fill tool. With each fill, the program responded slower and slower until it ultimately crashed. I suspect the SimplyHistoryItems just accumulated too much memory. The following was displayed in the "Application Output" window of Monodevelop:

The program 'Pinta' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 64344 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Don McComb (don-mccomb) on 2014-09-01
Changed in pinta:
assignee: nobody → Don McComb (don-mccomb)
status: Confirmed → In Progress
Don McComb (don-mccomb) wrote :

As mentioned by Camera and Jonathan, the problems occur when Pinta attempts to create a new Cairo.ImageSurface. Cairo returns a 'nil' ImageSurface which can be detected by checking if it's 'Status' member is 'NoMemory'. At the moment we don't detect this and attempt to carry on as if it is a valid ImageSurface. This leads to various strange and ugly situations.

It would take a little while to track down, but we could identify all locations in the program where this situation may occur and handle them more gracefully, though this could mean the user is repeatedly confronted with 'Insufficient Memory' messages. We could also give the user the option to abandon the history to free up more memory.

Ideally we would implement support for large images. Paint.NET does a reasonable job of large images and GIMP works extremely well. In 2009, GIMP used a tiling method to support large images:
http://comments.gmane.org/gmane.comp.lib.cairo/16596
Implementing tiling would be a very significant change to Pinta. I don't want to take this on, but I'm happy to work on detecting nil ImageSurfaces and presenting 'Insufficient Memory' messages.

Don McComb (don-mccomb) wrote :

I don't have time to work on this at the moment. We could look at the Gimp library GEGL, which features tiling to support editing of very large images. It also features a large array of image operations. There was a C# binding, GEGL Sharp, but it was abandoned a little over 18 months ago. The C# binding didn't support GEGL Buffer Iterators, and I stalled trying to get it across.

Changed in pinta:
assignee: Don McComb (don-mccomb) → nobody
status: In Progress → Confirmed
grofaty (grofaty) wrote :

Cameron, can you please do one of the two things: assign milestone to this "high" priority bug or lower the priority of bug. High priority bugs should have milestone defined.

Changed in pinta:
importance: High → Medium

(Pinta 1.7, Linux) When I try to work with 7000x5000 image with two layers, saving in .ora format throws exception which I can't get out of. The problem is probably related to memory use, even after short drawing memory use grows from 150MB to over a gigabyte. If this causes crashes and prevents saving, I suggest you give this as high priority as you can. Btw, there are many articles about C# memory problems, like avoiding foreach and how to implement additional memory management. I guess it's a must unless some other algorithmic memory can be used (like tiling). It probably would help with performance also.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers