Abraham Macias <amac...@gruposolutia.com> added the comment:
Thank you Victor for your response.
I follow your advice but the output was an error in a different point of the
code and I couldn't see any information about memory allocations.
But, I compiled Python 3.7 from source and modified the "Python/errors.c" code
where the problem is detected in the following way:
void
PyErr_SetObject(PyObject *exception, PyObject *value)
{
PyThreadState *tstate = PyThreadState_GET();
PyObject *exc_value;
PyObject *tb = NULL;
_PyErr_StackItem *exc_info = NULL;
if (exception != NULL &&
!PyExceptionClass_Check(exception)) {
PyErr_Format(PyExc_SystemError,
"exception %R not a BaseException subclass",
exception);
return;
}
Py_XINCREF(value);
exc_info = _PyErr_GetTopmostException(tstate);
exc_value = exc_info->exc_value;
if (exc_value != NULL && exc_value != Py_None) {
/* Implicit exception chaining */
printf("exc_value=%p\n", exc_value);
printf("exc_info=%p\n", exc_info);
printf("tstate=%p\n", tstate);
printf("traceback=%p\n", exc_info->exc_traceback);
printf("exc_value.ob_type=%p\n", exc_value->ob_type);
Py_INCREF(exc_value);
In this way I had the pointer printed just before the error happening:
exc_value=0x73726573756e69
exc_info=0x7f83bfafacb8
tstate=0x5605dcd41330
traceback=0x6b6f0100
Segmentation fault (core dumped)
And by using gdb I printed the memory contents:
(gdb) x/32c 0x7f83bfafacb8
0x7f83bfafacb8: 111 'o' 115 's' 99 'c' 99 'c' 46 '.' 97 'a' 100 'd' 109 'm'
0x7f83bfafacc0: 105 'i' 110 'n' 117 'u' 115 's' 101 'e' 114 'r' 115 's' 0 '\000'
0x7f83bfafacc8: 0 '\000' 1 '\001' 111 'o' 107 'k' 0 '\000'
0 '\000' 0 '\000' 0 '\000'
0x7f83bfafacd0: 0 '\000' 0 '\000' 0 '\000' -16 '\360'
63 '?' 0 '\000' 0 '\000' 0 '\000'
If you check the original post you will see:
#15 0x000000000053f732 in PyEval_EvalFrameEx (throwflag=0,
f=Frame 0x17882e8, for file
/usr/local/lib/python3.7/dist-packages/bson/__init__.py, line 1013, in
decode_all
(data=b'V\x00\x00\x00\x03cursor\x00=\x00\x00\x00\x04firstBatch\x00\x05\x00\x00\x00\x00\x12id\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02ns\x00\x13\x00\x00\x00gecoscc.adminusers\x00\x00\x01ok\x00\x00\x00\x00\x00\x00\x00\xf0?\x00',
codec_options=<CodecOptions at remote 0x7f1ab4ac2208>, view=<memoryview at
remote 0x7f1ab5375708>, data_len=86, docs=[], position=0, end=85)) at
../Python/ceval.c:547
So, somehow the "oscc.adminusers\x00\x00\x01ok\x00" part of the message is
written over the exc_info memory.
That makes me think that this is a problem in pymongo module. I will report
this bug to them.
Thank you very much!
----------
resolution: -> not a bug
stage: -> resolved
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue43626>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
