Project

General

Profile

Actions

Bug #6025

closed

asn1c ASN__STACK_OVERFLOW_CHECK() fails with gcc 13 and AddressSanitizer enabled

Added by pespin 11 months ago. Updated 10 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/04/2023
Due date:
% Done:

100%

Spec Reference:

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.

Actions #1

Updated by pespin 11 months ago

  • Status changed from New to Feedback
  • Assignee changed from pespin to laforge

laforge it seems in order to submit a PR to GH vlm/asn1c I need to agree with a CLA: https://cla-assistant.io/vlm/asn1c?pullRequest=476
Waiting for you on feedback on how should I submit it, not sure if that was solved already (since I so far only contributed to mouse07410/asn1c.git I think).

Actions #2

Updated by laforge 11 months ago

sysmocom has signed a corporate CLA for asn1c years ago, I'm quite sure.

Actions #3

Updated by pespin 11 months ago

  • Assignee changed from laforge to pespin

PR for https://github.com/mouse07410/asn1c/pull/128 has been merged.
I accepted the CLA as it was already in place for https://github.com/vlm/asn1c/pull/476

Actions #4

Updated by pespin 11 months ago

I updated SBcAP generated code from asn1c in osmo-cbc.git with the already merged patch in upstream:
https://gerrit.osmocom.org/c/osmo-cbc/+/32723 sbcap: Update asn1c skeleton files

Actions #5

Updated by pespin 10 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

The upstream asn1c https://github.com/vlm/asn1c projects seems to be unmaintainted in practice. I submitted a PR 1 month ago and I didn't receive any feedback (nor there was any more changes in any ticket apparently).
Looks like last commit merged in master branch there is from around 2 years ago, so doesn't look like the patch is going to be merged soon.
It was merged to mouse07410 fork though, which we use for osmo-cbc.git, so that's good enough.

Hence, closing this ticket instead of leaving it open for years.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)