CI: SGX 143 failure

[yamt]

spec_test_default (fast-jit, $DEFAULT_TEST_OPTIONS, ubuntu-22.04)

exception is ....'type mismatch'
Writing WAST module to '/tmp/block_rauaqwbl.wast'
Compiling WASM to '/tmp/block_0ete778f.wasm'
Running: ./wabt/out/gcc/Release/wat2wasm --enable-multi-memory --enable-threads --no-check /tmp/block_rauaqwbl.wast -o /tmp/block_0ete778f.wasm
Starting interpreter for module '/tmp/block_0ete778f.wasm'
Running: ../../../product-mini/platforms/linux-sgx/enclave-sample/iwasm --heap-size=0 --repl --stack-size=131072 /tmp/block_0ete778f.wasm
module is ....'(module (func $type-break-operand-f64-vs-f32 (result f64)
Error: Process completed with exit code 143.

references:
actions/runner-images#6680
#4222 this doesn't seem working well?

[lum1n0us]

Yes, it seems the retry approach based on bash can't detect the exit; maybe using the gh command is better.

[lum1n0us]

retry-action doesn't work. https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/15891351369/job/44814369031?pr=4415

what's our next option?

[yamt]

retry-action doesn't work. https://github.com/bytecodealliance/wasm-micro-runtime/actions/runs/15891351369/job/44814369031?pr=4415

what's our next option?

have anyone restarted manually? i haven't.

[yamt]

what's our next option?

i suspect the 143 failure is something which can't be detected by the workflow step itself.

i wonder why it only happens on the SGX workflow frequently.
if it's because of the size, maybe we can try to reduce/divide the workflow.

[lum1n0us]

i wonder why it only happens on the SGX workflow frequently.

No idea. I used to think it might be a compatibility problem, but found nothing after going through the manuals.

if it's because of the size, maybe we can try to reduce/divide the workflow.

Are you suggesting that SGX installation might consume too much resource and not leave enough disk space for CI?

Regarding reduce/divide, I thought jobs, especially spec-tests, are parallel and divided across different machines.

[yamt]

if it's because of the size, maybe we can try to reduce/divide the workflow.

Are you suggesting that SGX installation might consume too much resource and not leave enough disk space for CI?

my assumption was the job was somehow killed because of some resource limit.
i have no idea if it's the case or what resource it is. it can be disk, cpu, memory, swap, etc.