$1000 за починку SBCL

мало

Ну а сколько по-твоему? Я не оракл

Думаю, надо скастовать den73

да без проблем, если он сможет

Steel Bank Common Lisp?

да

Сами собирали или бинарь?

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

Ссылку на патч?

https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAK3-8Ji8XrjZd8ttKa0...

А под Линупсом исключения отлавливаются или только под Виндой? Там под Линупс с десяток функций, можно добавить вывод и отловить в какой происходит сбой.

Как-то лисп себя уже изжил давно

ДжаваСкрипт наше фсе?

Хм, похоже, кое-у кого суббота удалась на славу. Мне кажется, это RTFM для начала. Там что-то написано про особенности (ограничения) работы сторонних тредов в SBCL, в т.ч., связанные с сигналами. SBCL что-то там использует для своих нужд, что приличные процессы не используют. Более подробно я никогда это не копал. Я весьма далёк от того уровня знаний, чтобы это починить, это кто-нибудь типа Дмитрия Иванова. Ну или уж сам stassats. И кроме того, я уже нашёл работу.

Но в целом - так держать, продолжать гордо нести знамя лиспа!

Как этот bounty вообще работает? Деньги у вложившихся уходят сразу? Они могут передумать? Как определяется, достоин ли «починивший» награды?

С сигналами много что криво работает. Типичная ошибка следующая. Если там используется fork, то очень важно, чтобы за ним следовал exec(*) в дочернем процессе, а между этими вызовами должны использоваться исключительно «безопасные» относительно сигналов функции. Грубо говоря, нельзя использовать ни мьютексы, ни printf, ни чего такого. Строго ограниченный набор функций - их штук 200 где-то. Иначе в одном случае из ста крашится дочерний процесс, но не всегда, что затрудняет поиск причины. Многие просто не в курсе, что есть такая проблема. В общем, я бы в первую очередь проверил этот сценарий.

Подробнее можно? Я не вижу причин для падения. Вызов обработчиков сигналов и fork работают по-разному. Да и утверждение, что fork годится только для exec, странное.

Всё нормально у сигналов с процессами форками. А вот с тредами не совсем. Застолбив хендлеры сигналов, ты можешь получить этот сигнал в любом из тредов, включая основной тред процесса. Так вот, чтобы ненароком некорректно не вывалиться из треда при получении сигнала — нужно в хендлере проверять равен ли tid в текущем контексте tid'у основного треда. Если равен — обрабатывать. Если не равен — ничего не делать. А сигнал получат все треды. Просто нет гарантии, что первым его получит основной тред.

Лавсанчик, оно?

man fork:

CAVEATS There are limits to what you can do in the child process. To be totally safe you should restrict yourself to only executing async-signal safe operations until such time as one of the exec functions is called. All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frame- works in the child process, you must exec. In this situation it is reasonable to exec yourself.

По-моему у Стивенса есть детали в его знаменитой книге. Я же столкнулся на своей практике. Как раз починил регулярные падения одного сервиса. Потом стало работать как часы.

Если равен — обрабатывать. Если не равен — ничего не делать.

Так же сигналы будут игнорироваться. Мне кажется, что полностью блокировать сигналы не в основном потоке, а в основном оставлять лишь цикл вокруг sigwait() является более правильным решением.

будут игнорироваться

Не игнорироваться. Они будут приняты, просто в хендлере какая-либо работа должна пойти только после условия.

полностью блокировать сигналы не в основном потоке

Возможно. Но блокировать — это блокировать.

У меня нет такого в мане (онлайн версия). Смысл здесь есть и понятно, что общее состояние между процессами остаётся, но safe or async-signal safe очень жёсткое ограничение. Оно нужно для сигналов, так как они могут прервать эти функции в любом месте, а fork() в пользовательском коде этого не делает (если до форка был лишь один поток).

Этот кусок мана с макоси, но мне кажется, что все справедливо и для линукса. У нас как раз падения были на линуксе. Потом исправили. Ну, и Стивенс, как я написал.

И в этом сервисе было больше одного потока при вызове fork()?

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

Или я не понял твоего вопроса. В родительском процессе было много потоков. В дочернем до вызова exec - всего один поток.

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

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

Вот код который воспроизводит баг исключительно средствами SBCL, без моей библиотеки.

https://gist.github.com/Lovesan/d8c184c8a2d286255af03852e3019bb2

Т.е. для воспроизведения бага достаточно оказать нагрузку на GC и сигналы.

Вещь довольно критическая вобщем, я так понимаю, дело до quicklisp не дойдет пока SBCL не починится.

Оставил коммент на Гите

Вобщем, stassats намотал воркараунд. Сразу после того как рантайм .Net Core инициализируется и ставит свои сигналы - мы переустанавливаем оригинальные сигналы SBCL.

Смешное, что дотнету это работать дальше не мешает - спокойно и с GC работает, и с эксепшнами. А вот SBCL зато уже не падает.