GNOME Bugzilla – Bug 702908
osx: subclassing TextBuffer & overriding mark-set causes bus error
Last modified: 2014-03-01 18:58:33 UTC
(apologies for the oddly specific summary, I'm not wholly sure if the bug is more generic) pygobject 3.4.1 python 2.7.3 gtk+ 3.6.4 All running inside a jhbuild shell. MacOS 10.8, fully patched Xcode, latest version (4.4?) compiler: bash-3.2$ gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The following code crashes with a bus error: ================================= from gi.repository import Gtk class TestClass(Gtk.TextBuffer): def __init__(self): super(TestClass, self).__init__() def do_mark_set(self, iter, mark): pass x = TestClass() start, end = x.get_bounds() x.create_mark(None, start, True) ================================= removing the do_mark_set override is sufficient to "fix" the problem. I've tried tracing this using gdb but my knowledge of what's going on is deficient in multiple dimensions. Stack trace (I seem to be missing some symbols in the Python stack that preceeds this, will try to provide a better stack trace if necessary): (gdb) where
+ Trace 232134
I am unable to reproduce this in PyGObject/GTK+ 3.8.2 or later (on a 64bit linux machine). Please retry with a later version and let us know if this is still a problem.
Waide wasn't specific enough: The problem occurs on MacOSX when the Gtk stack is built with llvm-gcc4.2 from Xcode 4.4 and later, with the current tarballs of everything in the gtk-osx stable moduleset. The problem doesn't occur when building with Xcode 4.2, nor with the real gcc from Xcode 3. Interestingly, I'm not able to reproduce this when building from git, even when I check out the same versions as the stable tarballs. I'll test soon (perhaps by the weekend) with more recent tarballs.
My jhbuild foo is a little weak here. How do I replace the jhbuild-configured version (3.4.1) with my own?
The easy way (in gtk-osx) is to switch modulesets and use unstable instead of stable, which will build from git instead of from tarballs. You can do that on the command line or in .jhbuildrc-custom. To change tarballs, you'll need to edit the moduleset (gtk-osx-python.modules, in this case) in ~/Source/jhbuild/modulesets. Or you can just launch a jhbuild shell and build manually from tarballs you download from your web browser. pygobject doesn't take any special config args, so you can just say ./configure --prefix=$PREFIX && make && make install
Build 3.8.1 from tarball by specifying a branch override in jhbuildrc. Same bug occurs. Verifying that I didn't accidentally use the wrong version: bash-3.2$ pkg-config --print-provides pygobject-3.0 pygobject-3.0 = 3.8.1 I will try changing to the unstable tree as you've suggested to see what happens.
(hmm, guess I should've tried with a 3.8.2 or later tarball as well)
Indeed. Built with the following release tarballs: glib 2.36.3 gobject-introspection 1.36.0 atk-2.8.0 gdk-pixbuf 2.28.2 gtk 3.8.2 pygobject 3.8.3 the test fails. Built with the git masters (modulesets-unstable) and it passes. Substitute the git master build for each of the above tarballs in the stable build and it still fails. Baffling.
Do you have a sense that this is a problem with pygobject specifically, or an interaction between pygobject and gtk that results in code that the compiler is unhappy with?
(In reply to comment #8) > Do you have a sense that this is a problem with pygobject specifically, or an > interaction between pygobject and gtk that results in code that the compiler is > unhappy with? Well, it's not the compiler that's unhappy. We're unhappy with the code that the compiler is emitting. ;-) I started off thinking it was a pygobject problem and progressed to a pygobject-gtk+ interaction hypothesis, but my testing yesterday seems to have discredited both. So now I'm flailing around trying to find a package that makes it fail when built with a tarball and work when built from git.
Naive question, but are you doing a full scrub between the test builds you mentioned above, or otherwise ensuring that builds don't leak into each other?
I'm relying on reinstalling the shared library to have or not have the problem, and rebuilding pygobject just in case differences in underlying code affect its build. Do you think that's not enough? My next test this morning was to build from modulesets, which uses mostly git checkouts but of the same versions as the tarballs in modulesets-stable. That fails too, so maybe it's not one of the main-line packages that's causing the problem. Since my unstable build (the one where your test program doesn't crash) is the one I use for Gtk development it has glib and gtk built for debugging. Thinking that it might be an optimization bug, I tried doing debug builds in the modulesets builds; no change, it still failed. I'm still baffled.
I'm just wondering if maybe the issue is in the header files rather than the libraries, so that recompiling e.g. pygobject has no effect on anything that's already included a header file from an older pygobject version.
(In reply to comment #12) > I'm just wondering if maybe the issue is in the header files rather than the > libraries, so that recompiling e.g. pygobject has no effect on anything that's > already included a header file from an older pygobject version. Pygobject doesn't export header files, it exports Python functions which call functions in pygobject's loadable modules. But I see where you're going with that. I'll investigate that the next time I have a time slot to work on this.
Moving to unconfirmed as there are no open questions I can see. (In reply to comment #13) > Pygobject doesn't export header files... Actually we do ship pygobject.h which gives access to our Python wrapper classes.
No idea what actually fixed it, but after the most recent round of updates this isn't crashing for me anymore. Tested with both Xcode 5 (clang-500.2.79/LLVM 3.3svn) and Xcode3 (llvm-gcc-4.2, LLVM build 5646) and the following libraries: Python 2.7.3 Gtk+ 3.10.7 PyGObject 3.10.0 Waide, can you do a test build with the current modulesets?
I'll kick one off this morning and update with results here.
Built & ran successfully, and the minimal test posted above also works without fault. Closing this bug.