View Bug Activity | Format For Printing
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.
Live with it.
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().
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.
Reopening bug, deviation from documented behavior persists in 2.3.4.
BTW, what does Ulrich Drepper need to care for bugs not assigned to him?
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.
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.
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.