論文の概要: Detecting Build Dependency Errors in Incremental Builds

• arxiv url: http://arxiv.org/abs/2404.13295v2
• Date: Fri, 26 Apr 2024 02:03:41 GMT
• ステータス: 翻訳完了
• システム内更新日: 2024-04-29 15:13:44.251787
• Title: Detecting Build Dependency Errors in Incremental Builds
• Title（参考訳）: インクリメンタルビルドにおけるビルド依存性エラーの検出
• Authors: Jun Lyu, Shanshan Li, He Zhang, Yang Zhang, Guoping Rong, Manuel Rigger,
• Abstract要約: インクリメンタルビルドのコンテキストにおいて、ビルド依存性のエラーを検出するためにECheckerを提案する。 ECheckerは、C/C++プリプロセッサディレクティブと新しいコミットからのMakefile変更を推論することで、実際のビルド依存関係を自動的に更新する。 ECheckerはビルド依存性のエラー検出効率を平均85.14倍に向上させる。
• 参考スコア（独自算出の注目度）: 13.823208277774572
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Incremental and parallel builds performed by build tools such as Make are the heart of modern C/C++ software projects. Their correct and efficient execution depends on build scripts. However, build scripts are prone to errors. The most prevalent errors are missing dependencies (MDs) and redundant dependencies (RDs). The state-of-the-art methods for detecting these errors rely on clean builds (i.e., full builds of a subset of software configurations in a clean environment), which is costly and takes up to multiple hours for large-scale projects. To address these challenges, we propose a novel approach called EChecker to detect build dependency errors in the context of incremental builds. The core idea of EChecker is to automatically update actual build dependencies by inferring them from C/C++ pre-processor directives and Makefile changes from new commits, which avoids clean builds when possible. EChecker achieves higher efficiency than the methods that rely on clean builds while maintaining effectiveness. We selected 12 representative projects, with their sizes ranging from small to large, with 240 commits (20 commits for each project), based on which we evaluated the effectiveness and efficiency of EChecker. We compared the evaluation results with a state-of-the-art build dependency error detection tool. The evaluation shows that the F-1 score of EChecker improved by 0.18 over the state-of-the-art method. EChecker increases the build dependency error detection efficiency by an average of 85.14 times (with the median at 16.30 times). The results demonstrate that EChecker can support practitioners in detecting build dependency errors efficiently.
• Abstract（参考訳）: Makeのようなビルドツールによって実行される増分ビルドと並列ビルドは、現代のC/C++ソフトウェアプロジェクトの中心である。 それらの正しい効率的な実行は、ビルドスクリプトに依存する。 しかし、ビルドスクリプトはエラーを起こしやすい。 最も多いエラーは、依存性の欠如(MD)と冗長依存関係(RD)である。 これらのエラーを検出する最先端の手法は、クリーンなビルド(すなわち、クリーンな環境におけるソフトウェア構成のサブセットの完全なビルド)に依存している。 これらの課題に対処するため、インクリメンタルビルドのコンテキストにおいて、ビルド依存性エラーを検出するためのECheckerと呼ばれる新しいアプローチを提案する。 ECheckerの中核となる考え方は、C/C++プリプロセッサディレクティブとMakefileの変更を新しいコミットから推論することで、実際のビルド依存関係を自動的に更新することだ。 ECheckerは、効率を維持しながらクリーンビルドに依存する方法よりも高い効率を達成する。 私たちは、ECheckerの有効性と効率を評価するため、12の代表的なプロジェクトを選択しました。 評価結果を,最先端のビルド依存性検出ツールと比較した。 評価の結果,ECheckerのF-1スコアは最先端法に比べて0.18改善した。 ECheckerはビルド依存性のエラー検出効率を平均85.14倍に向上させる(中央値16.30倍)。 その結果、ECheckerは、ビルド依存性のエラーを効率的に検出する実践者をサポートすることができた。

関連論文リスト

