Crash interception/debugging systems like Apport or ABRT capture core dumps for
later crash analysis. However, if a program exits with an assertion failure,
the core dump is not useful since the assertion message is only printed to
stderr.
glibc recently got a patch which stores the message of assert() into the
__abort_msg global variable.
(http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=48dcd0ba)
That works fine for programs which actually use the standard C assert() macro.
This patch adds the same functionality for glib's assertion tests. If we are
building against a glibc which already has __abort_msg (2.11 and later, or
backported above git commit), use that, otherwise put it into our own field
__glib_assert_msg.
Usage:
$ cat test.c
#include <glib.h>
int main() {
g_assert(1 < 0);
return 0;
}
$ ./test
**ERROR:test.c:5:main: assertion failed: (1 < 0)
Aborted (Core dumped)
$ gdb --batch --ex 'print (char*) __abort_msg' ./test core
[...]
$1 = 0x93bf028 "ERROR:test.c:5:main: assertion failed: (1 < 0)"
https://bugzilla.gnome.org/show_bug.cgi?id=594872
Not only is the default implementation broken (it causes infinite recursion
as seen in bug #603982), but its also worthless. If we just fall back on the
default stream operations we automatically get async version based on
the sync filter stream operations, which is what we want.
Note: Since we export types with Iface in the name rather than
Interface we have to use some typedefs to make this work. New
interfaces should probably use Interface as the public name.
This works around the need to take a custom mutex twice and add the
object to a GSList of objects that are currently in construction for the
common case. Only when the constructor is overwritten do we use the
previous behavior and allow things like singleton objects.
The only slightly incompatible change is that previously, it was ok to
call g_object_set() on construct-only properties while the object was
initialized. This will now fail. If that behavior is needed, setting a
custom constructor that just chains up will reenable this functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=557151
g_type_default_interface_peek() and g_type_value_table_peek() don't need
to acquire read locks anymore when they test the refcount instead of
node->data.
The function returns TRUE if the type was previously initialized and can
be easily reused. It returns FALSE and does not take a reference if the
type is not referenced yet.
g_type_class_ref() uses this to avoid taking locks in the common path,
which speeds up object creation a lot - in particular in multithreaded
applications.
https://bugzilla.gnome.org/show_bug.cgi?id=585375
This does not change any locking behavior at all, it just replaces
simple getters/setters of the variable with atomic versions.
The ref_count variable was kept as unsigned, even though that requires
casting for all operations, to mirror GObject->refcount.
https://bugzilla.gnome.org/show_bug.cgi?id=585375
