SIGSEGV - memory fault at 0x00000000 (IP = 0x4d16c2183)

[tiagorvmartins]

Hello, I am trying to run a rust application using Gramine GSC and currently getting the application terminated with a SIGSEGV.
The application does in fact start because I can see some output logs, but then terminates further down the process.

I wonder if it's related with the following warnings I got in the verbose log:
warning: Unsupported system call mremap

Here is my current manifest file:

sys.enable_extra_runtime_domain_names_conf = true
sgx.edmm_enable = true
sgx.nonpie_binary = true
sgx.max_threads = 32
sgx.enclave_size = "32G"

sgx.trusted_files = [
  "file:/usr/local/bin/sandstorm-cli"   
]

sgx.allowed_files = [
  "file:/usr/src/app/example/"
]

loader.env.OMP_NUM_THREADS = "8"
loader.env.RUST_BACKTRACE = "full"
sys.insecure__allow_eventfd = true

The verbose log can be found attached, couldn't paste here since its too long.
verbose_log_sigsegv.txt

[dimakuv]

Did you try this application with gramine-direct? (You can ask GSC to enable gramine-direct via gsc build -L, and then run the direct version via docker run ... --env GSC_PAL=Linux; see details here: https://gramine.readthedocs.io/projects/gsc/en/latest/#envvar-GSC_PAL)

I wonder if it's related with the following warnings I got in the verbose log: warning: Unsupported system call mremap

No, I don't think the missing mremap() system call is in any way relevant. Applications almost certainly can fall back to other ways of memory allocation, and also looking at the log, your application continues happily after this unsupported syscall.

Looking at your log, I don't see anything special there. It does feel like your Rust application has some bug, that is triggered in Gramine.

I'm afraid you'll have to debug it with GDB... You can do docker run on your GSC-generated Docker image with the Bash entrypoint (and in interactive mode), and from inside there, you can install GDB and other required things and start GDB=1 gramine-sgx.

[llly]

Can you try to add sgx.require_exinfo = true to manifest?
I can see that you enabled EDMM. Some app requires this SGX feature to handle page fault when EDMM enabled.

[tiagorvmartins]

Thank you both for the answers,
After adding the suggestion from @llly I can now see a different problem after the memory fault:

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

I know that the app uses a lot of recursion, but it does in fact work outside of gramine when running the image as a standard docker container.

Is there something else I can do? without touching the app itself? Maybe disable EDMM?
Also attaching the new logs,
verbose_log_stackoverflow.txt

Thank you again

[tiagorvmartins]

Maybe increasing the stack size?
sys.stack.size = "[SIZE]"

[dimakuv]

@tiagorvmartins Yes, exactly, you should increase the sys.stack.size value in the manifest.

[tiagorvmartins]

Hello @dimakuv and @llly , swapping stack size to 16M completely solved my problem!
Thank you again for all the support.
Marking as answer and closing!