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
g_simple_async_result_complete() now checks that it's being run from
the correct main loop, so tests/gio/simple-async-result was failing,
because it called it from outside any main loop. (And gio's pltcheck
was failing because I hadn't added g_main_current_source() to it.)
glib/pcre/pcre_ucp_search_funcs.c, glib/pcre/pcre_valid_utf8.c: add
back missing config.h includes, and this time add them to the copies
in glib/update-pcre/ too so they don't get lost again on the next PCRE
update.
glib/garray.c, glib/gbase64.c: fix signed/unsigned pointer casts
gio/xdgmime/xdgmimeglob.c: remove unused variable
gio/tests/live-g-file.c: fix printf args on x86_64
tests/Makefile.am, tests/regex-test.c: remove redundant -DENABLE_REGEX
* glib/gtestutils.h (g_assert_no_error, g_assert_error): Macros to
assert that a GError is not set, or else is set to a particular
error.
* glib/gtestutils.c (g_assertion_message_error): utility for
those macros
* glib/tests/keyfile.c:
* tests/asyncqueue-test.c:
* tests/bookmarkfile-test.c:
* tests/convert-test.c:
* tests/file-test.c: Use g_assert_error/g_assert_no_error
svn path=/trunk/; revision=7555
2008-08-28 Bastien Nocera <hadess@hadess.net>
Bug 548612 – g_strstr_len() should use memmem when available
* glib/tests/strfuncs.c (test_strstr):
* tests/string-test.c (main): Patch by Paolo Borelli
<pborelli@katamail.com> to move the tests to the right place,
and add more tests
* glib/gstrfuncs.c (g_strstr_len): Fix problem with memmem ignoring
nul-terminators in strings, and using the haystack_len instead
svn path=/trunk/; revision=7409
2008-08-28 Bastien Nocera <hadess@hadess.net>
Bug 548612 – g_strstr_len() should use memmem when available
* configure.in: detect whether memmem is available in the C library
* glib/gstrfuncs.c (g_strstr_len): use memmem for g_strstr_len() if
available in it's available, as it could be optimised by the C library
* tests/string-test.c (main): Add a few tests for g_strstr_len()
svn path=/trunk/; revision=7407
