LINUX.ORG.RU

Привет, я опять выхожу на связь. Сигналы в sbcl

 , ,


0

3

Многопоточность в sbcl для dragonfly не пофиксил и уже в принципе сдался. Всем пофиг, к тому же.

Ситуация такая, что в многопоточной сборке sbcl падает по SIGILL (Illegal Instruction), если система нагружена чем-то ещё. В sb-qshow или ktrace нет никаких закономерностей, падает всегда по разному. Наверное, где-то race condition. Код, касемый мьютексов, вроде нормальный, значит, может дело в сигналах.

Спрошу на всякий случай:

В sbcl internals как-то размыто говорится, что есть blockable signals и semi-synchronous signals. Как работают последние? (кстати, SIGILL у них именно semi-synchronous). Ещё написано, что SIG_STOP_FOR_GC у них blockable, но не deferrable. Как я понимаю, при вызове sigaction у них стоит для SIG_STOP_FOR_GC флаг SA_NODEFER, а потом они блокируют его с помощью pthread_sigmask. Так почему он не deferrable? Видел, что где-то в src/runtime/interrupts.c есть обработчик для SIGILL (это interrupt_handle_now_handler). Какой процесс должен его вызывать и почему он так и остается не вызванным?

И ещё, что-то не пойму в чём разница между without-interrups и pseudo atomic sections. Где что применяется?

И да, кто может придумать какие-нибудь тесты, которые помогут отловить ошибку? Например, как-нибудь отключить GC, чтобы посмотреть, будет ли ошибка без него или уйдет, итд...

mv, поможешь советом?

Да, ещё безумно интересно, что такое sb-safepoint. В драгонфлае включить не смог, потому что там pthread_*_np функции

amphibrakhij
() автор топика

В sbcl internals как-то размыто говорится... semi-synchronous signals. Как работают последние?

SBCL Internals

6.1 Groups of signals

There are two distinct groups of signals. 
6.1.1 Semi-synchronous signals

The first group, tentatively named “semi-synchronous”, consists of signals that are raised on illegal instruction, hitting a protected page, or on a trap. Examples from this group are: SIGBUS/SIGSEGV, SIGTRAP, SIGILL and SIGEMT. The exact meaning and function of these signals varies by platform and OS.

И не стыдно?

LamerOk ★★★★★
()

Например, как-нибудь отключить GC, чтобы посмотреть, будет ли ошибка без него или уйдет, итд...

(without-gcing ...)

PS: Акерманн наше все. :)

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

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

ЗЫ. А не ты ли на Анну Варни на моём юзерпике однажды среагировал? Одно и то же слушаем, что ли?

amphibrakhij
() автор топика
Ответ на: комментарий от LamerOk

ты читать умеешь? Или там между строк написано, как они работают?

amphibrakhij
() автор топика

Меня по sbcl кастовать бесполезно: я пытался новую архитектуру вкорячить (s390x), но потом поменял работу, доступа не оказалось, да и ненужное это дело, вобщем-то. До хоть какого-нибудь полуживого образа дело не довёл.

SBCL, кстати, внутри жутко не понравился.

mv ★★★★★
()

Ситуация такая, что в многопоточной сборке sbcl падает по SIGILL (Illegal Instruction)

Ну и на какой инструкции падает, выяснил?

Harald ★★★★★
()

pseudo atomic sections применяются в тех местах, где нельзя обрабатывать сигналы, но делать pthread_sigmask слишком дорого. Например, при аллокации объектов. Поэтому обработчик прерывания анализирует нахождение кода в PA-секции.

dmitry_vk ★★★
()
Ответ на: комментарий от amphibrakhij

что значит semi-synchronous

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

dmitry_vk ★★★
()
Ответ на: комментарий от amphibrakhij

что такое sb-safepoint

SBCL издавна использует посылку нитям realtime-сигналов для управления нитями (такое взаимодействие нужно для того, чтобы сборщик мусора мог остановить нити).

