-
Notifications
You must be signed in to change notification settings - Fork 90
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
Some Java DaCapo benchmarks fail with unhandled SIGSEGVs in hw mode #645
Labels
Milestone
Comments
prp
changed the title
Some Java DaCapo benchmarks fail with unhandled SIGSEGVs
Some Java DaCapo benchmarks fail with unhandled SIGSEGVs in hw mode
Jul 19, 2020
With LKL syscall tracing (ignoring clock_gettime and futex calls):
|
This appears to be caused by the fact that the in-enclave signal handler does not report the faulting address of a page fault correctly to the JVM. With SGX1, there does not seem to be a way to obtain the address that caused the page fault. |
During triaging, it was decided to close this as a duplicate of #680. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running the Java DaCapo benchmarks, some of them fail with unhandled SIGSEGVs as follows:
$ SGXLKL_VERBOSE=1 SGXLKL_KERNEL_VERBOSE=1 SGXLKL_MMAP_FILES=Shared SGXLKL_TRACE_SIGNAL=1 sgx-lkl-run-oe --hw-debug --enclave-config=enclave_config-java-dacapo.json java-dacapo.img
I wonder if this is caused by #644 because signals are not delivered to the correct thread. (I suspect that the lkl_bug above (
bad count while changing owner (cpu.count=2 cpu.owner=139844147022336 owner=139844147019296)
) is a consequence of the signal handler trying to do a state dump to a file.)On the other hand, this problem only seems to be appearing in hw mode and not in sw mode. It also seems to be more prevalent for multi-threaded tests...?
It also doesn't occur if JIT is turned off.
The text was updated successfully, but these errors were encountered: