This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/956] New: regression: backtrace uses malloc()
- From: "matthias dot andree at gmx dot de" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 17 May 2005 02:04:20 -0000
- Subject: [Bug libc/956] New: regression: backtrace uses malloc()
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
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.
--
Summary: regression: backtrace uses malloc()
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: gotom at debian dot or dot jp
ReportedBy: matthias dot andree at gmx dot de
CC: glibc-bugs at sources dot redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://sources.redhat.com/bugzilla/show_bug.cgi?id=956
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.