Bug 956 - regression: backtrace uses malloc()
Summary: regression: backtrace uses malloc()
Status: RESOLVED DUPLICATE of bug 16159
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: GOTO Masanori
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-17 02:04 UTC by Matthias Andree
Modified: 2014-05-28 19:46 UTC (History)
4 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Andree 2005-05-17 02:04:18 UTC
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.
Comment 1 Ulrich Drepper 2005-09-27 05:55:57 UTC
Live with it.
Comment 2 Matthias Andree 2005-09-27 09:43:46 UTC
I'm reopening this bug as there is no reason given why this bug was marked 
WONTFIX the usual Drepper (= antisocial) way.

As already stated, this is a serious regression over previous versions - 
particularly as it can be expected that malloc() won't yield good results if 
we're backtracing, for instance, after SIGSEGV.

So before closing this bug as WONTFIX, please give a sustainable reason why 
there is no reasonable alternative to dlopen().
Comment 3 Ulrich Drepper 2006-08-13 20:38:06 UTC
You have no right to ask for a reason since you're not doing any of the work. 
I'm not changing the code and therefore it's closed as WONTFIX.
Comment 4 Matthias Andree 2006-08-13 20:45:26 UTC
Reopening bug, deviation from documented behavior persists in 2.3.4.
Comment 5 Matthias Andree 2006-08-13 20:50:57 UTC
BTW, what does Ulrich Drepper need to care for bugs not assigned to him?
Comment 6 Ulrich Drepper 2006-08-28 06:01:32 UTC
There is no bug and nobody is going to work on changing any behavior from what
it now is.  If somebody has sufficient interest, go ahead, create a patch, send
the assignment forms to the FSF, and then open a new bug.  But there is nothing
wrong here and nothing will change until somebody volunteers to do _all_ the work.
Comment 7 Matthias Andree 2006-12-07 14:12:41 UTC
Please leave the bug open since there is no final "wontfix", but the bug is
suspended until someone with FSF paper stuff contributes a patch.
Comment 8 Nils Goroll 2009-04-25 09:06:12 UTC
I came across this bug when trying to use backtrace while the main_arena
lock is helt, which will deadlock as well (as dlopen cannloc malloc()).

I guess it should be possible to add optional eager initialization via
backtrace.c init() and I will hopefully find the time to look into this.

For the time being, it might help to know that calling backtrace.c init()
somewhen before actually using backtrace will avoid this issue.
Comment 9 Darryl Miles 2013-11-13 03:34:07 UTC
See also Bug#16159
Comment 10 Carlos O'Donell 2013-11-13 03:44:48 UTC
I'm closing this issue in favour of using bug 16159 to track this.

*** This bug has been marked as a duplicate of bug 16159 ***
Comment 11 Jackie Rosen 2014-02-16 19:41:38 UTC Comment hidden (spam)