Повторю вопрос Почему python может завершаться без ошибки? Немного инфы Exit code: -1073741819 ОС:

Windows
По памяти: Максимум кушает 1.2 ГБ памяти в пике, в системе 32 ГБ и 32 ГБ подкачки
Проверяя теорию с памятью уменьшил датасет с 1.5 млн строчек до 12000 строчек
Вызваю gc после каждого цикла операций (optuna)

Скорее всего вызовы gc там ни к чему

Всм без ошибки? Вон есть код выхода, посмотри что он значит

Ничего :)

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

И я его выкинул и потом написал что не сработало

И больше таких нет?

Ни одного try вообще больше нет

Первый ответ в гугле

segfault не обрабатывается интерпретатором)

Питон случайно не 32-битный?

Не дергай gc, например, у меня он только тормозил, а смысла от него не было

Ну сейчас попробую так заранить

смотрел логи винды?

Какие именно? Системный журнал смотрел, вроде ничего интересного, если скажешь куда еще глянуть то чекну

Не помню как на русском журнал событий вроде.

Кстати, только что нашел: Название аварийного приложения: python.exe, версия: 3.10.7150.1013, отметка времени: 0x63160388 Название аварийного модуля: _catboost.pyd, версия: 0.0.0.0, отметка времени: 0x644fc463 Код исключения: 0xc0000005 Смещение ошибки: 0x0000000000c132ac Код аварийного процесса: 0x0x3998 Время запуска аварийного приложения: 0x0x1D9E71C53640519 На кэтбуст ссылается

посмотри мб еще есть записи

Все ошибки аналогичны, код ошибки тот же

как вариант можешь попробовать sysmon

https://github.com/catboost/catboost/issues/881 Нашел что такое уже было

у тебя windows 7 и версия <0.17.2?

Нет, ни то ни другое

Вообще звучит как повод поискать сделать минимальный код для воспроизведения и потыкать авторов библиотеки.

Там общая директирия для логов, есть предположение, так как я раню сразу N процессов, то оно пытается ударить одновременно один и тот же файл и падает на этом Очень странно что раньше не воспроизводилось

М... Ты корректное описание исключения нашёл? Потому что то что ты привёл — вообще не в тему.

https://github.com/catboost/catboost/commit/13b497550c59a7d77d25f68dc9bdf3ad1c04f32e#diff-0ba9f58875d7b56c2ed28cafcc9e0bf7b703946d66dc79b47011c43d16cb4834 Ну в прошлый раз вот они поменяли аллокатор памяти

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

Написал уже в чат авторов либы, посмотрим что там скажут

Падать из-за гонки по записи логов ничего не должно, могут просто логи попортиться