trunk: crash when resizing page

[Liam P. White]

When resizing the page of this image (enter various numbers into the either of the page size spinboxes) several times (often in combination with undoing that action), Inkscape crashes. The backtraces of these crashes are not consistent, nor are they consistently reproducible, but the issue always occurs after some amount of resizing the page.

If one manages to resize the page without Inkscape crashing, watch what happens to the canvas. Calligraphic strokes deform into unrecognizable blobs and other odd behaviour occurs.

[Liam P. White (liampwhite)]

Attaching three backtraces.

[ScislaC (scislac)]

Reproduced with r13454 by doing the following with your test file:

1) Resize to selection or drawing
2) Undo
3) Resize to selection or drawing
4) Undo

On the second undo it crashes reliably here.

[ScislaC (scislac)]

Nevermind the reliability of exact steps... by doing somewhere between 1-3 patterns of the first two steps it seems to hit every time. This is now 15 attempts and all crashed after the first time which just did hang as opposed to crash.

[su_v (suv-lp)]

Trunk 0.48+devel r13454 (64bit, OS X 10.7.5):
Crash reproduced based on steps in comment 5 (though higher number of repeats required)

Stable 0.48.5 (64bit, OS X 10.7.5):
Hangs on quit after having repeated the steps to reproduce many times (without crash)

[Tavmjong Bah (tavmjong-free)]

Could it be related to threading? It has the same symptoms as bugs:

  https://bugs.launchpad.net/inkscape/+bug/967416
  https://bugs.launchpad.net/inkscape/+bug/1333445

i.e., random crashes on large files.

[Liam P. White (liampwhite)]

I don't know if it's a threading-related issue; but all of the crashes seem to involve something happening during the document update loop, which to my knowledge runs only on the main thread (but potentially could create others if GTK functions are called).

[Liam P. White (liampwhite)]

I believe this has been fixed in lp:inkscape r13474.

[Liam P. White (liampwhite)]

@Tav:

Not a threading issue.

The manual call to the destructors of those sigc::connection objects was actually the problem here.

If you take a look at the sigc++ code here, you may or may not see the problem:
https://stardictproject.googlecode.com/svn-history/r2/trunk/src/sigc++/functors/slot_base.cc
https://stardictproject.googlecode.com/svn-history/r2/trunk/src/sigc++/functors/slot_base.h
https://stardictproject.googlecode.com/svn-history/r2/trunk/src/sigc++/connection.cc

By destroying the connections early, the slot it is connected to will end up calling notify(), then as it is no longer referenced, it will be freed.
sigc++ assumes that client code is smart enough not to call the destructor manually (a relatively safe assumption) and therefore does not bother with setting pointers to NULL during destruction.

Once the destructor has been called once, the slot_base object had been freed and the connection fully destroyed. Calling it again did this:

- found slot_base::remove_destroy_notify_callback
- called it against two freed pointers (this and a stored pointer used to call against)
- memory written to after it is freed!
- sigc::connection::notify() called
- more heap memory overwritten

During time-critical situations such as these where SPObjects are being modified very quickly, dlmalloc() needs to be very aggressive about reclaiming freed memory. The problem with said free memory is that it will be allocated, and then sometimes the heap block header will have been overwritten, which dlmalloc detects upon the next free and raises SIGABRT.

[jazzynico (jazzynico)]

Fix confirmed on Windows XP, Inkscape trunk revision 13484.