Open ramosian-glider opened 9 years ago
Also:
make: *** [realloc_uaf_crash.obj] Error 127
Reported by samsonov@google.com
on 2012-08-14 15:13:41
Reported by samsonov@google.com
on 2012-08-21 14:30:16
Also:
make: *** [wrong_free_crash_test.exe] Error 127
Reported by samsonov@google.com
on 2012-09-18 07:01:48
Hm...
In all cases so far the failures happened during compile-time.
Maybe it's just a compiler flakiness?
Reported by timurrrr@google.com
on 2012-09-18 07:29:25
It's rather unlikely for the compiler to be flaky.
Is it possible to print the log for the crashing test somehow?
Could the flakiness be caused by make -j and an incorrect dependencies?
Reported by ramosian.glider
on 2012-09-18 07:53:54
> It's rather unlikely for the compiler to be flaky.
Come on, it's Visual Studio :)
> Could the flakiness be caused by make -j
could be but not clear how
> and an incorrect dependencies?
don't think so - each test has unique dependency names
Reported by timurrrr@google.com
on 2012-09-18 08:17:48
FTR,
The compiler is actually Clang when building these tests.
What happens for each test X is basically:
a) clang++ -g test.cpp -o test.obj # Creates the .obj file,
b) link -debug /out:test.exe test.obj # Creates the .exe file,
c) ./test.exe # Runs the test.
What we observe when flakiness happens is that either (a) or (b) may fail at any time.
I can understand (b) as N linkers might be communicating with a shared mspdbsrv or
something like that, but it remains totally unclear to me how can (a) fail if clang
is not flaky.
Reported by timurrrr@google.com
on 2012-10-09 13:24:50
Couldn't repro and doesn't show up on the bot anymore.
Reported by timurrrr@google.com
on 2013-12-31 11:50:03
Invalid
Originally reported on Google Code with ID 102
Reported by
samsonov@google.com
on 2012-08-14 06:46:53