Deleting a group containing a gradient used outside => crash

[Wolfiq]

Hi,

I received the following bug-report against debian's
0.40 version of the package yesterday. Debian's BTS has
it at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292676
I can reproduce the bug here as well, but on my
PowerBook the corruption appears in the corner of the
"lock slice" which is not affected on the png he links
to. I created a backtrace too, which is quite different
from his. The attached file contains actually two
backtraces, one started via
gdb -c core /usr/bin/inkscape
the other via gdb -c core.

gdb output and comparison of the backtraces makes me
believe in stack corruption.

With best regards,

Wolfi

Matías Costa wrote:

Hello, I found a curious bug. How to reproduce:

1 - Open the file
http://webs.ono.com/uucp/inkscape/bug.svg

2 - You see a lock, and two papers. Remove some paper
shape, i.e: the
blue one on top, below the lock. Then you should see a
sape in the lock
filled with noise. something like this:
http://webs.ono.com/uucp/inkscape/shot.png

3 - Select the affected shape and move it... bye.

You can get a gdb backtrace from:
http://webs.ono.com/uucp/inkscape/gdb-bt.txt

BTW the lock should look full yellow.

Thanks.

[Wolfiq (wolfiq)]

Hi,

I received the following bug-report against debian's
0.40 version of the package yesterday. Debian's BTS has
it at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292676
I can reproduce the bug here as well, but on my
PowerBook the corruption appears in the corner of the
"lock slice" which is not affected on the png he links
to. I created a backtrace too, which is quite different
from his. The attached file contains actually two
backtraces, one started via
gdb -c core /usr/bin/inkscape
the other via gdb -c core.

gdb output and comparison of the backtraces makes me
believe in stack corruption.

With best regards,

Wolfi

Matías Costa wrote:

Hello, I found a curious bug. How to reproduce:

1 - Open the file
http://webs.ono.com/uucp/inkscape/bug.svg

2 - You see a lock, and two papers. Remove some paper
shape, i.e: the
blue one on top, below the lock. Then you should see a
sape in the lock
filled with noise. something like this:
http://webs.ono.com/uucp/inkscape/shot.png

3 - Select the affected shape and move it... bye.

You can get a gdb backtrace from:
http://webs.ono.com/uucp/inkscape/gdb-bt.txt

BTW the lock should look full yellow.

Thanks.

[Wolfiq (wolfiq)]

Other attachments

[Wolfiq (wolfiq)]

Other attachments

[Wolfram Quester (wolfi)]

# Automatically generated email from bts, devscripts version 2.8.10
forwarded 292676 https://sourceforge.net/tracker/index.php?func=detail&aid=1112537&group_id=93438&atid=604306

[Buliabyak-users (buliabyak-users)]

The reason for this is the stupid structure of the SVG file
(thanks Adobe): "the blue one on top" is a group which
contains a gradient which is referenced by another object
outside the group. If you delete the group, you delete the
gradient with it, and that outside object now refers to a
nonexistent gradient and crashes.

Mental, I'm assigning this to you because I need your advice
on how to handle this:

- refuse to delete object if one of its children is
referenced from outside?

- move any defs from deleted groups to global defs?

- add pervasive sanity checks to gradient/pattern/marker
code to make sure their servers are not deleted from under
them? (this is the biggest hassle)

[Buliabyak-users (buliabyak-users)]

Anyway, this does not block the release because this will
never happen with our own Inkscape SVG files, so I'm
lowering priority.

[Wolfiq (wolfiq)]

After I read your comments I've come to think that this bug
might be the same as the one I got for the debian package at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291751
Could you please have a look at ths and tell me if the bug
reported there is the same this one here?

Thanks,

Wolfi

[Mental-users (mental-users)]

If a gradient (or any other such object) we're referencing
is deleted, directly or indirectly, any URIReference objects
should pick that up and notify their owners that the current
referenced object is NULL. And then we should just render
that the same way we would if the referenced object had not
existed in the first place.

I don't yet understand why that isn't happening...

As far as the appropriate thing to do in terms of fixing up
such nested situations, probably the best thing is to move
or copy the gradient into defs.

I would be suspicious of sprinkling sanity checks
everywhere; that is likely a sign that we are not solving
the problem in the right place. The "right place" almost
always happens to be one or two places, not hundreds.

[Bryce Harrington (bryce)]

Originator: NO

This looks like a pretty old bug - could someone check and verify if it
still occurs? If it does still crashed, please up the priority of it.

[Buliabyak-users (buliabyak-users)]

Originator: NO

fixed in svn

[Bts-link-upstream (bts-link-upstream)]

#
# bts-link upstream status pull for source package inkscape
# see http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html
#

user <email address hidden>

# remote status report for #292676
# * http://sourceforge.net/tracker/?func=detail&atid=604306&aid=1112537&group_id=93438
# * remote status changed: Open -> Closed
# * remote resolution changed: (?) -> Fixed
# * closed upstream
tags 292676 + fixed-upstream
usertags 292676 - status-Open
usertags 292676 + status-Closed resolution-Fixed

thanks

[Alex Valavanis (valavanisalex)]

forwarded 292676 https://bugs.launchpad.net/debian/+source/inkscape/+bug/166254
tags 292676 + moreinfo
thanks

I've fixed the upstream link for this. It's marked as being fixed
upstream. Can someone confirm that this is fixed in the latest (0.47)
Debian Inkscape package?

[Alex Valavanis (valavanisalex)]

Version: 0.46-1

See comments at https://bugs.launchpad.net/debian/+source/inkscape/+bug/166254