segfault in PyObject_Init

[fenugrec]

Crash report

What happened?

On archlinux, attempting to build virtualbox-bin 7.1.4 from AUR.

The step that fails is VBOX_INSTALL_PATH="/${_installdir}" python vboxapisetup.py install --root "$pkgdir" --skip-build --optimize='1' which may be hard to reproduce on its own. I will try to reduce this a bit but I'm running out of time. Attached is a gdb backtrace with partial debug symbols pysegfault.log

CPython versions tested on:

3.12

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

Python 3.12.7 (main, Oct 1 2024, 11:15:50) [GCC 14.2.1 20240910]

[picnixz]

I think this should be reported to virtualbox and not here, unless you manage to find a reproducer. Apparently, there is some issue with their own functions (for instance PyXPCOM_Globals_Ensure is not a CPython function).

[ZeroIntensity]

Yeah, looking at the backtrace, a NULL pointer is getting passed as a type to PyObject_Init.

[fenugrec]

Would running with PYTHONFAULTHANDLER=1 help get more information ?

Apparently, there is some issue with their own functions (for instance PyXPCOM_Globals_Ensure

[EDIT] Thanks, that was the key to finding this (probably identical) existing virtualbox ticket: https://www.virtualbox.org/ticket/22017

Before closing this ticket :

a NULL pointer is getting passed as a type to PyObject_Init.

Indeed. I see PyObject_Init already has an assert on (op != NULL) , any reason not to check tp there too?

[ZeroIntensity]

We could, but I doubt it would be that useful. Python typically isn't built with assertions enabled.

[rruuaanng]

Indeed. I see PyObject_Init already has an assert on (op != NULL) , any reason not to check tp there too?

Usually when using assertions, we expect its value should be correct and don't want it to be implicitly processed (and the assertion build needs to be activated). In scenario PyObject_Init, I think everything should go smoothly, instead of a value being NULL.

[picnixz]

Indeed. I see PyObject_Init already has an assert on (op != NULL) , any reason not to check tp there too?

Semantically, the assert on op is because op == NULL is handled as a special case in PyObject_Init which is a shortcut for calling PyErr_NoMemory(). In addition, the type being passed is usually created before (in which case, you should check for NULL at that point), is the address of a structure (so no way it's NULL), or is a borrowed reference (again, that shouldn't be NULL at the moment of the call).

Now, we could add an assert in _PyObject_Init because it doesn't really cost that much. But instead of just adding it here, it's probably better to add it wherever a similar case happens (i.e., when not all parameters are asserted to be non-NULL).

[fenugrec]

For reference, the relevant virtualbox code is probably this here https://www.virtualbox.org/browser/vbox/trunk/src/libs/xpcom18a4/python/src/PyIID.cpp#L270

Interesting points. I would think since PyObject_Init can be called from "outside", it should have asserts on both parameters, but I understand such a decision goes beyond just this one function, and if anyway nobody builds with asserts (is it that much of a performance/size hit ?) then there is little point.

Thanks for the input everyone, closing this now.