• PhantomRun: Auto Repair of Compilation Errors in Embedded Open Source Software [2.64399132991614]
  プロジェクトのCI実行から4000以上のビルド障害にまたがる4つの主要なオープンソース組み込みシステムプロジェクトについて調査する。 ハードウェア依存関係がコンパイルエラーの大部分を占めており、その後に構文エラーやビルドスクリプトの問題が発生しています。 PhantomRunは、大規模な言語モデル(LLM)を活用してCIコンパイル障害の修正を生成し、検証する自動化フレームワークである。
  論文  参考訳（メタデータ） (2026-02-23T19:13:22Z)
• Outrunning LLM Cutoffs: A Live Kernel Crash Resolution Benchmark for All [57.23434868678603]
  Live-kBenchは、新たに発見されたカーネルバグのエージェントをスクラップし、評価するセルフ進化ベンチマークの評価フレームワークである。 kEnvは、カーネルのコンパイル、実行、フィードバックのためのエージェントに依存しないクラッシュ解決環境である。 kEnvを用いて3つの最先端エージェントをベンチマークし、最初の試行で74%のクラッシュを解決したことを示す。
  論文  参考訳（メタデータ） (2026-02-02T19:06:15Z)
• Understanding and Detecting Flaky Builds in GitHub Actions [6.3850400710838615]
  我々は,1,960のJavaプロジェクトからのデータの再実行に基づいて,GitHub Actionsにおけるフレキビルドに関する大規模な実証的研究を行った。 フレキなテスト、ネットワークの問題、依存関係の解決がもっとも多い15の異なる障害カテゴリを特定します。 本稿では,ジョブレベルでのフレキシブル障害検出のための機械学習に基づくアプローチを提案する。
  論文  参考訳（メタデータ） (2026-02-02T16:39:56Z)
• The Cost of Downgrading Build Systems: A Case Study of Kubernetes [9.25132407333504]
  アーティファクトベースのビルドツール(Bazel)から言語固有のソリューション(Go Build)に格下げしたプロジェクトについて研究する。 BazelのビルドはGo Buildよりも高速で、完全なビルドは23.06-38.66から75.19まで完了しています。 Bazelからのダウングレードは、CIリソースコストを最大76パーセント向上させる。
  論文  参考訳（メタデータ） (2025-10-22T21:40:23Z)
• Where LLM Agents Fail and How They can Learn From Failures [62.196870049524364]
  大規模言語モデル(LLM)エージェントは、複雑なマルチステップタスクの解決において有望であることを示す。 単一ルート原因エラーがその後の決定を通じて伝播する、障害のカスケードに対する脆弱性を増幅する。 現在のシステムは、モジュール的で体系的な方法でエージェントエラーを包括的に理解できるフレームワークを欠いている。 AgentErrorTaxonomyは、メモリ、リフレクション、計画、アクション、システムレベルの操作にまたがる障害モードのモジュール分類である。
  論文  参考訳（メタデータ） (2025-09-29T18:20:27Z)
• Alignment with Fill-In-the-Middle for Enhancing Code Generation [56.791415642365415]
  コードスニペットを小さな粒度のブロックに分割し,同じテストケースからより多様なDPOペアを生成する手法を提案する。 提案手法は,HumanEval (+), MBPP (+), APPS, LiveCodeBench, BigCodeBenchといったベンチマークデータセットの実験によって検証された,コード生成タスクの大幅な改善を示す。
  論文  参考訳（メタデータ） (2025-08-27T03:15:53Z)
• Improving Compiler Bug Isolation by Leveraging Large Language Models [14.679589768900621]
  本稿では,AutoCBIという新しいコンパイラバグ分離手法を提案する。 我々は、広く使われているGCCおよびLLVMコンパイラの120の現実世界バグに対して、最先端のアプローチ(DiWi、RecBi、FuseFL)に対してAutoCBIを評価した。 特に、GCC/LLVMの上位1位では、AutoCBIは66.67%/69.23%、300%/340%、100%/57.14%のバグをRecBi、DiWi、FuseFLより分離している。
  論文  参考訳（メタデータ） (2025-06-21T09:09:30Z)
• Attestable builds: compiling verifiable binaries on untrusted systems using trusted execution environments [3.207381224848367]
  attestableビルドは、ソフトウェアアーティファクトに強力なソース対バイナリ対応を提供する。 私たちは、ソースコードと最終バイナリアーティファクトの間の信頼を切断する不透明なビルドパイプラインの課題に取り組みます。
  論文  参考訳（メタデータ） (2025-05-05T10:00:04Z)
• CrashFixer: A crash resolution agent for the Linux kernel [58.152358195983155]
  この作業は、システムレベルのLinuxカーネルバグのベンチマークと、Linuxカーネルで実験を実行するプラットフォームを共有するkGymの上に構築されている。 CrashFixerはLinuxカーネルのバグに適応する最初のLCMベースのソフトウェア修復エージェントである。
  論文  参考訳（メタデータ） (2025-04-29T04:18:51Z)
• RAG-Based Fuzzing of Cross-Architecture Compilers [0.8302146576157498]
  OneAPIは、開発者による最小限の努力で、クロスアーキテクチャなソフトウェア開発をサポートするオープンスタンダードである。 OneAPIはDPC++とC++コンパイラを提供しており、その正確性、信頼性、セキュリティを検証するために徹底的にテストする必要がある。 本稿では,検索拡張生成(RAG)の概念を統合した大規模言語モデル (LLM) ベースのコンパイラファジィツールを提案する。
  論文  参考訳（メタデータ） (2025-04-11T20:46:52Z)
• CLOVER: A Test Case Generation Benchmark with Coverage, Long-Context, and Verification [71.34070740261072]
  本稿では,テストケースの生成と完成におけるモデルの能力を評価するためのベンチマークCLOVERを提案する。 ベンチマークはタスク間でのコード実行のためにコンテナ化されています。
  論文  参考訳（メタデータ） (2025-02-12T21:42:56Z)
• Finding Missed Code Size Optimizations in Compilers using LLMs [1.90019787465083]
  我々は,大規模言語モデルと一連の差分テスト戦略を組み合わせた新しいテスト手法を開発した。 当社のアプローチでは,実装に150行未満のコードが必要です。 現在までに、本番コンパイラの24のバグが報告されている。
  論文  参考訳（メタデータ） (2024-12-31T21:47:46Z)
• Commit0: Library Generation from Scratch [77.38414688148006]
  Commit0は、AIエージェントにスクラッチからライブラリを書くよう促すベンチマークである。 エージェントには、ライブラリのAPIを概説する仕様文書と、インタラクティブなユニットテストスイートが提供されている。 Commit0はまた、モデルが生成したコードに対して静的解析と実行フィードバックを受け取る、インタラクティブな環境も提供する。
  論文  参考訳（メタデータ） (2024-12-02T18:11:30Z)
• Local Software Buildability across Java Versions (Registered Report) [0.0]
  Javaのバージョン6から23をインストールしたコンテナで、すべてのプロジェクトを自動ビルドしようとします。 成功または失敗は終了コードによって決定され、標準出力とエラーストリームは保存される。
  論文  参考訳（メタデータ） (2024-08-21T11:51:00Z)
• KGym: A Platform and Dataset to Benchmark Large Language Models on Linux Kernel Crash Resolution [59.20933707301566]
  大規模言語モデル(LLM)は、ますます現実的なソフトウェア工学(SE)タスクにおいて一貫して改善されている。 現実世界のソフトウェアスタックでは、Linuxカーネルのような基本的なシステムソフトウェアの開発にSEの取り組みが費やされています。 このような大規模システムレベルのソフトウェアを開発する際にMLモデルが有用かどうかを評価するため、kGymとkBenchを紹介する。
  論文  参考訳（メタデータ） (2024-07-02T21:44:22Z)
• Does Using Bazel Help Speed Up Continuous Integration Builds? [9.098224117917336]
  Bazelのような新しいアーティファクトベースのビルド技術は、高度なパフォーマンス最適化をサポートする。 GitHubから383のBazelプロジェクトを収集し、人気の高い4つのCIサービスでBazelの並列およびインクリメンタルビルド使用状況を調査し、結果をMavenプロジェクトと比較しました。 私たちの結果は、Bazelプロジェクトの31.23%がCIサービスを採用しているが、CIサービスには使用していないことを示している。
  論文  参考訳（メタデータ） (2024-05-01T18:16:38Z)
• Automatic Build Repair for Test Cases using Incompatible Java Versions [7.4881561767138365]
  依存性の最小化を行うことで、Javaプロジェクトのテストケースを修復するアプローチを導入します。 既存の最先端技術とは異なり、我々の手法はソースレベルで動作し、コンパイル時のエラーを修正できる。
  論文  参考訳（メタデータ） (2024-04-27T07:55:52Z)
• 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)
• Repeated Builds During Code Review: An Empirical Study of the OpenStack Community [11.289146650622662]
  コミュニティから66,932のコードレビューの実証的研究を行った。 i)コードレビューの55%はビルド失敗後にリチェックコマンドを起動し、(ii)リチェックコマンドの呼び出しはビルド失敗の結果を42%のケースでのみ変更し、(iii)リチェックコマンドの呼び出しは平均2200%のレビュー待ち時間を増大させる。
  論文  参考訳（メタデータ） (2023-08-19T17:45:03Z)
• On the Security Blind Spots of Software Composition Analysis [46.1389163921338]
  Mavenリポジトリで脆弱性のあるクローンを検出するための新しいアプローチを提案する。 Maven Centralから53万以上の潜在的な脆弱性のあるクローンを検索します。 検出された727個の脆弱なクローンを検出し、それぞれに検証可能な脆弱性証明プロジェクトを合成する。
  論文  参考訳（メタデータ） (2023-06-08T20:14:46Z)
• A Static Evaluation of Code Completion by Large Language Models [65.18008807383816]
  単純なプログラミング問題に対するモデル生成コードの機能的正当性を評価するために,実行ベースベンチマークが提案されている。 プログラムを実行せずにエラーを検出するlinterのような静的解析ツールは、コード生成モデルを評価するために十分に研究されていない。 抽象構文木を利用して,Pythonのコード補完における静的エラーを定量化する静的評価フレームワークを提案する。
  論文  参考訳（メタデータ） (2023-06-05T19:23:34Z)
• Teaching Large Language Models to Self-Debug [62.424077000154945]
  大規模言語モデル(LLM)は、コード生成において素晴らしいパフォーマンスを達成した。 本稿では,大規模言語モデルで予測プログラムを数発のデモでデバッグする自己デバッグを提案する。
  論文  参考訳（メタデータ） (2023-04-11T10:43:43Z)
• Generating Bug-Fixes Using Pretrained Transformers [11.012132897417592]
  実世界のgithubからマイニングしたjavaメソッドのバグの検出と修正を学ぶ,データ駆動型プログラム修復手法を導入する。 ソースコードプログラムの事前トレーニングは,スクラッチからの教師ありトレーニングに比べて,33%のパッチ数を改善することを示す。 我々は,標準精度評価基準を非削除および削除のみの修正に洗練し,我々の最良モデルが従来よりも75%多くの非削除修正を生成することを示す。
  論文  参考訳（メタデータ） (2021-04-16T05:27:04Z)
• D2A: A Dataset Built for AI-Based Vulnerability Detection Methods Using Differential Analysis [55.15995704119158]
  静的解析ツールによって報告されたラベル問題に対する差分解析に基づくアプローチであるD2Aを提案する。 D2Aを使用して大きなラベル付きデータセットを生成し、脆弱性識別のためのモデルをトレーニングします。
  論文  参考訳（メタデータ） (2021-02-16T07:46:53Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。