GLib 2.33.2

2012-06-04 Thread Ryan Lortie

GLib 2.33.2 has been released.

This is a point release on the way to what will become 2.34.0.  API 
additions at this point should be considered unstable.


As usual, you can download from

  http://download.gnome.org/sources/glib/2.33

  b7163e9f159775d13ecfb433d67c3f0883e0e518e85b2e970d4ad9773d7cd0b4 
glib-2.33.2.tar.xz


Overview of changes from GLib 2.33.1 to 2.33.2
==

* GLIB_VERSION_MIN_REQUIRED now defaults to the current stable version

* GIO input and output stream classes have grown GBytes-based methods

* GApplication now has hooks to register D-Bus objects before the bus
  name is taken

* Bugs fixed:
 605976 add g_type_ensure(), to ensure that a type has...
 660851 Breakage of code due to changes in the GThread...
 666386 Empathy doesn't open Redirect URI with particu...
 671139 need (transfer async) for io stream buffers
 672329 memory leaks in gutils.c and glib tests
 672548 g_utf8_validate: @str shouldn't end up annotat...
 674111 Provide an accessor for MimeType desktop entry...
 674483 broken configure results when cross-compiling ...
 674634 Add g_clear_pointer()
 674777 What's the (transfer) of g_variant_lookup()?
 675309 gkeyfile: Fix annotations for g_key_file_load_...
 675446 gfile: Plug memory leak in g_file_make_directo...
 675509 add extra dbus hooks
 675832 Incomplete gsettings bash auto-completion
 676208 The tmpl parameter to g_file_new_tmp can be NULL
 676265 GNetworkMonitor leaks a lot of memory
 676277 Document that g_app_info_create_from_commandli...
 676397 g_environ_* should work with NULL envp
 676398 g_spawn_* should take PATH from the passed env...
 676478 Broken gzip decoding
 676594 [Patch] fix g_reload_user_special_dirs_cache
 676816 Add more GLIB_AVAILABLE_IN_*
 676937 Document notify signal deduplication with free...

* Translation updates:
 Czech
 French
 German
 Greek
 Japanese
 Russian
 Slovenian
 Spanish


Thanks to:

 Bruno Brouard
 Christian Kirbach
 Christian Persch
 Chun-wei Fan
 Colin Walters
 Dan Winship
 Daniel Mustieles
 Debarshi Ray
 Dimitris Spingos
 Emmanuele Bassi
 Giovanni Campagna
 Guillaume Desmottes
 Holger Berndt
 Jasper St. Pierre
 Jiro Matsuzawa
 Krzesimir Nowak
 Lars Uebernickel
 Marc-Antoine Perennou
 Marek Černocký
 Matej Urbančič
 Michael Olbrich
 Paolo Borelli
 Philip Withnall
 Ravi Sankar Guntur
 Xavier Claessens
 Yuri Kozlov

and to Matthias Clasen for preparing the NEWS.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: crash in glib 2.32 relating to use of Gtk file chooser dialogs

2012-06-04 Thread John Emmas
On 3 Jun 2012, at 20:05, David Andruczyk wrote:

