kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

Am Mo., 6. Aug. 2018 um 14:18 Uhr schrieb Tomasz Wlostowski <
tomasz.wlostowski@xxxxxxx>:

> On 06/08/18 18:35, Seth Hillbrand wrote:
> >
> > There's another 32-bit RTree issue that is showing its face
> > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905221).  The last
> > one (https://bugs.launchpad.net/kicad/+bug/1774316), we hacked around
> > for v5 but as this seems to be a recurring theme, I'd like to address it
> > with some finality.
> >
> > We could maintain the RTree implementation ourselves with updates to
> > correct these errors.
> > Or, we could use the Boost-based implementation
> > (
> https://www.boost.org/doc/libs/1_67_0/libs/geometry/doc/html/geometry/reference/spatial_indexes/boost__geometry__index__rtree.html
> ).
> >
> > I have a basic framework for shifting to the Boost-based
> > implementation.  In tests, I don't see a speed difference in running.
> > Compiling might be modestly slower.
>
> Hi Seth,
>
> I would be careful with anything related to geometry in Boost. Good
> things from Boost sooner or later end up in the standard C++ library
> (e.g. unordered). We had a lot of trouble in the past with crashes in
> boost::polygon that nobody could debug or even understand because of the
> vast complexity of Boost code. We struggled for few months to replace it
> with Clipper, since then, we've seen no crashes in polygon boolean ops.
>
> If the solution to fix the current R-tree to work on 32-bit platforms is
> to use doubles instead of floats, why not try it out? By changing to
> boost::geometry, we'll likely have to report bugs there. I'm also quite
> surprised this bug surfaced on one particular OS (Debian) 5 years after
> this R-tree implementation had been introduced to pcbnew. Does anyone
> here know why it crashes on Debian and not on other 32-bit systems?
>
> Tom
>

Hi Tom-

You make good points here.  I'm happy to wait on the boost:geometry
revision until we see if the double-fix addresses the issue.  I can't
recreate the currently reported issue, so I'm not certain whether the
double-fix addresses it as well as the original bug but it definitely makes
sense to try it out.

There may or may not have been a second report of this bug under Fedora
(see comment 19 and below at https://bugs.launchpad.net/kicad/+bug/1774316)
that may or may not have been 32-bit.  I'm vague on the details as the
original reporter did not follow up.

In the meantime, I'll push the double-fix to 5.0.1 and 5.1.

-Seth