[cfe-users] scan-build: False positive "Assigned value is garbage or undefined" warning on open() result
Hello all, CMake upstream here. After upgrading to clang 6 scan-build, we're seeing a rather odd warning in our in-source libuv build. It's complaining about "Assigned value is garbage or undefined" after calling open() and comparing it to "== -1" rather than "< 0", but only in this one particular call. You can see the warning at https://open.cdash.org/viewBuildError.php?ty pe=1&buildid=5707465 . This warning also appears when building libuv on its own. I've opened a PR on libuv upstream ( https://github.com/libuv/libuv/pul l/2140 ) which fixes the warning, but what I don't understand is why this is the only place where this appears - there are lots of other places where open() is called and compared against -1, but they don't trigger the warning. I also have not been able to come up with a minimal reproducible example. Anyone have any insight as to why this might be happening? (I am not subscribed to this list, so please be sure to CC me in your replies.) Kyle ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Silencing errors in TSAN
Hello all, I am attempting to build OpenMPI with TSAN enabled (to TSAN-itize a project that uses OpenMPI), and am finding that OpenMPI throws lots of errors in TSAN (not surprising.) I am attempting to build OpenMPI with the following blacklist: src:* However, I am still getting errors when I run mpiexec. I've reduced it down to the following minimal example: -- #include #include static int my_pipe[2]; int main() { pipe(my_pipe); std::thread([]() { std::this_thread::sleep_for(std::chrono::seconds(1)); close(my_pipe[1]); }).detach(); write(my_pipe[1], "Hello", 5); std::this_thread::sleep_for(std::chrono::seconds(2)); return 0; } -- Even when I compile this with -fsanitize-blacklist=blacklist.txt, I still get a warning about a race condition. Is there some way I can silence this, preferably without patching OpenMPI? Is this a bug in TSAN? Kyle ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Silencing errors in TSAN
On Wed, 2020-02-05 at 19:30 +0100, JVApen wrote: > Hey Kyle, > > This is a bug in your code, if you have a context switch after the > creation of the thread on an overloaded system, the close of the pipe > can be closed while writing or even before it. > > Timing ain't a good way to synchronize threads. TSan is correct in > flagging this occurrence. JVApen, Thanks for the response. I don't doubt that TSAN is correct. The problem is that this isn't my code. It's from OpenMPI, and fixing OpenMPI is beyond the scope of my work. I am attempting to build OpenMPI with TSAN enabled, so that applications that use it don't get false positives due to libraries built without TSAN, while silencing issues that might be present within OpenMPI itself. In this case, the error is coming from mpiexec, which exists as a completely separate process from my application. So, I am aware that this is probably an error in mpiexec, but would like to silence it anyway, and I can't seem to do that. In other words, this isn't a problem with TSAN yielding a false positive, but yielding an error with no way for me to silence it. Kyle ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users