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

S>Возможно, вы пользуетесь какой-то сторонней либой, которая берет на себя выдачу подобных стек-трейсов. Если это так, то вопросы нужно задавать по этой либе.

Я в первом же сообщении написал что использую llvm и при старте программы ставлю на обработчик сигналов выдачу трассы (там сразу готовая функция есть на это)

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

TB>Я в первом же сообщении написал что использую llvm и при старте программы ставлю на обработчик сигналов выдачу трассы (там сразу готовая функция есть на это)

Сорри, я не понял, что под "фреймворком" подразумевался LLVM. Виноват, был невнимателен.

Может быть можно сравнить что изменилось в новых реализациях stdlib и LLVM по сравнению со старыми? Т.е. если std::async сейчас ведет себя по новому, то можно глянуть как он вел себя раньше. А уже исходя из этой разницы искать решение.

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

S>Может быть можно сравнить что изменилось в новых реализациях stdlib и LLVM по сравнению со старыми? Т.е. если std::async сейчас ведет себя по новому, то можно глянуть как он вел себя раньше. А уже исходя из этой разницы искать решение.

Вот откатываться на прошлые версии не хотелось бы: сборка занимает пол дня
Подозреваю что llvm::ThreadPool раньше использовал std::thread, а в новой версии std::async
Велосипедить свой тредпул — это насколько адекватно?

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

TB>Вот откатываться на прошлые версии не хотелось бы: сборка занимает пол дня

Я не про откат говорил, а про то, чтобы сравнить и уже потом искать пути решения.

TB>Подозреваю что llvm::ThreadPool раньше использовал std::thread, а в новой версии std::async

Вроде бы так оно и есть.
Подозреваю, что раньше llvm::ThreadPool сам мандрячил комбинацию из Promise/Future и сам с ними колупался.

Теперь же он формирует Task посредством std::async. И, полагаю, уже в потрохах этого таска идет обработка выброшенного исключения.

TB>Велосипедить свой тредпул — это насколько адекватно?

Можно тупо клонировать имеющийся llvm::ThreadPool, но в клонированном интерфейсе ThreadPoolInterface заменить реализацию asyncImpl.

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

TB>Как сделать чтоб "было как раньше"? Чтоб исключение в другом потоке сразу вызывало падение с правильной трассой.
Нашлось решение?
Ваша проблема с фреймворком звучит похоже на проблему, которую я недавно решал. Проблема была вызванна статической линковкой libstdc++ в динамической библиотеке и использованием std::future/std::async.

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

TB>Линкер не дает, говорит что __cxa_throw уже определена в libstd++.a(eh_throw.o)
Статическая линкова к с libstd++ может быть проблематичной.
Посмотрите как символы разрешаются в рантайме и смотрите что-то связанное с _Prepare_execution:

LD_DEBUG=symbols <ваше приложение> ... 2>&1 | grep "_Prepare_execution"

Например, вот этот код в libstdc++ плохо дружит со статитческой линковкой: во время выполнения код может переключачться между разными бинарями/контекстами, и использовать разные __once_callable, инициализация может произойти в одном, а использование — в другом. Вот эта лямда может появиться в разных бинарях. nm/objdum/readelf в помощь.

Вот простейший пример для воспроизведения проблемы:

// libfoo.cpp
#include <future>
void foo()
{
    auto m_result = std::async(std::launch::async, [](){});

}

g++ -fPIC -static-libstdc++ -shared libfoo.cpp -o libfoo.so -Wl,--exclude-libs,ALL -pthread

// main.cpp

#include <future>

extern void foo();

int main()
{
    auto m_result = std::async(std::launch::async, [](){});
    foo();
}

g++ main.cpp -L. -lfoo -Wl,-rpath=. -pthread -O2
./a.out
Segmentation fault (core dumped)
gcc --version
gcc (Ubuntu 11.4.0-2ubuntu1~18.04) 11.4.0

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

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

TB>>Как сделать чтоб "было как раньше"? Чтоб исключение в другом потоке сразу вызывало падение с правильной трассой.
S>Нашлось решение?
S>Ваша проблема с фреймворком звучит похоже на проблему, которую я недавно решал. Проблема была вызванна статической линковкой libstdc++ в динамической библиотеке и использованием std::future/std::async.

Да, навелосипедил новый тредпул, 50 строк кода
А причина была в том что обновившийся фреймворк использовать std::async а раньше использовал std::thread

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

TB>Да, навелосипедил новый тредпул, 50 строк кода
TB>А причина была в том что обновившийся фреймворк использовать std::async а раньше использовал std::thread
Понятно. Скорее всего эта проблема которую я более подробно описал в другом ответе

Автор: Skorodum
Дата: 24.11 12:30

.
У нас тоже одним из возможных решений было переписать код с std::future на std::thread, т.к. оно проблему решало. Но это пока не поняли что там на самом деле происходит. Если вы линкуете libstdc++ статически в динамическую библиотеку, то подобные проблемы могут вылезти в другом месте. Нам разработчик GCC на днях прямо ответил так не делать.