Can you try with 2.15.4?  We fixed a bug that caused segfaults on some machines.

Created attachment 117966 [details]
build.log

still no luck, see attachment.

This suggest that a unit test fails.  Can you determine which test is that?

it's been kind of painful to get the tests to be verbose enough to show which test is failing but here are some details:


.../tests/test_gio.py:787: Warning: g_object_ref: assertion `G_IS_OBJECT (object)' failed
  info2 = info1.dup()

and the one causing the error in my build.log is in test_subtype.py

other tests looks fine, hope this helps.

Gilles: what does gio.app_info_get_all() and gio.app_info_get_all()[0] evaluate on your platform?  It those are lists of gio.unix.DesktopAppInfo and single instance of it (as expected), can you produce valgrind logs of running that single test?

I'm no python master so forgive me if what I'm doing is just silly :)

here is the output of running gio.app_info_get_all()[0] multiple times (but it's probably the result of currently installed 2.15.2 not the svn checkout)

>>> gio.app_info_get_all()[0]
<gio.unix.DesktopAppInfo at 0x767e60: Déchiffrer le fichier>
>>> gio.app_info_get_all()[0]
<gio.unix.DesktopAppInfo at 0x2b03d1e1d4b0: Déchiffrer le fichier>
>>> gio.app_info_get_all()[0]
<gio.unix.DesktopAppInfo at 0x765190: Déchiffrer le fichier>
>>> gio.app_info_get_all()[0]
<gio.unix.DesktopAppInfo at 0x2b03d1e1d4b0: Déchiffrer le fichier>


> It those are lists of gio.unix.DesktopAppInfo and single
instance of it (as expected), can you produce valgrind logs of running that
single test?

could you tell me how to do it ?

Such heavily changing addresses are somewhat suspicious, but not an error of itself.  Might or might not be an indication of something else going wrong.

Anyway:

$ valgrind --log-file=gio --num-callers=20 python
Python 2.5 (r25:51908, Apr  2 2007, 00:15:32)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gio
>>> info1 = gio.app_info_get_all()[0]
>>> info2 = info1.dup()
>>> info1 is info2
False
>>> info1 == info2
True

Then you will have file 'gio.pid###' with valgrind log.  However, I have some PyGObject-related error in my logs already.  Maybe they are significant, just don't cause such problems on my architecture.  Need to investigate.

Created attachment 118225 [details] [review]
maybe fixes this

Gilles: can you test if this fixes your problem?  I cannot say I quite understand why there is an error in my valgrind log, but this patch fixes it.  Maybe it fixes the whole bug too.

Created attachment 118230 [details]
valgrind-gio.log

here is the valgrind log with patch applied. It doesn't fix the testsuite though.

While running the commands you pasted, here is what I've got:

valgrind --log-file=gio.log --num-callers=20 python
Python 2.5.2 (r252:60911, Aug 23 2008, 19:09:54) 
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gio
>>> info1 = gio.app_info_get_all()[0]
>>> info2 = info1.dup()
__main__:1: Warning: g_object_ref: assertion `G_IS_OBJECT (object)' failed
>>> info1 is info2
False
>>> info1 == info2
True

In case I didn't write it before, I'm simple running on amd64, not that exotic :)

btw, is there any way to make the unittesting framework write out the name of the test its running ? I wouldn't really like having to split test_subtypes.py into separate chunks to find where's the culprit.

Gustavo: can you please look at this?  From valgrind report looks like another memory corruption on amd64 architecture caused by PYGLIB_DEFINE_TYPE() in 'pygspawn.c'.  I remember you fixed another instance of the same problem last time.

I have known for a few weeks there are probably lots of memory problems lurking around pygobject.  I am afraid to even look at this because it will take me many hours to fix them all :P

Gustavo: well, I didn't ask to fix them all, you could fix this one for a start.

Gilles: can you please evaluate the following (after 'import glib') on your platform:

glib.Pid
glib.Pid.__base__
glib.Pid.__basicsize__
glib.Pid.__base__.__basicsize__
glib.Pid.__itemsize__
glib.Pid.__base__.__itemsize__

>>> import glib
>>> glib.Pid
<type 'glib.Pid'>
>>> glib.Pid.__base__
<type 'int'>
>>> glib.Pid.__basicsize__
24
>>> glib.Pid.__base__.__basicsize__
24
>>> glib.Pid.__itemsize__
0
>>> glib.Pid.__base__.__itemsize__
0

If I remove gio unit tests, everything runs in valgrind with zero errors:

The GIO tests I cannot run because GVFS refuses to run in jhbuild:

GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.HalVolumeMonitor: org.freedesktop.DBus.Error.ServiceUnknown: The name org.gtk.Private.HalVolumeMonitor was not provided by any .service files
aborting...

gedit-2.24.0 already uses the gio bindings. Makes me feel a tad bit uncomfortable in packaging it...

for the record, this appears to be fixed with gnome a mixed 2.24.0 2.24.1 system. It seems an update of an underlying library fixed the issue (I think glib-2.18.2 is responsible here).

I'll try to double check that we I get enough time (hence not closing right now).

Gilles: any results of that check?

I can't test it right now because I'm using python 2.6 which is getting in the way like in bug #570281 but the test restriction has been lifted in our ebuild so it seems it was tested and it did pass tests. Thanks for helping out and sorry for the delayed answer. Closing fixed.