[Upstream] python2.7 crashed with SIGSEGV in Application::IsInMain()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LibreOffice |
Fix Released
|
Undecided
|
Unassigned | ||
libreoffice (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: python-uno
3) What is expected to happen via a terminal:
cd ~/Desktop && wget https:/
is it does not segfault.
4) It segfaults.
Reproducible in Natty:
https:/
Precise:
https:/
Original Reporter Comments:
lsb_release -d
Description: Ubuntu 8.04.1
python-uno ersion: 1:2.4.1-1ubuntu2
The python script that causes this so small I can include it in line
{{{
#!/usr/bin/python
import sys, uno, unohelper
# get the uno component context from the PyUNO runtime
ctx = uno.getComponen
smgr = ctx.ServiceManager
xToolkit = smgr.createInst
unohelper.
}}}
Saving this to a text file "test.py" and executing
python test.py
produces
Segmentation fault
I installed debugging symbols; here's the stack trace i got from gdb
#0 0xb68b60c7 in Application:
#1 0xb6d9a2ba in VCLXToolkit_
#2 0xb7b14373 in cppu::OSingleFa
#3 0xb7b10180 in cppu::OSingleFa
#4 0xb7b110e9 in cppu::OFactoryC
#5 0xb7b13e18 in cppu::ORegistry
#6 0xb7b10180 in cppu::OSingleFa
#7 0xb7b110e9 in cppu::OFactoryC
#8 0xb76edbcd in stoc_smgr:
#9 0xb76e87d7 in stoc_smgr:
#10 0xb7f3bae3 in callVirtualMethod () from /usr/lib/
#11 0xb7f3bdcf in cpp_call () from /usr/lib/
#12 0xb7f3c230 in bridges:
#13 0xb6e85f3a in stoc_corefl:
#14 0xb6ed49cc in stoc_inv:
#15 0xb7bb526e in pyuno::
#16 0x0805cb37 in PyObject_Call ()
#17 0x080c7987 in PyEval_EvalFrameEx ()
#18 0x080cb0d7 in PyEval_EvalCodeEx ()
#19 0x080cb227 in PyEval_EvalCode ()
#20 0x080ea6d8 in PyRun_FileExFlags ()
#21 0x080ea979 in PyRun_SimpleFil
#22 0x08059335 in Py_Main ()
#23 0x080587f2 in main ()
{{{
$ dpkg -l '*dbgsym*'
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Description
+++-===
ii openoffice.
ii openoffice.
ii openoffice.
ii openoffice.
ii openoffice.
ii openoffice.
ii openoffice.
}}}
What should have happened:
A meaningful exception (or no exception), justifying python as a quick-test tool for ideas.
What did happen:
Whether I wanted to or not, a headlong dive into Ububtu / Debian package management.
First I posted
https:/
How do I step through the source code of installed packages?
(thanks for your responses)
and realised that
1. It's quite uncommon for people to debug / step through installed binary packages - the de-facto approach is to build from source with debugging information and optimisation off, and step through that.
2. kdbg / gdb has no way of knowing (that I can find) where the source code for a loaded library / program is, even with the debug info package for that package installed.
3. sudo apt-get source <packagename> doesn't apply to OpenOffice.org - I got the following message when I tried:
$ apt-get -s source openoffice.org-core
NOTICE: 'openoffice.org' packaging is maintained in the 'Bzr' version control system at:
http://
Please use:
bzr get http://
to retrieve the latest (possible unreleased) updates to the package.
4. According to the apt-get man page, in the "source" command section:
"Note that source packages are not tracked like binary packages, they exist only in the current directory and are similar to downloading source tar balls.".
5. <trawls the net some more> I found
http://
Building OpenOffice.org 2.2.1 from the latest apt-gettable Debian sources
It suggested that I
apt-get update
apt-get build-dep openoffice.org
apt-get source openoffice.org
(which doesn't apply to Ubuntu, I guess)
In Ubuntu, OpenOffice.org is stored on Bazaar
6. OpenOffice.org is stored on Bazaar in 'bzip2 compressed archives' so I couldn't just point gdb at the expanded source tree.
sudo apt-get install bzr
bzr get http://
for which I would need about 6GB of free disk space and (from previous experience).
dpkg-
7. dpkg-buildpackage -uc -us -rfakeroot failed as I needed to
sudo apt-get install bison flex-old libpam0g-dev libxaw7-dev libfontconfig1-dev zlib1g-dev libfreetype6-dev libx11-dev libsm-dev libxt-dev libxext-dev libxtst-dev libice-dev libsane-dev libxrender-dev libcupsys2-dev libarchive-zip-perl libpng12-dev libjpeg62-dev libxml2-dev libldap2-dev libexpat1-dev libgnomevfs2-dev fastjar imagemagick netpbm libxkbfile-dev libxinerama-dev x11proto-render-dev unixodbc-dev gperf libpq-dev libxrandr-dev translate-toolkit libgl1-mesa-dev libglu1-mesa-dev libcurl4-
Actually dpkg-buildpackage included version constraints in brackets for the required packages. I won't repeat them here as I don't want to waste your time unnecessarily.
From building it before on Fedora 8 this would take up most of the day on my puny 1GHz pentium III with only 512MB RAM.
8. The recommended location for source files
http://
Filesystem Hierarchy Standard
I found the section on
/usr/src Source code (optional)
I'm guessing that I need to install the source code here.
Speaking of Fedora, kdbg integration is somewhat more integrated and will recommend
debuginfo-
this downloads and installs debugging symbol information and the source code in a well known location.
9. The debugging information in the debugging packages doesn't include source file and line number information.
I eagerly look forward to a considered response.
Changed in openoffice: | |
importance: | Undecided → Unknown |
status: | New → Unknown |
Changed in openoffice: | |
status: | Unknown → New |
tags: | added: hardy |
summary: |
- [upstream] [hardy] python-uno segfaults + [Upstream] python2.7 crashed with SIGSEGV in Application::IsInMain() |
Changed in libreoffice (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in openoffice.org (Ubuntu): | |
status: | Triaged → Won't Fix |
tags: | added: i386 natty precise |
Changed in df-libreoffice: | |
importance: | Unknown → High |
status: | Unknown → Incomplete |
tags: | added: quantal raring |
description: | updated |
description: | updated |
Changed in df-libreoffice: | |
status: | Incomplete → Confirmed |
This appears to be an upstream issue it segfaults for me on upstream's openoffice.org 2.4.1 as well.