Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

humility formats `anyhow` errors with backtraces, which is confusing when also displaying a Hubris stack trace

オープン
  • 何か問題がありますか？
#551 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
rust
領域
cli, devtools

調査の方向性

humility ... tasks <TASK> --stack と --stack --guess で動作を再現し、続いて tasks コマンドによる anyhow エラーの処理を追跡します。表示された 2 つのトレースを比較します。dump エラーが理解可能なままで、Hubris の stack trace と並んで混乱を招く 2 つ目の Humility backtrace まで生成されなければ完了です。

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

説明

When running humility tasks <TASK> --stack on a dump of a task that overflowed its stack, Humility prints an error indicating that the stack pointer points at an invalid memory address (which makes sense, as it points outside of the dumped region), and suggests the use of the --guess flag to try and reconstruct the stack trace from the frame pointer. This error is represented by an anyhow error, which includes a backtrace:

eliza@theseus ~/Code/oxide/hubris $ humility -d hubris.core.packrat.0 tasks packrat --stack
humility: attached to dump
system time = 321850
ID TASK                       GEN PRI STATE
11 packrat                      0   1 FAULT: stack overflow; sp=0x24001f98 (was: ready)
   could not read registers: read of 32 bytes from invalid address: 0x24001f98

Stack backtrace:
   0: <humility_core::dump::DumpCore as humility_core::core::Core>::read_8
   1: humility_core::hubris::HubrisArchive::registers
   2: humility_cmd_tasks::print_tasks
   3: humility_cmd_tasks::tasks
   4: humility_cmd::attach
   5: humility::cmd::subcommand
   6: humility::main
   7: std::sys::backtrace::__rust_begin_short_backtrace
   8: std::rt::lang_start::{{closure}}
   9: std::rt::lang_start_internal
  10: main
  11: __libc_start_call_main
  12: __libc_start_main_impl
  13: _start
   use `--guess` to guess at stack trace

When the command is run again with --stack --guess, Humility still points the error, along with the Hubris backtrace that it guessed at:

eliza@theseus ~/Code/oxide/hubris $ humility -d hubris.core.packrat.0 tasks packrat --stack --guess
humility: attached to dump
system time = 321850
ID TASK                       GEN PRI STATE
11 packrat                      0   1 FAULT: stack overflow; sp=0x24001f98 (was: ready)
   could not read registers: read of 32 bytes from invalid address: 0x24001f98

Stack backtrace:
   0: <humility_core::dump::DumpCore as humility_core::core::Core>::read_8
   1: humility_core::hubris::HubrisArchive::registers
   2: humility_cmd_tasks::print_tasks
   3: humility_cmd_tasks::tasks
   4: humility_cmd::attach
   5: humility::cmd::subcommand
   6: humility::main
   7: std::sys::backtrace::__rust_begin_short_backtrace
   8: std::rt::lang_start::{{closure}}
   9: std::rt::lang_start_internal
  10: main
  11: __libc_start_call_main
  12: __libc_start_main_impl
  13: _start
   guessing at stack trace using saved frame pointer
   |
   +--->  0x24002048 0x080564de core::fmt::write
          0x240020a0 0x080564de core::fmt::write
          0x240020d8 0x08056b24 rust_begin_unwind
          0x240020d8 0x08055d12 core::fmt::Formatter::pad_integral::write_prefix

This output is kinda goofy, since there are two stack traces printed out, with different formatting.

While an astute reader can pretty easily determine that one of these looks like a stack trace in Humility rather than Hubris, it's still pretty weird that there are two stacks displayed, which is potentially confusing. We should probably not format the anyhow::Error with the format specifier that includes a backtrace in this case, since it's not really an internal error we'd need the backtrace to debug, and is instead an error regarding the dump we tried to read.

主要言語
Rust
スター
587
フォーク
64
平均マージ
2日 1時間
マージ済み PR（30日）
7

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

oxidecomputer/humility のほかの issue

oxidecomputer/humility の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。