Skip to content
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

SEGV (/usr/local/bin/xst+0xdfee5f) in _fini #768

Closed
hope-fly opened this issue Jan 7, 2022 · 1 comment
Closed

SEGV (/usr/local/bin/xst+0xdfee5f) in _fini #768

hope-fly opened this issue Jan 7, 2022 · 1 comment
Labels
confirmed issue reported has been reproduced fixed - please verify Issue has been fixed. Please verify and close.

Comments

@hope-fly
Copy link

hope-fly commented Jan 7, 2022

Moddable-XS revision

Commit: 2f93df29

Version: 11.5.0 32 4

Build environment

Ubuntu 18.04.5 LTS (Linux 5.4.0-44-generic x86_64)

Build steps
cd  ~/moddable/xs/makefiles/lin
make -f xst.mk
Test case
poc.js

function JSEtest() {
    return { __proto__: setInterval(/a/g, "") } instanceof Array
        && !({ __proto__: null } instanceof Object);
}

if (!JSEtest())
    throw new Error("Test failed");

Execution & Output
$ ./moddable/build/bin/lin/debug/xst poc.js

Error: Test failed
AddressSanitizer:DEADLYSIGNAL
=================================================================
==50961==ERROR: AddressSanitizer: SEGV on unknown address 0x000000dfee60 (pc 0x000000dfee60 bp 0x7ffe67452190 sp 0x7ffe67452088 T0)

==50961==The signal is caused by a READ memory access.
==50961==Hint: PC is at a non-executable region. Maybe a wild jump?
    #0 0xdfee5f in _fini (/usr/local/bin/xst+0xdfee5f)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/local/bin/xst+0xdfee5f) in _fini
==50961==ABORTING

Credits: Found by OWL337 team.

@phoddie
Copy link
Collaborator

phoddie commented Jan 8, 2022

Thank you for the report!

The crash occurs in after the test exits. The call to fxDeleteMachine crashes when calls the destructor of the timer created by setInterval.

while (bSlot < cSlot) {
	if ((bSlot->kind == XS_HOST_KIND) && (bSlot->value.host.variant.destructor)) {
		if (bSlot->flag & XS_HOST_HOOKS_FLAG) {
			if (bSlot->value.host.variant.hooks->destructor)
				(*(bSlot->value.host.variant.hooks->destructor))(bSlot->value.host.data);
		}
		else
			(*(bSlot->value.host.variant.destructor))(bSlot->value.host.data);
	}
	bSlot++;
}

This may be a bug in the xst tool rather than the XS engine. Either way, we'll fix that so it doesn't get in the way of testing.

mkellner pushed a commit that referenced this issue Jan 17, 2022
@phoddie phoddie added confirmed issue reported has been reproduced fixed - please verify Issue has been fixed. Please verify and close. labels Jan 18, 2022
mkellner pushed a commit that referenced this issue Jan 31, 2022
@phoddie phoddie closed this as completed Feb 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed issue reported has been reproduced fixed - please verify Issue has been fixed. Please verify and close.
Projects
None yet
Development

No branches or pull requests

2 participants