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

Bug #120569 reported by Susan Cragin on 2007-06-15
Affects Status Importance Assigned to Milestone
gnome-python-extras (Ubuntu)
gramps (Ubuntu)
gtkspell (Ubuntu)

Bug Description

Binary package hint: gramps

susan@susan:~$ gramps

***MEMORY-WARNING***: gramps.py[15131]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon...
Segmentation fault (core dumped)

see bug 116870 glibc

By the way, my python was the newest version available on 15 June.

Susan Cragin (susancragin) wrote :
Changed in gramps:
status: Unconfirmed → Confirmed

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
/usr/share/gramps/Spell.py:53: GtkWarning: gtk_text_buffer_get_bounds: assertion `GTK_IS_TEXT_BUFFER (buffer)' failed

William Grant (wgrant) wrote :

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 ?? ()

Changed in gramps:
importance: Undecided → High
Alexander Roitman (shura) wrote :

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

Duncan Lithgow (duncan-lithgow) wrote :

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

Alexander Roitman (shura) wrote :


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)

Duncan Lithgow (duncan-lithgow) wrote :

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 Lithgow (duncan-lithgow) wrote :

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

Scott Kitterman (kitterman) wrote :


Alexander Roitman (shura) wrote :

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.

Susan Cragin (susancragin) wrote :

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.

Alexander Roitman (shura) wrote :

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.

David Dan (davidwdan) wrote :

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...

Alexander Roitman (shura) wrote :

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.

Alexander Roitman (shura) wrote :

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?

Benny (bm-cage) wrote :
Philipp Kern (pkern) wrote :

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.

Philipp Kern (pkern) wrote :

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.

Philipp Kern (pkern) wrote :
Philipp Kern (pkern) wrote :

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.

Changed in gramps:
status: New → In Progress
Changed in gramps:
assignee: nobody → kitterman
importance: Undecided → Medium
Changed in gtkspell:
importance: High → Medium
status: Confirmed → Triaged
Changed in gnome-python-extras:
importance: Undecided → Medium
status: New → Triaged
Gustavo Carneiro (gjc) wrote :

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.

Scott Kitterman (kitterman) wrote :

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
  * Bumped standards version to 3.7.2 without further change

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

Changed in gramps:
status: In Progress → Fix Released
Changed in gramps:
assignee: kitterman → nobody
Changed in gtkspell:
status: Unknown → Invalid
Sebastien Bacher (seb128) wrote :

that's not a gnome-python-extras bug

Changed in gnome-python-extras:
status: Triaged → Invalid
Scott Kitterman (kitterman) wrote :

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.

Gustavo Carneiro (gjc) wrote :

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?

Pedro Villavicencio (pedro) wrote :

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.

Changed in gtkspell (Ubuntu):
status: Triaged → Incomplete
Susan Cragin (susancragin) wrote :

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.

Susan Cragin (susancragin) wrote :

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.

Changed in gtkspell (Ubuntu):
status: Incomplete → 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

Remote bug watches

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