On Fri, Aug 1, 2014 at 8:46 AM, Kostya Serebryany <[email protected]> wrote: > > > > On Fri, Aug 1, 2014 at 4:42 PM, Aaron Ballman <[email protected]> > wrote: >> >> On Fri, Aug 1, 2014 at 8:38 AM, Kostya Serebryany <[email protected]> wrote: >> >> >> >> I don't have access to either a valgrind or a msan build, but I took a >> > >> > For msan you do need a separate build, but for valgrind your just run >> > valgrind on a regular build. >> >> Valgrind doesn't work on Windows; I'm uncertain whether msan does or not? > > Nope. On Windows your are on your own against uninits (unless you want to > try DrMemory) >> >> >> >> >> >> stab in the dark with r214502. I'll see if the msan bot thinks I've >> > >> > Nope, the report is still there. >> >> Drat! I'll do a bit more investigating... > > > valgrind with --track-origins=yes gives this: > ==3308== Uninitialised value was created by a heap allocation > ==3308== at 0x402F7C4: malloc > (valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:270) > ==3308== by 0x25CEAEA: clang::Preprocessor::AllocateMacroInfo() > ==3308== by 0x25CEC3C: > clang::Preprocessor::AllocateMacroInfo(clang::SourceLocation) > ==3308== by 0x25D312A: > clang::Preprocessor::HandleDefineDirective(clang::Token&, bool) > ==3308== by 0x25D8E58: > clang::Preprocessor::HandleDirective(clang::Token&) > ...
Yes, I found another code path where this wasn't getting initialized. Perhaps 214504 fixes this? (Thank you for your help with tracking this down!) ~Aaron _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
