Critical warnings with symbols and clones

Bug #1653184 reported by su_v on 2016-12-30
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Low
Mc
0.92.x
Low
Mc

Bug Description

In lp:inkscape (trunk) and lp:inkscape/0.92.x, interacting with symbols and clones may trigger console messages like these:

** (inkscape:45273): CRITICAL **: SPObject *SPDocument::getObjectById(const gchar *) const: assertion 'id != NULL' failed

Just opening the Symbols dialog in a new drawing in a new document window produces 324 such warnings, and every time a different symbol set is selected, or a symbol is instantiated on the canvas a new warning is generated.

Other circumstances:
- load a file which has instances of <symbol> elements (see attached)
- create a text object and clone it
- group/ungroup, duplicate or copy&paste a clone of a text object or a clone referencing a symbol
- ... probably more.

Based on tests with archived builds (on OS X 10.7.5):
- not reproduced with Inkscape 0.91 r13725
- not reproduced with lp:inkscape/0.92.x <= 15133,
- reproduced with lp:inkscape/0.92.x >= 15138,
- reproduced with Inkscape 0.92pre5 r15287;
these warnings seem to have been exposed in lp:inkscape/0.92.x with the changes in r15138, which is a backport of lp:inkscape r15193:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/changes/15138
https://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15138

Revision 15193: Fix regression in loop prevention (bug #1636533)
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15193

Reproduced with Inkscape 0.92+devel r15371 on Ubuntu 14.04 and Inkscape 0.92pre5 r15288 on OS X 10.7.5.

=====
Comments from Mc on irc (#inkscape-devel):
Mc : I see how it's linked to this rev
Mc : but I don't know how to fix it simply
Mc : I would need a 3m x 5m whiteboard and a full week to figure out in which order inkscape builds elements to do it properly :/
Mc : (except if I just replace "if(object->cloned)" with "if(object->cloned && repr->attribute("id"))")
...
Mc : I think it's when clones are created before their base objects
Mc : (ie it creates an "unlinked" clone poitning to a not-yet-existant object)
Mc : there also may be several sources of these warnings
Mc : (they'll appear as soon as someone in the code tries to get an object with its id without ensuring an object with this id already exists)

su_v (suv-lp) wrote :
jazzynico (jazzynico) wrote :

Reproduced on Windows XP (32-bit) with lp:inkscape/0.92.x rev. 15302.

Changed in inkscape:
importance: Undecided → Low
status: New → Triaged
su_v (suv-lp) wrote :

@JazzyNico - any chance you could milestone to 0.92 (or 0.92.1 once that milestone is available)? I really would appreciate if the warnings could be addressed (or silenced) for this LTS release if possible/feasible:

Working with certain files [1] or with Inkscape symbols (dialog) floods the console with tons of messages, which can make it very cumbersome to detect new or relevant warnings among the many "known" ones.

[1] This is the file which ultimately triggered me to file a report (10499 (!) warnings every time the document is opened in Inkscape):
https://gitlab.com/su-v/inx-drawtext/blob/master/src/drawtextdata/Lettering_ISO_3098-01.svg

jazzynico (jazzynico) wrote :

Just created the 0.92.1, but let's milestone it to 0.92 for now.

<off-topic>
I'm wondering how we should manage our old reports milestoned 0.91.1. Most (if not all) of them are backports from the current 0.92.x branch, and I'd tend to change everything to 0.92 so that they show as fixed in a released version. Do you have an opinion on it?
</off-topic>

Changed in inkscape:
milestone: none → 0.92

On 2017-01-03 15:46 (+0100), jazzynico wrote:
> <off-topic>
> I'm wondering how we should manage our old reports milestoned
> 0.91.1. Most (if not all) of them are backports from the current
> 0.92.x branch, and I'd tend to change everything to 0.92 so that they
> show as fixed in a released version. Do you have an opinion on it?
> </off-topic>

From my point of view, the reports targeted for milestone 0.91.1 with
bug status 'Fix Committed' should be "mass-changed" to milestone 0.92
once the new release has been officially announced (or maybe even before
the announcement).

I would assume that this could be done with a modified version of the
script bryce used (and likely will use for 0.92, too) to change the bug
status for the reports of the latest milestone (from 'Fix Committed' to
'Fix Released'):

https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/packaging/scripts/

The script requires a platform/distro which provides the necessary
python modules to access launchpad via scripts, and someone to run it
who has any required priviledges on launchpad (probably any member of
the admin group of the 'Inkscape' project).

Probably best coordinated with Bryce (mailing list, or irc)?

su_v (suv-lp) wrote :

<off-topic mode="jftr">
irclog #inkscape-devel 2017-01-03 (CET):
23:27 su_v : bryce: <...> do you think you could help the bug team with this one (related to release milestones)? https://bugs.launchpad.net/inkscape/+bug/1653184/comments/5
23:29 bryce : su_v, um possibly; I'll put it on my todo list for post-release work
23:29 su_v : thx
23:29 bryce : su_v, I know we also have to do the script to close the Fix Committed bugs, and make a 0.92.1 milestone, and so on, so probably fits with that work
23:30 su_v : the comment refers and links to that script
23:30 bryce : heh, I always forget just how many tasks there are in putting out a release
23:31 bryce : su_v, yeah the change in the comment shouldn't be hard to do. The main trouble is usually dealing with whatever's changed in Launchpad since the last time the script was run. ;-)
</off-topic>

jazzynico (jazzynico) wrote :

Thanks, su_v! I'm going to let Bryce handle that with the script.

Changed in inkscape:
milestone: 0.92 → 0.92.1
jazzynico (jazzynico) wrote :

A bit more critical for the inkscape-docs project because the bug prevents the calligraphy tutorial from being generated (see Bug #1651815, comment #8 to #16).

Some local testings seem to show that the warning are caused by text content in the linked object. In the calligraphy tutorial, the object is a text element. In the symbols, we have a title element. Manually removing its content (the "Coat Check" text in the attached file) also removes the warnings (even if the element itself is kept).

Mc (mc...) wrote :

Warnings fixed in trunk r15398 and .92.x r15309, I hope. I have no idea how this could have had an incidence on calligraphy tutorials; how do you generate them ?

Changed in inkscape:
assignee: nobody → Mc (mc...)
status: Triaged → Fix Committed
jazzynico (jazzynico) wrote :

Thanks for the fix!

A tutorial source is composed of an XML file for the text and structure, and some SVG files for the images. The final file is generated with some Java code that convert a source XML file to SVG and merge it with the images. Somewhere in the process it needs to calculate the size of the images, and something related to the warnings broke that part for one image file ('y' attribute set to 'NaN' or 'OINVALID' for some elements).

jazzynico (jazzynico) on 2017-01-18
Changed in inkscape:
milestone: 0.92.1 → 0.93
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers