Terminate called without an active exception

@squareroot · Регистрация: 19.10.2019

Студворк — интернет-сервис помощи студентам

При компиляции такого примера:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
class TestClass
{
public:
    TestClass()
    {
        auto func_ptr = &TestClass::Process;
        m_pthread = new std::thread(func_ptr, this);
    }
    ~TestClass() { delete m_pthread; }
private:
    void Process()
    {
          std::cerr << "run" <<  std::endl;
    }
    std::thread* m_pthread = nullptr;
};
 
int main(int argc, char *argv[])
{
    TestClass* ptc = new TestClass;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    delete ptc;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::cerr << "finished" << std::endl;
    return 0;
}

Возникает ошибка:

run
terminate called without an active exception
Press <RETURN> to close this window...

Т.е. текст finished даже не выводится.
Санитайзеры включены:
set (CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set (CMAKE_LINKER_FLAGS_DEBUG "${CMAKE_LINKER_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
Но без них врде тоже самое.
Что я делаю не так ?

@DrOffset · 13.01.2020, 09:58

squareroot, на самом деле мне кажется я выше дал ясно понять, что ни PTHREAD_CANCEL_ASYNCHRONOUS на общих основаниях, ни tgkill, ни TerminateThread - не являются теми решениями, которые можно назвать хорошими.
Т.е. еще более прямо, если вы будете их централизованно использовать - вы никогда не получите стабильное приложение. Особенно в С++.

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

Ваш код не работает скорее всего из-за того, что cancel в современном Linux реализуется через бросок исключения.

@squareroot · 13.01.2020, 14:33 **[ТС]**

Сообщение от DrOffset

squareroot, на самом деле мне кажется я выше дал ясно понять, что ни PTHREAD_CANCEL_ASYNCHRONOUS на общих основаниях, ни tgkill, ни TerminateThread - не являются теми решениями, которые можно назвать хорошими.

Хорошие или нехорошие это философский вопрос.
Решение должно решать поставленную задачу - завершать исполнение потока без завершения приложения.

Сообщение от DrOffset

PTHREAD_CANCEL_ASYNCHRONOUS из всего этого является самым мягким решением, потому что позволяет указать область, где прерывание в произвольном месте делать безопасно.
Ваш код не работает скорее всего из-за того, что cancel в современном Linux реализуется через бросок исключения.

В бусте тоже самое.
Как вы считаете, стоит попробовать вариант с tgkill или я могу столкнуться с анологичными побочными эффектами ?
И если стоит, то как его лучше реализовать ? Обязательно ли "пробрсывать" tid из нутри в наружу.

@DrOffset · 13.01.2020, 14:49

Сообщение от squareroot

Решение должно решать поставленную задачу - завершать исполнение потока без завершения приложения.

Оно не решает ее. Если вы водитель скорой и едете на красный, то вы не должны задевать пешеходов, даже если от этих секунд зависит жизнь пациента.

Единственный надежный вариант, при условии вероятности зависания - это отказаться от потоков.

Сообщение от squareroot

Как вы считаете, стоит попробовать вариант с tgkill или я могу столкнуться с анологичными побочными эффектами ?

С такими скорее всего не столкнетесь, столкнетесь с другими, о которых шла речь выше.

Добавлено через 6 минут

Сообщение от squareroot

Обязательно ли "пробрсывать" tid из нутри в наружу.

Да, придется пробрасывать.

@squareroot · 13.01.2020, 15:36 **[ТС]**

Сообщение от DrOffset

Оно не решает ее. Если вы водитель скорой и едете на красный, то вы не должны задевать пешеходов, даже если от этих секунд зависит жизнь пациента.

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

Сообщение от DrOffset

Единственный надежный вариант, при условии вероятности зависания - это отказаться от потоков.

Это вопрос архиектуры конкретного приложенияю Я тут решаю задачу создания элемента своего маленького SDK

Сообщение от DrOffset

С такими скорее всего не столкнетесь, столкнетесь с другими, о которых шла речь выше.

Ну то что может быть утечка ресурсов, это к гадалки не ходи.

Сообщение от DrOffset

Да, придется пробрасывать.

Жалко. Ну пусть так.

Добавлено через 17 минут
DrOffset, Я больше склоняюсь к варианту с tgkill, чем к pthread_cancel потомучто если выдвигать требования к процедуре потока, либо не аллоцировать ресурсы динамически, либо не использовать обработчики исключений, то первый вариант создаёт меньше проблем при разработке процедуры потока. Вы так не считаете ? Все необходимые ресурсы можно выделить заранее или вести их учёт из основного потока.

Добавлено через 11 минут
И ещё непонятно, tgkill, оно вроде не посиксовый. POSIX не даёт инструментов уничтожения потока ?

Добавлено через 3 минуты
Если дело обстоит именно так, то pthread_cancel можно оставить в качестве говядины второй свежести для нелинуксовых посикс систем.

@DrOffset · 13.01.2020, 17:33

Сообщение от squareroot

POSIX не даёт инструментов уничтожения потока ?

pthread_kill можно использовать, но его надо "готовить".

Добавлено через 45 секунд

Сообщение от squareroot

И ещё непонятно, tgkill, оно вроде не посиксовый.

Linux-specific

Добавлено через 1 минуту

Сообщение от squareroot

Я тут решаю задачу создания элемента своего маленького SDK

Я думаю вас должен был насторожить тот факт, что подобного библиотечного решения еще никто не сделал. Наверное ведь это неспроста?

Добавлено через 6 минут

Сообщение от squareroot

Ну то что может быть утечка ресурсов, это к гадалки не ходи.

Не только утечка, например, если у вас для общения с потоком используется mutex и прерывание произошло во время работы одной из его функций, то сам объект mutex может остаться в недетерминированном состоянии. Любые попытки обращения к нему впоследствии могут закончиться плохо. Т.е. все ресурсы, которые имеют состояние и расшарены с этим потоком остаются в неизвестном состоянии, в корректном или нет - вам снаружи будет неясно. Программа в состоянии UB, вы, по-хорошему, ничего сделать уже не можете, кроме как завершить весь процесс. Но даже это уже будет потенциальной ошибкой, деструкторы объектов в неизвестном состоянии могут оказаться не готовы к этому. В итоге, например, просто получите SEGFAULT при завершении.
С конкретно мьютексом все еще проще, он может остаться в нормальном, но залоченном состоянии. Но снаружи вы никак об этом не узнаете. По большом счету вы даже разлочить его не сможете, потому что делать это должен тот же поток, который вызывал lock. А потока этого уже нет.

Добавлено через 3 минуты
Самое страшное во всем этом: вы можете долгое время не видеть ошибки вообще. Т.е. все как-то так будет складываться, что сброс потока не будет иметь последствий. Это ни что иное, как мина замедленного действия, старательно заложенная вами самим.

@squareroot · 13.01.2020, 17:39 **[ТС]**

Сообщение от DrOffset

Самое страшное во всем этом: вы можете долгое время не видеть ошибки вообще. Т.е. все как-то так будет складываться, что сброс потока не будет иметь последствий. Это ни что иное, как мина замедленного действия, старательно заложенная вами самим.

Что всё так ужасно ???

А кто нам мешаем "запилить" обработчик сигнала SGKILL для потока в качестве сапёра?

@DrOffset · 13.01.2020, 17:44

Сообщение от squareroot

А кто нам мешаем "запилить" обработчик сигнала SGKILL для потока в качестве сапёра?

Запилить вы сможете, и даже что-то сделать из него, но далеко не все. Контекст-то выполнения вы откуда возьмете?
Например у вас в потоке вот такая функция выполняется, где-нибудь в цикле:

C++
1
2
3
4
5
6
7
//...............
 
    m_mutex.lock()
    m_queue.push(....);
    m_mutex.unlock();
 
   ///..............

Допустим убили поток на push. Как ваш обработчик узнает, что надо сделать unlock (даже если бы он имел право его делать)?

@squareroot · 13.01.2020, 17:55 **[ТС]**

Сообщение от DrOffset

Запилить вы сможете, и даже что-то сделать из него, но далеко не все. Контекст-то выполнения вы откуда возьмете?
Например у вас в потоке вот такая функция выполняется, где-нибудь в цикле:

C++
1
2
3
4
5
6
7
//...............
 
    m_mutex.lock()
    m_queue.push(....);
    m_mutex.unlock();
 
   ///..............

Допустим убили поток на push. Как ваш обработчик узнает, что надо сделать unlock (даже если бы он имел право его делать)?

Обработчику не надо ничего знать и сам он вещь опциональная и нужен для тех случаев когда обрётка для потока представлена в виде либы с закрытым кодом или никакой другой поток не мониторит ситуацию аварийного завершения. В остальных случаях можно ввести статический флаг ошибки завершения одного или нескольких потоков (что уже и сделано).
Как разруливать ситуацию и в каком потоке определяется спецификой конкретного приложения. Задача обёртки - проинформировать.
Но если никто не мониторит ситуацию аварийного завершения потока, значит заблоченный мьютекс при принудительном завершении потока разработчика конечного приложения не волнует.

@DrOffset · 13.01.2020, 17:58

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

В этом обработчике не будет никакой возможности узнать, где именно прервали поток

C++
1
2
3
4
5
    // здесь
    m_mutex.lock(); // здесь
    m_queue.push(....); // здесь
    m_mutex.unlock(); // здесь
    // или здесь

@squareroot · 13.01.2020, 18:04 **[ТС]**

Сообщение от DrOffset

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

В этом обработчике не будет никакой возможности узнать, где именно прервали поток

C++
1
2
3
4
5
    // здесь
    m_mutex.lock(); // здесь
    m_queue.push(....); // здесь
    m_mutex.unlock(); // здесь
    // или здесь

для этого есть try_lock
ну tid убитого потока можно сохранять.

@DrOffset · 13.01.2020, 18:12

Сообщение от squareroot

для этого есть try_lock

Для чего?

Ну не пишите уж откровенные-то глупости.
Допустим try_lock - он работает, потому что мьютекс в коректном залоченном состоянии. Дальше что? Он будет долбиться в него бесконечно, потом unlock имеет право делать только поток, вызвавший lock.
Я уж не говорю, про неизвестное, "промежуточное" состояние, когда поток прервали посреди работы функции lock.

Вот цитаты из документации

Кликните здесь для просмотра всего текста

TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems:

If the target thread owns a critical section, the critical section will not be released.
If the target thread is allocating memory from the heap, the heap lock will not be released.
If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.

Кликните здесь для просмотра всего текста

Since the thread could be canceled at any time, it
cannot safely reserve resources (e.g., allocating memory with
malloc(3)), acquire mutexes, semaphores, or locks, and so on.
Reserving resources is unsafe because the application has no way of
knowing what the state of these resources is when the thread is
canceled; that is, did cancellation occur before the resources were
reserved, while they were reserved, or after they were released?
Furthermore, some internal data structures (e.g., the linked list of
free blocks managed by the malloc(3) family of functions) may be left
in an inconsistent state if cancellation occurs in the middle of the
function call.

Это пустой звук для вас?

@squareroot · 13.01.2020, 18:15 **[ТС]**

DrOffset, вообще говоря наиболее ожидаемое поведение при принудительном завершении потока это завершение приложения, но не аварийное завершение как в случае pthread_cancel и catch(...) {} а нормальное, с сохранием в логах ошибки из-за которой завершается приложение. Но наверно есть способ справится с залоченным мьютексом системными средствами, если разработчик конечного приложения сделает восстановления после сбоя без завершения приложения.

@DrOffset · 13.01.2020, 18:22

Сообщение от squareroot

Но наверно есть способ справится с залоченным мьютексом системными средствами, если разработчик конечного приложения сделает восстановления после сбоя без завершения приложения.

Это же только пример. На нем не заканчиваются проблемы.
Таких ситуаций множество, некоторые можно решить, некоторые нет.
Самое страшное, что неизвестно как решать. Было бы гораздо проще, если бы программа точно знала что она делала до завершения. Но знать это нельзя в общем случае, о чем красноречиво пишут в документации.

@squareroot · 13.01.2020, 18:46 **[ТС]**

Сообщение от DrOffset

Это же только пример. На нем не заканчиваются проблемы.
Таких ситуаций множество, некоторые можно решить, некоторые нет.

Мне кажется вы драматизируете ситуацию. Если Разработчик решится на такой геройский поступок как восстановление после сбоя без завершения, то он вместо объектов ядра может использовать чтото своё, например спинлоки. Тут нет непреодолимых трудностей.

Сообщение от DrOffset

Это же только пример. На нем не заканчиваются проблемы.
Самое страшное, что неизвестно как решать. Было бы гораздо проще, если бы программа точно знала что она делала до завершения. Но знать это нельзя в общем случае, о чем красноречиво пишут в документации.

Это документация по использованию системных ресурсов, а не по c++. Кому надо найдут альтернативные ресурсы.
Даже если допустим поток испльзует сокет и он останется в неизвестном состоянии после завершения потока. Всегда можно спросить файловые хендлы у ОС для данного процесса и по тихому закрыть, те что стали "зомби."

@DrOffset · 13.01.2020, 19:18

Сообщение от squareroot

Мне кажется вы драматизируете ситуацию.

Мне это как раз позволительно.
А вот вам, раз уж вы пишете SDK - не позволительно слишком оптимистично к этому относиться. Так что смотрите.

Добавлено через 17 минут

Сообщение от squareroot

Кому надо найдут альтернативные ресурсы.

А смысл тогда это все делать, если ваше решение не предоставляет никаких гарантий? В смысле зачем нужна ваша абстракция над системным API, если она все равно вынуждает пользователя знать ее внутренности, чтобы потом корректно избегать проблем? Вы заявляете о возможности сбросить поток, но это в обычном многопоточном приложении не нужно вообще, а в необычном - дешевле и безопаснее использовать процессы, как и поступают все взрослые приложения. Зачем тогда нужна ваша абстракция, если она не решает проблем пользователя?

Вообще говоря, я уже проходил ваш путь (только без помощи форумов). Т.е. я исследовал возможности построить стабильную систему с произвольным кодом внутри потоков, с возможностью остановки потоков в случае проблем. Так вот, со всей ответственностью заявляю: в построить такую систему на потоках - нельзя. В частном случае - можно. В общем - нельзя.

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

@squareroot · 13.01.2020, 19:40 **[ТС]**

DrOffset, У меня щас недостаточно знаний и опыта чтобы сделать грамотно на уровне процессов, а халтуру делать нехочу и не хочется на этом сильтно зацикливоться.
Завершение потока у меня не получается:

C++
1
2
        auto tgid = getpid();
        auto ret = syscall(SYS_tgkill, tgid, m_tid, SIGKILL );

Завершается процесс, а не приложении.
В документации сказано:
http://man7.org/linux/man-page... ill.3.html

Signal dispositions are process-wide: if a signal handler is
installed, the handler will be invoked in the thread thread, but if
the disposition of the signal is "stop", "continue", or "terminate",
this action will affect the whole process.

Ну и как тогда завершить отдельный поток ?

Добавлено через 9 минут
Завершается процесс, а не поток.

@DrOffset · 13.01.2020, 20:50

<в примере ошибка, поторопился>

Добавлено через 35 минут

Сообщение от squareroot

Ну и как тогда завершить отдельный поток ?

Никак. Не смотря на то, что в документации tgkill об этом явно не сказано, эффект от сигнала распространяется на весь процесс, даже если сигнал был отправлен отдельному потоку (поток в этом случае его может получить через sigwaitinfo).

@squareroot · 13.01.2020, 23:18 **[ТС]**

Сообщение от DrOffset

<в примере ошибка, поторопился>

Добавлено через 35 минут

Никак. Не смотря на то, что в документации tgkill об этом явно не сказано, эффект от сигнала распространяется на весь процесс, даже если сигнал был отправлен отдельному потоку (поток в этом случае его может получить через sigwaitinfo).

А если я форкнусь, то новый процесс создасться вместе в отсоединёнными потоками ?

Добавлено через 45 минут
А впрочем я нашёл ответ, что после форка, только один поток остаётся в новом процессе. Выходит поток убить можно через процесс клонирование процесса

@DrOffset · 13.01.2020, 23:20

Сообщение от squareroot

А если я форкнусь, то новый процесс создасться вместе в отсоединёнными потоками ?

В POSIX - нет.

Для того, чтобы продублировать все потоки есть системный вызов forkall, но я его встречал только в Solaris.

@squareroot · 14.01.2020, 01:15 **[ТС]**

DrOffset, А покакой причине санитайзер после форка детектирует утечку памяти ?

C++
1
2
3
        auto ret = fork();
        errspace::show_errmsg(std::to_string(ret).c_str());
        if (ret != 0) abort();

======================================== =========================
==11061==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7f40b4775458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
#1 0x55ba02741757 in std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> > std::thread::_S_make_state<std::thread:: _Invoker<std::tuple<void (ThreadFeatures<void (TTestBench::*)(), TTestBench>::*)(void (TTestBench::*)(), TTestBench*), ThreadFeatures<void (TTestBench::*)(), TTestBench>*, void (TTestBench::*)(), TTestBench*> > >(std::thread::_Invoker<std::tuple<voi d (ThreadFeatures<void (TTestBench::*)(), TTestBench>::*)(void (TTestBench::*)(), TTestBench*), ThreadFeatures<void (TTestBench::*)(), TTestBench>*, void (TTestBench::*)(), TTestBench*> >&&) /usr/include/c++/7/thread:197

Добавлено через 4 минуты
Если форк не делать, то санитайзер утечку не фиксирует.

Новые блоги и статьи Все статьи Все блоги /
Многофункциональное здание: как одно здание порождает конфликты требований, которые никто не планировал (мат мет мод 29) anaschu 23.06.2026 Многофункциональное здание: как одно здание порождает конфликты требований, которые никто не планировал Материалы для обсуждения с МГСУ · 2026 Рисунки внутри приложенного ворд файла. Что за. . .	28. Конкретное развертывание плана номер 1 из поста номер 27 anaschu 22.06.2026 Можно ли из модели получить конкретные строительные требования? Честно — напрямую из текущей модели такие ответы не получить. Но цепочка логики есть, и она не такая длинная. Где разрыв . . .	27. Планы на разработку функциональных требований к строительству внутри модели пищеблока (или не только его?) anaschu 22.06.2026 Что уже реализовано и даёт конфликты «бесплатно» Самый простой конфликт уже работает — конфликт за ресурс-работника. Заданий больше, чем доступных поваров → очередь в queue1. Это прямое отражение. . .	26. мед мат модель.Какие типы конфликтов функциональных требований можно рассчитать через ДЕС-моделирование (СМО) в AnyLogic? anaschu 22.06.2026 Что ДЕС/ СМО умеет считать напрямую: Конфликты за ресурсы (очереди, узкие места). Несколько типов агентов (повара, учителя, рабочие, пациенты) претендуют на один ресурс (лифт, вход, коридор,. . .
25 модель здравосохранения и функциональных требований к пищеблоку: конфликты функциональных требований. anaschu 22.06.2026 Есть ли данные о том, какие функциональные/ эксплуатационные требования или их сочетания труднее всего учитывать при проектировании зданий? Да, такие данные есть, и они хорошо описаны и в российской,. . .	Remote Connection Manager DevAlt 21.06.2026 Написал для себя небольшую прилагу: https:/ / github. com/ altbodhi/ ReConMan По итогу пришел к мысли, что DU не дружат с существующими технологиями. От сериализации до отображения в реляционную. . .	Администрация Хабра удаляет новые энрегоэфективные алгоритмы, которые не западной школы кода, и вовсе никак не сгенерировавны. Hrethgir 20.06.2026 Делается это, как замечено, при правках - при объявлении концептуальных отличий в алгоримах. Делается это, по линейке событий - после дополнения публикации основными отличиями от основных западных. . .	Процесс ориентированная диалектика (не новость - просто системное обновление, философия). Hrethgir 20.06.2026 Однажды один участник в своём блоге, на этом форуме, сделал запись "О языках замолвите слово". Понимая, что язык - важная вещь, я решил хорошо подумать, прежде чем сказать, и сказал то, что вы видите. . .

@DrOffset 19501 / 10106 / 2461 Регистрация: 30.01.2014 Сообщений: 17,825
	13.01.2020, 09:58
	squareroot, на самом деле мне кажется я выше дал ясно понять, что ни PTHREAD_CANCEL_ASYNCHRONOUS на общих основаниях, ни tgkill, ни TerminateThread - не являются теми решениями, которые можно назвать хорошими. Т.е. еще более прямо, если вы будете их централизованно использовать - вы никогда не получите стабильное приложение. Особенно в С++. PTHREAD_CANCEL_ASYNCHRONOUS из всего этого является самым мягким решением, потому что позволяет указать область, где прерывание в произвольном месте делать безопасно. Ваш код не работает скорее всего из-за того, что cancel в современном Linux реализуется через бросок исключения. 0

@squareroot 13 / 13 / 1 Регистрация: 19.10.2019 Сообщений: 607
	13.01.2020, 18:15 [ТС]
	DrOffset, вообще говоря наиболее ожидаемое поведение при принудительном завершении потока это завершение приложения, но не аварийное завершение как в случае pthread_cancel и catch(...) {} а нормальное, с сохранием в логах ошибки из-за которой завершается приложение. Но наверно есть способ справится с залоченным мьютексом системными средствами, если разработчик конечного приложения сделает восстановления после сбоя без завершения приложения. 0