1896052 - TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/1659595.js | Over recursed (code 1, args "") [0.0 s]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mike Hommey [:glandium]]

Enabling ASan's detect_stack_use_after_return (which is the default since clang 15, but that we disabled back when clang 15 was clang trunk) causes errors such as:

[task 2024-05-09T08:07:21.549Z] TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/1659595.js | Over recursed (code 1, args "") [0.0 s]
[task 2024-05-09T08:07:21.549Z] INFO exit-status     : 1
[task 2024-05-09T08:07:21.549Z] INFO timed-out       : False
[task 2024-05-09T08:07:21.549Z] INFO stderr         2> Over recursed
[task 2024-05-09T08:07:21.585Z] Can't open self-hosted stencil XDR file.
[task 2024-05-09T08:07:21.585Z] Falling back on parsing source.
[task 2024-05-09T08:07:21.586Z] Over recursed
[task 2024-05-09T08:07:21.586Z] Exit code: 1
[task 2024-05-09T08:07:21.586Z] FAIL - bug1323854-2.js

Comment 1

[Mike Hommey [:glandium]]

Attachment: Bug 1896052 - Use the frame address instead of a pointer to a stack variable.

To measure how far along in the stack recursion has been going, the JS
engine gets a pointer to a dummy variable on the stack and compares it
to the end of the stack.

This works fine, except when the pointer tothe variable on the stack
points to somewhere... not exactly on the stack. When ASan's
detect_stack_use_after_return is enabled, stack variables actually live
on a fake stack, breaking the assumptions the stack recursion protection
does.

GCC has __builtin_stack_address, but clang doesn't. Both however have
__builtin_frame_address, which is close enough, and always points
somewhere on the real stack.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4fe736e4a99d
Use the frame address instead of a pointer to a stack variable. r=spidermonkey-reviewers,sfink

Comment 3

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/4fe736e4a99d