This is obviously working in other environments, so we'll need more information in order to reproduce it.

 Does introspection work in windows?  Are the typelibs compiled and loaded correctly?  Looks like it isn't getting the right gtype.  Could be an alignment issue in the GI structs.  Have you run the test cases (make check) for gobject-introspection to make sure it is functioning correctly on windows?

Cygwin != Windows.

GI in general is working; I can run lightsoff and swell-foop (from gnome-games, which use GI via Seed).  I can also run simple python-gi Gtk test programs, as long as I don't import GLib.

Could be something with GVariants under cygwin.  Can you remove the GLib override, run python and try importing GLib and creating a variant?

v = GLib.Variant.new_boolean(True)

Also, if you could try writing a C app that does the same thing:

GVariant *v = g_variant_new_boolean(TRUE);

Run it in gdb to see if v is valid.

Also is there any easy way for me to compile the cygwin stack on Fedora?  Like a JHBuild that uses cygwin instead of GCC (or can I configure jhbuild to do that?)

(In reply to comment #4)
> Also is there any easy way for me to compile the cygwin stack on Fedora?  Like
> a JHBuild that uses cygwin instead of GCC (or can I configure jhbuild to do
> that?)

My Fedora Cygwin RPM repository provides an entire cygwin cross-compiler stack for F14, including gtk 2 and 3:

http://www.mail-archive.com/cygwin-ports-general@lists.sourceforge.net/msg00894.html

I'll have to get back to you later regarding the rest.

(In reply to comment #4)
> Could be something with GVariants under cygwin.  Can you remove the GLib
> override, run python and try importing GLib and creating a variant?
> 
> v = GLib.Variant.new_boolean(True)

Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import GLib
>>> v = GLib.Variant.new_boolean(True)
Traceback (most recent call last):

+ Trace 226849

Note that I have no problem using GLib.Variant in seed.

> Also, if you could try writing a C app that does the same thing:
> 
> GVariant *v = g_variant_new_boolean(TRUE);
> 
> Run it in gdb to see if v is valid.

This looks fine.

Hi.

Running gobject-introspection-0.10.8, python-2.6.6 and py-gobject-2.28.4 I have trouble importing GLib.py.

>>> from gi.repository import GLib
Traceback (most recent call last):

+ Trace 227114

I know it's not much information, let me know if there's something else you need. I've been scratching my head over this with no luck so far... :-/

Thanks.

(In reply to comment #7)
> Hi.
> 
> Running gobject-introspection-0.10.8, python-2.6.6 and py-gobject-2.28.4 I have
> trouble importing GLib.py.

I forgot to mention this was under OpenBSD.

No idea about the OpenBSD aspects, but I see it is installed in /usr/local/lib and not /usr/lib

Be careful that you are not mixing different build/installed versions. Set PATH/LD_LIBRARY_PATH/PYTHONPATH to be sure.

(In reply to comment #9)
> No idea about the OpenBSD aspects, but I see it is installed in /usr/local/lib
> and not /usr/lib
> 
> Be careful that you are not mixing different build/installed versions. Set
> PATH/LD_LIBRARY_PATH/PYTHONPATH to be sure.

"/usr/local" is the standard prefix under OpenBSD. All external applications (python included) are installed under this path.

> >>> from gi.repository import GLib
> Traceback (most recent call last):

FYI, if I run this import line twice, then it seems to work (I don't get the error/traceback anymore) :-/

Hi John.

I'm willing to hunt and fix this bug but I could use a little help. What would be the most obvious thing that would trigger such an error? I just need some advise on where to start looking.
I understand it works on Linux so the rest is not important but as I said, I'm willing to work on it, I just need a little hint for starting.
Seeing this issue is shared by both OpenBSD and cygwin, that's a least 2 environments where it doesn't work.
Thanks.

To me it looks like we are trashing stack somewhere.  It might just not be triggered by GCC because the way GCC does memory allocation.  I would run it under valgrind.  Also we know it has something to do with the variants.  Try editing the GLib overrides /usr/lib/pythonx.x/site-packages/gi/overrides/GLib.py to not load variants.

Actually to eliminate any issue with installation just run your test app from the source directory, in which case modify gi/overrides/GLib.py.

Ok, to explicitly rule out any installation issue:
gurthang:site-packages {2005} pwd
/usr/local/lib/python2.6/site-packages
gurthang:site-packages {2006} ls gi/overrides/
GIMarshallingTests.py       Gdk.pyc                     Gio.pyo                     __init__.py
GIMarshallingTests.pyc      Gdk.pyo                     Gtk.py                      __init__.pyc
GIMarshallingTests.pyo      Gedit.py                    Gtk.pyc                     __init__.pyo
GLib.py                     Gedit.pyc                   Gtk.pyo                     keysyms.py
GLib.pyc                    Gedit.pyo                   Pango.py                    keysyms.pyc
GLib.pyo                    Gio.py                      Pango.pyc                   keysyms.pyo
Gdk.py                      Gio.pyc                     Pango.pyo
gurthang:site-packages {2007} python2.6 -c "from gi.repository import GLib"
Traceback (most recent call last):

+ Trace 227244

gurthang:site-packages {2008} 
gurthang:site-packages {2009} python2.6 -c "from gi.repository import Pango"
gurthang:site-packages {2010} echo $?
0
gurthang:site-packages {2011} 

If I completely comment out the GLib.py file by adding '"""' after
___all___ = []

and after
__all__.append('Variant')

I can import GLib:
gurthang:site-packages {2013} python2.6 -c "from gi.repository import GLib"
gurthang:site-packages {2014} echo $?
0
gurthang:site-packages {2015} 

Trying out various scripts (like gedit-plugins) no longer crash or fail to load and after some quick testing they appear to work).

Any further ideas? Running it in valgrind is not an option as it's not available in OpenBSD.

Can you run this.  That looks like it is erroring out and preventing the override to load.  My guess is you are getting an attr error.  Either GLib.Variant doesn't exist or new_boolean doesn't exist, in which case you most likely have a really old GLib (and we should up the required version).

a = GLib.Variant.new_boolean

My glib version is 2.28.7, not really old methinks.

How should I run the above code? Still with a commented overrides file? If so, I get this:

>>> from gi.repository import GLib
>>> a = GLib.Variant.new_boolean
Traceback (most recent call last):

+ Trace 227273

>>>

I also have 2.28.7 (now, started this bug with 2.28.6), and with the GLib overrides gone, I get the same results.  But the essentially identical code works on Seed.

ok, on line #98 in gi/module.py right after the lines:

    def __getattr__(self, name):
        info = repository.find_by_name(self._namespace, name)

add this and run the script above with the commented overrides file:

print info, type(info), self._namespace, name

Also around line 130 after:

        elif isinstance(info, RegisteredTypeInfo):
            g_type = info.get_g_type()

add this:

print g_type


let me know what the output is.

>>> from gi.repository import GLib
>>> a = GLib.Variant.new_boolean
<StructInfo object (Variant) at 0x0x2097d0550> <type 'StructInfo'> GLib Variant
<GType GVariant (84)>
Traceback (most recent call last):

+ Trace 227274

>>>

Wow you are getting GVariant instead of a <GType void (4)> which denotes a C struct.  I'll have to get Tomeu and Martin to look at this as they wrote most of the GVariant code.  Good news is that the values look sane so I can mostly rule out memory corruption.  Looks like some code path is not getting executed or is being executed out of order.  One thing you can do is execute the code in GDB and break on g_variant_from_arg to make sure that it is being executed.

If this is what you mean, then it's not getting executed:

(gdb) gurthang:jasper {2002} gdb python2.6
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd4.9"...(no debugging symbols found)

(gdb) break g_variant_from_arg
Function "g_variant_from_arg" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (g_variant_from_arg) pending.
(gdb) from gi.repository import GLib
Undefined command: "from".  Try "help".
(gdb) run
Starting program: /usr/local/bin/python2.6 
Python 2.6.6 (r266:84292, May 22 2011, 21:02:29) 
[GCC 4.2.1 20070719 ] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import GLib
>>> a = GLib.Variant.new_boolean
<StructInfo object (Variant) at 0x0x20b678550> <type 'StructInfo'> GLib Variant
<GType GVariant (84)>
Traceback (most recent call last):

+ Trace 227277

>>> [New process 5984]
>>>

Created attachment 189333 [details] [review]
Use _gi.Struct to wrap fundamentals

Yep, this works fine on OpenBSD!
Thanks.

Created attachment 189342 [details] [review]
Use _gi.Struct to wrap fundamentals

Created attachment 189343 [details] [review]
GVariantType is a boxed struct

Created attachment 189344 [details] [review]
GVariant has now a GType, take that into account

Well, I'm able to import GLib now, and everything which uses pygi is working now except for gnome-tweak-tool, but I'll assume for the moment that something else is wrong there.

However I am seeing this error with all PyGI packages:

** (process:4444): CRITICAL **: g_type_info_get_interface: assertion `GI_IS_TYPE_INFO (info)' failed

Attachment 189342 [details] pushed as 2d73012 - Use _gi.Struct to wrap fundamentals
Attachment 189343 [details] pushed as bd7b8d9 - GVariantType is a boxed struct
Attachment 189344 [details] pushed as fe386a0 - GVariant has now a GType, take that into account

BTW the assertion is a known issue.  I don't think it harms anything though we should be looking into it.

Created attachment 189493 [details] [review]
pygobject patch

This is the same as: GVariant has now a GType, take that into account. For some reason the one in master wasn't applying in pygobject-2-28