systray.py crashed with SIGSEGV

Bug #860680 reported by Ron Brown
174
This bug affects 20 people
Affects Status Importance Assigned to Milestone
HPLIP
Invalid
Undecided
Unassigned
hplip (Ubuntu)
Invalid
Medium
Unassigned
pango (Ubuntu)
New
Medium
Unassigned
pygobject-2 (Ubuntu)
New
Medium
Unassigned
python-defaults (Ubuntu)
New
Medium
Unassigned

Bug Description

system reboot and after loading the desktop the error happened.

ProblemType: Crash
DistroRelease: Ubuntu 11.10
Package: hplip-data 3.11.7-1ubuntu2
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 1.23-0ubuntu1
Architecture: amd64
CrashCounter: 1
Date: Tue Sep 27 11:33:43 2011
EcryptfsInUse: Yes
ExecutablePath: /usr/share/hplip/systray.py
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110922)
InterpreterPath: /usr/bin/python2.7
Lpstat: device for Officejet6500: hp:/net/Officejet_6500_E709n?ip=10.80.0.11
MachineType: Dell Inc. Inspiron N7010
PackageArchitecture: all
Papersize: letter
PpdFiles: Officejet6500: HP Officejet 6500 e709n hpijs, 3.11.7
ProcCmdline: python /usr/bin/hp-systray
ProcCwd: /home/rbrown
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-11-generic root=UUID=e545f842-1c5b-4880-b81d-75cfaeef4f0c ro quiet splash vt.handoff=7
SegvAnalysis:
 Segfault happened at: 0x49c60b: mov 0x10(%rax),%rdi
 PC (0x0049c60b) ok
 source "0x10(%rax)" (0x00000010) not located in a known VMA region (needed readable region)!
 destination "%rdi" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: hplip
StacktraceTop:
 ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
Title: systray.py crashed with SIGSEGV
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 10/20/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A09
dmi.board.name: 08VFX1
dmi.board.vendor: Dell Inc.
dmi.board.version: A09
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A09
dmi.modalias: dmi:bvnDellInc.:bvrA09:bd10/20/2010:svnDellInc.:pnInspironN7010:pvrA09:rvnDellInc.:rn08VFX1:rvrA09:cvnDellInc.:ct8:cvrA09:
dmi.product.name: Inspiron N7010
dmi.product.version: A09
dmi.sys.vendor: Dell Inc.

