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.

Sign up for GitHub

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

Jump to bottom

python-2.7.3-r3: crash in visit_decref() #61436

Closed
mmokrejs mannequin opened this issue Feb 19, 2013 · 9 comments
Closed

python-2.7.3-r3: crash in visit_decref() #61436

mmokrejs mannequin opened this issue Feb 19, 2013 · 9 comments
Labels
type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@mmokrejs
Copy link
Mannequin

mmokrejs mannequin commented Feb 19, 2013

BPO 17234
Nosy @vstinner, @tiran

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-03-21.09:43:43.728>
created_at = <Date 2013-02-19.09:35:44.819>
labels = ['type-crash']
title = 'python-2.7.3-r3: crash in visit_decref()'
updated_at = <Date 2019-03-21.09:43:43.727>
user = 'https://bugs.python.org/mmokrejs'

bugs.python.org fields:

activity = <Date 2019-03-21.09:43:43.727>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-03-21.09:43:43.728>
closer = 'vstinner'
components = []
creation = <Date 2013-02-19.09:35:44.819>
creator = 'mmokrejs'
dependencies = []
files = []
hgrepos = []
issue_num = 17234
keywords = []
message_count = 9.0
messages = ['182371', '182374', '182375', '192569', '196118', '196119', '214534', '228567', '338535']
nosy_count = 5.0
nosy_names = ['mmokrejs', 'vstinner', 'christian.heimes', 'BreamoreBoy', 'Ramchandra Apte']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue17234'
versions = ['Python 2.7']
@mmokrejs
Copy link
Mannequin Author

mmokrejs mannequin commented Feb 19, 2013

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)

@mmokrejs mmokrejs mannequin added the type-crash A hard crash of the interpreter, possibly with a core dump label Feb 19, 2013
@RamchandraApte
Copy link
Mannequin

RamchandraApte mannequin commented Feb 19, 2013

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.

@RamchandraApte
Copy link
Mannequin

RamchandraApte mannequin commented Feb 19, 2013

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/

@tiran
Copy link
Member

tiran commented Jul 7, 2013

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.

@tiran tiran added the stale Stale PR or inactive for long period of time. label Jul 7, 2013
@mmokrejs
Copy link
Mannequin Author

mmokrejs mannequin commented Aug 25, 2013

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

@RamchandraApte
Copy link
Mannequin

RamchandraApte mannequin commented Aug 25, 2013

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

@BreamoreBoy
Copy link
Mannequin

BreamoreBoy mannequin commented Mar 23, 2014

I'm guessing that the status was inadvertently changed as this issue is only one year old. Could someone set it to open please.

@BreamoreBoy
Copy link
Mannequin

BreamoreBoy mannequin commented Oct 5, 2014

Should this be closed as I'm not aware of any similar problems with 2.7, particularly when this addresses 2.7.3.rc3?

@serhiy-storchaka serhiy-storchaka removed the stale Stale PR or inactive for long period of time. label Feb 10, 2015
@vstinner
Copy link
Member

The latest message from the reporter was at 2013-08-25: 6 years ago. I don't think that we will be able to continue to investigate the issue, so I close it as "out of date".

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@vstinner @tiran @serhiy-storchaka