Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when running the test suite with Python 3.10 #210

Open
mcepl opened this issue May 11, 2022 · 7 comments
Open

Crash when running the test suite with Python 3.10 #210

mcepl opened this issue May 11, 2022 · 7 comments

Comments

@mcepl
Copy link

mcepl commented May 11, 2022

When running the test suite, it fails with this backtrace:

https://gist.github.com/mcepl/43ada31674951bdbd62d8d560575a9f1

This is complete build log describing all packages used and steps taken to reproduce the problem (unfortunately, I had to collect backtrace outside of the build environment).

It is probably blocking #204

@mcepl
Copy link
Author

mcepl commented May 21, 2022

Or there is this backtrace ... not exactly the same: tests/test_xmlsec.py::TestModule::test_reinitialize_module passed and it failed only in tests/test_constants.py::test_transform_str: https://gist.github.com/mcepl/7c0cba8a3b41780dbb3e56ed31bbf299

@dirkmueller
Copy link

dirkmueller commented May 23, 2022

I have similar one under valgrind:

tests/test_constants.py ==15782== Invalid read of size 8
==15782==    at 0x969DFEF: PyXmlSec_Transform__str__ (constants.c:25)
==15782==    by 0x49AFEA3: PyObject_Str (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x49D1F1A: ??? (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x499C668: ??? (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x499C4E3: _PyObject_MakeTpCall (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x49990D1: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x4993672: ??? (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x499737E: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x4993672: ??? (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x49948B9: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x4993672: ??? (in /usr/lib64/libpython3.10.so.1.0)
==15782==    by 0x49A6A91: PyVectorcall_Call (in /usr/lib64/libpython3.10.so.1.0)
==15782==  Address 0x9963b50 is not stack'd, malloc'd or (recently) free'd
==15782== 
Fatal Python error: Segmentation fault

it appears this is due to

https://github.com/mehcode/python-xmlsec/blob/2460f50a51ae3719cdab5dbeabc18b8ef8c71f52/src/constants.c#L25

where id is suddenly pointing into the wild west. it looks like https://github.com/mehcode/python-xmlsec/blob/2460f50a51ae3719cdab5dbeabc18b8ef8c71f52/src/constants.c#L133 is the only place where id is assigned.

I'm obviously not understanding things, but this is not doing a deep-copy, just copying the pointer. what exactly is supposed to keep the reference alive?

shouldn't this be copied and freed then in __del__ ?

@mcepl
Copy link
Author

mcepl commented Jun 2, 2022

Isn't it just that transform->id->href can be uninitialized? I have to admit that I got lost in the bizarre maze of macro hell in src/constants.c.

@dirkmueller
Copy link

I don't see how it can be uninitialized, it is unconditionally initialized in the constructing function?

@mcepl
Copy link
Author

mcepl commented Jun 8, 2022

s/uninitialized/has not been initialized/ I had lost my way in the endless bogs of src/constants.c, but I am just not persuaded still that there are no situations where transform->id->href has not been set at all.

@danigm
Copy link

danigm commented Dec 19, 2022

Debugging this problem I've found that the problem is when trying to access transform->id->href, but it's even not null, so it should be something deeper.

25	    if (transform->id->href != NULL)
(gdb) p transform
$1 = (PyXmlSec_Transform *) 0x7ffff5704230
(gdb) p transform->id
$2 = (xmlSecTransformId) 0x7ffff5d13220
(gdb) p transform->id->href
Cannot access memory at address 0x7ffff5d13230

I've also detected that this problem doesn't happen to me if I run just the test_constants but it happens when running the full test suite, so it should be some weird state.

@danigm
Copy link

danigm commented Dec 19, 2022

Looks like the problem is with test_reinitialize_module, the call to shutdown and a race condition or something like that. I've detected that running the tests with pytest -n 1 doesn't produce this problem.

bmwiedemann pushed a commit to bmwiedemann/openSUSE that referenced this issue Dec 19, 2022
https://build.opensuse.org/request/show/1043746
by user dgarcia + dimstar_suse
- Run tests with -n1 to avoid race condition in tests
  gh#xmlsec/python-xmlsec#210
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants