論文の概要: SyzRetrospector: A Large-Scale Retrospective Study of Syzbot
- arxiv url: http://arxiv.org/abs/2401.11642v1
- Date: Mon, 22 Jan 2024 01:06:55 GMT
- ステータス: 処理完了
- システム内更新日: 2024-01-23 15:46:54.961144
- Title: SyzRetrospector: A Large-Scale Retrospective Study of Syzbot
- Title（参考訳）: syzretrospector: syzbotの大規模振り返り調査
- Authors: Joseph Bursey, Ardalan Amiri Sani, Zhiyun Qian
- Abstract要約: 我々は、Syzbotのパフォーマンスとバグ発見の改善をよりよく理解し、定量化しようとしました。
SyzRetrospectorを大規模に使用して599のバグを分析し、Syzbotが発見できる平均331.17日前にバグが隠されていることを発見した。
- 参考スコア（独自算出の注目度）: 18.608808127947455
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Over the past 6 years, Syzbot has fuzzed the Linux kernel day and night to
report over 5570 bugs, of which 4604 have been patched [11]. While this is
impressive, we have found the average time to find a bug is over 405 days.
Moreover, we have found that current metrics commonly used, such as
time-to-find and number of bugs found, are inaccurate in evaluating Syzbot
since bugs often spend the majority of their lives hidden from the fuzzer. In
this paper, we set out to better understand and quantify Syzbot's performance
and improvement in finding bugs. Our tool, SyzRetrospector, takes a different
approach to evaluating Syzbot by finding the earliest that Syzbot was capable
of finding a bug, and why that bug was revealed. We use SyzRetrospector on a
large scale to analyze 559 bugs and find that bugs are hidden for an average of
331.17 days before Syzbot is even able to find them. We further present
findings on the behaviors of revealing factors, how some bugs are harder to
reveal than others, the trends in delays over the past 6 years, and how bug
location relates to delays. We also provide key takeaways for improving
Syzbot's delays.
- Abstract（参考訳）: 過去6年間で、SyzbotはLinuxカーネルを昼夜混乱させ、5570以上のバグを報告し、そのうち4604がパッチが当てられた[11]。
これは印象的なことですが、バグを見つける平均時間は405日以上であることが分かりました。
さらに,Syzbotの評価では,バグの大部分がファザから隠されているため,タイム・トゥ・フィンドやバグの数といった現在のメトリクスが不正確であることが判明した。
本稿では,Syzbotの性能とバグ発見の改善について,より深く理解し,定量化する。
我々のツールであるSyzRetrospectorは、Syzbotがバグを見つけることができる最初期の方法と、そのバグが明らかにされた理由を見つけることで、Syzbotの評価に異なるアプローチを取っています。
SyzRetrospectorを大規模に使用して599のバグを分析し、Syzbotが発見できる平均331.17日前にバグが隠されていることを発見した。
さらに,発見要因の挙動,バグの公開が困難であること,過去6年間の遅延傾向,バグの位置が遅延とどのように関係しているか,などについて明らかにする。
また、Syzbotの遅延を改善するための重要なポイントも提供します。
関連論文リスト
- Discovery of Timeline and Crowd Reaction of Software Vulnerability Disclosures [47.435076500269545]
Apache Log4Jはリモートコード実行攻撃に対して脆弱であることが判明した。
35,000以上のパッケージが最新バージョンでLog4Jライブラリをアップデートせざるを得なかった。
ソフトウェアベンダが脆弱性のないバージョンをリリースするたびに、ソフトウェア開発者がサードパーティのライブラリを更新するのは、事実上妥当です。
論文 参考訳（メタデータ） (2024-11-12T01:55:51Z) - Fast Fixes and Faulty Drivers: An Empirical Analysis of Regression Bug Fixing Times in the Linux Kernel [3.1959458747110054]
本稿では、回帰バグの修正に要する時間を考慮して、カーネルの回帰バグ追跡に焦点を当てる。
調査したデータセットは、Linuxカーネルのレグレッションを追跡するregzbot自動化フレームワークに基づいている。
論文 参考訳（メタデータ） (2024-11-04T13:53:29Z) - Taming Timeout Flakiness: An Empirical Study of SAP HANA [47.29324864511411]
不安定なテストは回帰テストに悪影響を及ぼします。
テストタイムアウトは、このような不安定なテストの失敗に寄与する要因のひとつです。
テストのフレキネス率は、繰り返しテストの実行回数によって49%から70%の範囲である。
論文 参考訳（メタデータ） (2024-02-07T20:01:41Z) - DebugBench: Evaluating Debugging Capability of Large Language Models [80.73121177868357]
DebugBench - LLM(Large Language Models)のベンチマーク。
C++、Java、Pythonの4つの主要なバグカテゴリと18のマイナータイプをカバーする。
ゼロショットシナリオで2つの商用および4つのオープンソースモデルを評価する。
論文 参考訳（メタデータ） (2024-01-09T15:46:38Z) - Can LLMs Demystify Bug Reports? [0.6650227510403052]
ChatGPTは報告されたバグの50%を解読し、再現することができた。
報告されたバグの半数に自動的に対処できることは、バグに対処するために機械学習を適用することで、バグを報告できるのは人力のみである、という有望な可能性を示している。
論文 参考訳（メタデータ） (2023-10-10T05:07:00Z) - Bugsplainer: Leveraging Code Structures to Explain Software Bugs with
Neural Machine Translation [4.519754139322585]
Bugsplainerは、バグ修正コミットの大規模なコーパスから学ぶことによって、ソフトウェアバグの自然言語説明を生成する。
Bugsplainerはバグを推論するためにコード構造を利用し、テキスト生成モデルの微調整バージョンであるCodeT5を採用している。
論文 参考訳（メタデータ） (2023-08-23T17:35:16Z) - Evaluating SZZ Implementations: An Empirical Study on the Linux Kernel [8.698309437598944]
ゴーストコミットがSZZアルゴリズムに与える影響の評価は依然として限られている。
Linuxカーネル開発者は、標準のプラクティスとして、対応するバグ誘発コミット(s)のコミット識別子でバグ修正パッチのラベル付けを始めた。
本稿では6つのSZZアルゴリズムを76,046対のバグ修正パッチとLinuxカーネルからのバグ発生コミットに適用する。
論文 参考訳（メタデータ） (2023-08-09T16:41:27Z) - What Happens When We Fuzz? Investigating OSS-Fuzz Bug History [0.9772968596463595]
我々は2022年3月12日までにOSS-Fuzzが公表した44,102件の問題を分析した。
コードを含むバグの発生時期を推定するために,バグ貢献のコミットを特定し,検出から修正までのタイムラインを測定した。
論文 参考訳（メタデータ） (2023-05-19T05:15:36Z) - Using Developer Discussions to Guide Fixing Bugs in Software [51.00904399653609]
我々は,タスク実行前に利用可能であり,また自然発生しているバグレポートの議論を,開発者による追加情報の必要性を回避して利用することを提案する。
このような議論から派生したさまざまな自然言語コンテキストがバグ修正に役立ち、オラクルのバグ修正コミットに対応するコミットメッセージの使用よりもパフォーマンスの向上につながることを実証する。
論文 参考訳（メタデータ） (2022-11-11T16:37:33Z) - A ground-truth dataset and classification model for detecting bots in
GitHub issue and PR comments [70.1864008701113]
ボットはGithubリポジトリで、分散ソフトウェア開発プロセスの一部である反復的なアクティビティを自動化するために使用されている。
本稿では,5000のGithubアカウントのプルリクエストとコメント発行に関する,高い相互契約を伴う手動分析に基づいて,基幹トラスデータセットを提案する。
ボットを検出する自動分類モデルを提案し,各アカウントの空のコメント数と空でないコメント数,コメントパターンの数,コメントパターン内のコメント間の不平等を主特徴とする。
論文 参考訳（メタデータ） (2020-10-07T09:30:52Z) - TACRED Revisited: A Thorough Evaluation of the TACRED Relation
Extraction Task [80.38130122127882]
TACREDはリレーショナル抽出(RE)において最も大きく、最も広く使われているクラウドソースデータセットの1つである
パフォーマンスの天井に到達したのか、改善の余地はあるのか?
ラベルエラーは絶対F1テストエラーの8%を占めており、例の50%以上を可逆化する必要がある。
論文 参考訳（メタデータ） (2020-04-30T15:07:37Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。