[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 5/5] * open_issues/automatic_backtraces_when_assertions_hit.mdwn:
From: |
address@hidden |
Subject: |
[PATCH 5/5] * open_issues/automatic_backtraces_when_assertions_hit.mdwn: delete file. |
Date: |
Mon, 15 May 2023 11:34:57 -0400 |
---
...omatic_backtraces_when_assertions_hit.mdwn | 79 -------------------
1 file changed, 79 deletions(-)
delete mode 100644 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
deleted file mode 100644
index df7294e9..00000000
--- a/open_issues/automatic_backtraces_when_assertions_hit.mdwn
+++ /dev/null
@@ -1,79 +0,0 @@
-[[!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
-
- <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel:
Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed.
- <youpi> it'd be great if we could have backtraces in such case
- <youpi> at least just the function names
- <youpi> 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]].
-
- <braunr> pinotree: tschwinge: do you know if our packages are built with
- -rdynamic ?
- <pinotree> braunr: debian's cflags don't include it, so unless the upstream
- build systems do, -rdynamic is not added
- <braunr> i doubt glibc' backtrace() is able to find debugging symbol files
- on its own
- <pinotree> what do you mean?
- <braunr> the port reference bug youpi noticed is rare
- <pinotree> even on linux, a program compiled with normal optimizations (eg
- -O2 -g) can give just pointer values in backtrace()'s output
- <braunr> core dumps are unreliable at best
-
-[[crash_server]].
-
- <braunr> uh, no, backtrace does give names
- <braunr> but not with -fomit-frame-pointer
- <braunr> unless the binary is built with -rdynamic
- <braunr> at least it used to
- <pinotree> not really, when being optimized some steps can be optimized
- away (eg inlines)
- <braunr> that's ok
- <braunr> anyway, the point is i'd like a way that can give us as much
- information as possible when the problem happens
- <braunr> the stack trace being the most useful imo
- <pinotree> do you face issues currently with backtrace()?
- <braunr> not tried yet
- <braunr> 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 :>
- <pinotree> that would imply the need for interactivity when the fault
- happens, wouldn't it?
- <braunr> no
- <braunr> it would remain this way until someone comes, hours, days later
- <braunr> pinotree: well ok, it would require interactivity, but not *when*
- it happens ;p
- <braunr> pinotree: right, it needs -rdynamic
-
-
-## IRC, freenode, #hurd, 2012-07-21
-
- <braunr> tschwinge: my current "approach" is to introduce an infinite loop
- <braunr> it makes the faulting task mapped in often enough to use gdb
- through qemu
- <braunr> ... :)
- <tschwinge> 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).
- <braunr> yes, i thought it used the backtrace functions internally though
- <braunr> that is, execinfo
- <braunr> but this does require -rdynamic
-
-
-# GCC's libbacktrace
-
-Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde.
--
2.32.0