[gutsy] gtkspell segfaults when trying to set the language on gtk.TextView

I also saw the following information in the terminal I started gramps from:

/usr/share/gramps/Spell.py:53: GtkWarning: gtk_text_view_get_buffer: assertion `GTK_IS_TEXT_VIEW (text_view)' failed
  gtkspell.Spell(gtk.TextView()).set_language(lang)
/usr/share/gramps/Spell.py:53: GtkWarning: gtk_text_buffer_get_bounds: assertion `GTK_IS_TEXT_BUFFER (buffer)' failed
  gtkspell.Spell(gtk.TextView()).set_language(lang)

It's segfaulting in aspell like so:

(gdb) bt
#0 0xb67ed76d in delete_aspell_speller () from /usr/lib/libaspell.so.15
#1 0xb6801260 in ?? () from /usr/lib/libgtkspell.so.0
#2 0x756d2e42 in ?? ()
#3 0xb6801d36 in ?? () from /usr/lib/libgtkspell.so.0
#4 0xb6801d30 in ?? () from /usr/lib/libgtkspell.so.0
#5 0x08854bcc in ?? ()
#6 0x00000000 in ?? ()

This is most likely to be the gtkspell problem. If you can reproduce the gramps crash, try running the code below in terminal, without gramps. It should not crash if there's no bug. If this crashes then it's a gtkspell bug.

$ python
>>> import gtk
>>> import gtkspell
>>> import locale
>>> lang = locale.getlocale()[0]
>>> if lang == None:
... print "lang is None"
... success = False
... else:
... gtkspell.Spell(gtk.TextView()).set_language(lang)
... success = True
...
>>> success
True

Sorry Alex, I'm getting that script failing in several way, lots of syntax trouble. Can you re-write it, test it on your system, and load it as an attachment? Thanks

Duncan,

It was meant to be typed in, it is only a few lines.

If you want to cut/paste, here it is:
1. First start python
2. Run the stuff below

import gtk
import gtkspell
import locale
lang = locale.getlocale()[0]
if lang == None: print "lang is None"
else: gtkspell.Spell(gtk.TextView()).set_language(lang)

Thanks Alex, how's this: bad news?