Revision history for this message
Ron Brown (ronw-brown) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 setup_context (registry=<synthetic pointer>, module=<synthetic pointer>, lineno=<synthetic pointer>, filename=<synthetic pointer>, stack_level=1) at ../Python/_warnings.c:449
 do_warn (message="gdk_xsettings_watch_cb(): Couldn't find window to unwatch", category=<type at remote 0x29397a0>, stack_level=1) at ../Python/_warnings.c:594
 PyErr_WarnEx (category=<type at remote 0x29397a0>, text=<optimized out>, stack_level=1) at ../Python/_warnings.c:720
 _log_func (log_domain=<optimized out>, log_level=G_LOG_LEVEL_WARNING, message=0x2c50210 "gdk_xsettings_watch_cb(): Couldn't find window to unwatch", user_data=0x29397a0) at /build/buildd/pygobject-2-2.28.6/gobject/gobjectmodule.c:2353
 ?? ()

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in hplip (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in hplip (Ubuntu):
status: New → Confirmed
visibility: private → public
Revision history for this message
Roger James (rogerjames99) wrote :

This bug has many duplicates. It appears that systray.py will crash whenever a warning message is generated. The oither bugs report a number of different warning messages.

The following bugs are definite duplicates.

#862779
#1046036
#1046635
#1157504
#1287596
#1299676
#1299764

The following are potential duplicates

#917727
#923137
#963315

Revision history for this message
Roger James (rogerjames99) wrote :

This bug still exists on 14.04 Trusty Tahr.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

To the HPLIP developers at HP, it seems that the do_warn() function used by systray is generally broken, causing a segmentation fault whenever it is called. Can you have a look into this? Thanks.

Revision history for this message
Roger James (rogerjames99) wrote :

This looks like a bug in the python interpreter.

The routine setup_context in Python/_warnings.c looks like this.

setup_context(Py_ssize_t stack_level, PyObject **filename, int *lineno,
              PyObject **module, PyObject **registry)
{
    PyObject *globals;

    /* Setup globals and lineno. */
    PyFrameObject *f = PyThreadState_GET()->frame;

PyThreadState_GET is a macro defined in Include/pystate.h

#ifdef Py_DEBUG
#define PyThreadState_GET() PyThreadState_Get()
#else
#define PyThreadState_GET() (_PyThreadState_Current)
#endif

Py_DEBUG does not appear to have been defined when this version of python was compiled. So the contents of _PyThreadState_Current are used as a pointer. Unfortunately it looks like this routine can be called when it is set to NULL. I put a break on the do_warn function in the interpreter and ran hp-systray -g -x. The first time it triggers (_PyThreadState_Current is non NULL and all is OK. The second time it is NULL and the crash occurs. This may be because this warning is being triggered deep in the initialisation code of a python object.

I do not know whether this is a python bug or an hplip bug. Maybe a python expert can comment on this.

P.S. the python assembly code is heavily inline optimised by gcc so is very hard to relate to real line numbers.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Added python-defaults task so that the Python experts will see this bug report.

Revision history for this message
Matthias Klose (doko) wrote :

does this work with the python-dbg interpreter?

Revision history for this message
Matthias Klose (doko) wrote :

another candidate for the real issue are the pygobject bindings.

Revision history for this message
Roger James (rogerjames99) wrote :
Download full text (16.4 KiB)

I had a quick try with python-dbg but got some error messages very early one in the initialisation process. I have not looked into them any further.

However I have no do a run with a hardware break point on _PyThreadState_Current. This show that it is the /usr/lib/python2.7/dist-packages/PyQt4/QtGui.so module that is causing the problem by calling PyEval_SaveThread () just before the crash. This has the affect of setting the current thread state to NULL. So this no looks like it could be a problem with the Qt4 support in Python not handling multithreading correctly. I think this is a far as I can go diagnosing this. I was hoping I could find some way of hacking a work around into hp-systray but this seems unlikely.

(gdb) ignore 1 1147
Will ignore next 1147 crossings of breakpoint 1.
(gdb) run
Starting program: /usr/bin/python /usr/bin/hp-systray -g -x
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

HP Linux Imaging and Printing System (ver. 3.14.3)
System Tray Status Service ver. 2.0

Copyright (c) 2001-13 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

hp-systray[3456]: debug: Locking: /home/roger/.hplip/hp-systray.lock
hp-systray[3456]: debug: Creating pipe: hpssd (5) ==> systemtray (4)
hp-systray[3456]: debug: Creating pipe: hpssd (6) ==> hpdio (4)
hp-systray[3456]: debug: Creating pipe: hpdio (8) ==> hpssd (7)
hp-systray(hpdio)[3458]: debug: PID=3458
hp-systray(hpssd)[3457]: debug: PID=3457
hp-systray(hpssd)[3457]: debug: Entering main dbus loop...
[New Thread 0xb40a9b40 (LWP 3459)]
[New Thread 0xb36ffb40 (LWP 3460)]
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:127: RuntimeWarning: PyOS_InputHook is not available for interactive use of PyGTK
  set_interactive(1)
hp-systray(qt4)[3456]: debug: PID=3456
hp-systray(qt4)[3456]: debug: Go to here 1!
Hardware watchpoint 1: _PyThreadState_Current

Old value = (PyThreadState *) 0x835d050
New value = (PyThreadState *) 0x0
PyEval_SaveThread () at ../Python/ceval.c:340
340 if (tstate == NULL)
(gdb) bt
#0 PyEval_SaveThread () at ../Python/ceval.c:340
#1 0xb6413d58 in ?? () from /usr/lib/python2.7/dist-packages/PyQt4/QtGui.so
#2 0xb723fd86 in ?? () from /usr/lib/python2.7/dist-packages/sip.so
#3 0x08144c11 in wrap_init.25210 (self=<SystemTrayApp at remote 0xb7a664f4>,
    args=(['/usr/bin/hp-systray', '-g', '-x'],), wrapped=0xb723faa0, kwds=0x0)
    at ../Objects/typeobject.c:4748
#4 0x0814481c in wrapper_call.11136 (wp=wp@entry=0xb7285eac,
    args=args@entry=(['/usr/bin/hp-systray', '-g', '-x'],),
    kwds=kwds@entry=0x0) at ../Objects/descrobject.c:1035
#5 0x081045a9 in PyObject_Call (kw=0x0,
    arg=(['/usr/bin/hp-systray', '-g', '-x'],),
    func=<method-wrapper at remote 0xb7285eac>) at ../Objects/abstract.c:2529
#6 PyEval_CallObjectWithKeywords (
    func=func@entry=<method-wrapper at remote 0xb7285eac>,
    arg=arg@entry=(['/usr/bin/hp-systray', '-g', '-x'],), kw=kw@entry=0x0)
    at ../Python/ceval.c:3889
#7 0x0817c6ed in wrappe...

Revision history for this message
Roger James (rogerjames99) wrote :
Download full text (21.0 KiB)

Here is a slighlty more informative gdb run with the python-qt4 debug symbols loaded.

You can see from this that the crash occurs because the qt4 sip code calls

Py_BEGIN_ALLOW_THREADS

This sets _PyThreadState_Current to NULL, and then

sipCpp = new sipQApplication(nargc, argv);

Somewhere in the setup of this object a call to the Python warning mechansim occurs with the trhead state still NULL.

(gdb) ignore 1 1149
Will ignore next 1149 crossings of breakpoint 1.
(gdb) run
Starting program: /usr/bin/python /usr/bin/hp-systray -g -x
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

