Clang test failures starting with Clang 3.4

[ghost]

From the mailing list: https://groups.google.com/forum/#!topic/oce-dev/4YOJk9jWP8U

Apparently Clang 3.4 picks up a lot more undefined behavior than 3.3, and the resulting 'ud2' instructions make several hundred of the OCCT tests fail.

[dbarbier]

Running TCollection_test in gdb gives:

Starting program: /home/barbier/oce/build-clang/test/TCollection_test/TCollection_test  
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
==3068== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f5622e32e47 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1a8e47)
    #1 0x7f5622e3d8a9 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1b38a9)
    #2 0x7f5622e3115b (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1a715b)
    #3 0x7f5622e4ccc5 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1c2cc5)
    #4 0x7f5622de2493 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x158493)
    #5 0x7f5622d54898 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0xca898)
    #6 0x7f5622ea1c4c (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x217c4c)
    #7 0x7f561f785ad4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ad4)
    #8 0x7f5622d559b3 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0xcb9b3)

SUMMARY: MemorySanitizer: use-of-uninitialized-value ??:0 ??

But I do not know what to do next.

[ghost]

Hi Denis. That's troubling, I just read this on the MemorySantizer page:
"Currently, MemorySanitizer does not symbolize its output by default, so
you may need to use a separate script to symbolize the result offline (this
will be fixed in future)." However, I did a Google search and found this:
http://stackoverflow.com/questions/24399485/clang-memory-sanitizer-how-to-make-it-print-source-line-numbers
Looks like you just have to set some environmental variables to point the
sanitizer to a symbolizer.

Out of curiosity, what all steps did you take to get it compiled with the
MemorySanitizer?

On Mon, Oct 27, 2014 at 3:30 PM, Denis Barbier notifications@github.com
wrote:

Running TCollection_test in gdb gives:

Starting program: /home/barbier/oce/build-clang/test/TCollection_test/TCollection_test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
==3068== WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f5622e32e47 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1a8e47)
#1 0x7f5622e3d8a9 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1b38a9)
#2 0x7f5622e3115b (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1a715b)
#3 0x7f5622e4ccc5 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x1c2cc5)
#4 0x7f5622de2493 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x158493)
#5 0x7f5622d54898 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0xca898)
#6 0x7f5622ea1c4c (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0x217c4c)
#7 0x7f561f785ad4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ad4)
#8 0x7f5622d559b3 (/home/barbier/oce/build-clang/test/TCollection_test/TCollection_test+0xcb9b3)

SUMMARY: MemorySanitizer: use-of-uninitialized-value ??:0 ??

But I do not know what to do next.

—
Reply to this email directly or view it on GitHub
#520 (comment).

[ghost]

Okay, I compiled with -fsanitize=memory,undefined, then set MSAN_SYMBOLIZER_PATH to /usr/bin/llvm-symbolizer-3.5 and got this:

root@tester:~/oce-master/build/test/TCollection_test# lldb-3.5 ./TCollection_test
Current executable set to './TCollection_test' (x86_64).
(lldb) run
Process 19713 launching
Process 19713 stopped
* thread #1: tid = 19713, 0x00007f0886db42d0, name = 'TCollection_tes', stop reason = trace
    frame #0: 0x00007f0886db42d0
-> 0x7f0886db42d0:  movq   %rsp, %rdi
   0x7f0886db42d3:  callq  0x7f0886db7a70
   0x7f0886db42d8:  movq   %rax, %r12
   0x7f0886db42db:  movl   0x221b17(%rip), %eax
