From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- .../automatic_backtraces_when_assertions_hit.mdwn | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 open_issues/automatic_backtraces_when_assertions_hit.mdwn (limited to 'open_issues/automatic_backtraces_when_assertions_hit.mdwn') diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn new file mode 100644 index 00000000..df7294e9 --- /dev/null +++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn @@ -0,0 +1,79 @@ +[[!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. -- cgit v1.2.3