[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_glibc]] # IRC, unknown channel, unknown date tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. it'd be great if we could have backtraces in such case at least just the function names and in this case (static), just addresses would be enough # IRC, freenode, #hurd, 2012-07-19 In context of the [[ext2fs_libports_reference_counting_assertion]]. pinotree: tschwinge: do you know if our packages are built with -rdynamic ? braunr: debian's cflags don't include it, so unless the upstream build systems do, -rdynamic is not added i doubt glibc' backtrace() is able to find debugging symbol files on its own what do you mean? the port reference bug youpi noticed is rare even on linux, a program compiled with normal optimizations (eg -O2 -g) can give just pointer values in backtrace()'s output core dumps are unreliable at best [[crash_server]]. uh, no, backtrace does give names but not with -fomit-frame-pointer unless the binary is built with -rdynamic at least it used to not really, when being optimized some steps can be optimized away (eg inlines) that's ok anyway, the point is i'd like a way that can give us as much information as possible when the problem happens the stack trace being the most useful imo do you face issues currently with backtrace()? not tried yet i guess i could make the application trap in the kernel, and fault there, so we can attach gdb while still in the pager address space :> that would imply the need for interactivity when the fault happens, wouldn't it? no it would remain this way until someone comes, hours, days later pinotree: well ok, it would require interactivity, but not *when* it happens ;p pinotree: right, it needs -rdynamic ## IRC, freenode, #hurd, 2012-07-21 tschwinge: my current "approach" is to introduce an infinite loop it makes the faulting task mapped in often enough to use gdb through qemu ... :) My understanding is that glibc already does have some mechanism for that: I have seen it print backtraces whendetecting malloc inconsistencies (double free and the lite). yes, i thought it used the backtrace functions internally though that is, execinfo but this does require -rdynamic # GCC's libbacktrace Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde.