summaryrefslogtreecommitdiff
path: root/open_issues/boehm_gc.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/boehm_gc.mdwn')
-rw-r--r--open_issues/boehm_gc.mdwn30
1 files changed, 29 insertions, 1 deletions
diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn
index 623dcb83..2913eea8 100644
--- a/open_issues/boehm_gc.mdwn
+++ b/open_issues/boehm_gc.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2012, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -199,6 +199,9 @@ sources, and for `libatomic_ops` to the
rely on glibc internals. Or we instead add support to parse
[[`/proc/`|hurd/translator/procfs]] (can even use the same as Linux?),
or use some other interface. [[!tag open_issue_glibc]]
+ This is also likely the issue causing the GDB [[!tag open_issue_gdb]]
+ `GC_find_limit_with_bound` SIGSEGV startup confusion described in
+ [[binutils]].
* `#define SIG_SUSPEND SIGUSR1`, `#define SIG_THR_RESTART SIGUSR2`
@@ -523,3 +526,28 @@ restults of GNU/Linux and GNU/Hurd look very similar.
<congzhang> hi, I am dotgnu work on hurd, and even winforms app
<congzhang> s/am/make
<congzhang> and maybe c# hello world translate another day :)
+
+
+### IRC, freenode, #hurd, 2013-12-16
+
+ <braunr> gnu_srs: ah, libgc
+ <braunr> there are signal-related problems with libgc
+
+
+## Leak Detection
+
+### IRC, freenode, #hurd, 2013-10-17
+
+ <teythoon> I spent the last two days integrating libgc - the boehm
+ conservative garbage collector - into hurd
+ <teythoon> it can be used in leak detection mode
+ <azeem> whoa, cool
+ <teythoon> and it actually kind of works, finds malloc leaks in translators
+ <braunr> i think there were problems with signal handling in libgc
+ <braunr> i'm not sure we support nested signal handling well
+ <teythoon> yes, I read about them
+ <teythoon> libgc uses SIGUSR1/2, so any program installing handlers on them
+ will break
+ <azeem> (which is not a problem on Linux, cause there some RT-signals or so
+ are used)
+ <teythoon> yes