Onboard segfaults on Ubuntu Hardy

Bug #220475 reported by Luke Yelavich on 2008-04-22
30
Affects Status Importance Assigned to Milestone
virtkey
Undecided
Unassigned
virtkey (Ubuntu)
High
Unassigned
Hardy
High
Unassigned
Intrepid
High
Unassigned

Bug Description

Running Ubuntu hardy with latest archive updates. When attempting to run onboard in any way, a segmentation fault occurs. However, whenever booting the live CD and using the on-screen keyboard
accessibility profile, onboard loads properly. However, when you shut it down, and attempt to run it again, the segmentatino fault occurs.

TEST CASE:
1. Make sure the onboard package is installed.
2. Attempt to run onboard, either from GNOME's run dialog, or from a terminal.
3. Onboard should segfault.
4. Install the python-virtkey package from proposed with Chris' patch.
5. Attempt to run onboard again.
6. Onboard should load successfully.

Regression potential:
Since the package segfaults, except when being booted via the accessibility profile from the live CD, and since geometry information is not needed by python-virtkey, as well as onboard being the only package in the archive that depends on python-virtkey, the chance of a regression is next to nothing.

Course for Intrepid:
As soon as intrepid opens, I will upload a fixed virtkey package.

Luke Yelavich (themuso) on 2008-04-22
Changed in onboard:
importance: Undecided → High
Luke Yelavich (themuso) wrote :

Here is a backtrace:

#0 0xb73d7f8c in XkbGetNames () from /usr/lib/libX11.so.6
#1 0xb6e61932 in getKbd (cvirt=0x83d7ab8) at python-virtkey.c:170
#2 0xb6e61b0f in virtkey_new (self=0x0, args=0xb7dbc02c) at python-virtkey.c:124
#3 0x080c9993 in PyEval_EvalFrameEx (f=0x83d0514, throwflag=0) at ../Python/ceval.c:3573
#4 0x080cb0d7 in PyEval_EvalCodeEx (co=0xb7d84770, globals=0xb7d9502c, locals=0x0, args=0xb7d8bdd8, argcount=1, kws=0x0, kwcount=0, defs=0x839b3d8, defcount=1, closure=0x0) at ../Python/ceval.c:2836
#5 0x08113430 in function_call (func=0x839c9cc, arg=0xb7d8bdcc, kw=0x0) at ../Objects/funcobject.c:517
#6 0x0805cb37 in PyObject_Call (func=0x0, arg=0xb7d8bdcc, kw=0x0) at ../Objects/abstract.c:1861
#7 0x08062b9b in instancemethod_call (func=0x839c9cc, arg=0xb7d8bdcc, kw=0x0) at ../Objects/classobject.c:2519
#8 0x0805cb37 in PyObject_Call (func=0x0, arg=0xb7dbc02c, kw=0x0) at ../Objects/abstract.c:1861
#9 0x0809d26b in slot_tp_init (self=0xb7d9a38c, args=0xb7dbc02c, kwds=0x0) at ../Objects/typeobject.c:4943
#10 0x0809ee64 in type_call (type=0x83d1064, args=0xb7dbc02c, kwds=0x0) at ../Objects/typeobject.c:436
#11 0x0805cb37 in PyObject_Call (func=0x0, arg=0xb7dbc02c, kw=0x0) at ../Objects/abstract.c:1861
#12 0x080c7987 in PyEval_EvalFrameEx (f=0x83d22ac, throwflag=0) at ../Python/ceval.c:3784
#13 0x080cb0d7 in PyEval_EvalCodeEx (co=0xb7d84410, globals=0xb7dd5acc, locals=0xb7dd5acc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2836
#14 0x080cb227 in PyEval_EvalCode (co=0xb7d84410, globals=0xb7dd5acc, locals=0xb7dd5acc) at ../Python/ceval.c:494
#15 0x080eadb0 in PyRun_InteractiveOneFlags (fp=0xb7f48440, filename=0x8123f04 "<stdin>", flags=0xbfd2da78) at ../Python/pythonrun.c:1273
#16 0x080eafd6 in PyRun_InteractiveLoopFlags (fp=0xb7f48440, filename=0x8123f04 "<stdin>", flags=0xbfd2da78) at ../Python/pythonrun.c:723
#17 0x080eb0f2 in PyRun_AnyFileExFlags (fp=0xb7f48440, filename=0x8123f04 "<stdin>", closeit=0, flags=0xbfd2da78) at ../Python/pythonrun.c:692
#18 0x08059335 in Py_Main (argc=0, argv=0xbfd2db44) at ../Modules/main.c:523
#19 0x080587f2 in main (argc=Cannot access memory at address 0x0
) at ../Modules/python.c:23

Francesco Fumanti (frafu) wrote :

Here on my Ubuntu Hardy RV, onboard segfaults when I try to use it remotely, but it does not segfault when used locally.

Moreover, have you tried by setting onboard to use a layout stored on a disk instead of the layout generated automatically at startup of onboard? (The latter was always more crash prone.)

