Hello, I am almost certain to have found a bug in valgrind. The false positive error appears only when compiled with tcc compiler. The platform is x86_64 linux, musl.
I can reproduce it in my regex engine and I have created the following branch for you to check it out: https://github.com/kyx0r/pikevm/tree/valgrind_bug Diff last commit on that branch, the valgrind_bug.sh runs compiles pike.c with tcc and runs it to show the false report. I have added a comment where the so called "uninitialized value" comes from. I am using the latest git commit of tcc and valgrind. This error does not happen on any other compiler, any optimization level. Code generated by tcc does not seem to produce any erroneous results. Not a single defect, segfault or anything has ever been found. I am also confident that code like this is permitted by the C standard as its simple pointer arithmetic. *(p - 1) The test cases in tesh.sh, specifically those around cases 130-150 certainly will fail if there actually is an uninitialized variable. If somehow the result of this branch: if (*nlist[nlistidx-1].pc == MATCH) break; gets tampered with the test case fails %100. What i've done to test, I have put the test suite into an infinite loop and it keeps running without ever failing, so that means there is never uninitialized variable there, and it's also obvious if you read the code, why it will never be that. It has been running for a few hours now. Usually chances of seeing the effects take a few runs, here is not the case. I know this is not the dev mailing list, please forward it to them. This is a very interesting case to investigate, as this questions the broader validity of valgrind's uninitialized value tracking. _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
