Markus Engel tells me that all of the clang compiler warnings are now gone. That is good news.

There was one clang warning about style.cpp in the list, and I was hoping that the clang fix would resolve an annoying valgrind issue with that file. Sadly, retested with all of these new patches in place and it is still there. When this test is run:

valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15 --show-reachable=yes --suppressions=./wcslen_sse2.supp --track-origins=yes src/inkscape --file /tmp/small.emf >/tmp/vgJ.log 2>&1

(The input file doesn't matter, I just use that one because it has some text, in fact, if memory serves, the first such error appears even if no input file is used. Each test takes about 5 minutes to get to the point where the window can be closed.)

there are problems like this (sorry about the wrap):

==14247== Conditional jump or move depends on uninitialised value(s) ==14247== at 0x836DFC3: Inkscape::Text::Layout::Calculator::_computeFontLineHeight(font_instance*, double, SPStyle const*, Inkscape::Text::Layout::LineHeight*, double*) (Layout-TNG-Compute.cpp:1054) ==14247== by 0x8370F36: Inkscape::Text::Layout::Calculator::_buildSpansForPara(Inkscape::Text::Layout::Calculator::ParagraphInfo*) const (Layout-TNG-Compute.cpp:1268) ==14247== by 0x837146A: Inkscape::Text::Layout::Calculator::calculate() (Layout-TNG-Compute.cpp:1584) ==14247== by 0xA24A387: ??? ==14247== Uninitialised value was created by a stack allocation ==14247== at 0x821BA60: sp_style_read_ilengthornormal(SPILengthOrNormal*, char const*) (style.cpp:3576)

This is line 1054 in Layout-TNG-Compute.cpp

switch (style->line_height.unit) {

and for some reason valgrind thinks the ".unit" part is either itself uninitialized or the result of something else being uninitialized. Try to print that value immediately before that line and valgrind warns on the output statement.

Now here is where it gets weird. sp_style_read_ilengthornormal() is not a complicated function, and when debug print statements are placed in it that print that value valgrind does not complain about accessing that memory location. If memset is used to clear every bit in "val" in that function at the top it does not fix the problem. Running Inkscape in gdb and catching the first place where it goes wrong (from the valgrind output and the print statements, used to show the function parameters and the memory locations) and then setting a watch on that memory location (unit is a bit range, so the whole byte must be watched) shows that _nothing_ touched it before it got to the place where valgrind shows an error. So in location A in the program memory location "M" is initialized, and some time later in location B in the program memory location "M" is no longer initialized as far as valgrind is concerned. (The values stored there are the same in both locations in the program.)

For the piece de resistance, if there are a bunch of print statements in sp_style_read_ilengthornormal(), and this

std::cout << "DEBUG ssri final unit " << val->unit << " val " << val << std::endl;

is placed just above the closing bracket, and valgrind run again, the problem goes away. But that output line _alone_ is not sufficient to clear up the problem, there have to be a bunch of other output lines present.

Even though valgrind warns the values all seem to be good. But valgrind is already packed to the gills with warnings and the last thing it needs is many more.

I have seen issues like this before, although usually in C, and they usually turned out to be erroneous memory accesses that by chance landed on valid memory.

Anyway, I'm glad the scanner is coming up clean, but there is still something wrong with style.cpp. Or at least valgrind thinks so.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech