debug symbols not found by gdb

[James Henstridge]

Binary package hint: subversion

I ran into a crash in a program that included a frame in /var/lib/python-support/python2.4/libsvn/_wc.so. To try and find out what was going on I installed the corresponding debugging symbols package (python-subversion-dbg).

However, it installed the debug symbols to /usr/lib/debug/usr/lib/python2.4/site-packages/libsvn/_wc.so which gdb couldn't find.

I had to create a symlink to allow gdb to find the python-subversion debugging symbols:

    $ ls -l /usr/lib/debug/var/lib/python-support/python2.4
    lrwxrwxrwx 1 root root 40 2007-03-13 15:15 /usr/lib/debug/var/lib/python-support/python2.4 -> ../../../usr/lib/python2.4/site-packages

The system is running feisty as of today on AMD64. I have python-subversion 1.4.2dfsg1-2ubuntu5 installed.

[Adam Niedling (krychek)]

Feisty is not supported anymore.

[James Henstridge (jamesh)]

While Feisty may be nearing the end of its support lifetime, the problem still persists in newer releases. Did you actually test the bug before marking it invalid?

I just tried installing python-subversion-dbgsym_1.5.1dfsg1-1ubuntu2_amd64.ddeb on my machine (running Intrepid), and could easily reproduce the problem. I set a break point on svn_wc_version function and then ran the equivalent Python function. The back trace started with:

  #0 0x00007f2743c624e0 in svn_wc_version () from /usr/lib/libsvn_wc-1.so.1
  #1 0x00007f2745f45b6a in ?? ()
     from /var/lib/python-support/python2.5/libsvn/_wc.so

After adding a symlink as described in the original description (although for Python 2.5 rather than 2.4), I got the following back trace:

  #0 0x00007f6ab301e4e0 in svn_wc_version () from /usr/lib/libsvn_wc-1.so.1
  #1 0x00007f6ab5301b6a in _wrap_svn_wc_version (self=<value optimized out>,
      args=0x7f6ab6f25050) at subversion/bindings/swig/python/svn_wc.c:3123

(Note the difference in the second stack frame).

[Gaetan Nadon (memsize)]

James,

I can observe the same problem, the debug version of the Subversion python libraries is not loaded. For that reason, I've moved the bug report to Confirm. It's not the same scenario as what you described, but it's enough to show there is something wrong in that area. I devised a test case to demonstrate the situation.

Details of the test case for anyone to reproduce:

Required packages
=================
python 2.5.2-0ubuntu1
python-dbg 2.5.2-0ubuntu1
python-subversion 1.4.6dfsg1-2ubuntu1
python-subversion-dbg 1.4.6dfsg1-2ubuntu1

Environment Variables
=====================
PYTHONPATH=/usr/lib/python-support/python-subversion/python2.5/libsvn

This should not be required, but the Subversion app does not add a .pth file in the site-packages as others do. One must then take an action to provide the path to the Subversion libraries. You can verify this by inoking the Python interpreter and importing the _wc module.

@ubuntu:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _wc
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named _wc
>>>

Displaying the effective library path
=====================================

>>> import sys
>>> print "\n".join(sys.path)

/usr/lib/python-support/python-subversion/python2.5/libsvn
/usr/lib/python25.zip
/usr/lib/python2.5
/usr/lib/python2.5/plat-linux2
/usr/lib/python2.5/lib-tk
/usr/lib/python2.5/lib-dynload
/usr/local/lib/python2.5/site-packages
/usr/lib/python2.5/site-packages
/usr/lib/python2.5/site-packages/Numeric
/usr/lib/python2.5/site-packages/PIL
/usr/lib/python2.5/site-packages/gst-0.10
/var/lib/python-support/python2.5
/usr/lib/python2.5/site-packages/gtk-2.0
/var/lib/python-support/python2.5/gtk-2.0
/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode
>>>

Note that the Numeric app is already in the path without any actions on our part. None of the paths point to a debug version of the librairies either. So far we have been using the /usr/bin/python executable.

Run the Debugger and the debug version of Python
================================================
We will set a breakpoint in the Python code where it loads the shared libraries. This is how we can tell if the debug version have been loaded or not. We then run the python interpreter and it will stop in the readline module. Note the library module name is readline_d.so in the same directory as readline.so. Type c to continue execution.

We are ready to import the Subversion _wc module which should load the _wc debug version somehow. However, the non-debug version is loaded. This concluded the demonstration for the bug report.

@ubuntu:~/python$ gdb -q --args python-dbg
(gdb) b _PyImport_LoadDynamicModule
Breakpoint 1 at 0x4d8bd8: file ../Python/importdl.c, line 28.
(gdb) run
Starting program: /usr/bin/python-dbg
[Thread debugging using libthread_db enabled]
Python 2.5.2 (r252:60911, Jul 31 2008, 17:30:47)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "c...

[James Henstridge (jamesh)]

The _d.so modules are compiled to work with Python's debug interpreter (which includes reference count debugging, etc) and don't have their debug symbols stripped, which accounts for the size difference.

The non-debug versions of extensions are stripped and have separate debug symbols. This bug is about gdb not finding those symbols due to the symlink tricks stopping gdb from matching the path names.

[Maarten Bezemer (veger)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect 91845 and any other logs that are relevant for this particular issue.

[Launchpad Janitor (janitor)]

[Expired for subversion (Ubuntu) because there has been no activity for 60 days.]