| 2020-11-24 19:21:18 |
Dave Nadler |
bug |
|
|
added bug |
| 2020-11-25 01:30:36 |
Dave Nadler |
description |
Concurrently throwing exceptions in multiple threads crashes.
This bug has impacted multiple commercial projects, some examples:
https://forums.xilinx.com/t5/Embedded-Development-Tools/Re-building-the-SDK-libc-newlib-and-libgcc-for-reentrancy/m-p/1164973
https://www.arangodb.com/2019/09/when-exceptions-collide/
https://forums.freertos.org/t/freertos-and-c-exceptions/10911
BACKGROUND
Exception unwinding requires some datastructures; specifically
the libgcc module unwind-dw2-fde.c has two-three statics.
These statics are protected by a gthread_mutex.
BUG
Arm build of libgcc builds gthread_mutex as no-op.
Thus applications cannot provide for example an RTOS
mutex with priority inheritance to protect above statics.
If I understand correctly, ARM toolchain build includes:
gthr-single.h
which dummies out the gthread functions as inline no-ops;
consequently they cannot be overridden.
SUGGESTIONS
A couple different approaches to fix this:
1) Create+use a separate gthreads module, including weak
no-op functions for the gthreads functions. Thus RTOS users
can provide an alternate implementation of gthreads
appropriate for their RTOS, and non-RTOS users are
unaffected.
2) Use thread-local storage instead of statics in unwind-dw2-fde.c?
Is there a architecture-independent TLS wrapper in gcc libcc?
Please let me know if you agree, and if I can help...
Thanks!
Best Regards, Dave |
Concurrently throwing C++ exceptions in multiple threads crashes.
This bug has impacted multiple commercial projects, some examples:
https://forums.xilinx.com/t5/Embedded-Development-Tools/Re-building-the-SDK-libc-newlib-and-libgcc-for-reentrancy/m-p/1164973
https://www.arangodb.com/2019/09/when-exceptions-collide/
https://forums.freertos.org/t/freertos-and-c-exceptions/10911
BACKGROUND
Exception unwinding requires some data structures; specifically
the libgcc module unwind-dw2-fde.c has two-three statics.
These statics are protected by a gthread_mutex.
BUG
Arm build of libgcc builds gthread_mutex as no-op.
Thus applications cannot provide for example an RTOS
mutex with priority inheritance to protect above statics.
If I understand correctly, ARM toolchain build includes:
gthr-single.h
which dummies out the gthread functions as inline no-ops;
consequently they cannot be overridden.
SUGGESTIONS
A couple different approaches to fix this:
1) Create+use a separate gthreads module, including weak
no-op functions for the gthreads functions. Thus RTOS users
can provide an alternate implementation of gthreads
appropriate for their RTOS, and non-RTOS users are
unaffected.
2) Use thread-local storage instead of statics in unwind-dw2-fde.c?
Is there a architecture-independent TLS wrapper in gcc libcc?
Please let me know if you agree, and if I can help...
Thanks!
Best Regards, Dave |
|
| 2020-12-05 14:18:36 |
Dave Nadler |
description |
Concurrently throwing C++ exceptions in multiple threads crashes.
This bug has impacted multiple commercial projects, some examples:
https://forums.xilinx.com/t5/Embedded-Development-Tools/Re-building-the-SDK-libc-newlib-and-libgcc-for-reentrancy/m-p/1164973
https://www.arangodb.com/2019/09/when-exceptions-collide/
https://forums.freertos.org/t/freertos-and-c-exceptions/10911
BACKGROUND
Exception unwinding requires some data structures; specifically
the libgcc module unwind-dw2-fde.c has two-three statics.
These statics are protected by a gthread_mutex.
BUG
Arm build of libgcc builds gthread_mutex as no-op.
Thus applications cannot provide for example an RTOS
mutex with priority inheritance to protect above statics.
If I understand correctly, ARM toolchain build includes:
gthr-single.h
which dummies out the gthread functions as inline no-ops;
consequently they cannot be overridden.
SUGGESTIONS
A couple different approaches to fix this:
1) Create+use a separate gthreads module, including weak
no-op functions for the gthreads functions. Thus RTOS users
can provide an alternate implementation of gthreads
appropriate for their RTOS, and non-RTOS users are
unaffected.
2) Use thread-local storage instead of statics in unwind-dw2-fde.c?
Is there a architecture-independent TLS wrapper in gcc libcc?
Please let me know if you agree, and if I can help...
Thanks!
Best Regards, Dave |
Concurrently throwing C++ exceptions in multiple threads crashes.
This bug has impacted multiple commercial projects, some examples:
https://forums.xilinx.com/t5/Embedded-Development-Tools/Re-building-the-SDK-libc-newlib-and-libgcc-for-reentrancy/m-p/1164973
https://www.arangodb.com/2019/09/when-exceptions-collide/
https://forums.freertos.org/t/freertos-and-c-exceptions/10911
BACKGROUND
Exception unwinding requires some data structures; specifically
the libgcc module unwind-dw2-fde.c has two-three statics.
These statics are protected by a gthread_mutex.
BUG
Arm build of libgcc builds gthread_mutex as no-op.
Thus applications cannot provide for example an RTOS
mutex with priority inheritance to protect above statics.
If I understand correctly, ARM toolchain build includes:
gthr-single.h
which dummies out the gthread functions as inline no-ops;
consequently they cannot be overridden.
SUGGESTIONS
A couple different approaches to fix this:
1) Create+use a separate gthreads module to provide weak
no-op functions for the gthreads functions. Thus RTOS users
can provide an alternate implementation of gthreads
appropriate for their RTOS, and non-RTOS users are
unaffected.
2) Use thread-local storage instead of statics in unwind-dw2-fde.c?
Is there a architecture-independent TLS wrapper in gcc libcc?
Please let me know if you agree, and if I can help...
Thanks!
Best Regards, Dave |
|
| 2020-12-05 14:19:47 |
Dave Nadler |
summary |
Not thread-safe: C++ Exception Processing in GNU Arm Embedded Toolchain |
Not thread-safe: C++ Exception Processing Crashes in GNU Arm Embedded Toolchain |
|
