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[]).
-mental