Term sig null error code 2

Catch SIGSEGV error #4

It builds fine one Fedora 22 with gcc 5.3.1 but failes one of the catch unit tests on Fedora Rawhide with gcc 6.0

The text was updated successfully, but these errors were encountered:

Whilst Fedora Rawhide has now moved from 6.3.1 to 7.0.1, the problem is present on Debian Sid with 6.3.1. We can therefore treat this as a confirmed bug.

This could be a problem on line 107 (of zipios-2.1.1/tests/directoryentry.cpp ) in the event the clone cannot be created. We should probably add a line just before 107 to make sure the clone was created:

That would at least get rid of the SIGSEGV and replace it with a cleanly failed test. Then it will be to find out why the clone() function fails.

This is assuming that the pointer comes back out null and not some other problem (maybe cloning some of the I/O environment fails. )

I am getting a SIGSEGV using Debian Sid with GCC 6.3.1 even after the recent changeset.

zipios_tests is a Catch v1.2.0 host application. Run with -? for options ——————————————————————————- Scenario: BackBuffer read a file Given: a binary file of 256 bytes When: setting up a backbuffer Then: try with an invalid chunk size ——————————————————————————- /home/users/russel/Repositories/Git/Forks/Zipios/tests/backbuffer.cpp:35 . /home/users/russel/Repositories/Git/Forks/Zipios/tests/backbuffer.cpp:74: FAILED: REQUIRE_THROWS_AS( [&]() < zipios::BackBuffer bb(is, zipios::VirtualSeeker(), i); >) because no exception was thrown where one was expected: ——————————————————————————- Scenario: BackBuffer read a file Given: a binary file of 256 bytes When: setting up a backbuffer Then: we close the file and we get an exception ——————————————————————————- /home/users/russel/Repositories/Git/Forks/Zipios/tests/backbuffer.cpp:35 . /home/users/russel/Repositories/Git/Forks/Zipios/tests/backbuffer.cpp:84: FAILED: REQUIRE_THROWS_AS( [&]() < zipios::BackBuffer bb(is); >) because no exception was thrown where one was expected: ——————————————————————————- Scenario: DirectoryEntry with invalid paths Given: test a fantom file (path that «cannot» exists) and no comment verify that the object looks as expected ——————————————————————————- /home/users/russel/Repositories/Git/Forks/Zipios/tests/directoryentry.cpp:65 . /home/users/russel/Repositories/Git/Forks/Zipios/tests/directoryentry.cpp:72: FAILED: due to a fatal error condition: SIGSEGV — Segmentation violation signal =============================================================================== test cases: 13 | 11 passed | 2 failed assertions: 549436 | 549433 passed | 3 failed»>

I want to note here that this is not just a Fedora thing, and so not a GCC 7 thing, I get the same behaviour on Debian Sid GCC 6.3.0 as with Fedora Rawhide GCC 7.0.1. I am therefore going to amend the title of the issue to remove the Fedora reference.

Источник

Обработка многократно возникающих SIGSEGV-подобных ошибок

Тема изъезжена и уже не мало копий было сломано из-за неё. Так или иначе люди продолжают задаваться вопросом о том может ли приложение написанное на C/C++ не упасть после разыменования нулевого указателя, например. Краткий ответ — да, даже на Хабре есть статьи на сей счёт.

Одним из наиболее частых ответов на данный вопрос является фраза «А зачем? Такого просто не должно случаться!». Истинные причины того почему люди продолжают интересоваться данной тематикой могут быть разные, одной из них может быть лень. В случая когда лениво или дорого проверять всё и вся, а исключительные ситуации случаются крайне редко можно, не усложняя кода, завернуть потенциально падающие фрагменты кода в некий try / catch который позволит красиво свернуть приложение или даже восстановится и продолжить работу как ни в чём не бывало. Наиболее ненормальным как раз таки может показаться желание снова и снова ловить ошибки, обычно приводящие к падению приложения, обрабатывать их и продолжать работу.

Итак попробуем создать нечто позволяющее решать проблему обработки SIGSEGV-подобных ошибок. Решение должно быть по максимуму кроссплатформенным, работать на всех наиболее распространённых десктопных и мобильных платформах в однопоточных и многопоточных окружениях. Так же сделаем возможным существование вложенных try / catch секций. Обрабатывать будем следующие виды исключительных ситуаций: доступ к памяти по неправильным адресам, выполнение невалидных инструкций и деление на ноль. Апофеозом будет то, что произошедшие аппаратные исключения будут превращаться в обычные C++ исключения.

Наиболее часто для решения аналогичным поставленной задачам рекомендуется использовать POSIX сигналы на не Windows системах, а на Windows Structured Exception Handling (SEH). Поступим примерно следующим образом, но вместо SEH будем использовать Vectored Exception Handling (VEH), которые очень часто обделены вниманием. Вообще, со слов Microsoft, VEH является расширением SEH, т.е. чем-то более функциональным и современным. VEH чем-то схож c POSIX сигналами, для того чтобы начать ловить какие либо события обработчик надо зарегистрировать. Однако в отличии от сигналов для VEH можно регистрировать несколько обработчиков, которые будут вызываться по очереди до тех пор пока один из них не обработает возникшее событие.

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

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

Выше приведённый фрагмент кода регистрирует обработчик для следующий сигналов: SIGBUS , SIGFPE , SIGILL , SIGSEGV . Помимо этого с помощью вызова sigaltstack указываться, что обработчик сигнала должен запускаться на альтернативном, своём собственном, стеке. Это позволяет выживать приложению даже в условиях stack overflow, который легко может возникнуть в случае бесконечно рекурсии. Если не задать альтернативный стек, то подобного рода ошибки не возможно будет обработать, приложение будет просто падать, т.к. для вызова и выполнения обработчика просто не будет стека и с этим ничего нельзя будет сделать. Так же сохраняются указатели на ранее зарегистрированные обработчики, что позволит их вызывать, если наш обработчик поймёт, что делать ему нечего.

Для Windows код намного короче:

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

Сам обработчик для POSIX систем выглядит следующим образом:

Надо сказать, что для того чтобы наш обработчик сигналов стал многоразовым, т.е. мог вызываться снова и снова в случае возникновения новых ошибок, мы должны при каждом заходе разблокировать сработавший сигал. Это необходимо в тех случаях, когда обработчик знает, что исключительная ситуация возникла в участке кода, который завёрнут в некие try / catch о которых речь пойдёт позже. Если же аварийная ситуация сложилась там где мы её совсем не ожидали, дела будут переданы ранее зарегистрированному обработчику сигналов, если такового нет, то вызывается обработчик по умолчанию, который завершит терпящее аварию приложение.

Обработчик для Windows выглядит следующим образом:

Как уже упоминалось выше VEH обработчик на Windows ловит много чего ещё помимо аппаратных исключений. Например при вызове OutputDebugString возникает исключение с кодом DBG_PRINTEXCEPTION_C . Подобные события мы обрабатывать не будем и просто вернём EXCEPTION_CONTINUE_SEARCH , что приведёт к тому что ОС пойдёт искать следующий обработчик, который обработает данное событие. Также мы не хотим обрабатывать C++ исключения, которым соответствует магический код 0xE06D7363L не имеющий нормального имени.

Как на POSIX-совместимых системах так и на Windows в конце обработчика вызывается longjmp , который позволяет нам вернуться вверх по стеку, до самого начала секции try и обойти её попав в ветку catch , в которой можно будет сделать все необходимые для восстановления работы действия и продолжить работу так как будто ничего страшного не произошло.

Для того, чтобы обычный C++ try начал ловить не свойственные ему исключительные ситуации необходимо в самое начало поместить небольшой макрос HW_TO_SW_CONVERTER :

Выглядит довольно кудряво, но по факту здесь делается очень простая вещь:

1. Вызывается setjmp , который позволяет нам запомнить место где мы начали и куда нам надо вернуться в случае аварии.
2. Если по пути выполнения случилось аппаратное исключение, то setjmp вернёт не нулевое значение, после того как где-то по пути был вызван longjmp . Это приведёт к тому, что будет брошено C++ исключение типа HwException, которое будет содержать информацию о том какого вида ошибка случилась. Брошенное исключение без проблем ловится стандартным catch .

Упрощённо приведённый выше макрос разворачивается в следующий псевдокод:

У подхода setjmp / longjmp есть один существенный недостаток. В случае обычных C++ исключений, происходит размотка стека при которой вызываются деструкторы всех созданных по пути объектов. В случае же с longjmp мы сразу прыгаем в исходную позицию, никакой размотки стека не происходит. Это накладывает соответствующие ограничения на код, который находится внутри таких секций try , там нельзя выделять какие-либо ресурсы ибо есть риск их навсегда потерять, что приведёт к утечкам.

Ещё одним ограничением является то, что setjmp нельзя использовать в функциях/методах объявленных как inline . Это ограничение самого setjmp . В лучшем случае компилятор просто откажется собирать подобный код, в худшем он его соберёт, но полученный бинарный файл будет просто аварийно завершать свою работу.

Самым ненормальным действием, которое приходится принимать после обработки аппаратного исключения на Windows является необходимость вызова RemoveVectoredExceptionHandler . Если этого не сделать, то после каждого входа в наш обработчик VEH и выполнения longjmp там будет складываться ситуация как-будто наш обработчик был зарегистрирован ещё один раз. Это приводит к тому, что при каждой последующей аварийной ситуации обработчик будет вызываться всё больше и больше раз подряд, что будет приводить к плачевным последствиям. Данное решение было найдено исключительно путём многочисленных магических экспериментов и нигде никак не документировано.

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

Сам контекст исполнения оформлен в виде простого класса имеющего следующие конструктор и деструктор:

Данный класс имеет поле prev_context , которое даёт нам возможность создавать цепочки из вложенных секций try / catch .

Полный листинг описанного выше изделия доступен в GitHub’е:
https://github.com/kutelev/hwtrycatch

В доказательство того, что всё работает как описано имеется автоматическая сборка и тесты под платформы Windows, Linux, Mac OS X и Android:

Под iOS это тоже работает, но за неимением устройства для тестирования нет и автоматических тестов.

В заключение скажем, что подобный подход можно использовать и в обычном C. Надо лишь написать несколько макросов, которые будут имитировать работу try / catch из C++.

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

Источник

How to debug PostgreSQL segmentation fault?

I have a PostgreSQL 13 instance that keeps crashing:

I’ve updated /etc/postgresql/13/main/pg_ctl.conf to include core dumps

and restarted postgresql service. Now it seems to allow core dumps:

gdb backtrace gives following output

Adding log_statement = ‘all’ to /etc/postgresql/13/main/postgresql.conf doesn’t really help, as postmaster terminates all processes immediately and the query doesn’t get written to logs.

here’s strace output after running COMMIT

Is there a way how to trace back the exact SQL query that was executed?

1 Answer 1

Firstly install debugging symbols for your distribution, for Debian distros:

Jump to a frame that contains some queryDesc variable, e.g 12 :

print that variable:

now copy the line above after equal sign and dereference it using *

It doesn’t give you the whole query but at least an idea on which table is the query executed.

Based on the gdb output I’ve managed to isolate clients that were executing such query.

I’ve tried running VACUUM FULL on the affected table, rebuilding table and indexes, switching to replica, copying whole database using pg_dump . Nonetheless the issue still persisted also on database copies.

With a code to replicate this was enough to report a bug to pgsql-bugs mailing list (there’s also a webform). Turned out to be a bug with re-execution of a plan that already reached completion on a un-stable cursor that was included in PostgreSQL 13.4, 12.8 (and possibly other versions).

Источник

Обработка ошибок сегментации

