Powerstroke LPE hangs

[Parcly Taxel]

(Trisquel 7.0, Inkscape r14313) The attached file causes Inkscape to freeze (become unresponsive) upon opening. Note that the second control point (10,4) lies at the very end of the single path.

Backtrace:
#0 _int_free (av=0x7ffff0406760 <main_arena>, p=0x808de70, have_lock=0) at malloc.c:3897
#1 0x0000000000c6fa1a in deallocate (this=<optimised out>, __p=<optimised out>) at /usr/include/c++/4.8/ext/new_allocator.h:110
#2 _M_deallocate (this=<optimised out>, __n=<optimised out>, __p=<optimised out>) at /usr/include/c++/4.8/bits/stl_vector.h:174
#3 ~_Vector_base (this=0x7fffffffa130, __in_chrg=<optimised out>) at /usr/include/c++/4.8/bits/stl_vector.h:160
#4 ~vector (this=0x7fffffffa130, __in_chrg=<optimised out>) at /usr/include/c++/4.8/bits/stl_vector.h:416
#5 ~SBasis (this=0x7fffffffa130, __in_chrg=<optimised out>) at ./2geom/sbasis.h:69
#6 RescaleForNonVanishingEnds (MM=..., ZERO=0.0001) at 2geom/sbasis-geometric.cpp:110
#7 0x0000000000c71018 in Geom::unitVector (V_in=..., tol=tol@entry=0.01, order=order@entry=3) at 2geom/sbasis-geometric.cpp:229
#8 0x00000000007a959d in Geom::touching_circle (curve=..., tol=0.01, t=0) at live_effects/lpe-powerstroke.cpp:111
#9 0x00000000007a9d7e in Inkscape::LivePathEffect::path_from_piecewise_fix_cusps (B=..., y=...,
    jointype=jointype@entry=Inkscape::LivePathEffect::LINEJOIN_EXTRP_MITER_ARC, miter_limit=4, tol=0.01) at live_effects/lpe-powerstroke.cpp:421
#10 0x00000000007ac5ef in Inkscape::LivePathEffect::LPEPowerStroke::doEffect_path (this=0x80f1990, path_in=...) at live_effects/lpe-powerstroke.cpp:637
#11 0x000000000073af8b in Inkscape::LivePathEffect::Effect::doEffect (this=0x80f1990, curve=0x80c2320) at live_effects/effect.cpp:519
#12 0x000000000058161a in SPLPEItem::performPathEffect (this=this@entry=0x80bf910, curve=curve@entry=0x80c2320) at sp-lpe-item.cpp:254
#13 0x000000000059fe70 in SPPath::update_patheffect (this=0x80bf910, write=<optimised out>) at sp-path.cpp:339
#14 0x00000000005a06db in SPPath::build (this=0x80bf910, document=<optimised out>, repr=<optimised out>) at sp-path.cpp:173
#15 0x000000000059939b in SPObject::invoke_build (this=0x80bf910, document=0x1e48680, repr=0x3e712b0, cloned=<optimised out>) at sp-object.cpp:725
#16 0x000000000059b3c0 in SPObject::build (this=this@entry=0x8108b40, document=document@entry=0x1e48680, repr=repr@entry=0x3e71580) at sp-object.cpp:698
#17 0x0000000000571b7b in SPItem::build (this=this@entry=0x8108b40, document=document@entry=0x1e48680, repr=repr@entry=0x3e71580) at sp-item.cpp:409

The problematic file is extracted from my MLPFIM comic Cherry's Birthday, with which I have tested my SVG optimisation script Rarify. Note that when opening from the file explorer Nautilus, the process does not terminate.

[su_v (suv-lp)]

Reproduced with Inkscape 0.91+devel r14313 on OS X 10.7.5

Based on tests with archived builds:
- not reproduced with rev <= 14293,
- reproduced with rev >= 14299:
the hang on load seems to be a regression introduced with the latest (smaller) 2geom update:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/14299

Revision 14299: 2Geom: update to r2422. (Fixes LP #1482806)
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14299

[Felipe "Juca" Sanches (felipe-sanches)]

Actually Inkscape seem to be always hanging when a user applies a PowerStroke effect to a new path. It does not seem to require that it be an effect "with control points at path ends". So this bug title seems a bit misleading.

Other LPEs apply nicely.

[Felipe "Juca" Sanches (felipe-sanches)]

Reverting the single change made in src/2geom/sbasis-geometric.cpp on https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14299, Inkscape does not hang anymore. We need to understand the rationale behind this line of code. Maybe git-blaming the corresponding commit in 2geom may provide some insight.

[Parcly Taxel (parclytaxel-deactivatedaccount)]

And then I realised something. Look at the problematic code:

if (V[0].isZero(0) && V[1].isZero(0))
        return Piecewise<D2<SBasis> >(D2<SBasis>(Linear(1),SBasis()));

Suppose V is a zero D2<SBasis> object of order greater than one. Since isZero() does not check whether an SBasis is of order one – whereas empty() of the old code does – the program will return an SBasis object of order one. Therefore the order of the SBasis may be changed here, which goes against the intent of the unitVector() function this code resides in (to return a D2<SBasis> of the same order). Ha!

[Alvin Penner (apenner)]

attached is a proposed fix for this bug.

The origin of the problem seems to be the multiple derivatives that are, sometimes, being taken in the routine 'touching_circle' in the file lpe-powerstroke.cpp, in the case where the incoming derivative is very small. The multiple derivatives are presumably being taken in order to expose higher-order non-trivial behavior. There are cases where this may be productive, for example if 't' has been arbitrarily replaced by t-squared so that the first derivative is trivial but the second derivative is not. However, if the underlying curve is already linear then there is no purpose served by taking multiple derivatives, so the new code avoids this case.

[Felipe "Juca" Sanches (felipe-sanches)]

ok, it sounds reasonable, but how does that result in Inkscape hanging ?

[Parcly Taxel (parclytaxel-deactivatedaccount)]

I have tested Penner's patch on r14298 (again, on Trisquel 7.0). While the program doesn't hang now on load, I must note a serious instability: if I move the knot too fast the program hangs again – and I can't get a backtrace because the entire GNOME desktop is affected by this new hang.

Kosiński has, once again, rocked the boat too much and threw some passengers overboard; instead of making the smallest fixing change he has looked too far, thereby introducing the regression here. r14298 with Penner's fix for the Pattern Along Path LPE in bug #1482806 correctly loads both Pattern Along Path LPEs and powerstroke LPEs, without the previously described hanging when the latter LPE's control points are dragged too fast. I suggest that the most recent 2geom update be reverted and the Pennerian PAP fix be applied after that.

[Alvin Penner (apenner)]

attached is an improved patch for this bug. It incorporates the changes proposed in comment 6, and it includes a new check on the validity of the data, in order to deal with the crash observed in comment 8.

[Parcly Taxel (parclytaxel-deactivatedaccount)]

I've tested the new patch on r14332 and it's successful with flying colours – indeed powerstrokes respond faster to editing and other interactions now. I would definitely recommend that it be incorporated into the trunk as soon as possible!

[Alvin Penner (apenner)]

good to hear, fix committed to rev 14333