On Tue, 2004-08-10 at 11:23, Bob Jamison wrote:
> I finally got it working on this box. The only difference between
> the boxen where Inkscape was running correctly and this one
> where it was not, is that this one has GCC3.4.1 on it. I built
> Inkscape on this box with GCC3.3 to test, and it worked.
> Maybe there is a quirk with vector indexing & unsigned
> ints on the current g++/stl? I traced my problem to
> line 190 of ShapeSweep.cpp, where an infinite loop was in progress.
> Having found no earthly reason why that happened, I tried
> reducing the amount of indexing in the for() loop.
> Everything works fine now.
> ... Or maybe it is a reentrancy problem? Don't know.
STL vector subscripts are pretty straightforward -- they inline to
simple C-style array subscripts. No reentrancy issues to speak of.
When you "reduced the indexing", did you assign to a signed or unsigned
temporary variable for the intermediate index?
Now that livarot's Shape has been fixed to be relatively valgrind-clean,
I discovered a problem that had been buried in the other spurious
valgrind warnings before:
In places, Shape::dg_arete::st and Shape::dg_arete::en will be -1
(indicating a "null edge"), but this is not currently checked for in all
the places it should be.
[ Fred says that ideally null edges shouldn't have been left behind in
the edge data in the first place, but they are otherwise harmless and
should be ignored. ]
Anyway, it looks like as a result the old code was occasionally
accessing e.g. Shape::pData[-1].
Accessing indices outside the bounds of an array mean undefined
behavior, which as a rule will vary from compiler to compiler.
It apparently previously normally got away with this when the arrays
were allocated with C's malloc/realloc, but now we're using a different
allocator (C++'s new).