У меня есть приложение, которое я использую для обнаружения ошибок сегментации или ctrl-c. Используя приведенный ниже код, я могу обнаружить ошибку сегментации, но обработчик вызывается снова и снова. Как я могу остановить их. К вашему сведению, я не хочу выходить из своего приложения. Я просто могу позаботиться об освобождении всех поврежденных буферов.

Является ли это возможным?

и обработчик выглядит так.

Здесь для сигнала ошибки сегментации обработчик вызывается несколько раз, и, как очевидно, MyfreeBuffers() выдает мне ошибки для освобождения уже освобожденной памяти. Я просто хочу освободиться только один раз, но все равно не хочу выходить из приложения.

7 ответы

Действие по умолчанию для таких вещей, как SIGSEGV заключается в завершении вашего процесса, но, поскольку вы установили для него обработчик, он вызовет ваш обработчик, переопределяющий поведение по умолчанию. Но проблема в том, что инструкция segfaulting может быть повторена после того, как ваш обработчик завершит работу, и если вы не предприняли меры для исправления первой ошибки seg, повторная инструкция снова выдаст ошибку, и она будет продолжаться снова и снова.

Итак, сначала найдите инструкцию, которая привела к SIGSEGV и попытайтесь это исправить (вы можете вызвать что-то вроде backtrace() в обработчик и сами посмотрите что пошло не так)

Кроме того, стандарт POSIX говорит, что

Поведение процесса не определено после нормального возврата из функции перехвата сигнала для сигнала [XSI] SIGBUS, SIGFPE, SIGILL или SIGSEGV, который не был сгенерирован kill(), [RTS] sigqueue() или raise( ).

Итак, в идеале в первую очередь нужно исправить ошибку segfault. Обработчик segfault не предназначен для обхода основного состояния ошибки.

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

ответ дан 09 окт ’13, 10:10

Выявление нарушений сегментации иногда полезно, потому что тогда программист может сообщить, где произошла ошибка, в stderr, файле журнала или на удаленном сервере, прежде чем произойдет сбой программы. Я представляю это так: программист хранит глобальные переменные, сохраняя имя текущей обрабатываемой функции (разные вещи для многопоточных программ) и номер текущей строки (операторы обновления переменной номера строки (за счет вычислительной мощности) будут вставляется автоматически в каждую строку). Когда происходит segfault, программист может сообщить в журнал «SIGSEGV in tois()@main.c:492». — Сиянец

вообще не согласен с утверждением «Не ловите SIGSEGV».

Это довольно хорошая практика для решения неожиданный условия. И это намного чище, чтобы справиться с NULL, указатели (в соответствии с ошибками malloc) с сигнальным механизмом, связанным с setjmp/longjmp , чем распределять управление ошибками по всему коду.

Обратите внимание, однако, что если вы используете »sigaction» на SEGV , вы не должны забыть сказать SA_NODEFER in sa_flags — или найти другой способ справиться с фактом SEGV вызовет ваш обработчик только один раз.

ответ дан 02 мая ’17, 18:05

Это хорошее решение. Мне не особенно нравилось «дать ему сбой, а затем проанализировать дамп ядра». — дтурвен

Обратите внимание, что вы do еще нужно выкладывать проверки ошибок с этим стилем, но другим способом. Здесь вызывающий код должен знать, как очистить любые ресурсы для всего кода, который он вызывал в случае ошибки. В традиционном стиле каждый фрагмент кода проверяет наличие ошибок, а затем очищает только свои собственные ресурсы. IMO последнее предпочтительнее, так как каждая часть должна меньше знать о других. — Gntskn

Супер полезный ответ, спасибо. См. также раздел «Стандартные сигналы». здесь. Похоже, мне придется вручную указать кучу сигналов, если я хочу поймать все. — Эндрю

Итак, если вы сделаете это, вы можете использовать strsignal чтобы получить строковое представление сигнала, а затем вы можете распечатать/записать эту строку и sig int себя в общем. Затем вы можете повторно использовать этот код для целой группы сигналов, используя только 1 handler() функция! — Эндрю

