Bug #6025
closedasn1c ASN__STACK_OVERFLOW_CHECK() fails with gcc 13 and AddressSanitizer enabled
100%
Description
osmo-iuh unit tests (hnbap) started failing today after I upgraded by system to gcc 13.1.1 20230429.
A bit of debugging resulted in _ASN_STACK_OVERFLOW_CHECK() in our libasn1c sometimes returning an error. After disabling building with AddressSAnitizer (I usually build with --enable-sanitize), then the tests started passing.
When debugging with ASan enabled, I saw the stack pointers doing some interesting jumps in the address space (going and coming back to close values) every time a new call frame was entered.
Reading what may probably have changed, I stumbled upon https://gcc.gnu.org/gcc-13/changes.html :
"AddressSanitizer defaults to detect_stack_use_after_return=1 on GNU/Linux targets. For compatibility, it can be disabled with env ASAN_OPTIONS=detect_stack_use_after_return=0."
Indeed, using "export ASAN_OPTIONS=detect_stack_use_after_return=0" makes test pass again.
In any case, it was concluded that it's not a good idea to have such in-code check when building/running with ASan enabled.
Hence, I submitted a patch for our libasn1c.git to gerrit which disables the check when building with ASan:
https://gerrit.osmocom.org/c/libasn1c/+/32612
Upstream as1nc repositories still seem to have the same issue:
https://github.com/vlm/asn1c/blob/master/skeletons/asn_internal.h#L131
https://github.com/mouse07410/asn1c/blob/vlm_master/skeletons/asn_internal.h#L148
So I submitted patches for both upstream repos too:
https://github.com/vlm/asn1c/pull/476
https://github.com/mouse07410/asn1c/pull/128
Once those are merged, we may want to use the new mouse07410 vlm_master and generate new skeletons code for osmo-cbc.git/src/sbcap/skel. I think since we generated the code there has been some extra fixes upstream.