Здравствуйте, Mazay, Вы писали:

M>Так что бы бряк поставить надо в дебагере запускаться. Тогда проблем нет. А хочется иметь возможность анализировать крэш-дамп.
тогда так: создавай .so библиотеку экспортирующую __cxa_allocate_exception() функцию, и в этой функции зови std::abort(), или что душе угодно. подгружать при помощи: LD_PRELOAD=mydll.so ./myapp

Здравствуйте, Mazay, Вы писали:

M>Это не поможет, потому что в библиотечном коде стэк от моей функции до обработчика уже раскручен.
да, стек уже потерян...

ставь бряк на __cxa_allocate_exception()/__cxa_throw()/__cxa_free_exception().

ну и почитай: https://habrahabr.ru/post/279111/

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Mazay, Вы писали:

M>>Так что бы бряк поставить надо в дебагере запускаться. Тогда проблем нет. А хочется иметь возможность анализировать крэш-дамп.
X>тогда так: создавай .so библиотеку экспортирующую __cxa_allocate_exception() функцию, и в этой функции зови std::abort(), или что душе угодно. подгружать при помощи: LD_PRELOAD=mydll.so ./myapp


Дааа! Именно то, что надо!
Для всех интересующихся:
What is the LD_PRELOAD trick?
How to wrap a system call (libc function) in Linux


Ещё ссылка по теме — обсуждение схожей проблемы в трекере GCC: Impossible to find/debug unhandled exceptions in an std::thread. Там они после 4-х лет обсуждений таки решили отключить обработку исключений и позволить программе падать с дампом.

Можно ещё форкнуть boost.python и убрать там заглушку.

Здравствуйте, Mazay, Вы писали:

Здравствуйте, Mazay, Вы писали:

M>Есть моя функция, которая может бросать исключения.
M>Есть библиотечный код, который эту функцию вызывает.
M>Библиотечный код заворачивает вызов моей функции в try/catch и обрабатывает исключения неким своим образом, который мне не нравится.
M>Я хочу, чтобы программа просто падала при вылете исключений — хочу видеть дамп ядра.

Всё, что тебе надо было сделать -- запустить отлдадчик, и сказать "Break on exceptions".
Всё, что надо было сделать авторам тех библиотек, что ты использовал, снабдить
все throw перед ними ASSERT-ами.

Есть моя функция, которая может бросать исключения.
Есть библиотечный код, который эту функцию вызывает.
Библиотечный код заворачивает вызов моей функции в try/catch и обрабатывает исключения неким своим образом, который мне не нравится.
Я хочу, чтобы программа просто падала при вылете исключений — хочу видеть дамп ядра. Но из-за библиотечного перехватчика стэк раскручивается и я не вижу откуда именно в моей функции вылетело исключение.
Можно ли как-то обмануть рантайм и отключить перехватчик, устанавливаемый библиотекой?
Можно хакерское решение, можно только для Линукса.

в библиотечном коде сделать re-throw после библиотечного обработчика?

вообще, это проблема библиотеки. плохо, брать на себя заботу о том, знаниями о чем не владеешь...

Здравствуйте, niXman, Вы писали:

X>в библиотечном коде сделать re-throw после библиотечного обработчика?

Это не поможет, потому что в библиотечном коде стэк от моей функции до обработчика уже раскручен.

X>вообще, это проблема библиотеки. плохо, брать на себя заботу о том, знаниями о чем не владеешь...
Да. Это Boost::Python. Решу проблему — напишу им гневное письмо.

Здравствуйте, Mazay, Вы писали:

M>Есть моя функция, которая может бросать исключения.
M>Есть библиотечный код, который эту функцию вызывает.
M>Библиотечный код заворачивает вызов моей функции в try/catch и обрабатывает исключения неким своим образом, который мне не нравится.
M>Я хочу, чтобы программа просто падала при вылете исключений — хочу видеть дамп ядра. Но из-за библиотечного перехватчика стэк раскручивается и я не вижу откуда именно в моей функции вылетело исключение.
M>Можно ли как-то обмануть рантайм и отключить перехватчик, устанавливаемый библиотекой?
M>Можно хакерское решение, можно только для Линукса.


