This morning (Monday) I have been having trouble running CVS inkscape. Even after doing clean checkout/builds, the resulting inkscape does not show a GUI, even after 5 mins. Has someone modified the startup?
Bob
On Mon, 9 Aug 2004, Bob Jamison wrote:
This morning (Monday) I have been having trouble running CVS inkscape. Even after doing clean checkout/builds, the resulting inkscape does not show a GUI, even after 5 mins. Has someone modified the startup?
Last night I comitted some cleanup to livarot's Shape class (std::vector to replace ad-hoc reallocs), as well as some related signed/unsigned changes.
I should have held off on comitting the latter bit; I made a few variables unsigned which ought not to have been, and created some infinite loops in the process.
I cleaned up what I could last night; peter is working on the rest. Not that many files were actually affected and it was during a quiet period; if you do a CVS diff between noon yesterday and last night's commit, the int->unsigned changes should stand out.
The ones being used for loop iterators are OK (although they then require more signedness casts downstream); most of the rest should not have been touched at all. Like most of my large-scale changes it was automated; my normal regexp testing procedures seem to have failed me this time.
I did build and test it into normal startup, but since I'd been testing in valgrind all night and it was an unoptimized build I killed it before the GUI should have come up (I'd been used to waiting minutes).
What would have caught this earlier is if I'd captured the build stderr to a log and reviewed it before comitting -- in general I would have noticed that I'd created more warnings than I'd fixed, too.
I will do that in the future; sorry for the inconvenience.
-mental
MenTaLguY wrote:
Last night I comitted some cleanup to livarot's Shape class (std::vector to replace ad-hoc reallocs), as well as some related signed/unsigned changes.
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.
Bob
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
MenTaLguY wrote:
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?
No. What I did, was get the ref to the indexed structure, and used that afterward. So for each of the structures involved, there is a single someStruct * = &(a->someVector[i]); then for the rest of the loop it is merely someStruct->field;
Probably lightens up on the cpu a bit, too.
Bob
participants (3)
-
Bob Jamison -
MenTaLguY -
Peter Moulder