-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Test for incompatible HEAP transforms in acorn-optimizer #24309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
4baf35f
to
22719e3
Compare
Actually, if I add |
Ah yeah, looks like |
'other/test_null_deref_via_js.c', | ||
emcc_args=args, | ||
assert_returncode=NON_ZERO, | ||
expected_output=[expected_output]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps a single test with all 3 features enabled is enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be enough to reproduce the issue, but I found that having separate tests helps to narrow down which particular transform is at fault. Just really putting "unit" into the "unit tests".
I guess it's not surprising some of these combinations don't work, given the possible interactions, and that we don't have exhaustive testing... I'd say that only memory growth is a high priority, of the three (asan is run locally, and devs can work around feature combinations, and big-endian likely has very few users). |
Yeah I agree, combo of memory growth + ASan is the first one I noticed and then thought it's worth checking other combinations too. I'd like to merge #24291 + #24295 + |
While working on #24295, I noticed I could accidentally prevent ASan and SAFE_HEAP from finding any
HEAPxx[n]
accesses from JS whenALLOW_MEMORY_GROWTH
is enabled, and no tests would catch it, because no tests verify that acorn-optimizer passes which changeHEAPxx[n]
into something else can work in conjunction with each other.After adding the test, I found that an existing
SUPPORT_BIG_ENDIAN
feature was already broken in the same way, because it transformsHEAPxx[n]
accesses into DataView methods, and since it was running before ASan and SAFE_HEAP, those latter transforms became no-ops. I fixed that in the same PR by moving the big-endian transform to the end.In the future we might want to consolidate those transforms in a more reliable way (e.g. only run a single code transform that does
HEAPxx[n]
->__loadHeap
/__storeHeap
where those functions do all the work using#if
s), but at least for now this PR fixes an immediate problem and catches potential future regressions.