Uncaught exception in ‘boost/thread/lock_types.hpp’

オープン
#344 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
cpp
領域
backend

調査の方向性

boost/thread/lock_types.hpp の 632 行目付近から始め、shared_lock のデストラクタと mutex unlock_shared() の動作を調査してください。報告された Boost 1.75.0 と Coverity のコンテキストを使用して、関連する C++ 例外仕様の規則の下で例外経路に到達可能かどうかを確認してください。この issue では具体的な修正も受け入れテストも定義されていないため、完了には診断の確認と、合意された変更またはテストが必要です。

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

説明

Hi,
I've just run Coverity, version 2020.03, static analysis on a program using Boost v 1_75_0
It has highlighted several potential issues one of which I will describe here.

In lock_types.hpp on line 632 the destructor of the ‘shared_lock’ class calls the unlock_shared() method of the mutex. This method can throw an exception of type boost::lock_error. However, although the shared_lock destructor is not explicitly declared as ‘noexcept’ the compiler will use the exception specification from the hypothetical implicitly-generated destructor definition. This way it will deduce noexcept(true) for this destructor. Then if an exception is thrown from the destructor’s body this will result in calling unexpected() which calls terminate(). Synopsis Coverity static analysis tool highlighted this problem. In my opinion the described problem can happen. Do you think so or I am missing something?

Thanks,
Dimitar

主要言語
C++
スター
213
フォーク
171
PR マージ指標
30日以内にマージされた PR はありません

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

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

はじめの一歩

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

boostorg/thread のほかの issue

boostorg/thread の issue をすべて見る

似ている issue

C++ の issue をもっと見る

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

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