ramosian-glider / sanitizers

0 stars 0 forks source link

[Windows] malloc_uaf_crash is unstable on bot #103

Closed ramosian-glider closed 9 years ago

ramosian-glider commented 9 years ago

Originally reported on Google Code with ID 102

From time to time I get these reports from the Windows buildbot:
@@@BUILD_STEP asan test@@@
run_beginthreadex_pass_test - PASSED
<....>
malloc_right_oob_crash_test.output - PASSED (CRASHED WITH THE CORRECT OUTPUT)
make: *** [malloc_uaf_crash.obj] Error 127

Reported by samsonov@google.com on 2012-08-14 06:46:53

ramosian-glider commented 9 years ago
Also:
make: *** [realloc_uaf_crash.obj] Error 127

Reported by samsonov@google.com on 2012-08-14 15:13:41

ramosian-glider commented 9 years ago

Reported by samsonov@google.com on 2012-08-21 14:30:16

ramosian-glider commented 9 years ago
Also:
make: *** [wrong_free_crash_test.exe] Error 127

Reported by samsonov@google.com on 2012-09-18 07:01:48

ramosian-glider commented 9 years ago
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

ramosian-glider commented 9 years ago
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

ramosian-glider commented 9 years ago
> 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

ramosian-glider commented 9 years ago
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

ramosian-glider commented 9 years ago
Couldn't repro and doesn't show up on the bot anymore.

Reported by timurrrr@google.com on 2013-12-31 11:50:03

ramosian-glider commented 9 years ago
Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:59