<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - linux stack backtrace truncated in python crash"
href="http://llvm.org/bugs/show_bug.cgi?id=18656">18656</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>linux stack backtrace truncated in python crash
</td>
</tr>
<tr>
<th>Product</th>
<td>lldb
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>All Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>lldb-dev@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Reporter</th>
<td>tfiala@google.com
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>When tracking down this bug:
<a class="bz_bug_link
bz_status_NEW "
title="NEW --- - tests: seg faults in python object cleanup during python shutdown"
href="show_bug.cgi?id=18655">http://llvm.org/bugs/show_bug.cgi?id=18655</a>
I'm finding that that /usr/bin/python core file backtrace as shown in
post-mortem debugging with lldb is not giving a complete backtrace:
(lldb) target create --core ./core /usr/bin/python
Core file '/mnt/ssd/work/svn/lgs/build/core' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0, 0x00007fa54badd425
libc.so.6`__GI_raise(sig=<unavailable>) + 53 at raise.c:64, name = 'python',
stop reason = signal SIGABRT
frame #0: 0x00007fa54badd425 libc.so.6`__GI_raise(sig=<unavailable>) + 53
at raise.c:64
(lldb) bt
* thread #1: tid = 0, 0x00007fa54badd425
libc.so.6`__GI_raise(sig=<unavailable>) + 53 at raise.c:64, name = 'python',
stop reason = signal SIGABRT
* frame #0: 0x00007fa54badd425 libc.so.6`__GI_raise(sig=<unavailable>) + 53
at raise.c:64
frame #1: 0x00007fa54bae0b8b libc.so.6`__GI_abort + 379 at abort.c:91
frame #2: 0x000000000053ed5d python`Py_FatalError + 45
(lldb) exit
That's the entirety of it. This is with top of tree lldb (trunk) as of this
morning (7:30 AM PST).
In gdb, I get this backtrace (same core, same python exe):
tfiala@tfiala2:~/lldb/svn/lgs/build$ gdb /usr/bin/python core
GNU gdb (GDB) 7.6-gg23
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <<a href="http://gnu.org/licenses/gpl.html">http://gnu.org/licenses/gpl.html</a>>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux".
<<a href="http://go/gdb-home">http://go/gdb-home</a> FAQ: <a href="http://go/gdb-faq">http://go/gdb-faq</a> Email: gdb-team IRC: gdb>
Reading symbols from /usr/bin/python...done.
WARNING: no debugging symbols found in /usr/bin/python.
Either the binary was compiled without debugging information
or the debugging information was removed (e.g., with strip or strip -g).
Debugger capabilities will be very limited.
For further information: <a href="http://wiki/Main/GdbFaq#No_debugging_symbols_found">http://wiki/Main/GdbFaq#No_debugging_symbols_found</a>
[New LWP 23442]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/grte/v3/lib64/libthread_db.so.1".
Core was generated by `python ../llvm/tools/lldb/test/dotest.py -C gcc
--executable /usr/local/google/'.
Program terminated with signal 6, Aborted.
#0 0x00007fa54badd425 in __GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007fa54badd425 in __GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007fa54bae0b8b in __GI_abort () at abort.c:91
#2 0x000000000053ed5d in Py_FatalError ()
#3 0x00000000004925cf in ?? ()
#4 0x000000000047f797 in ?? ()
#5 0x00007fa5462c0fd9 in lldb_private::PythonObject::Reset (this=0x1b63850,
py_obj=0x0)
at
/mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/../../include/lldb/Interpreter/PythonDataObjects.h:65
#6 0x00007fa5462c0f35 in lldb_private::PythonObject::~PythonObject
(this=0x1b63850, __in_chrg=<optimized out>)
at
/mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/../../include/lldb/Interpreter/PythonDataObjects.h:51
#7 0x00007fa5462c3a50 in
lldb_private::ScriptInterpreterPython::~ScriptInterpreterPython
(this=0x1b63810,
__in_chrg=<optimized out>) at
/mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/ScriptInterpreterPython.cpp:205
#8 0x00007fa5462c3ab4 in
lldb_private::ScriptInterpreterPython::~ScriptInterpreterPython
(this=0x1b63810,
__in_chrg=<optimized out>) at
/mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/ScriptInterpreterPython.cpp:207
#9 0x00007fa5461f16d4 in
std::default_delete<lldb_private::ScriptInterpreter>::operator()
(this=0x1798f38, __ptr=
0x1b63810) at
/usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:67
#10 0x00007fa5461f08d9 in std::unique_ptr<lldb_private::ScriptInterpreter,
std::default_delete<lldb_private::ScriptInterpreter> >::~unique_ptr
(this=0x1798f38, __in_chrg=<optimized out>)
at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:184
#11 0x00007fa5461edaab in lldb_private::CommandInterpreter::~CommandInterpreter
(this=0x1798cf0,
__in_chrg=<optimized out>) at
/mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:2097
#12 0x00007fa5461edba0 in lldb_private::CommandInterpreter::~CommandInterpreter
(this=0x1798cf0,
__in_chrg=<optimized out>) at
/mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:2099
#13 0x00007fa54608541a in
std::default_delete<lldb_private::CommandInterpreter>::operator()
(this=0x18302b8,
__ptr=0x1798cf0) at
/usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:67
#14 0x00007fa54608396d in std::unique_ptr<lldb_private::CommandInterpreter,
std::default_delete<lldb_private::CommandInterpreter> >::~unique_ptr
(this=0x18302b8, __in_chrg=<optimized out>)
at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:184
#15 0x00007fa54607b500 in lldb_private::Debugger::~Debugger (this=0x182ff20,
__in_chrg=<optimized out>)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Core/Debugger.cpp:668
#16 0x00007fa54607b60e in lldb_private::Debugger::~Debugger (this=0x182ff20,
__in_chrg=<optimized out>)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Core/Debugger.cpp:671
#17 0x00007fa546089c3a in std::_Sp_counted_ptr<lldb_private::Debugger*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose (
this=0x1b3c330) at
/usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:290
#18 0x00007fa545f602b4 in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x1b3c330)
at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:144
#19 0x00007fa545f5fd67 in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x1c12688,
__in_chrg=<optimized out>) at
/usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:546
#20 0x00007fa545f65cfc in std::__shared_ptr<lldb_private::Debugger,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr (
this=0x1c12680, __in_chrg=<optimized out>) at
/usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:781
#21 0x00007fa545f65d16 in std::shared_ptr<lldb_private::Debugger>::~shared_ptr
(this=0x1c12680, __in_chrg=<optimized out>)
at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr.h:93
#22 0x00007fa545f6fd26 in lldb::SBDebugger::~SBDebugger (this=0x1c12680,
__in_chrg=<optimized out>)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/API/SBDebugger.cpp:247
#23 0x00007fa54621c35f in _wrap_delete_SBDebugger (args=0x17a64d0) at
LLDBWrapPython.cpp:14646
#24 0x00000000004f7496 in PyObject_Call ()
---Type <return> to continue, or q <return> to quit---
#25 0x00000000004f87cb in PyObject_CallFunctionObjArgs ()
#26 0x00007fa5461fb73d in SwigPyObject_dealloc (v=0x1d45600) at
LLDBWrapPython.cpp:1697
#27 0x000000000054878d in ?? ()
#28 0x000000000045d198 in ?? ()
#29 0x0000000000555d65 in ?? ()
#30 0x00000000004bef09 in PyDict_SetItem ()
#31 0x000000000044c9b9 in _PyModule_Clear ()
#32 0x00000000004369c8 in PyImport_Cleanup ()
#33 0x000000000047ec4c in Py_Finalize ()
#34 0x000000000047f148 in Py_Exit ()
#35 0x000000000047f27c in ?? ()
#36 0x0000000000424a8c in PyRun_SimpleFileExFlags ()
#37 0x0000000000425cb6 in Py_Main ()
#38 0x00007fa54bac876d in __libc_start_main (main=0x41bb00 <main>, argc=8,
ubp_av=0x7fffe1597538, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffe1597528)
at libc-start.c:226
#39 0x000000000041bb31 in _start ()
(gdb)
Perhaps a stack unwinding bug?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>