вместо(е) кидания исключения в fork-у делать SIGABRT как сказано здесь не пойдет?

Здравствуйте, niXman, Вы писали:


M>>Это не поможет, потому что в библиотечном коде стэк от моей функции до обработчика уже раскручен.
X>да, стек уже потерян...

X>ставь бряк на __cxa_allocate_exception()/__cxa_throw()/__cxa_free_exception().

Так что бы бряк поставить надо в дебагере запускаться. Тогда проблем нет. А хочется иметь возможность анализировать крэш-дамп.

X>ну и почитай: https://habrahabr.ru/post/279111/

Спасибо

Здравствуйте, rumit7, Вы писали:


R>вместо(е) кидания исключения в fork-у делать SIGABRT как сказано здесь не пойдет?

Нет. Код кидания исключения тоже не мой — исключения летят из стандартной библиотеки.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, rumit7, Вы писали:


R>>вместо(е) кидания исключения в fork-у делать SIGABRT как сказано здесь не пойдет?

M>Нет. Код кидания исключения тоже не мой — исключения летят из стандартной библиотеки.

самому врапнуть в try/catch потроха своей функции тоже не?

Перехватить все исключения и сделать SIGABRT в перехватчике.

Здравствуйте, rumit7, Вы писали:


R>>>вместо(е) кидания исключения в fork-у делать SIGABRT как сказано здесь не пойдет?

M>>Нет. Код кидания исключения тоже не мой — исключения летят из стандартной библиотеки.

R>самому врапнуть в try/catch потроха своей функции тоже не?

В моём блоке catch тоже уже будет раскручен стэк.

Здравствуйте, Vamp, Вы писали:

V>Перехватить все исключения и сделать SIGABRT в перехватчике.

Если перехватывать исключения с помощью try-catch, то на момент перехвата стэк уже раскручен, информация о точке вызова первого throw потеряна.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, Vamp, Вы писали:

V>>Перехватить все исключения и сделать SIGABRT в перехватчике.

M>Если перехватывать исключения с помощью try-catch, то на момент перехвата стэк уже раскручен, информация о точке вызова первого throw потеряна.

Компилируй с -fno-exceptions

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, rumit7, Вы писали:


R>>>>вместо(е) кидания исключения в fork-у делать SIGABRT как сказано здесь не пойдет?

M>>>Нет. Код кидания исключения тоже не мой — исключения летят из стандартной библиотеки.

R>>самому врапнуть в try/catch потроха своей функции тоже не?

M>В моём блоке catch тоже уже будет раскручен стэк.

почему? вы же его перехватите до boost::Python-а

Здравствуйте, Vamp, Вы писали:

V>Здравствуйте, Mazay, Вы писали:

M>>Здравствуйте, Vamp, Вы писали:

V>>>Перехватить все исключения и сделать SIGABRT в перехватчике.

M>>Если перехватывать исключения с помощью try-catch, то на момент перехвата стэк уже раскручен, информация о точке вызова первого throw потеряна.

V>Компилируй с -fno-exceptions

Не собирается из-за Boost.Python. Почему-то игнорируется флаг BOOST_NO_EXCEPTIONS.

А если объявить свою функцию noexcept?

Здравствуйте, rumit7, Вы писали:

R>>>>>вместо(е) кидания исключения в fork-у делать SIGABRT как сказано здесь не пойдет?

M>>>>Нет. Код кидания исключения тоже не мой — исключения летят из стандартной библиотеки.

R>>>самому врапнуть в try/catch потроха своей функции тоже не?

M>>В моём блоке catch тоже уже будет раскручен стэк.

R>почему? вы же его перехватите до boost::Python-а

Мне интересна именно та часть стэка, которая содержит вызовы потрохов моей функции — они уже будут раскручены.

