Closed Bug 982600 Opened 10 years ago Closed 10 years ago

ASAN log spew: "AddressSanitizer: SEGV /builds/slave/m-in-l64-asan-0000000000000000/build/js/src/ctypes/typedefs.h:78 js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*)"

Categories

(Core :: js-ctypes, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla35
Tracking Status
firefox33 --- fixed
firefox34 --- fixed
firefox35 --- fixed

People

(Reporter: cbook, Assigned: decoder)

References

(Blocks 2 open bugs, )

Details

Attachments

(1 file)

Ubuntu ASAN VM 12.04 x64 mozilla-inbound opt test mochitest-browser-chrome on 2014-03-12 01:36:22 PDT for push 01ca94b4729f

slave: tst-linux64-spot-641

https://tbpl.mozilla.org/php/getParsedLog.php?id=35989404&tree=Mozilla-Inbound#error0

01:48:27     INFO -  SUMMARY: AddressSanitizer: SEGV /builds/slave/m-in-l64-asan-0000000000000000/build/js/src/ctypes/typedefs.h:78 js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*)
While it's good to have gotten this on file, note that this is *NOT* currently an intermittent failure. The actual failure in the linked log was the timeout in browser_968447_bookmarks_toolbar_items_in_panel.js. The ASAN warning is just a bunch of noise that we're seeing now due to the recent TBPL log parser changes.

I'm taking intermittent-failure off this bug because I don't want it being a source of mis-stars for other failures.
If this is a bother, you could alter the TBPL regexp so it doesn't match "SUMMARY: AddressSanitizer: SEGV".
Is there a reason these shouldn't be fatal errors?
It looks like this test is intentionally crashing a child process:
  http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/social/browser_social_workercrash.js
So this behavior is probably expected.
In general, yes, we do care about a SEGV, and it could end up causing a real crash, but in general those are going to show up in non-ASAN builds, so it isn't as big of a deal to miss them.  And presumably they'd show up as regular crashes that the test harness can deal with if they happen in the parent process.
Blocks: log-SnR
Summary: Intermittent ASAN | AddressSanitizer: SEGV /builds/slave/m-in-l64-asan-0000000000000000/build/js/src/ctypes/typedefs.h:78 js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*) → ASAN log spew: "AddressSanitizer: SEGV /builds/slave/m-in-l64-asan-0000000000000000/build/js/src/ctypes/typedefs.h:78 js::ctypes::ConvertToJS(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, void*, bool, bool, JS::Value*)"
I might add this to the list that TBPL blacklists, given me forgetting this and getting confused again today, plus things like bug 985845 being misfiled as a result.
Component: JavaScript Engine → js-ctypes
FWIW, I got confused by this today and filed bug 1057907, and we even briefly closed the tree as a result.
(In reply to Ed Morley [:edmorley] from comment #7)
> I might add this to the list that TBPL blacklists, given me forgetting this
> and getting confused again today, plus things like bug 985845 being misfiled
> as a result.

I think we need to proceed with this approach, since I don't think we're going to fix this on the harness side. It's an ongoing source of confusion for people.
Decoder, do you know if there's some way to annotate an intentional crash in ASan?
Flags: needinfo?(choller)
(In reply to Andrew McCreight [:mccr8] from comment #10)
> Decoder, do you know if there's some way to annotate an intentional crash in
> ASan?

There is no way to do this. In general, crashing tests should just be disabled under ASan (there is no crash reporter anyway to do something useful with the crash)
Flags: needinfo?(choller)
Ah, that's a good point.

It looks like these tests are crashing if you want to disable them for ASan, Ryan:
  toolkit/components/thumbnails/test/browser_thumbnails_bg_crash_during_capture.js
  toolkit/components/thumbnails/test/browser_thumbnails_bg_crash_while_idle.js
  browser/base/content/test/social/browser_social_workercrash.js
  dom/ipc/tests/test_process_error.xul
Pushed patch to try that disables all of these tests if no crashreporter is present:

https://tbpl.mozilla.org/?tree=Try&rev=7533382916e8

Please report back if this solves your problems.
(In reply to Christian Holler (:decoder) from comment #13)
> Pushed patch to try that disables all of these tests if no crashreporter is
> present:
> 
> https://tbpl.mozilla.org/?tree=Try&rev=7533382916e8
> 
> Please report back if this solves your problems.

No logspam in the run :) f+
Assignee: nobody → choller
Status: NEW → ASSIGNED
Attachment #8498052 - Flags: review?(adw)
Attachment #8498052 - Flags: review?(mhammond)
Requested review from both test owners based on f+ in comment 14. This patch disables the mentioned tests if no crashreporter is present (which is the case for ASan builds).
Comment on attachment 8498052 [details] [diff] [review]
disable-asan-tests.patch

Review of attachment 8498052 [details] [diff] [review]:
-----------------------------------------------------------------

Note :adw is on PTO, but I think this looks fine with the requested changes.

::: browser/base/content/test/social/browser.ini
@@ +54,5 @@
>  [browser_social_status.js]
>  skip-if = e10s # Bug 915547 (social providers don't install)
>  [browser_social_window.js]
>  [browser_social_workercrash.js]
> +run-if = crashreporter

please make this 'skip-if = !crashreporter' - see https://bugzilla.mozilla.org/show_bug.cgi?id=1074507#c2

::: dom/ipc/tests/chrome.ini
@@ +3,5 @@
>    process_error.xul
>    process_error_contentscript.js
>  
>  [test_process_error.xul]
> +skip-if = buildapp == "mulet" || (crashreporter == false)

just '|| !crashreporter' here (and the other spots) too please.
Attachment #8498052 - Flags: review?(mhammond)
Attachment #8498052 - Flags: review?(adw)
Attachment #8498052 - Flags: review+
Landed with the requested changes, thanks Mark!

https://hg.mozilla.org/integration/mozilla-inbound/rev/bef7426ecdb2
https://hg.mozilla.org/mozilla-central/rev/bef7426ecdb2
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: