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", "credits" or "license" for more information.
[New Thread 0x7f54f6db36e0 (LWP 11909)]
[Switching to Thread 0x7f54f6db36e0 (LWP 11909)]
Breakpoint 1, _PyImport_LoadDynamicModule (name=0x7ffffedcfd20 "readline",
pathname=0x7ffffedcec30 "/usr/lib/python2.5/lib-dynload/readline_d.so",
fp=0x831540) at ../Python/importdl.c:28
28 ../Python/importdl.c: No such file or directory.
in ../Python/importdl.c
(gdb) c
Continuing.
>>> import _wc
Breakpoint 1, _PyImport_LoadDynamicModule (name=0x7ffffedcf4f0 "_wc",
pathname=0x7ffffedce400
"/usr/lib/python-support/python-subversion/python2.5/libsvn/_wc.so",
fp=0x853470) at ../Python/importdl.c:28
28 in ../Python/importdl.c
Observations
============
The python interpreter loads its own libraries as _d.so. This also applies to
other applications. I tried one, Numeric for which I installed the
debug-version. It too, loads a _d.so library for debugging. I searched the
Internet and found several python related makefile with some scheme to handle
*_d.so.
When I copy the _wc.so debug version, rename it to _wc_d.so and place it
in the same directory as the _wc.so, everything now works out of the box
(save for the PYTHONPATH env var). It does appear that the debug
architecture is to provide debug version libraires with a _d suffix and
place them in the same directory.
For the python libraires, there are 2 copies of each debug version library:
/usr/lib/debug/usr/lib/python2.5/lib-dynload/array.so
/usr/lib/python2.5/lib-dynload/array_d.so
However they have significant size differences. I have not seen the
/usr/lib/debug version being used, perhaps they are in a different context.
BugSquad
** Changed in: subversion (Ubuntu)
Status: New => Confirmed
--
debug symbols not found by gdb
https://bugs.launchpad.net/bugs/91845
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