Здравствуйте, Masterspline, Вы писали:

M>А если объявить свою функцию noexcept?

Тогда стэк-трэйс в дампе только до функции noexcept показывается. Это хорошая мысль. Я даже пробовал делать матрёшку из функций с noexcept и с noexcept(false). Всё равно показывает стэк только до первого вызова — дальше просто адреса без имён.

Здравствуйте, Mazay, Вы писали:

M>Ещё ссылка по теме — обсуждение схожей проблемы в трекере GCC: Impossible to find/debug unhandled exceptions in an std::thread. Там они после 4-х лет обсуждений таки решили отключить обработку исключений и позволить программе падать с дампом.

лучше поздно... =)

Можно в своей функции создать ScopeGuard, который в деструкторе сделает abort(), а при успешном выходе из функции отключать Guard. Возможно, стек трейс останется.

Здравствуйте, Masterspline, Вы писали:

M>Можно в своей функции создать ScopeGuard, который в деструкторе сделает abort(), а при успешном выходе из функции отключать Guard. Возможно, стек трейс останется.

можно через stack_unwinding

Здравствуйте, Mazay, Вы писали:

M>Можно ли как-то обмануть рантайм и отключить перехватчик, устанавливаемый библиотекой?

Можно объявить твою функцию небросающей (throw()) — но это, фактически, просто добавит в неё код вида

void foo() throw() {
  try {
  .....
  } catch(...) { terminate(); }
}

То есть, стек размотается, все деструкторы вызовутся, а уже потом программа рухнет.

Другой вариант — собрать твою библиотеку (содержащую твою функцию) с ключом -f-noexceptions
Тогда весь STL будет не throw делать, а тупо abort().

Третий вариант — хакнуть загрузчик, подменить на лету __cxa_throw(). И сделать там внутри что угодно, приводящее к крешдампу.
Как это технически сделать
https://habrahabr.ru/post/199090/
https://codedump.io/share/whtWHR3CJ5Sa/1/disabling-c-exceptions-how-can-i-make-any-std-throw-immediately-terminate

IMHO, обсуждение было бы более конструктивным, если бы был представлен пример, где-нибудь на ideone, например или другом онлайн компиляторе, который позволяет выполнять код.

Здравствуйте, Masterspline, Вы писали:

M>... который позволяет выполнять код.
+ собирать .so`шки и подсовывать их программе.

Здравствуйте, Mazay, Вы писали:

X>>тогда так: создавай .so библиотеку экспортирующую __cxa_allocate_exception() функцию, и в этой функции зови std::abort(), или что душе угодно. подгружать при помощи: LD_PRELOAD=mydll.so ./myapp
M>Дааа! Именно то, что надо!

Это работает, только если каждое исключение фатальное. А если нет?
А если нет, то лучше в этой библиотеке залогировать бэктрэйс в __cxa_throw или через __gxx_personality_v0 (?).

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Masterspline, Вы писали:

M>>... который позволяет выполнять код.
X>+ собирать .so`шки и подсовывать их программе.

Скорее всего, вот здесь получится так сделать.

Здравствуйте, Mazay, Вы писали:

M>Есть моя функция, которая может бросать исключения.
M>Есть библиотечный код, который эту функцию вызывает.
M>Библиотечный код заворачивает вызов моей функции в try/catch

перед инклюдом библиотеки сделай

#define try {}
#define catch(...) {} // только попробуйте уволить Mazay'я :)

отладка третьими лицами идёт накуй, но проблема решена дёшево и технично


А лучше — напрямую вставь в заголовочники библиотеки под ключ компиляции

#ifdef MY_DEBUG_MACRO_SUPER_PUPER_KEY
#  define try {}
#  define catch(...) {}
#endif

сам ключ передавай в параметрах командной строки. Тогда случайно эти строки не включатся.

Конечно, нужны исходники либы.

P.S. Отмаза. Естессно, это хакерское решение, костыль под краткосрочную задачу. В качестве постоянной или долговременной практики я такое категорически осуждаю