1081229 - ASAN failures aren't recognized by mozharness as errors

Status: RESOLVED INCOMPLETE

(Release Engineering :: Applications: MozharnessCore, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

ASAN builds disable the crash reporter, so ASAN failures are directly indicated only by ASAN's log messages, which mozharness doesn't recognize as errors.  The process also exits, but if it's a child process and it fails in this way at a time that doesn't cause a test failure (if the test script is insufficiently strict, or if it's on a shutdown path after the test considers itself finished, or something like that) then the test run will be green on Treeherder/TBPL despite containing evidence of what could be a security issue.

I don't know if it would be appropriate to add this kind of thing to the "harness_error" regexp in TinderBoxPrintRe in mozharness/mozilla/testing/errors.py, alongside the regexp alternatives for LSAN messages, or if there's some other place that makes more sense.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Apparently this sort of works?  e.g., https://treeherder.mozilla.org/ui/logviewer.html#?job_id=2490777&repo=try flags a line "INFO - SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??", but in that case there was also a test failure.  (Maybe bug 1081251 was unintentionally fixed?)

Also, that "??:0" looks like something tried to use addr2line, but misparsed the log and supplied an incorrect address (or used a stripped binary, or something like that).