sb-safepoint — это альтернативная реализация взаимодействия нитей и GC, использующая не отправку realtime-сигналов, а обработку нитей сегфолта в строго контролируемом месте.

dmitry_vk ★★★
()
Последнее исправление: dmitry_vk (всего исправлений: 1)

И еще: ЕМНИП, то SBCL использует опкод UD2, который в разных ОС может приходить в виде SIGTRAP или SIGILL.

dmitry_vk ★★★
()
Ответ на: комментарий от dmitry_vk

т.е. SBCL его специально вставляет в сгенерированный код. А с какой целью?

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

Harald ★★★★★
()
Ответ на: комментарий от Harald

А с какой целью?

Чтобы короткой инструкцией вызвать обработчик сигнала, который должен проанализировать всю сложившуюся ситуацию и решить, что делать дальше. Кажется, pseudo-atomic тоже использует этот опкод.

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

dmitry_vk ★★★
()
Ответ на: комментарий от mv

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

amphibrakhij
() автор топика
Ответ на: комментарий от dmitry_vk

SBCL издавна использует посылку нитям realtime-сигналов для управления нитями (такое взаимодействие нужно для того, чтобы сборщик мусора мог остановить нити).

А если в DragonFly даже SIGRTMIN...SIGRTMAX нет, это может быть плохим знаком? А шлет нитям он SIG_STOP_FOR_GC == SIGUSR2 в gc_stop_the_world. Ты не про это говорил?

amphibrakhij
() автор топика
Ответ на: комментарий от dmitry_vk

Пряд ли что будет понятно. Бектрейс и info thread такие:

(gdb) bt
#0 0x000000080085f864 in _umtx_wakeup_err () from /usr/lib/libpthread.so.0
Cannot access memory at address 0x80ebcff08

(gdb) info thread
   Id     Target     Id       Frame
   6       process   765    0x0000000800859dc8  in ?? () from /usr/lib/libpthread.so.0
   5       process   711    0x000000080085f864   in  _umtx_wakeup_err ()from /usr/lib/libpthread.so.0
   4       process   705    0x0000000020100019  in  ?? ()
   3       process   1        0x0000001002c458fb   in  ?? ()
* 2       process   724    0x000000080085f864   in  _umtx_wakeup_err() from /usr/lib/libpthread.so.0

_umtx_wakeup_err() присутствует всегда. Это фигня, специфичная для DragonFly.

http://leaf.dragonflybsd.org/cgi/web-man?command=umtx&section=2

amphibrakhij
() автор топика
Ответ на: комментарий от dmitry_vk

Ну и да, нужна ещё какая-нибудь инфа - спрашивай

amphibrakhij
() автор топика

Ещё симптом: SIGINT (через нажатие ^C) частенько перед падением не обрабатывается. То есть на него 0 реакции

amphibrakhij
() автор топика
Ответ на: комментарий от dmitry_vk

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

В thread post mortem есть такая функция:

static void*
perform_thread_post_mortem(struct thread_post_mortem *post_mortem)
{
#ifdef CREATE_POST_MORTEM_THREAD
    pthread_detach(pthread_self());
#endif
    if (post_mortem) {
        gc_assert(!pthread_join(post_mortem->os_thread, NULL));
        gc_assert(!pthread_attr_destroy(post_mortem->os_attr));
        free(post_mortem->os_attr);
        os_invalidate(post_mortem->os_address, THREAD_STRUCT_SIZE);  // <- ВОТ ЭТА СТРОЧКА
        free(post_mortem);
    }
    return NULL;
}

os_invalidate это обертка вокруг munmap. Если её закомментировать, всё будет OK (не считая утечки памяти). Какие тут могут быть причины? Потоко/сигнало небезопастность?

onanij
()
Ответ на: комментарий от auto12884839

Я man посмотрел, EAGAIN в бзде не возвращается при mmap/munmap. К тому же, при аллокации он проверяет, что вернул.

onanij
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.