Uninitialized bytes in Clang?

[zimmski]

I am trying to get the -msan flag working by eliminating all found problems but I think this is a hopeless case because I do not think that it is our fault now. Even if I get everything working as I want it to be (e.g. line numbers are still missing) the problem looks like it is coming from LLVM/Clang itself? Am I wrong?

The following example (it dos not even touch any go-clang code)

func OK() {
    idx := C.clang_createIndex(0, 1)

    c_sourceFilename := C.CString("../testdata/basicparsing.c")
    defer C.free(unsafe.Pointer(c_sourceFilename))

    tu := C.clang_parseTranslationUnit(idx, c_sourceFilename, nil, 0, nil, 0, 0)

    C.clang_disposeTranslationUnit(tu)
    C.clang_disposeIndex(idx)
}

Produces the following problem

Uninitialized bytes in __interceptor_memchr at offset 6 inside [0x70800000bf58, 7)
==24394==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f3d25c68c85  (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x653c85)
    #1 0x7f3d25c790a7  (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x6640a7)
    #2 0x7f3d29ba8bbe  (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0xc05bbe)
    #3 0x7f3d29bb84ca  (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0xc154ca)
    #4 0x7f3d29433f39  (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0x490f39)
    #5 0x7f3d29411504  (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0x46e504)
    #6 0x7f3d2920678e  (/usr/lib/x86_64-linux-gnu/libclang-3.9.so.1+0x26378e)
    #7 0x7f3d25c43314  (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x62e314)
    #8 0x7f3d25c43393  (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x62e393)
    #9 0x7f3d25ca64bc  (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x6914bc)
    #10 0x7f3d28d8d183  (/lib/x86_64-linux-gnu/libpthread.so.0+0x8183)
    #11 0x7f3d2819237c  (/lib/x86_64-linux-gnu/libc.so.6+0xfa37c)

  Uninitialized value was stored to memory at
    #0 0x42d0d5  (/tmp/go-build242820838/github.com/go-clang/bootstrap/clang/_test/clang.test+0x42d0d5)
    #1 0x7f3d253cc9bd  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xbb9bd)

  Uninitialized value was stored to memory at
    #0 0x42d0d5  (/tmp/go-build242820838/github.com/go-clang/bootstrap/clang/_test/clang.test+0x42d0d5)
    #1 0x7f3d253cbe2f  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xbae2f)

  Uninitialized value was created by a heap allocation
    #0 0x42b6d9  (/tmp/go-build242820838/github.com/go-clang/bootstrap/clang/_test/clang.test+0x42b6d9)
    #1 0x7f3d2536fdac  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x5edac)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1+0x653c85)

[zchee]

@zimmski Sorry, not related, but I was just curious (from before).

go-clang auto-building scripts seem to already installed the clang-$LLVM_VERSION from the apt-get, but why use the gcc rather than clang for $CC in the https://github.com/go-clang/gen/blob/0a3be65df975b34cee486c733a387ab691966967/.travis.yml#L31?

The Makefile has CC := clang, but it seems to use the gcc at install the go-clang-gen.(travis's go env $CC is gcc) Is there any reason? (there is no difference to build the go-clang-gen binary?)

If I said something strange, please ignore it. (also, sorry for bad English)

[zimmski]

@zchee You are right, I opened https://github.com/go-clang/gen/issues/124 I think I should address this in the "Upgrade to Go 1.7" PRs. Would you mind adding your ideas to the #124 issue?

[zchee]

@zimmski np! very thanks :)

I don't know go's build architecture, but go-clang-gen uses cgo, so it might be different a little(I think)

[marxriedl]

Just to double check: https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo

at one point they mention

If you want MemorySanitizer to work properly and not produce any false positives, you must ensure that all the code in your program and in libraries it uses is instrumented (i.e. built with -fsanitize=memory).

Did you do that?

[zimmski]

Definitely not for the LLVM/Clang libraries. I think I will try this using pure C and then post it on the LLVM/Clang tracker/ML.

[zimmski]

I opened an issue in the LLVM tracker https://llvm.org/bugs/show_bug.cgi?id=30410

The gist: @marxriedl mentioned quote says it all. The TravisCI/Debian version of Clang/LLVM was not compiled with the memory sanitizer. The problem is that we would need to compile libc++ and Clang and all other libraries that we use ourselves, see [https://github.com/google/sanitizers/wiki/MemorySanitizerBootstrappingClang]. I did a quick search and could not find any packages that we could use in TravisCI, and I am not sure that we want to exploit our free CI service that much.