On 2023-10-12 12:31, Paul Gevers wrote:
> If I rename tests/test_stanza_error.py to something else such that
> it's not automatically run as test, the segfault doesn't happen.
Thanks, Paul, that helped a lot!
In xmpp:slix...@muc.poez.io?join Link Mauve came up with the idea to run
the test in pdb, and that's how it segfaults on amd64, too, not only on
arm64:
$ python3 -m pdb ./run_tests.py tests/test_stanza_error.py
> /usr/local/src/debian/xmpp-team/slixmpp/run_tests.py(3)<module>()
-> import sys
(Pdb) r
Using slower stringprep, consider compiling the faster cython/libidn one.
testCondition (tests.test_stanza_error.TestErrorStanzas.testCondition)
Test modifying the error condition. ... ok
testDelCondition (tests.test_stanza_error.TestErrorStanzas.testDelCondition)
Test that deleting error conditions doesn't remove extra elements. ... ok
testDelText (tests.test_stanza_error.TestErrorStanzas.testDelText)
Test deleting the text of an error. ... ok
testSetup (tests.test_stanza_error.TestErrorStanzas.testSetup)
Test setting initial values in error stanza. ... ok
----------------------------------------------------------------------
Ran 4 tests in 1.149s
OK
<tests xmlns='http//andyet.net/protocol/tests' ran='4' errors='0' fails='0'
success='True'/>
--Return--
> /usr/local/src/debian/xmpp-team/slixmpp/run_tests.py(73)<module>()->None
-> sys.exit(not result.wasSuccessful())
(Pdb) quit
Segmentation fault
This is the backtrace:
Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
PyObject_CallOneArg (func=0x0, arg=0x7fffefacd7e0) at ../Objects/call.c:376
376 ../Objects/call.c: Bad file descriptor.
(gdb) bt
#0 PyObject_CallOneArg (func=0x0, arg=0x7fffefacd7e0) at ../Objects/call.c:376
#1 0x000000000056fcea in PyObject_Repr (v=0x7fffefacd7e0) at
../Objects/object.c:433
#2 0x0000000000521179 in unicode_fromformat_arg (vargs=0x7fffffffe160,
f=<optimized out>, writer=0x7fffffffe180) at ../Objects/unicodeobject.c:3036
#3 PyUnicode_FromFormatV (format=<optimized out>, vargs=<optimized out>) at
../Objects/unicodeobject.c:3100
#4 0x0000000000560da7 in _PyErr_FormatV (vargs=0x7fffffffe200, format=0x858991
"%R is not in deque",
exception=0x947140 <_PyExc_ValueError.lto_priv.0>, tstate=0xa840d8
<_PyRuntime+166328>) at ../Python/errors.c:1078
#5 PyErr_Format (exception=0x947140 <_PyExc_ValueError.lto_priv.0>,
format=0x858991 "%R is not in deque") at ../Python/errors.c:1120
#6 0x0000000000480988 in deque_remove (deque=0x7fffef951e40,
value=0x7fffefacd7e0) at ../Modules/_collectionsmodule.c:1256
#7 0x0000000000567b4f in method_vectorcall_O (func=0x7ffff74823e0,
args=0x7fffef9aca98, nargsf=<optimized out>, kwnames=0x0)
at ../Objects/descrobject.c:481
#8 0x000000000053ac2c in _PyObject_VectorcallTstate (kwnames=<optimized out>,
nargsf=<optimized out>, args=<optimized out>,
callable=0x7ffff74823e0, tstate=0xa840d8 <_PyRuntime+166328>) at
../Include/internal/pycore_call.h:92
#9 PyObject_Vectorcall (callable=0x7ffff74823e0, args=<optimized out>,
nargsf=<optimized out>, kwnames=<optimized out>) at ../Objects/call.c:299
#10 0x000000000052b940 in _PyEval_EvalFrameDefault (tstate=<optimized out>,
frame=<optimized out>, throwflag=<optimized out>)
at ../Python/ceval.c:4772
#11 0x0000000000641aaa in _PyEval_EvalFrame (throwflag=<optimized out>,
frame=0x7fffef9aca30, tstate=0xa840d8 <_PyRuntime+166328>)
at ../Include/internal/pycore_ceval.h:73
#12 gen_send_ex2 (gen=gen@entry=0x7fffef9ac9e0, arg=0x959cc0 <_Py_NoneStruct>,
presult=presult@entry=0x7fffffffe588, exc=exc@entry=1,
closing=closing@entry=1) at ../Objects/genobject.c:219
#13 0x0000000000642588 in gen_send_ex (gen=gen@entry=0x7fffef9ac9e0,
arg=<optimized out>, exc=exc@entry=1, closing=closing@entry=1)
at ../Objects/genobject.c:287
#14 0x00000000005859e8 in gen_close (gen=0x7fffef9ac9e0, args=<optimized out>)
at ../Objects/genobject.c:391
#15 0x00000000006a32ef in gen_close_iter (yf=<optimized out>) at
../Objects/genobject.c:327
#16 0x0000000000585a44 in gen_close (gen=gen@entry=0x7ffff4258c20,
args=args@entry=0x0) at ../Objects/genobject.c:385
#17 0x0000000000585249 in _PyGen_Finalize (self=0x7ffff4258c20) at
../Objects/genobject.c:96
#18 0x000000000050b543 in finalize_garbage (tstate=0xa840d8
<_PyRuntime+166328>, collectable=0x7fffffffe710) at ../Modules/gcmodule.c:978
#19 gc_collect_main (tstate=0xa840d8 <_PyRuntime+166328>, generation=2,
n_collected=0x0, n_uncollectable=0x0, nofail=1) at ../Modules/gcmodule.c:1274
#20 0x000000000065570c in _PyGC_CollectNoFail.isra.0 (tstate=<optimized out>)
at ../Modules/gcmodule.c:2110
#21 0x000000000064698a in Py_FinalizeEx () at ../Python/pylifecycle.c:1833
#22 0x000000000064f974 in Py_RunMain () at ../Modules/main.c:682
#23 0x00000000006275c7 in Py_BytesMain (argc=<optimized out>, argv=<optimized
out>) at ../Modules/main.c:734
#24 0x00007ffff7cc31ca in __libc_start_call_main (main=main@entry=0x627530
<main>, argc=argc@entry=5, argv=argv@entry=0x7fffffffea78)
at ../sysdeps/nptl/libc_start_call_main.h:58
#25 0x00007ffff7cc3285 in __libc_start_main_impl (main=0x627530 <main>, argc=5,
argv=0x7fffffffea78, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffea68) at
../csu/libc-start.c:360
#26 0x0000000000627461 in _start ()
Am I right, that the error is in Python itself?
And maybe it is already solved: The error does not occur with
Python 3.12 anymore, at least not on amd64. Let's see, if the original
problem, on arm64, is fixed, too.
