You're receiving this bug because the package in Summary has produced _FORTIFY_SOURCE related warnings indicating the presence of a sure overflow in a static buffer. Even though this is not always an indication of a security problem it might even be. So please check this out ASAP. By the way, _FORTIFY_SOURCE is disabled when you disable optimisation, so don't try finding out the cause using -O0. Thanks, Your friendly neighborhood tinderboxer
Created attachment 249708 [details] Build log
Contacted author
The warning is In function ‘char* strncpy(char*, const char*, size_t)’, inlined from ‘void ImageWindow::exportLinecut()’ at ImageWindow.C:2053:33: /usr/include/bits/string3.h:123:71: warning: call to char* __builtin___strncpy_chk(char*, const char*, unsigned int, unsigned int) will always overflow destination buffer In function ‘char* strncpy(char*, const char*, size_t)’, inlined from ‘void ImageWindow::exportLinecut()’ at ImageWindow.C:2055:34: /usr/include/bits/string3.h:123:71: warning: call to char* __builtin___strncpy_chk(char*, const char*, unsigned int, unsigned int) will always overflow destination buffer and the corresponding code in ImageWindow.C is 2034 void ImageWindow::exportLinecut() 2035 { 2036 // Ok, this is a real hack, but it's easy... 2037 char tmp[1024]; 2038 char label[1024]; 2039 char fn[1024]; 2040 2041 //sprintf is just so damn more convenient than c++ strings 2042 if (line_cut_type == HORZLINE) 2043 snprintf(label, 1024, "l.%d", line_cut_yp); 2044 else if (line_cut_type == VERTLINE) 2045 snprintf(label, 1024, "c.%d", line_cut_xp); 2046 else 2047 sprintf(label, "other"); 2048 snprintf(fn, 1024, "%s.%s.linecut.dat", output_basename, label); 2049 2050 info("exporting linecut to file %s\n", fn); 2051 2052 strncpy(tmp, xsection_fn, 1024); 2053 strncpy(xsection_fn, fn, 1024); //<<<<<<<<<<<<<<<<< 2054 plotLineCut(); 2055 strncpy(xsection_fn, tmp, 1024); //<<<<<<<<<<<<<<<<< 2056 }
Looking at the source made me suspect this was a false positive already long time ago. And voila, with current stable gcc the error message is gone.
Define "Current stable gcc" because I think it is older than what produced this warning in the first place. And also remember that "false positive" with these warnings is not any better, the code _will_ abort at runtime if it's reported.
(In reply to comment #5) > Define "Current stable gcc" because I think it is older than what produced this > warning in the first place. x86_64-pc-linux-gnu-4.4.5 No reference in your build log which gcc was used, but you are correct, the warnings reappear with 4.5.2. As a sidenote, some of the QA warnings appear only for LANG=C - that should probably be fixed. > And also remember that "false positive" with these warnings is not any better, > the code _will_ abort at runtime if it's reported. Well, where should I go with that then? I tried to contact you on IRC already loooong time ago to get a second opinion... as far as I know the code snippet in comment #3 together with the published definition of strncpy should be sufficient proof for a false positive, and it would be nice for some with more C knowledge to confirm this.
I'm afraid you'd got to debug it by looking at the emitted assembly... http://blog.flameeyes.eu/2010/09/12/some-_fortify_source-far-fetched-warnings-are-funny This is an oldish post of mine that shows how I had to debug a similarly-surreal warning.
Fixed in spyview-20110329-r1 (yes it was a real buffer overflow, me stupid).