HP Linux Imaging and Printing System (ver. 3.14.3)
System Tray Status Service ver. 2.0

Copyright (c) 2001-13 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

hp-systray[3194]: debug: Locking: /home/roger/.hplip/hp-systray.lock
hp-systray[3194]: debug: Creating pipe: hpssd (5) ==> systemtray (4)
hp-systray[3194]: debug: Creating pipe: hpssd (6) ==> hpdio (4)
hp-systray[3194]: debug: Creating pipe: hpdio (8) ==> hpssd (7)
hp-systray(hpdio)[3196]: debug: PID=3196
hp-systray(hpssd)[3195]: debug: PID=3195
hp-systray(hpssd)[3195]: debug: Entering main dbus loop...
[New Thread 0xb40a9b40 (LWP 3197)]
[New Thread 0xb36ffb40 (LWP 3198)]
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:127: RuntimeWarning: PyOS_InputHook is not available for interactive use of PyGTK
  set_interactive(1)
hp-systray(qt4)[3194]: debug: PID=3194
hp-systray(qt4)[3194]: debug: Go to here 1!
Hardware watchpoint 1: _PyThreadState_Current

Old value = (PyThreadState *) 0x835d050
New value = (PyThreadState *) 0x0
PyEval_SaveThread () at ../Python/ceval.c:340
340 if (tstate == NULL)
(gdb) finish
Run till exit from #0 PyEval_SaveThread () at ../Python/ceval.c:340
init_type_QApplication (sipSelf=0xb7a664f4, sipArgs=
    (['/usr/bin/hp-systray', '-g', '-x'],), sipKwds=0x0, sipUnused=0xbfffe880,
    sipParseErr=0xbfffe88c)
    at /build/buildd/python-qt4-4.10.4+dfsg/sip/QtGui/qapplication.sip:886
886 sipCpp = new sipQApplication(nargc, argv);
Value returned is $2 = (PyThreadState *) 0x835d050
(gdb) next
885 Py_BEGIN_ALLOW_THREADS
(gdb) next
886 sipCpp = new sipQApplication(nargc, argv);
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
do_warn.29441 (
    message=message@entry='/usr/lib/i386-linux-gnu/pango/1.8.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory',
    category=category@entry=<type at remote 0xb43a878c>,
    stack_level=stack_level@entry=1) at ../Python/_warnings.c:594
594 if (!setup_context(stack_level, &filename, &lineno, &module, &registry))
(gdb) bt
#0 do_warn.29441 (
    message=message@entry='/usr/lib/i386-linux-gnu/pango/1.8.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory',
    category=category@entry=<type at remote 0xb43a878c>,
    stack_level=stack_level@entry=1) at ../Python/_warnings.c:594
#1 0x081f34c...

Revision history for this message
Roger James (rogerjames99) wrote :

I suspect that this is happening because python has hooked itself if into the GTK logging system. So it looks like _PyErr_WarnEx should really check whether _PyThreadState_Current is non NULL before proceding. This rreally looks like a horrible can of worms.

Can the python guys please look at this.

Revision history for this message
Roger James (rogerjames99) wrote :

I switched to trying to resolve my case of the bug by fixing the cause of the warning. In my case this is a warning from pango that it could not find a loadable module.

/usr/lib/i386-linux-gnu/pango/1.8.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory'

The directory /usr/lib/i386-linux-gnu/pango does not even exist on my installation. However in /etc/pango/pango.modules there is a long list of modules supposedly in that directory including an entry for pango-basic-fc.so. I found some comments on the web that pango-basic-fc.so is now statically linked in recent revisions of pango. So I just renamed the pango.modules file to pango.modules.old. Everything now works fine.

This would seem to prove that this is a bug in the python infrastructure. It is definitely not a bug in hplip.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

So I am marking the HPLIP tasks invalid and I have also added a Pango task as moving away a bogus config file of Pango also solves the problem.

Changed in hplip:
status: New → Invalid
Changed in hplip (Ubuntu):
status: Confirmed → Invalid
Changed in pango (Ubuntu):
importance: Undecided → Medium
Changed in pygobject-2 (Ubuntu):
importance: Undecided → Medium
Changed in python-defaults (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Roger James (rogerjames99) wrote :

For a more comprehensive fix that catches all the cases where warning are generated when the global intrepreter lock has been released and _PyThreadState_Current set to NULL, you can try the following patch to pygobject-2.

--- pygobject-2-2.28.6.orig/gobject/gobjectmodule.c
+++ pygobject-2-2.28.6/gobject/gobjectmodule.c
@@ -2307,7 +2307,7 @@ _log_func(const gchar *log_domain,
           const gchar *message,
           gpointer user_data)
 {
- if (G_LIKELY(Py_IsInitialized()))
+ if (G_LIKELY(Py_IsInitialized()) && (NULL != _PyThreadState_Current))
     {
  PyGILState_STATE state;
  PyObject* warning = user_data;

This seems a bit like wallpapering over the cracks, but it was the simplest fix I could come up with.

Roger

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.