requested update while update in progress

Bug #1273900 reported by David Mathog
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
New
High
Unassigned

Bug Description

On or near revision 12982 there is a show stopper of a bug. On linux when the program starts it goes into a loop where it emits
these:

WARNING: Requested update while update in progress, counter = 5

until the program is killed through external means (control-c or the like).

Revision history for this message
David Mathog (mathog) wrote :

I should add that it enters this loop as the program starts, no user input is needed (or possible) to trigger the problem.

Revision history for this message
David Mathog (mathog) wrote :

The problem was introduced at revision 12978.
"make clean" did not resolve the issue.

The system I tested this on is

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.3 LTS"

  gcc --version
gcc-4.6.real (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Revision history for this message
su_v (suv-lp) wrote :

> The problem was introduced at revision 12978.

Duplicate of bug #1272649?

See also comments of bug #1274158 (the same console messages, but with r12976).

Changed in inkscape:
importance: Undecided → High
milestone: none → 0.91
tags: added: crash regression
removed: critical
Revision history for this message
David Mathog (mathog) wrote :

Interesting.

Probably an access to uninitialized memory or something along those lines, which would explain why the symptoms vary from machine to machine. Testing was a binary search with these final results:

12983 bad
12982 bad
12979 bad
12978 bad
12977 good
12976 good
12970 good

all the bad ones failed the same way for me.

There are not that many changes in 12978, perhaps I can figure out the problem. Link to whichever other bug you want to be the primary.

Revision history for this message
David Mathog (mathog) wrote :
Download full text (3.5 KiB)

Ran it in the debugger and it had different symptoms. It stopped here:

Program received signal SIGSEGV, Segmentation fault.
0x08230e1b in SPObject::detach (this=0xa1329b8, object=0x5f9) at sp-object.cpp:539
539 g_return_if_fail(object->parent == this);
(gdb) bt
#0 0x08230e1b in SPObject::detach (this=0xa1329b8, object=0x5f9) at sp-object.cpp:539
#1 0x081f733b in SPImage::clear_image (this=0xa1329b8) at sp-image.cpp:537
#2 0x081f6aae in SPImage::update (this=0xa1329b8, ctx=0xbfffca90, flags=125) at sp-image.cpp:330
#3 0x082326c8 in SPObject::updateDisplay (this=0xa1329b8, ctx=0xbfffca90, flags=125) at sp-object.cpp:1144
#4 0x082024a6 in SPGroup::update (this=0xa132540, ctx=0xbfffcbb0, flags=95) at sp-item-group.cpp:186
#5 0x082326c8 in SPObject::updateDisplay (this=0xa132540, ctx=0xbfffcbb0, flags=95) at sp-object.cpp:1144
#6 0x082024a6 in SPGroup::update (this=0xa131a50, ctx=0xbfffccd0, flags=95) at sp-item-group.cpp:186
#7 0x082326c8 in SPObject::updateDisplay (this=0xa131a50, ctx=0xbfffccd0, flags=95) at sp-object.cpp:1144
#8 0x082024a6 in SPGroup::update (this=0xa131630, ctx=0xbfffcdf0, flags=95) at sp-item-group.cpp:186
#9 0x082326c8 in SPObject::updateDisplay (this=0xa131630, ctx=0xbfffcdf0, flags=95) at sp-object.cpp:1144
#10 0x082024a6 in SPGroup::update (this=0xa91a948, ctx=0xbfffcf74, flags=27) at sp-item-group.cpp:186
#11 0x082447be in SPRoot::update (this=0xa91a948, ctx=0xbfffd1a8, flags=27) at sp-root.cpp:496
#12 0x082326c8 in SPObject::updateDisplay (this=0xa91a948, ctx=0xbfffd1a8, flags=27) at sp-object.cpp:1144
#13 0x080d8dd9 in SPDocument::_updateDocument (this=0x922dee0) at document.cpp:1072
#14 0x080d8e80 in SPDocument::ensureUpToDate (this=0x922dee0) at document.cpp:1099
#15 0x084c748b in SVGDocCache::SVGDocCache (this=0xb4d56a8, doc=0x922dee0) at widgets/icon.cpp:1221
#16 0x084c5624 in IconImpl::load_svg_pixels (names=..., psize=18, stride=@0xbfffd3b4: 174706048) at widgets/icon.cpp:1298
#17 0x084c62d8 in IconImpl::prerenderIcon (name=0xa6afa90 "edit-undo", lsize=GTK_ICON_SIZE_SMALL_TOOLBAR, psize=18) at widgets/icon.cpp:1427
#18 0x084c711b in IconImpl::imageMapNamedCB (widget=0xa5b1538, user_data=0x0) at widgets/icon.cpp:1640
#19 0x012911ec in g_cclosure_marshal_VOID__VOID () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#20 0x0128f484 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0

The reason it stopped there is:
(gdb) print object
$15 = (SPObject *) 0x5f9
(gdb) print object->parent
Cannot access memory at address 0x611
(gdb) up
#1 0x081f733b in SPImage::clear_image (this=0xa1329b8) at sp-image.cpp:537
537 this->detach(this->child);
(gdb) print this
$16 = (SPImage * const) 0xa1329b8
(gdb) print this->child
$17 = (SPItem *) 0x5f9
(gdb) print this->child.parent
Cannot access memory at address 0x611
(gdb) up
#2 0x081f6aae in SPImage::update (this=0xa1329b8, ctx=0xbfffca90, flags=125) at sp-image.cpp:330
330 this->clear_image();
(gdb) print this->child.parent
Cannot access memory at address 0x611
(gdb) up
#3 0x082326c8 in SPObject::updateDisplay (this=0xa1329b8, ctx=0xbfffca90, flags=125) at sp-object.cpp:1144
1144 this->update(ctx, flags);...

Read more...

Revision history for this message
su_v (suv-lp) wrote :

> Program received signal SIGSEGV, Segmentation fault.
> 0x08230e1b in SPObject::detach (this=0xa1329b8, object=0x5f9) at sp-object.cpp:539
> 539 g_return_if_fail(object->parent == this);

Linking as duplicate to bug #1272649.

Revision history for this message
David Mathog (mathog) wrote :

revision 12984 works. (Doesn't crash as noted above, images seem to be handled properly.)

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.