classification
Title: python-2.7.3-r3: crash in visit_decref()
Type: crash Stage:
Components: Versions: Python 2.7
process
Status: languishing Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, Ramchandra Apte, christian.heimes, mmokrejs
Priority: normal Keywords:

Created on 2013-02-19 09:35 by mmokrejs, last changed 2014-10-05 13:56 by BreamoreBoy.

Messages (8)
msg182371 - (view) Author: Martin Mokrejs (mmokrejs) Date: 2013-02-19 09:35
Hi,
  I do see relatively often a crash in python. Here is one stacktrace from my Gentoo Linux running 3.7.4 kernel:

(gdb) where
#0  0x00007f624f340f08 in visit_decref () from /usr/lib64/libpython2.7.so.1.0
#1  0x00007f624f2a455a in list_traverse () from /usr/lib64/libpython2.7.so.1.0
#2  0x00007f624f3412c7 in collect () from /usr/lib64/libpython2.7.so.1.0
#3  0x00007f624f341f11 in _PyObject_GC_Malloc () from /usr/lib64/libpython2.7.so.1.0
#4  0x00007f624f2cdd59 in PyType_GenericAlloc () from /usr/lib64/libpython2.7.so.1.0
#5  0x00007f624f2d09c3 in type_call () from /usr/lib64/libpython2.7.so.1.0
#6  0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#8  0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#9  0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#11 0x00007f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0
#12 0x00007f624f32e53d in PyRun_StringFlags () from /usr/lib64/libpython2.7.so.1.0
#13 0x00007f624f30a44e in builtin_eval () from /usr/lib64/libpython2.7.so.1.0
#14 0x00007f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#15 0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#16 0x00007f624f2a104c in function_call () from /usr/lib64/libpython2.7.so.1.0
#17 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#18 0x00007f624f28a82f in instancemethod_call () from /usr/lib64/libpython2.7.so.1.0
#19 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#20 0x00007f624f30c9b7 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0
#21 0x00007f624612f807 in call_with_frame.isra.9 () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#22 0x00007f6246132080 in my_StartElementHandler () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#23 0x00007f6245ed0fb0 in doContent () from /usr/lib64/libexpat.so.1
#24 0x00007f6245ed21b4 in contentProcessor () from /usr/lib64/libexpat.so.1
#25 0x00007f6245ecce2a in XML_ParseBuffer () from /usr/lib64/libexpat.so.1
#26 0x00007f6246132d5b in xmlparse_Parse () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#27 0x00007f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#28 0x00007f624f296379 in gen_send_ex.isra.1 () from /usr/lib64/libpython2.7.so.1.0
#29 0x00007f624f2ce40f in wrap_next () from /usr/lib64/libpython2.7.so.1.0
#30 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#31 0x00007f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#32 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#33 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#34 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#35 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#36 0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#37 0x00007f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#38 0x00007f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0
#39 0x00007f624f32e750 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0
#40 0x00007f624f32f1cf in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#41 0x00007f624f3407e2 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#42 0x00007f624ec8f91d in __libc_start_main () from /lib64/libc.so.6
#43 0x000000000040094d in _start ()
(gdb)
msg182374 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-02-19 12:36
Sorry, but this doesn't give enough information to fix it, nevertheless reproduce it. Please tell us what Python was running. Also run python with -X faulthandler and give the results.
msg182375 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-02-19 12:39
Oops. Please ignore the sentence about adding -X faulthandler. Please install the faulthandler module [0] and run "import faulthandler;faulthandler.enable()", and then reproduce the bug.

^0 https://pypi.python.org/pypi/faulthandler/
msg192569 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-07-07 14:57
Are you using any 3rd party components with C extension modules? That kind of error is often caused by an extension with erroneous reference counting.
msg196118 - (view) Author: Martin Mokrejs (mmokrejs) Date: 2013-08-25 11:02
Hi Ramchandra and Christian,
  I am using numpy, matplotlib, expat/cElementTree, doing a lot of os.Popen calls. But I think the problem is taht I have huge lists and when I do not need them I do del(_mylist) in the code ASAP. That probably causes a lot of churn.

  Here is one stacktrace I just got with the faulthandler installed. It does not show in the trace any 3rd-party module so can I conclude it is a core python bug? Just recompiling with "-ggdb" so eventually will have better stacktraces.




  Does this help? I don't have the gdb stacktrace as I recompiled the binary now again ... :(

Fatal Python error: /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:1009 object at 0x40c0a60 has negative ref count -1
Fatal Python error: Aborted
msg196119 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-08-25 11:27
> Here is one stacktrace I just got with the faulthandler installed. It does not show in the trace any 3rd-party module so can I conclude it is a core python bug? Just recompiling with "-ggdb" so eventually will have better stacktraces.

I'm a C noob but I think one can't conclude that it is a core python bug as the ref count could have been messed with, then sometime later the error may occur and GDB's stacktrace will show the latter.
Or in pseudo-code:

mess_with_ref_count() # In 3rd party code
non_3rd_party_code() #the error may occur here, after the refcount was messed with, and gdb will show this function in the stack trace

BTW, run ./configure with the --with-pydebug option, that makes Python perform extra checks on refcounts and other things [0]

^0 http://docs.python.org/devguide/setup.html#compiling-for-debugging
msg214534 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 01:45
I'm guessing that the status was inadvertently changed as this issue is only one year old.  Could someone set it to open please.
msg228567 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-10-05 13:56
Should this be closed as I'm not aware of any similar problems with 2.7, particularly when this addresses 2.7.3.rc3?
History
Date User Action Args
2014-10-05 13:56:00BreamoreBoysetmessages: + msg228567
2014-03-23 01:45:37BreamoreBoysetnosy: + BreamoreBoy
messages: + msg214534
2013-08-25 11:27:47Ramchandra Aptesetmessages: + msg196119
2013-08-25 11:02:02mmokrejssetmessages: + msg196118
2013-07-07 14:57:22christian.heimessetstatus: open -> languishing
nosy: + christian.heimes
messages: + msg192569

2013-02-19 12:39:41Ramchandra Aptesetmessages: + msg182375
2013-02-19 12:36:54Ramchandra Aptesetnosy: + Ramchandra Apte
messages: + msg182374
2013-02-19 09:35:44mmokrejscreate