Boost.Python should not catch C++ exception allowing std::terminate call
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 30/100
Piste de recherche
Commencez par boost::python::handle_exception_impl() et make_holder::apply::execute, puis lisez la discussion de Boost.Python Reference sur la gestion des exceptions ainsi que le fil GCC associé. Déterminez si les blocs try-catch doivent être supprimés ou rendus configurables, et vérifiez que le comportement choisi préserve l’emplacement d’origine de l’exception pour l’analyse des core-dumps.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
All calls of C/C++ functions and methods are wrapped in Boost.Python internals by try-catch constructions. The specific code is in boost::python::handle_exception_impl() and in make_holder::apply::execute. There are good reasons to do it and they are described in the Reference. But due to handling of exceptions in Boost.Python internals core dumps are never created. Core dumps are generated only when unhandled exceptions are being thrown. handle_exception_impl() handles all stdlib exception and even all unknown exceptions (with catch(...) block ). Although it is possible to catch exceptions from C/C++ code by registering custom exception translators, it is impossible to get core dump for post-mortem analysis. The fundamental problem here is that at the moment when any exception handler is invoked (in exception translator or in custom catch(){} block ) the stack of calls is already unwinded and information about point of exception throwing is already lost. Even if the exception is just rethrown by the handler, and is not handled further, the call stack into the core dump will show the handler as a point of exception throwing, without information about original problem source.
I think that try-catch blocks in handle_exception_impl() and make_holder::apply::execute() should be removed. Alternatively, probably an option could be added to the def macros (the one nested in BOOST_PYTHON_MODULE() macros) that would control the strategy of exception handling. Anyway, current solution significantly complicates debugging of C/C++ modules and IMHO it should be fixed.
The similar problem was considered here: Impossible to find/debug unhandled exceptions in an std::thread
Finally they decided to "Remove try-block so that exceptions propagate out of the thread and terminate".
- Langage dominant
- C++
- Étoiles
- 537
- Forks
- 223
- Merge moyen
- 11 h 22 min
- PR mergées (30 j)
- 2
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de boostorg/python
-
numpy::from_data calls vector::front and crashes (or has UB) when called with a scalar object Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 84/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
-
BoostDetectToolset-1.90.0.cmake file not found in an include() call in boost_python-config.cmake Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 48/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
Toutes les issues de boostorg/python
Issues similaires
-
ai_reviewed
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
ydb-platform/ydb#53869 · 3 commentaires ·
-
bug cert blocker needs triage
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
project-chip/connectedhomeip#74373 ·
-
[request] tracy/0.14.1 Ouverteupstream update
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
documentation
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
vllm-project/vllm-ascend#17329 ·