hijack: roll back signal before func_exit_handler

[miRoox]

if any function inside func_exit_handle calls exit indirectly, it will lead
to infinity recursive calls. Roll back the signal in the beginning of the
handler to avoid such cases.

Signed-off-by: Yong-an Lu yongan.lu@intel.com

[marc-hb]

No, bash is not that stupid. Type this:

bash
func_exit_handler() { printf 'in exit handler\n'; exit ; }
trap func_exit_handler EXIT
exit

=> no infinite loop

Are you trying to call the handler directly? Don't do that. If you need to call the handler's code then insert one layer of indirection.

[miRoox]

@marc-hb Maybe my understanding is incorrect, but in https://sof-ci.sh.intel.com/#/result/planresultdetail/17476?model=TGLU_RVP_NOCODEC_IPC4ZPH&testcase=check-playback-all-formats

2022-11-08 22:08:09 UTC [REMOTE_ERROR] firmware path not found from journalctl, no firmware loaded or debug option disabled?
2022-11-08 22:08:09 UTC [REMOTE_ERROR] Starting func_exit_handler(), exit status=1, FUNCNAME stack:
2022-11-08 22:08:09 UTC [REMOTE_ERROR]  die()  @  /home/ubuntu/sof-test/test-case/../case-lib/lib.sh
2022-11-08 22:08:09 UTC [REMOTE_ERROR]  is_firmware_file_zephyr()  @  /home/ubuntu/sof-test/test-case/../case-lib/lib.sh:697
2022-11-08 22:08:09 UTC [REMOTE_ERROR]  logger_disabled()  @  /home/ubuntu/sof-test/test-case/../case-lib/lib.sh:746
2022-11-08 22:08:09 UTC [REMOTE_ERROR]  main()  @  /home/ubuntu/sof-test/test-case/check-playback.sh:57
2022-11-08 22:08:10 UTC [REMOTE_ERROR] firmware path not found from journalctl, no firmware loaded or debug option disabled?

It looks like a recursive call on https://github.com/thesofproject/sof-test/pull/973/files#diff-bc7925bc6dfddedfd138183aeea9aafd0010bde80cb9d55b12701a2c0d0fc32fR697

[miRoox]

BTW, in sh-tglu-rvp-nocodec-ci-02 the journal seems lost, @marc-hb do you have any solution?

ubuntu@sh-tglu-rvp-nocodec-ci-02:~$ sudo journalctl --list-boots
 0 319d9cd004744b379a8c6208e119a6aa Wed 2022-11-09 01:29:23 UTC—Wed 2022-11-09 01:46:54 UTC

[marc-hb]

Maybe it was called twice because of our weird SubTest thing. Anyway https://sof-ci.sh.intel.com/#/result/planresultdetail/17476?model=TGLU_RVP_NOCODEC_IPC4ZPH&testcase=check-playback-all-formats does not look like an infinite loop at all.

[marc-hb]

Can you reproduce a problem that is fixed by this PR?

[miRoox]

Can you reproduce a problem that is fixed by this PR?

No, I'm still trying.

[miRoox]

I understand where the TIMEOUT came from: it's just because there is no "Test Result: FAIL!" at the end of the log. But there are still 2 mysteries:

1. Why is "firmware path not found from journalctl" in the middle of the tests?
2. Why "firmware path not found from journalctl" occurred twice in https://sof-ci.sh.intel.com/#/result/planresultdetail/17476?model=TGLU_RVP_NOCODEC_IPC4ZPH&testcase=check-playback-all-formats?

[marc-hb]

This looks like a double reservation:

ln: failed to create hard link '/tmp/sof-test-card0.lock': File exists

It could also be the previous test that just crashed.

[marc-hb]

Why is "firmware path not found from journalctl" in the middle of the tests?
Why "firmware path not found from journalctl" occurred twice

this function is called in many places.

[marc-hb]

BTW, in sh-tglu-rvp-nocodec-ci-02 the journal seems lost, @marc-hb do you have any solution?

This is worrying and not the first time.

I recently found that Ubuntu 22 still uses rsyslogd in addition to journald. Weird. Look in /var/log/

• HOWTO use journalctl when faced with time warps #908 (comment)