duncan@ubuntu:~$ python
Python 2.5.1 (r251:54863, May 27 2007, 15:55:14)
[GCC 4.1.3 20070518 (prerelease) (Ubuntu 4.1.2-8ubuntu1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
>>> import gtkspell
>>> import locale
>>> lang = locale.getlocale()[0]
>>> if lang == None: print "lang is None"
... else: gtkspell.Spell(gtk.TextView()).set_language(lang)
...
Segmentation fault (core dumped)
duncan@ubuntu:~$

... and the script crashed python2.5 which kicked apport into life and gave us bug report 122477, anything useful there?

No.

It's not bad news for gramps. It clearly demonstrates the issue with "gtkspell" python module. Guessing from my past experience with this on Debian, it is not because of the python bindings but rather in gtkspell itself. However, I am not 100% sure, it's just a guess.

just a standard crash report -- I didn't run the script mentioned above.

I get the same Segmentation fault as Duncan.

If Alex is right, and this is a gtkspell bug, where do we report it? Once it is reported, someone can link this bug to the gtkspell bug.

I don't think there's an "if" here. The python script is pretty short, and the only thing that could have crashed it is "gtkspell" python module.

This can be either a problem with python bindings for gtkspell: package python-gnome2-extras
Or this can be a gtkspell library problem: package libgtkspell0

The sensible thing would be to re-assign this bug report to python-gnome2-extras with my testcase. They can sort it out as to whether this is a python bindings or the unrelying lib that has a problem. So Amk going to do just that.

I think the problem might be with aspell.

#strace gramps

...

access("/home/dave/.aspell.en.pws", F_OK) = -1 ENOENT (No such file or directory)
open("/home/dave/.aspell.en.per", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/home/dave/.aspell.en.prepl", F_OK) = -1 ENOENT (No such file or directory)
open("/home/dave/.aspell.en.rpl", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/usr/lib/aspell/standard.kbd", F_OK) = 0
open("/usr/lib/aspell/standard.kbd", O_RDONLY) = 15
fstat64(15, {st_mode=S_IFREG|0644, st_size=100, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6c16000
read(15, "# Standard keyboard data file\n\nq"..., 4096) = 100
read(15, "", 4096) = 0
close(15) = 0
munmap(0xb6c16000, 4096) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 31893 detached

I don't know if this help...

Can you try this script instead of gramps? Just run
$ strace python test.py
with the attached test.py file. This script has nothing to do with gramps and should crash just the same. Just to show that this is not a gramps issue and should be dealt with by gtkspell folks.

Here's the output on mu machine, just updated. For some reason I couldn't get it written to file, so I've lost some of the start of the output.

Looks like same crash to me.

Can we please drop the gramps thing now and work with the script? This issue just happened to cause gramps to crash too, but this is not gramps problem. The script demonstrates it clearly :-)

We need someone from MOTU to take on either getting this fixed or re-packaging the current version unhooked from gtkspell. I don't think we should wait much longer if GRAMPS is to make it into Gutsy. Anyone able to take this on?

bug is mentioned elsewhere, see:

https://bugs.launchpad.net/ubuntu/+source/gramps/+bug/131854

Opened a bug at the GtkSpell page on SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=1802122&group_id=7896&atid=107896

The problem is how this function is called. The GtkTextView is instanciated temporarely and is destroyed after the construction of the GtkSpell object, which triggers a destruction of the relevant parts needed by set_language. I personally would consider the call method wrong, but well.

A solution is to bump the refcnt of the textview in the GtkExtra python module (found in gnome-python-extras) by adding it to the type struct, and bumping the count in new_attach and get_from_textview. Also I think that one needs to introduce a destructor to decrease the refcnt of the textview. I tried this and the relevant part worked fine, but there was a crash in Python's GC instead.

So an immediate fix would be to move the gtk.TextView() into a temporary variable instead. With that it works even with the version of python-gtkspell currently in the archives.

gtkspell is buggy in terms that no way of gathering the information "is a spell checker available for this language" is exposed, gnome-python-extras is buggy because it does not increase the refcounter of the textview and gramps was buggy because it tried to acquire the information in a bogus way.

To fix the problem for real libgtkspell should be using a weak reference to the GtkTextView object, so that when the GtkTextView is destroyed GtkSpell is notified and removes the reference.

gramps (2.2.8-1ubuntu2) gutsy; urgency=low

  [ Philipp Kern ]
  * Work around a bug in gnome-python-extras which caused a deallocation
    of the TextView in the check if a spell checker is present.
    (LP: #120569)

  [ Scott Kitterman ]
  * Corrected XSBC-Original-Maintainer field name in debian/control
  * Moved debhelper from Build-Depends-Indep to Build-Depends to satisfy
    lintian
  * Bumped standards version to 3.7.2 without further change

 -- Scott Kitterman <email address hidden> Tue, 25 Sep 2007 12:49:53 -0400

that's not a gnome-python-extras bug

So I've worked around the issue in Gramps, but the fundamental problem remains.

I'd appreciate it if someone who understands Gnome would figure out which is the correct upstream to point fingers at.

It's like I said in comment 25. libgtkspell should be fixed. It's rather simple to fix using g_object_weak_ref API, but I don't have time.

I am not an expert, but I do think this is a gnome-python-extras bug. A python object should live as long as there are any references held to it.
In this case the Spell object still holds a reference to the TextView object. So the Spell object should increase the reference counter on the TextView.

The "C" GtkSpell itself is not designed to live without a corresponding TextView. (gtkspell_detach even destroys the GtkSpell "C" object)
One could argue about the approach used in gtkspell but as of now most of the functions depend on the view. The change suggested by Gustavo Carneiro would make gtkspell more robust against such situations, but I think it's a bigger change.

In the test script above, if done correctly, the TextView would be destroyed automatically, when the GtkSpell object is destroyed. After the last line there is no reference hold to the GtkSpell object anymore and the GC would destroy them both.

Philipp Kern: I would be interested in your code that tried to fix the issue in gnome-python-extras.

Is this bug related to bug #261596?

Why is this bug still stuck on 'Fix released' and not actually committed?

Thanks for the report Susan Cragin , It has been a long time without any comment or a duplicate in this bug report and It is possible that the bug has been fixed. May you please try to reproduce it with the latest Stable Release of Ubuntu the Natty Narwhal and add the respective comments to the report? You can learn how to get that release at http://www.ubuntu.com/download . Thanks again and we appreciate your help.

Sadly, I can only confirm that it is fixed in oneiric, since that is what I have now and I just checked.
But it appears to be fixed.
I did use gramps last year and had no trouble with it, so I assume it has been fixed for some time. I'd say safe to say fixed in Natty.

I should say, I know that gramps works.
If the fix worked by removing gtk-spell, then gtk-spell could still have problems, and I wouldn't know about them.
But I suspect it's fixed because I have other programs that use gtk-spell and have had no problems.