gdb unable to read python frame information

[Wesley]

Hi guys,
My env: centos 6.5 64 bit; gdb 7.1; python 2.6.6

I wanna use gdb to attach my running python scripts.
Successfully import libpython in gdb, but seems all py operations failed to read python information.

Here is the snippet:
(gdb) python
>import libpython
>end
(gdb) py-bt
#3 (unable to read python frame information)
#5 (unable to read python frame information)
#7 (unable to read python frame information)
#9 (unable to read python frame information)
#18 (unable to read python frame information)
#22 (unable to read python frame information)
#26 (unable to read python frame information)
#28 (unable to read python frame information)
#29 (unable to read python frame information)
#38 (unable to read python frame information)
#39 (unable to read python frame information)
#40 (unable to read python frame information)
#42 (unable to read python frame information)
#44 (unable to read python frame information)
#45 (unable to read python frame information)
#47 (unable to read python frame information)
#49 (unable to read python frame information)
#51 (unable to read python frame information)
#55 (unable to read python frame information)
#62 (unable to read python frame information)
#64 (unable to read python frame information)
#76 (unable to read python frame information)
#88 (unable to read python frame information)
#100 (unable to read python frame information)
(gdb) py-locals
Unable to read information on python frame
(gdb)

Is there anything wrong?
Thanks.
Wesley

[dieter]

Wesley <nis...@gmail.com> writes:

> I wanna use gdb to attach my running python scripts.
> Successfully import libpython in gdb, but seems all py operations failed to read python information.
>
> Here is the snippet:
> (gdb) python
>>import libpython
>>end
> (gdb) py-bt
> #3 (unable to read python frame information)
> #5 (unable to read python frame information)

The simplest possible interpretation would be that your
Python lacks debugging symbols. That often happens with
system installed Python installations (which usually are stripped
to the bare minimal symbol set - as "normal" users do not need
debugging).

Try with a Python that you have generated yourself.

[Wesley]

Then, how to make python get debug symbols?

Install python from source with some special configure options?

[Neal Becker]

dieter wrote:

> Wesley <nis...@gmail.com> writes:
>
>> I wanna use gdb to attach my running python scripts.
>> Successfully import libpython in gdb, but seems all py operations failed to
>> read python information.
>>
>> Here is the snippet:
>> (gdb) python
>>>import libpython
>>>end
>> (gdb) py-bt
>> #3 (unable to read python frame information)
>> #5 (unable to read python frame information)
>

> The simplest possible interpretation would be that your
> Python lacks debugging symbols. That often happens with
> system installed Python installations (which usually are stripped
> to the bare minimal symbol set - as "normal" users do not need
> debugging).
>
> Try with a Python that you have generated yourself.

You probably need to install the python-debuginfo package

[Ned Deily]

In article <c583c21d-d0a2-449a...@googlegroups.com>,

Wesley <nis...@gmail.com> wrote:
> Then, how to make python get debug symbols?
>
> Install python from source with some special configure options?

If your distribution doesn't have a debug version of Python and you need
to build your own, add --with-pydebug to your ./configure options. See:

./configure --help

--
Ned Deily,
n...@acm.org

[dieter]

Wesley <nis...@gmail.com> writes:

> Install python from source with some special configure options?

When I last generated Python from source, there was no need
to do anything special to get debugging symbols (the option
("gcc") option "-g" was automatically included).

[Wesley]

1. install gdb from source with configure option --with-python

2. install python from source with configure option --with-pydebug

3. Got error in gdb here:
2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
(gdb) py-bt
Undefined command: "py-bt". Try "help".

(gdb) python
>import libpython
>end

Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/local/share/gdb/python/libpython.py", line 49, in <module>
_type_size_t = gdb.lookup_type('size_t')
gdb.error: No type named size_t.
Error while executing Python code.
(gdb)

[Wesley]

python debuginfo is installed...
Still,py-bt, py-locals.etc cannot read python frame

[Mark Lawrence]

On 08/03/2014 13:32, Wesley wrote:
> python debuginfo is installed...
> Still,py-bt, py-locals.etc cannot read python frame
>

If you don't provide context people are less likely to help you.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Wesley]

Now I use gdb python -p <pid>
then, import libpython
py-bt is null, py-locals raise here:
Unable to locate python frame

What's going on...

[Wesley]

So, let me clarify here, in order to try, I get a clean machine.

Centos 6.5 64bit.
Now , I try this:
1. install gdb 7.7 from source , with configure option --with-python

2. install python 2.6.6 from source, with configure option --with-pydebug

3. run a python script

4. from command line, gdb python -p <pid> to attach the running script

5. within gdb, issue python, import libpython, end
no errors
6. py-bt outputs nothing, py-locals says Unable to locate python frame
here is the snippet:
[root@localhost Python-2.6.6]# gdb python 52315
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...done.
Attaching to program: /home/nipen/test/Python-2.6.6/python, process 52315
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00000030a98e15c3 in ?? ()
(gdb) bt
#0 0x00000030a98e15c3 in ?? ()
#1 0x00007f4cf68d1219 in ?? ()
#2 0x0000000000000000 in ?? ()

(gdb) py-bt
Undefined command: "py-bt". Try "help".

(gdb) python
>import libpython
>end
(gdb) py-bt

(gdb)
(gdb) py-locals

Unable to locate python frame

(gdb)

[Wesley]

Anybody has suggestions?

This really makes me crazy...

[Mark Lawrence]

On 09/03/2014 03:49, Wesley wrote:
> Anybody has suggestions?
>
> This really makes me crazy...
>

What makes you crazy? You keep sending messages with no context. We
might be smart, but we're not (yet :) mind readers.

[Terry Reedy]

On 3/9/2014 10:57 AM, Mark Lawrence wrote:
> On 09/03/2014 03:49, Wesley wrote:
>> Anybody has suggestions?

Don't expect crazy things.
Send suggestions to the right place (a gdb list for a gdb enhancement).

>> This really makes me crazy...

> What makes you crazy?

The supposed fact that GnuDeBug does not understand Python frames on the
stack.

> You keep sending messages with no context. We
> might be smart, but we're not (yet :) mind readers.

But we do speculate ;-)

--
Terry Jan Reedy

[Wesley]

What's information do you want?

I told the OS, gdb and python version.

And my operation steps.

What do you want more, then, I can type here.

Wesley

[Mark Lawrence]

Context, you just keep sending messages like the above which on its own
is meaningless. Why should anybody answer your question when you can't
be bothered to supply all the needed data in one hit?

[Wesley]

If you don't read the loop from the top, and don't tell me exactly what you want by just keep saying context, please ingore this post.

Thanks.
Wesley

在 2014年3月10日星期一UTC+8上午9时48分41秒，Mark Lawrence写道：

[Mark Lawrence]

Ah, that explains things, you're using the notoriously bug ridden google
groups. You could read and action this
https://wiki.python.org/moin/GoogleGroupsPython but I'd suggest you
equip yourself with a decent email client. Thunderbird comes highly
recommended.

[dieter]

Wesley <nis...@gmail.com> writes:

> So, let me clarify here, in order to try, I get a clean machine.
>
> Centos 6.5 64bit.
> Now , I try this:
> 1. install gdb 7.7 from source , with configure option --with-python
>
> 2. install python 2.6.6 from source, with configure option --with-pydebug
>
> 3. run a python script
>
> 4. from command line, gdb python -p <pid> to attach the running script
>
> 5. within gdb, issue python, import libpython, end
> no errors
> 6. py-bt outputs nothing, py-locals says Unable to locate python frame
> here is the snippet:
> [root@localhost Python-2.6.6]# gdb python 52315
> GNU gdb (GDB) 7.7

> ....

> Attaching to program: /home/nipen/test/Python-2.6.6/python, process 52315
> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> 0x00000030a98e15c3 in ?? ()
> (gdb) bt
> #0 0x00000030a98e15c3 in ?? ()
> #1 0x00007f4cf68d1219 in ?? ()
> #2 0x0000000000000000 in ?? ()

This looks like a very strange backtrace on C level as well.

The most natural explanation would be: your process is in a very strange
state (due to some C level problem). But, of course, your
"gdb" might have general problems, as well.

[dieter]

Mark Lawrence <bream...@yahoo.co.uk> writes:
> On 10/03/2014 01:06, Wesley wrote:

> ...

> Context, you just keep sending messages like the above which on its
> own is meaningless.

The original poster has send messages lacking important pieces
of information -- but on request from the list, he has fixed this
initial error. Thus, on his side, there was progress ;-)

[dieter]

Wesley <nis...@gmail.com> writes:

> If you don't read the loop from the top, and don't tell me exactly what you want by just keep saying context, please ingore this post.

You are doing things only a few people do: trying to debug
a Python process on C level -- and you observe really strange things.
It is very difficult to guess from the distance what goes wrong.

Apparently, your gdb sees a very strange state of the debugged
process. But why?

Missing symbols was the first guess (the
gdb output you have provided does not suggest this - but
I have not seen the "reading symbols from "python" ..."; thus,
there may still be a problem with this).

A runaway process is another guess.

Some gdb problem another one.


I would approach the situation by simplifying the setup.
Instead of attaching a running Python process, I would
use "gdb python"; then "run"; then "CTRL-C" and there look
what "bt" gives you (this should demonstrate whether your
"gdb" is set up correctly and can debug Python on C level).
Then you write an infinitely running function in Python,
run it and again interrupt with "gdb" to see whether the "py-*"
commands are working. If this all work, you come again
to your actual task -- understanding what your python process
is doing.

[Wesley]

[root@localhost ~]# gdb python
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...Reading symbols from /usr/lib/debug/usr/bin/python2.6.debug...done.
done.
(gdb) run
Starting program: /usr/bin/python
warning: the debug information found in "/usr/lib/debug//usr/lib64/libpython2.6.so.1.0.debug" does not match "/usr/lib64/libpython2.6.so.1.0" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug" does not match "/usr/lib64/libpython2.6.so.1.0" (CRC mismatch).

[Thread debugging using libthread_db enabled]
Python 2.6.6 (r266:84292, Nov 22 2013, 12:16:22)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
Program received signal SIGTSTP, Stopped (user).
0x00000034214e15c3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82
82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install python-2.6.6-51.el6.x86_64

Seems no debuginfo installed, but actually I have installed before, here is check:

root@localhost ~]# debuginfo-install python-2.6.6-51.el6.x86_64
Loaded plugins: auto-update-debuginfo, fastestmirror, refresh-packagekit
enabling epel-debuginfo
Loading mirror speeds from cached hostfile
epel/metalink | 4.7 kB 00:00
epel-debuginfo/metalink | 4.9 kB 00:00
* base: mirrors.yun-idc.com
* epel: mirrors.hustunique.com
* epel-debuginfo: mirrors.hustunique.com
* extras: mirrors.yun-idc.com
* rpmforge: mirror.hmc.edu
* updates: mirrors.stuhome.net
adobe-linux-x86_64 | 951 B 00:00
base | 3.7 kB 00:00
debug | 2.5 kB 00:00
debug/primary_db | 966 kB 00:06
epel | 4.2 kB 00:00
epel/primary_db | 6.0 MB 01:19
epel-debuginfo | 3.0 kB 00:00
epel-debuginfo/primary_db | 587 kB 00:07
extras | 3.4 kB 00:00
google64 | 951 B 00:00
rpmforge | 1.9 kB 00:00
updates | 3.4 kB 00:00
Checking for new repos for mirrors
Package matching python-debuginfo-2.6.6-51.el6.x86_64 already installed. Checking for update.
Package glibc-debuginfo-2.12-1.132.el6.x86_64 already installed and latest version
Package glibc-debuginfo-2.12-1.132.el6.x86_64 already installed and latest version
Package glibc-debuginfo-2.12-1.132.el6.x86_64 already installed and latest version
Package glibc-debuginfo-2.12-1.132.el6.x86_64 already installed and latest version
Package glibc-debuginfo-2.12-1.132.el6.x86_64 already installed and latest version
Package matching python-debuginfo-2.6.6-51.el6.x86_64 already installed. Checking for update.
Package glibc-debuginfo-2.12-1.132.el6.x86_64 already installed and latest version
No debuginfo packages available to install

在 2014年3月10日星期一UTC+8下午3时28分30秒，dieter写道：

[Wesley]

Now, I fixed the problem...

Instead of python2.6.6, for python 2.7 it's OK..

Why? gdb does not support python 2.6.6?

Is it related to python-gdb.py? I googled a lot, seems only has python2.7-gdb.py, no python2.6-gdb.py.


在 2014年3月10日星期一UTC+8下午3时28分30秒，dieter写道：

[dieter]

Wesley <nis...@gmail.com> writes:
> ...

> [root@localhost ~]# gdb python
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)

> This GDB was configured as "x86_64-redhat-linux-gnu".

> Reading symbols from /usr/bin/python...Reading symbols from /usr/lib/debug/usr/bin/python2.6.debug...done.
> done.
> (gdb) run
> Starting program: /usr/bin/python
> warning: the debug information found in "/usr/lib/debug//usr/lib64/libpython2.6.so.1.0.debug" does not match "/usr/lib64/libpython2.6.so.1.0" (CRC mismatch).
>
> warning: the debug information found in "/usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug" does not match "/usr/lib64/libpython2.6.so.1.0" (CRC mismatch).

This indicates that there is a problem between the executed code
and the debug information. Apparently, they do not match.

An installation problem might be the cause - maybe, a packaging problem.


Have you not told us that you have build your own Python from
source? Usually, such a Python would not reside under "/usr/bin"
but more likely under "/usr/local/bin" (of course, doing special
things, you can force a build from source to install unter "/usr/bin",
but this usually is not advicable -- it is potentially interfering with
system installed components).

If you have generated your own Python, you must ensure that it
is consistently used (for all the cases you are concerned by).

[dieter]

Wesley <nis...@gmail.com> writes:

> Now, I fixed the problem...
>
> Instead of python2.6.6, for python 2.7 it's OK..
>
> Why? gdb does not support python 2.6.6?

gdb supports python 2.6.6 as well (it is a C level debugger with
very few dependencies on Python).

Your reports seem to suggest that your Python 2.6.6 installation
is somehow screwed up - for whatever reason.

> Is it related to python-gdb.py?

Very unlikely.