Crash internal error while resizing when snapping enabled

Is this still reproducible when using one of the nightly development builds? Lots of improvements have been made to the snapping mechanism, but if this bug is still there then it should be fixed before the upcoming v0.47 release!

You can download these development versions here:

http://inkscape.modevia.com/win32/?M=D

Thanks for the report!

I think I have been able to reproduce this bug with SVN of Today on Fedora 11.

Steps to reproduce:
1. Open new document
2. Create Grid
3. Make sure "snap nodes and handles" and "snap to grids" is enabled
4. create a Bezier Curve between two horizontal (!!!) grid points.
5. create a clone of the line
6. use the "select and transform"-tool
7. drag the right stretch handle of the clone to the next grid point
8. BOOOMMM!!!!

Terminal output is
ERROR:sp-item-transform.cpp:166:Geom::Rect get_visual_bbox(const Geom::OptRect&, const Geom::Matrix&, gdouble, bool): assertion failed: (initial_geom_bbox)
Backtrace is attached

I have tried to revert to svn from 2009-05-15, the bug is already existant there. earlier versions do not compile properly. I reverted src/sp-item-transform.{cpp,h} to revision {"2009-01-01 00:00"} and I also see the crash there. Earlier revisions have incompatible changes in sp-item-transform.h and do not compile with just reverting the two files.

Another case of a bounding box with one dimension being zero, making Inkscape go bezerk

I'm not sure if I can really fix this quickly, this short before our upcomming release. But the least we should do is to let Inkscape fail silenty with maybe just a warning instead of crashing. If I remove the g_assert though then it will crash in a different place downstream.

Just a small reminder for myself:

1) _geometric_bbox = selection->bounds(SPItem::GEOMETRIC_BBOX), in seltrans.cpp calls

2) Geom::OptRect Selection::bounds(SPItem::BBoxType type) const, in selection.cpp, which in turn calls

3) unify() in src/2geom/rect.h, which sees to empty bounding boxes.

It all boils down to sp_use_bbox calling the deprecated version of sp_item_invoke_bbox_full, which is still using NRRects and which is known to have difficulties with bounding boxes having a zero dimension. The bigger picture IMHO is that we still need to replace all occurrences of NRRect by Geom::Rect, in each SPItemClass.

For the time being I've prepared a patch which prevents Inkscape from crashing. This patch will introduce inaccuracies though when transforming, but that's obviously better than crashing.

"Ugly hack to _mitigate_ bug 318726" should have been more appropriate....

Thanks Diederik, patch committed in r22413. I will close this report, but please keep track of it so you can do a proper fix post-0.47.

@Diederik - fix confirmed with r22413 on osx, but I noticed something else while testing:

1) use the geometric bounding box option for the select tool
2) following above steps to reproduce:
   - create horizontal line snapped to grid
   - clone it
   - try to re-size the clone
3) no bounding box handles of the clone visible, it is un-selectable and un-movable using the mouse,
    menu commands, keyboard shortcuts and cursor keys still allow selection, transforms etc.
4) rotating it using the 'Transform…' dialog makes all handles re-appear.

reproduced with 0.47pre3 and r22413. Known issue (could not find a bug #)?
only reproduced with _clones_ of paths with H=0 or W=0, not with groups or the paths themselves

Hi ~suv, this definitely looks related. We've had similar bugs before indeed, but this still needs a proper fix. The main reason this hasn't received much attention so far is the amount of work this requires (replacing NRRect by Boost::Opt(Geom::Rect)), and the new bugs this might cause or reveal.

> looks related
Should I file it as separate bug or will it be included in the 'proper' fix (as side-effect ;-) anyway?

> (replacing NRRect by Boost::Opt(Geom::Rect))
If this is the reason behind other 'geometric bbox' bugs as well - no hope for easy fixes to issues like bug #212768 then?

No need to file a separate bug.

> If this is the reason behind other 'geometric bbox' bugs as well - no hope for easy fixes to issues like bug #212768 then?

That bug requires a different fix as far as I can tell. I know, it's an annoying one :-(

SCNR to ask ;-)
Thank you for the many recent enhancements and bug fixes - snapping and guides especially!

Thanks. But don't forget that your commitment to bug report triaging is equally much appreciated!