stacktrace_from_exception on non-x86

オープン

#163 2024年4月29日に作成コメント 7 件リアクション 0 件担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度: 4/5
見積もり時間: 3〜5日
初心者へのやさしさ: 35/100

issue の種類: バグ
明瞭さ: おおむね明確
活発さ: 停滞
技術スタック: cpp
領域: devtools

調査の方向性

issue に記載された bootstrap.sh コマンドと b2 コマンドを使って non-x86 のビルドを再現します。src/exception_headers.h と src/from_exception.cpp を読み、is_libcpp_runtime も含めて、アーキテクチャとランタイムのチェックを追跡します。stacktrace library が、記載された回避策を必要とせずに GCC/libstdc++ で non-x86 上にビルドできれば完了です。

索引モデルが issue の本文から書いたものです。

説明

enhancement help wanted

I submitted the below to the mailing list, but I wanted to re-iterate it here for more eyes. https://lists.boost.org/Archives/boost/2024/04/256604.php

This feature is guarded by BOOST_STACKTRACE_ALWAYS_STORE_IN_PADDING, but that is only enabled on x86.
This means that

./bootstrap.sh --with-toolset=gcc --with-libraries=stacktrace
./b2 install threading=multi toolset=gcc

always fails to build on non-x86 platforms. There are three current workarounds:

set boost.stacktrace.from_exception=off
set BOOST_STACKTRACE_LIBCXX_RUNTIME_MAY_CAUSE_MEMORY_LEAK
build with threading=single

(1) prevents me from using this feature. (2) shouldn't be needed on it's face because I'm using gcc/libstdc++. (3) affects more than stacktrace.

Is this an incidental error, or is there a reason I wasn't able to deduce as to why this feature can't be used on non-x86+libstdc++?

It seems like the check for libc++ on non-x86 can't be entirely done at compile time. I definitely understand wanting to alert users to the dangers of using this feature, but there also doesn't seem to be a good way of detecting the presence of libc++ at compile time (hence the need for is_libcpp_runtime).

主要言語: C++
スター: 497
フォーク: 86
平均マージ: 8日 20時間
マージ済み PR（30日）: 3

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
リポジトリをフォークし、ブランチを切って変更します。
issue 番号を参照したプルリクエストを送ります。

boostorg/stacktrace のほかの issue

`std::formatter` specialization オープン

難易度 4/5 3〜5日初心者へのやさしさ 52/100

boostorg/stacktrace#233 · 2026年7月7日に作成
Ошибка в Inscape オープン

難易度 5/5 1週間以上初心者へのやさしさ 15/100

boostorg/stacktrace#211 · コメント 1 件 · 2025年10月2日に作成
`-static-libstdc++` with `stacktrace_from_exception` produces duplicate symbol `__cxa_allocate_exception` オープン

難易度 4/5 3〜5日初心者へのやさしさ 35/100

boostorg/stacktrace#208 · コメント 6 件 · 2025年7月24日に作成
The BOOST_STACKTRACE_HAS_BACKTRACE check doesn't seem to work with clang オープン

難易度 3/5 1〜2日初心者へのやさしさ 48/100

boostorg/stacktrace#197 · コメント 3 件 · 2024年12月20日に作成
Implementation with `libdwfl`? オープン

enhancement help wanted

難易度 5/5 1週間以上初心者へのやさしさ 25/100

boostorg/stacktrace#176 · コメント 1 件 · 2024年8月22日に作成

boostorg/stacktrace の issue をすべて見る

似ている issue

Use 4:4:4 for multichannel AVIF and HEIF gain maps オープン

難易度 2/5 1〜3時間初心者へのやさしさ 70/100

google/libultrahdr#485 · 2026年9月24日に作成
Missing tile warnings in TileMap dock display with wrong texture filter オープン

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

godotengine/godot#123776 · 2026年9月23日に作成
if(cond,a,b) treats any nonzero cond as true in every bngsim backend (ExprTk interpreter, C codegen, SSA), which contradicts docs/reference/expressions.md ('true when > 0.5') and BNG's run_network. A non-boolean condition in (-inf,0) or... オープン

bug

難易度 1/5 1時間未満初心者へのやさしさ 60/100

lanl/bngsim#774 · 2026年9月23日に作成
Delete ament_export_include_directories() and ament_export_libraries() calls オープン

good first issue

難易度 1/5 1時間未満初心者へのやさしさ 90/100

ros2/rosbag2#2509 · 2026年9月23日に作成
Delete ament_export_include_directories() and ament_export_libraries() calls オープン

good first issue

難易度 2/5 1〜3時間初心者へのやさしさ 75/100

ros2/common_interfaces#344 · 2026年9月23日に作成

C++ の issue をもっと見る