(lldb) Process 19713 launched: './TCollection_test' (x86_64)
==19713== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f08872cbd2b in testing::internal::FilePath::Normalize() (/root/oce-master/build/test/TCollection_test/TCollection_test+0x2f3d2b)
    #1 0x7f08872f46c1 in testing::internal::FilePath::FilePath(std::string const&) (/root/oce-master/build/test/TCollection_test/TCollection_test+0x31c6c1)
    #2 0x7f08872c4b9a in testing::internal::FilePath::GetCurrentDir() (/root/oce-master/build/test/TCollection_test/TCollection_test+0x2ecb9a)
    #3 0x7f088733486f in testing::internal::UnitTestImpl::AddTestInfo(void (*)(), void (*)(), testing::TestInfo*) (/root/oce-master/build/test/TCollection_test/TCollection_test+0x35c86f)
    #4 0x7f08871ce334 in testing::internal::MakeAndRegisterTestInfo(char const*, char const*, char const*, char const*, void const*, void (*)(), void (*)(), testing::internal::TestFactoryBase*) (/root/oce-master/build/test/TCollection_test/TCollection_test+0x1f6334)
    #5 0x7f08870e0fd0 in __cxx_global_var_init1 (/root/oce-master/build/test/TCollection_test/TCollection_test+0x108fd0)
    #6 0x7f08870e105d in _GLOBAL__I_a (/root/oce-master/build/test/TCollection_test/TCollection_test+0x10905d)
    #7 0x7f08874d767c in __libc_csu_init (/root/oce-master/build/test/TCollection_test/TCollection_test+0x4ff67c)
    #8 0x7f0881a37e54 (/lib/x86_64-linux-gnu/libc.so.6+0x21e54)
    #9 0x7f088712ab1c in _start (/root/oce-master/build/test/TCollection_test/TCollection_test+0x152b1c)

SUMMARY: MemorySanitizer: use-of-uninitialized-value ??:0 testing::internal::FilePath::Normalize()
Exiting
Process 19713 exited with status = 77 (0x0000004d)
(lldb) quit

Note that I used lldb instead of gdb, gdb gave me trouble about compiling with -fPIE

[dbarbier]

Hello, this is indeed much simpler than looking at disassembly code, thanks.
For gdb, see warning message, you can type "set disable-randomization off" to make it work.
I commented Normalize() call, and now MemorySanitizer complains when creating some std::string (still withing gtest), and I cannot see any coding error. So this seems to be unusable, sadly.

[ghost]

Very possible, I think most of the sanitizers are experimental. Any other
ideas about how we can get to the root of why so many more tests are
failing when compiled with Clang?

On Tue, Oct 28, 2014 at 12:30 PM, Denis Barbier notifications@github.com
wrote:

Hello, this is indeed much simpler than looking at disassembly code,
thanks.
For gdb, see warning message, you can type "set disable-randomization off"
to make it work.
I commented Normalize() call, and now MemorySanitizer complains when
creating some std::string (still withing gtest), and I cannot see any
coding error. So this seems to be unusable, sadly.

—
Reply to this email directly or view it on GitHub
#520 (comment).

[dbarbier]

Many failing tests are about boolean operations. I picked a single one, and it segfaulted because of null references. See src/BSplCLib/BSplCLib_CurveComputation.gxx line 225:

  Standard_Boolean rational = &Weights  != NULL;

It is assumed that Weights is NULL when NoWeights had been passed as an argument, but references cannot be null. I guess that we should either replace reference by a pointer, or use a specific instance for NoWeights.

[ghost]

I'd prefer to report this on the OCCT bugtracker and let them sort it out.
Seems like quite a bit of code is affected and it'd cause trouble in the
future if we were to fix it one way and for them to fix it another way,
IMO.

On Tue, Oct 28, 2014 at 4:46 PM, Denis Barbier notifications@github.com
wrote:

Many failing tests are about boolean operations. I picked a single one,
and it segfaulted because of null references. See
src/BSplCLib/BSplCLib_CurveComputation.gxx line 225:

Standard_Boolean rational = &Weights != NULL;

It is assumed that Weights is NULL when NoWeights had been passed as an
argument, but references cannot be null. I guess that we should either
replace reference by a pointer, or use a specific instance for NoWeights.

—
Reply to this email directly or view it on GitHub
#520 (comment).

[ghost]

http://tracker.dev.opencascade.org/view.php?id=25429

[ghost]

Putting this issue as a whole over to OCCT: http://tracker.dev.opencascade.org/view.php?id=25454