This bug exists since 3 weeks for me. It even can be reproduced on the RC live-cd by simply executing the command onboard. Really annoying for some users...

Chris Jones (tortoise) wrote :

Sorry it's taken so long for me to get round to looking at this.

Could you run gnome-keyboard properties, go to the layout tab and click add. Click on a few different layouts in the combo boxes.

If you have the same bug that I have locally
(gnome-keyboard-properties:8533): GnomeKbdIndicator-CRITICAL **: XkbGetKeyboard failed to get keyboard from the server!
will appear in the console and the keyboard will fail to be displayed.

Onboard and gnome-keyboard-properties use the same mechanism to get keyboard layouts.

Yes, you are right. Same failure here:

dpy: 0x8077290
evt/error/major/minor: 94/163/1/0
(gnome-keyboard-properties:18187): GnomeKbdIndicator-CRITICAL **: XkbGetKeyboard failed to get keyboard from the server!

Do you need any further input?

Chris Jones (tortoise) wrote :

I've filed #220809 which is the cause of this bug.

sir_skiner (sir-skiner) wrote :

same thing for me :/

Chris Jones (tortoise) wrote :

This patch works around the issue by no longer requesting the geometry information from the server. The Onboard in Hardy does not use this information.

Luke Yelavich (themuso) wrote :

Ok that patch works around the issue, but is any functionality lost, or does it introduce any regressions? I'd like to get this fixed in a stable release update, but need to know whether this is likely to break anything else, or reduce onboard's functionality.

Chris Jones (tortoise) wrote :

It doesn't break anything that wasn't already broke. The geometry information from XKBGetKeyboard became unreliable early in Hardy's development cycle #188115. I worked round this by shipping the keyboard layout with Onboard.

I'm not aware of any other applications that use virtkey. If there are they might rely on this geometry information, in which case they might break.

#220809 does need fixing as it affects gnome-keyboard-properties as well.

sir_skiner (sir-skiner) wrote :

so, I would need to patch python-virtkeys and compile it?
which is hardly for me, because i literally can't type on keyboard - i use virtual keyboards to write things on my computer whith mouse pointer. now i use windows and since i basicaly can't use ubuntu, i also can't build this package. and of story :(

so, if some one could provide precompiled python-virtkey deb file, i would be more than greatefull.

Luke Yelavich (themuso) wrote :

TEST CASE:
1. Make sure the onboard package is installed.
2. Attempt to run onboard, either from GNOME's run dialog, or from a terminal.
3. Onboard should segfault.
4. Install the python-virtkey package from proposed with Chris' patch.
5. Attempt to run onboard again.
6. Onboard should load successfully.

Regression potential:
Since the package segfaults, except when being booted via the accessibility profile from the live CD, and since geometry information is not needed by python-virtkey, as well as onboard being the only package in the archive that depends on python-virtkey, the chance of a regression is next to nothing.

Course for Intrepid:
As soon as intrepid opens, I will upload a fixed virtkey package.

As there is no updatet package in updates-proposed, I compiled the python-virtkey package with Chris' patch by myself.
Onboard starts and works fine now! And there are no visible regressions.
I hope it will get its way in the Hardy Repos soon!

Martin Pitt (pitti) wrote :

Please upload to -propsed, and add a "TEST CASE:" to the description if there's a way to reproduce this reliably.

Changed in virtkey:
status: New → Confirmed
Luke Yelavich (themuso) on 2008-04-30
description: updated
Steve Langasek (vorlon) wrote :

accepted into hardy-proposed, please test.

Changed in virtkey:
status: Confirmed → Fix Committed
sir_skiner (sir-skiner) wrote :

hi,
I'm not so sure that the problem is within Chris' patch, but after installed patched python-virtkey I can't write polish special chars with onboard.
I can get to use them when typing from live cd.

Chris Jones (tortoise) wrote :

I can't think of any reason why my patch would affect that so it must be a separate issue.

Could you open a new bug and list the steps that you would normally take to write a Polish special character and say what is now happening instead.

Many thanks, Chris

Steve Langasek (vorlon) on 2008-05-02
Changed in virtkey:
importance: Undecided → High
status: New → Fix Committed
status: Fix Committed → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package virtkey - 0.50ubuntu1

---------------
virtkey (0.50ubuntu1) intrepid; urgency=low

  [ Chris Jones ]
  * Work round broken xkb. (LP: #220475)

  [ Luke Yelavich ]
  * Modify Maintainer value to match the DebianMaintainerField
    specification.

 -- Luke Yelavich <email address hidden> Wed, 30 Apr 2008 09:59:52 +1000

Changed in virtkey:
status: Triaged → Fix Released

Test Case Passed.

Testing with python-virtkey version 0.50build1, running onboard segfaults.

Testing with python-virtkey version 0.50ubuntu0.1 from hardy-proposed, running onboard loads successfully.

Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in virtkey:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers