These allow applications to give meaningful names to their sources.
Source names can then be used for debugging and profiling, for
example with systemtap or gdb.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
For some reason, even though the tests are linked against libgobject.la
and libgobject.la mentions libglib.la as a dependency, the tests are
running against the system glib instead of the in-tree one.
Adding the libglib.la file as an explicit LDFLAG fixes it.
Re-using glibc's __abort_msg symbol causes linking problems, since the symbol
is declared private. Always use our own__glib_abort_msg symbol to store
assertion messages, to avoid compatibility and linking problems.
Also fix the test case to work with out of tree builds (such as "make
distcheck"), and re-enable it.
https://bugzilla.gnome.org/show_bug.cgi?id=594872
It makes the IBM XL C Compiler (the 'native' non-free compiler
on the AIX 5.3 and 6.1 platform) stop compiling with syntax error.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=581300
Signed-off-by: Javier Jardón <jjardon@gnome.org>
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
These are basic performance test for a couple of basic gobject
primitives:
* construction of simple objects. Simple is a bare gobject derived
class with no properties, signals or interfaces.
* construction of complex objects. Complex is a gobject subclass
with construct properties, normal properties, signals, and
implements an interface.
* run-time type check of complex objects
* signal emissions
Lots of care is taken to try to make the results reproducible. Each
test is run for multible "rounds", where we try to make each round be
"not too short" in order to be significant wrt timer accuracy, but
also "not to long" to make the probability of some other random event
happening on the system (interrupts, other process scheduled, etc)
during the round less likely.
The current target round time is 4 msecs, which was picked without
rigour, but seems small wrt e.g. scheduler time.
For each test we then run the calculated round size for 60 seconds,
and then report the performance based on the minimal time of one
round. The model here is that any random stuff that happens during a
round can only slow it down, there is nothing that can make it go
faster, so the minimal time is the best estimate of how fast one round
goes.
The result is not ideal, even on a "idle" system the results vary
from round to round, but the variation seems to be less than 1%.
So, any performance difference reported by this test over 1% is
probably statistically significant.
Additionally the tests can be run with or without threads being
initialized. The script tests/gobject/run-performance.sh makes
it easy to produce a performance report for the current checkout.
https://bugzilla.gnome.org/show_bug.cgi?id=557100