Если же линия индикатора SIGSEGV снова срабатывает, очевидный вывод состоит в том, что вызов MyfreeBuffers(); и не устранена основная проблема (и если эта функция действительно делает только free() какая-то выделенная память, я не уверен, почему вы так думаете).

Примерно, а SIGSEGV срабатывает при попытке доступа к недоступному адресу памяти. Если вы не собираетесь выходить из приложения, вам нужно либо сделать этот адрес памяти доступным, либо изменить путь выполнения с помощью longjmp() .

ответ дан 18 апр.

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

Совершенно законно обрабатывать control-C. Многие приложения делают это, но вы должны быть очень осторожны с тем, что вы делаете в своем обработчике сигналов. Вы не можете вызвать любую функцию, которая не является реентерабельной. Значит, если ваш MyFreeBuffers() вызывает стандартную библиотеку free() функции, вы, вероятно, облажались. Если пользователь нажимает Control-C, когда программа находится в середине malloc() or free() и, таким образом, на полпути к манипулированию структурами данных, которые они используют для отслеживания распределения кучи, вы почти наверняка испортите кучу, если вызовете malloc() or free() в обработчике сигналов.

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

ответ дан 18 апр.

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

ответ дан 18 апр.

Я вижу случай восстановления из SIG_SEGV, если вы обрабатываете события в цикле и одно из этих событий вызывает нарушение сегментации, тогда вам нужно пропустить только это событие, продолжая обрабатывать оставшиеся события. На мой взгляд, SIG_SEGV похож на NullPointerException в Java. Да, состояние будет непоследовательным и неизвестным после любого из них, однако в некоторых случаях вы хотели бы справиться с ситуацией и продолжить. Например, в алго-трейдинге вы можете приостановить выполнение ордера и позволить трейдеру вручную взять на себя управление, не разрушая всю систему и не разрушая все остальные ордера.

Создан 22 июля ’14, 12:07

Похоже, что по крайней мере под Linux использование трюка с опцией -fnon-call-exceptions может быть решением. Это даст возможность преобразовывать сигнал в общее исключение C++ и обрабатывать его обычным способом. Посмотрите linux3 / gcc46: «-fnon-call-exceptions», какие сигналы являются инструкциями перехвата? например.

ответ дан 23 мая ’17, 13:05

Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками c linux signals signal-handling or задайте свой вопрос.

Источник

I am still experiencing similar issues, see out put below.