> I'm trying to debug a crash users are reporting with my app on glib 2.32.1  
> (gtk+-2.24.10-0ubuntu6) (what's is installed by default on ubuntu 12.04) 
> gtk3.x is not possible with this app due to other conflicting requirements. 
> The issues also occurs in an identical fashion on debian sid using glib 
> 2.32.3 (gtk+2.24.10-1).  The app makes use of GtkFileChooserDialogs which is 
> where the crash occurs, specifically on the second one used,  the first one 
> called by my app, always works, the subsequent ones tends to crash
> 

Hi David,

I use gtk 2.20 / glib 2.24 on Windows and I can confirm that the same thing 
happens.  I've reported it myself and there are at least 2 other reports in 
Bugzilla (#636758 and #674269).  It tends to be exactly as you described.  The 
dialog box works once - but will crash if hidden and then re-displayed.  Gtk 
file chooser widget has the same problem IIRC.

This issue has been around for so long that I've had to assume it can't be 
fixed.  The only workaround seems to be not to create file choosers as 
persistent objects (e.g. class member objects).  Instead, store a pointer 
somewhere, create your file chooser each time you need it, then destroy it 
afterwards.  It's hugely annoying but it's the only solution that works AFAICT.

Just out of interest - are you using a theming engine (such as clearlooks).  On 
Windows, the problem seems to be worse when themes are being used but I don't 
know if that's significant or just a coincidence.

John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


crash in glib 2.32 relating to use of Gtk file chooser dialogs

2012-06-04 Thread David Andruczyk
I'm trying to debug a crash users are reporting with my app on glib 2.32.1
 (gtk+-2.24.10-0ubuntu6) (what's is installed by default on ubuntu 12.04)
gtk3.x is not possible with this app due to other conflicting requirements.
The issues also occurs in an identical fashion on debian sid using glib
2.32.3 (gtk+2.24.10-1).  The app makes use of GtkFileChooserDialogs which
is where the crash occurs, specifically on the second one used,  the first
one called by my app, always works, the subsequent ones tends to crash in
lib with:
GLib (gthread-posix.c): Unexpected error from C library during
'pthread_setspecific': Invalid argument.  Aborting.

Tracing with installation of debug symbols  goes to glib/gthread-posix.c
around line 1024 shows where the abort within glib is coming from.  I dl'd
and built a "local" edition of glib matching the OS release and added some
printf's to g_private_set in glib/gthread-posix.c to spit out the key and
value addresses, to see if anything looked out of the ordinary.  Commenting
out the abort, allows the application to run seemingly normally with no
further issues. I also enabled threadpool debugging (glib/gthreadpool.c)
via uncommenting the working "DEBUG_MSG" macro and comment out the dummy
one above it) as well which generates a LOT of additional logging output in
the hopes of trying to figure out what glib/gtk+ is doing that causes the
crash.

The logging at the point where the second filechooser is being called shows
this (NOTE this is code where the abort in g_private_set is commented out) :

MTXDBG: calling gtk_file_chooser_dialog_new
g_private_set, Address of key: 0x38ae38 , Address of value: 0xb1400e88
pthread_setspecific status != 0, BAD KEY!!! Abort commented out
g_private_set, Address of key: 0x9839e0 , Address of value: 0x1
g_private_set, Address of key: 0x9839e0 , Address of value: (nil)
g_private_set, Address of key: 0x38ae38 , Address of value: 0xb1400e18
g_private_set, Address of key: 0x38ae38 , Address of value: (nil)
dialog created
g_private_set, Address of key: 0x38ae38 , Address of value: 0xb1400dd8
g_private_set, Address of key: 0x38ae38 , Address of value: (nil)
initiating dialog to run

Based on the manpages for pthread_setspecific():
The pthread_setspecific() function shall fail if:

[ENOMEM]
Insufficient memory exists to associate the non-NULL value with the key.
The pthread_setspecific() function may fail if:

[EINVAL]
The key value is invalid.
These functions shall not return an error code of [EINTR].

There isn't any really checking for whether the issue is an ENOMEM or
EINVAL (just a zero or nonzero in g_private_set()) , though the abort
message say's its an EINVAL which means a bad key, perhaps a race where the
key hasn't yet been created with pthread_key_create someplace else within
glib?

I have an open bug filed with the Gnome bugzilla (though I can not retrieve
the number at the moment),  however it hasn't received any attention yet,
and as of now (june 3rd 2012, 14:43 EST) the bugzilla web page is returning
and Error 500 Internal Server Error.

Once the bugzilla is available again I'll try to attach the detailed
execution log with the instrumented glib for perusal.


Thoughts?
-- 

-- David J Andruczyk
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list