Commit Graph

8 Commits

Author SHA1 Message Date
Matthias Clasen
d1c25d3191 Fix the assert-msg test
gdb is playing games with us, by breaking -x /dev/stdin
2013-01-14 17:35:47 -05:00
Dan Winship
1d7985aa0a tests: multiple fixes to run-assert-msg-test.sh
1) use "../libtool" rather than "libtool" to avoid problems
with wacky OS X not-actually-libtool

2) Use libtool on the libtool script, not the binary, so that it
actually does anything

3) Don't use "gdb --ex" since it's apparently new-ish/non-portable.

https://bugzilla.gnome.org/show_bug.cgi?id=684723
2012-12-19 08:32:42 -05:00
Nirbheek Chauhan
840c32281d Run gdb under libtool so that local libraries are used
If this isn't done, the system-wide glib is used for this test,
and that can cause test failures.

https://bugzilla.gnome.org/621368
2012-03-04 20:36:04 -05:00
Peter Kjellerstedt
50efbaf063 Do not fail unit test due to gdb abbreviating strings
gdb by default will only print strings up to 200 characters. After that
it abbreviates them. This affects the run-assert-msg-test.sh script if
the path to the glib installation is too long (in our case it was 133
characters, 132 would still have worked...)

By having gdb execute "set print elements 0" before printing the assert
string, the limit on maximum number of characters to print is set to
unlimited.

Signed-off-by: Peter Kjellerstedt <pkj@axis.com>

https://bugzilla.gnome.org/show_bug.cgi?id=670218
2012-02-17 11:59:30 -05:00
Matthias Clasen
94a46ea410 Fix 'make check' with clang
Patch by Elias Pipping

https://bugzilla.gnome.org/show_bug.cgi?id=662491
2011-10-24 13:43:11 -04:00
Priit Laes
96d105906e Fix run-assert-msg-test to work with libtool-2.2.x. 2010-03-08 00:16:23 -05:00
Martin Pitt
3658727cfa always use our own internal assertion message symbol
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
2010-01-26 11:22:31 +01:00
Martin Pitt
da66897950 Support storing assertion messages into core dump
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
2009-12-23 15:51:11 +00:00