[cfe-users] scan-build: False positive "Assigned value is garbage or undefined" warning on open() result

2019-01-15 Thread Kyle Edwards via cfe-users
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

2020-01-29 Thread Kyle Edwards via cfe-users
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

2020-02-05 Thread Kyle Edwards via cfe-users
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