Traceback (most recent call last):
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 1075, in init
    wi.setup(kwargs)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 165, in setup
    self._wl = wandb_setup.setup()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 312, in setup
    ret = _setup(settings=settings)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 307, in _setup
    wl = _WandbSetup(settings=settings)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 293, in __init__
    _WandbSetup._instance = _WandbSetup__WandbSetup(settings=settings, pid=pid)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 106, in __init__
    self._setup()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 234, in _setup
    self._setup_manager()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 265, in _setup_manager
    self._manager = wandb_manager._Manager(
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_manager.py", line 108, in __init__
    self._service.start()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/service/service.py", line 112, in start
    self._launch_server()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/service/service.py", line 108, in _launch_server
    assert ports_found
AssertionError
wandb: ERROR Abnormal program exit
Traceback (most recent call last):
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 1075, in init
    wi.setup(kwargs)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 165, in setup
    self._wl = wandb_setup.setup()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 312, in setup
    ret = _setup(settings=settings)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 307, in _setup
    wl = _WandbSetup(settings=settings)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 293, in __init__
    _WandbSetup._instance = _WandbSetup__WandbSetup(settings=settings, pid=pid)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 106, in __init__
    self._setup()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 234, in _setup
    self._setup_manager()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_setup.py", line 265, in _setup_manager
    self._manager = wandb_manager._Manager(
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_manager.py", line 108, in __init__
    self._service.start()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/service/service.py", line 112, in start
    self._launch_server()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/service/service.py", line 108, in _launch_server
    assert ports_found
AssertionError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "train_masters.py", line 897, in <module>
    wandb.init(project="Masters", config=args, resume=False, group="final",
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 1116, in init
    raise Exception("problem") from error_seen
Exception: problem
Traceback (most recent call last):
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/__main__.py", line 3, in <module>
    cli.cli(prog_name="python -m wandb")
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/cli/cli.py", line 97, in wrapper
    return func(*args, **kwargs)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/cli/cli.py", line 282, in service
    server.serve()
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/service/server.py", line 130, in serve
    self._inform_used_ports(grpc_port=grpc_port, sock_port=sock_port)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/service/server.py", line 65, in _inform_used_ports
    pf.write(self._port_fname)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/site-packages/wandb/sdk/service/port_file.py", line 25, in write
    f = tempfile.NamedTemporaryFile(prefix=bname, dir=dname, mode="w", delete=False)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/tempfile.py", line 540, in NamedTemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type)
  File "/scratch/hywluc001/conda-envs/pointnet/lib/python3.8/tempfile.py", line 250, in _mkstemp_inner
    fd = _os.open(file, flags, 0o600)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpsnxv_nef/port-18551.txtacbmdqof'

Что такое необъявленная ошибка:
Когда мы используем некоторую константу в нашей программе, они могут быть встроенными константами и могут быть созданы пользователем в соответствии с требованиями. Но когда мы используем некоторую константу, а они не являются встроенными и также не определены пользователем в этом состоянии, мы получаем необъявленную ошибку.

Ниже приведен код, показывающий пример необъявленной ошибки NULL:

Приведенный выше код покажет ошибку как «необъявленная ошибка NULL» . Причина необъявленной ошибки NULL в том, что «NULL» не является встроенной константой.

Зачем нам NULL?
Когда мы создаем какой-либо указатель в нашей программе, они используются для хранения адресов. Но неинициализированные переменные-указатели очень опасны, так что мы можем присвоить им NULL, что означает, что они не указывают ни на какую ячейку памяти, поэтому наша программа работает плавно и безопасно.
Теперь, если NULL не является встроенной константой, как мы можем преодолеть необъявленную ошибку NULL.

Ниже приведен код, который используется для удаления необъявленной ошибки NULL:

1. Присвоить 0: вместо присвоения NULL для num мы можем просто присвоить 0, что означает, что он не указывает какой-либо адрес, поэтому простейшим решением является просто присвоение 0.
   Код ниже показывает его реализацию:

   using namespace std;

   int main()

   {

   int * num = 0;

   return 0;

   }

2. Включите файл заголовка «stddef.h»: в файле заголовка stddef.h уже определен NULL , поэтому мы можем включить этот файл заголовка в нашу программу, и наша программа будет компилироваться и выполняться без каких-либо ошибок.
   Код ниже показывает его реализацию:

   #include <stddef.h>

   int main()

   {

   int * num = NULL;

   return 0;

   }

3. Включите файл заголовка iostream: в C ++, если мы хотим выполнить нашу программу без необнаруженной ошибки NULL, мы можем просто включить iostream в нашу программу и сделать это без ошибок.
   Код ниже показывает его реализацию:

   #include <iostream>

   using namespace std;

   int main()

   {

   int * num = NULL;

   return 0;

   }

4. #define NULL 0: Используя строку #define NULL 0 в нашей программе, мы можем решить необъявленную ошибку NULL.
   Код ниже показывает его реализацию:

   #define NULL 0

   using namespace std;

   int main()

   {

   int * num = NULL;

   return 0;

   }

5. В новом C ++ (C ++ 11 и выше):: nullptr — это встроенная константа, поэтому мы можем использовать ее вместо NULL.

   #include <iostream>

   using namespace std;

   int main()

   {

   int * num = nullptr;

   return 0;

   }

   Хотите учиться на лучших видео и практических задачах, ознакомьтесь с базовым курсом C ++ для базового и продвинутого уровня C ++ и курсом C ++ STL для языка и STL. Чтобы завершить подготовку от изучения языка к DS Algo и многому другому, см. Полный курс подготовки к собеседованию .