The info file suggests that backtrace() allocated memory on the stack and could
thus be used in situations where malloc() wasn't available, quoting
manual/debug.texi:

| The following program illustrates the use of these functions.  Note that
| the array to contain the return addresses returned by @code{backtrace}
| is allocated on the stack.  Therefore code like this can be used in
| situations where the memory handling via @code{malloc} does not work
| anymore (in which case the @code{backtrace_symbols} has to be replaced
| by a @code{backtrace_symbols_fd} call as well).

This worked nicely up to and including 2.3.3.

2.3.4 introduced this dlopen() stuff for libgcc_s.so which calls malloc
indirectly, which is evil[tm]. This backtrace is from a SUSE Linux 9.3 system
but I don't see in sysdeps/i386/backtrace.c why a vanilla glibc 2.3.4 would
behave differently - and CVS hasn't changed i386/backtrace.c since 2.3.4
according to cvsweb:

#0  0xb7f0b526 in malloc () from /lib/tls/libc.so.6
#1  0xb7ff14d2 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#2  0xb7f9323e in _dl_open () from /lib/tls/libc.so.6
#3  0xb7ff7186 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#4  0xb7f92be0 in _dl_open () from /lib/tls/libc.so.6
#5  0xb7f94d4d in __libc_dlopen_mode () from /lib/tls/libc.so.6
#6  0xb7ff7186 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#7  0xb7f94bd5 in _dl_mcount_wrapper () from /lib/tls/libc.so.6
#8  0xb7f94cfb in __libc_dlopen_mode () from /lib/tls/libc.so.6
#9  0xb7f723ba in __nss_passwd_lookup () from /lib/tls/libc.so.6
#10 0xb7f72557 in backtrace () from /lib/tls/libc.so.6
#11 0x080484c0 in print_trace () at trybacktrace.c:12
#12 0x08048517 in dummy_function () at trybacktrace.c:26
#13 0x0804852a in main () at trybacktrace.c:31

It would be nice if backtrace() could be reverted to a state where it works
without malloc(), direct or indirect.

Note that this change also breaks Boehm GC 6.4.