Merge remote-tracking branch 'fp/master'

4 files changed, 201 insertions, 5 deletions

diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn
index 8f1b7b48..b9114b69 100644
--- a/open_issues/gdb_attach.mdwn
+++ b/open_issues/gdb_attach.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -54,3 +54,30 @@ License|/fdl]]."]]"""]]
       process
     <tschwinge> That is supposed to work.
     <tschwinge> If the permission match.
+
+
+# `gdb --pid [PID]`
+
+That is, not explicitly specifying an `executable-file`.
+
+
+## IRC, OFTC, debian-hurd, 2013-04-15
+
+    <paravoid> I don't seem to be able to run gdb
+    <paravoid> that happened on the buildd and happens on exodar too
+    <paravoid> #0  0x010c07cc in ?? ()
+    <paravoid> #1  0x010c1078 in ?? ()
+    <paravoid> #2  0x0109eabf in ?? ()
+    <paravoid> [...]
+    <paravoid> Backtrace stopped: previous frame inner to this frame (corrupt
+      stack?)
+    <paravoid> that's pid 24235 on exodar
+    <paravoid> I did gdb -p 24235 and then bt
+    <paravoid> just the output above
+    <youpi> I don't know about gdb -p
+    <youpi> I usually run gdb
+      /home/paravoid/gdnsd-1.8.1/plugins/meta/libgdmaps/t/.libs/lt-t17_extn_empty.bin
+      24235
+    <paravoid> okay, that indeed works 
+    <youpi> I guess the support for finding out the binary automatically wasn't
+      done yet on hurd
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index 511d3f2b..60ec7357 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -2229,3 +2229,37 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> (i mean, when i made my tests, it looked like there were few
       kernel map entries, but i may have missed corner cases that could cause
       more of them to be needed)
+
+
+# IRC, freenode, #hurd, 2013-04-18
+
+    <braunr> oh nice, i've found a big scalability issue with my slab allocator
+    <braunr> it shouldn't affect gnumach much though
+
+
+## IRC, freenode, #hurd, 2013-04-19
+
+    <ArneBab> braunr: is it fixable?
+    <braunr> yes
+    <braunr> well, i'll do it in x15 for a start
+    <braunr> again, i don't think gnumach is much affected
+    <braunr> it's a scalability issue
+    <braunr> when millions of objects are in use
+    <braunr> gnumach rarely has more than a few hundred thousands
+    <braunr> it's also related to heavy multithreading/smp
+    <braunr> and by multithreading, i also mean preemption
+    <braunr> gnumach isn't preemptible and uniprocessor
+    <braunr> if the resulting diff is clean enough, i'll push it to gnumach
+      though :)
+
+
+### IRC, freenode, #hurd, 2013-04-21
+
+    <braunr> ArneBab_: i fixed the scalability problems btw
+
+
+## IRC, freenode, #hurd, 2013-04-20
+
+    <braunr> well, there is also a locking error in the slab allocator,
+      although not a problem for a non preemptible kernel like gnumach
+    <braunr> non preemptible / uniprocessor
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
index 1418bea1..e8160528 100644
--- a/open_issues/libpthread_assertion_thread_prevp.mdwn
+++ b/open_issues/libpthread_assertion_thread_prevp.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -13,7 +13,8 @@ failed"]]
 
 [[!tag open_issue_libpthread]]
 
-IRC, OFTC, #debian-hurd, 2011-10-21:
+
+# IRC, OFTC, #debian-hurd, 2011-10-21
 
     [Python testsuite]
     <pinotree> [169/340/1] test_logging
@@ -22,7 +23,8 @@ IRC, OFTC, #debian-hurd, 2011-10-21:
       __pthread_enqueue: Assertion `thread->prevp == 0' failed.
     <pinotree> sigh
 
-IRC, freenode, #hurd, 2011-10-21:
+
+## IRC, freenode, #hurd, 2011-10-21
 
     <pinotree> am i missing anything, or in libpthread the __pthread_threads
       list does not ever has elements removed from it?
@@ -33,7 +35,8 @@ IRC, freenode, #hurd, 2011-10-21:
     <pinotree> maybe reusing the same next+prevp pointers in the __pthread
       struct for more than one list at the same time isn't a good idea...
 
-2011-10-23:
+
+## IRC, freenode, #hurd, 2011-10-23
 
     <youpi> pinotree: I don't understand the relation between thread->prevp !=
       0 and the __pthread_threads list
@@ -50,3 +53,37 @@ IRC, freenode, #hurd, 2011-10-21:
     <pinotree> yeah
     <pinotree> apparently prevp/next are used for lists of held
       waitcond/mutex/rwlock and free threads
+
+
+# IRC, freenode, #hurd, 2013-03-20
+
+    <braunr> aw
+    <braunr> i hit the ext2fs.static: ./pthread/pt-internal.h:122:
+      __pthread_enqueue: Assertion `thread->prevp == 0' failed.
+    <braunr> assertion
+    <braunr> looks like there is a deadlock on assert
+    <braunr> which might explain why i never saw progress when i tested that in
+      the past
+
+
+## IRC, freenode, #hurd, 2013-04-21
+
+    <braunr> damn, there still bugs in libpthread
+    <braunr> (about prevp not being null when it should i mean)
+    <pinotree> braunr: found another trigger for that?
+    <braunr> no
+    <braunr> it's so random i wonder if it's not a completely unrelated
+      corruption
+    <braunr> pinotree: also, i'm having more of these issues with my custom
+      hurd packages that let threads exit after some time from managing ports
+    <braunr> (i removed the libports_stability patch)
+    <braunr> i once had this : http://www.sceen.net/~rbraun/darnassus_crash.png
+
+[The assertion failure.]
+
+
+## IRC, freenode, #hurd, 2013-04-23
+
+    <braunr> removing the libports_stability patch exposed bugs in libpthread,
+      triggering assertions when queueing/dequeue threads from a queue (but i
+      don't know which one / in which function)
diff --git a/open_issues/libpthread_cancellation_points.mdwn b/open_issues/libpthread_cancellation_points.mdwn
index af0efa9d..48f1acf5 100644
--- a/open_issues/libpthread_cancellation_points.mdwn
+++ b/open_issues/libpthread_cancellation_points.mdwn
@@ -39,3 +39,101 @@ type to asynchronous permits this testcase to terminate. We do have the
 pthread_setcanceltype glibc/libpthread hook in the forward structure, but we are
 not using it: the LIBC_CANCEL_ASYNC macros are void, and we're not using them in
 the mig msg call either.
+
+
+# Provenance
+
+## IRC, OFTC, #debian-hurd, 2013-04-15
+
+    <paravoid> so, let me say a few things about the bug in the first place
+    <paravoid> the package builds and runs a test suite
+    <paravoid> the second test in the test suite blocks forever
+    <paravoid> a blocked pthread_join is what I see
+    <paravoid> I'm unsure why
+    <paravoid> have you seen anything like it before?
+    <youpi> whenever the thread doesn't actually terminate, sure
+    <youpi> what is the thread usually blocked on when you cancel it?
+    <paravoid> this is a hurd-specific issue
+    <paravoid> works on all other arches
+    <youpi> could be just that all other archs have more relaxed behavior
+    <youpi> thus the question of what exactly is supposed to be happening
+    <youpi> apparently it is inside a select?
+    <youpi> it seems select is not cancellable here
+    <pinotree> wasn't the patch you sent?
+    <youpi> no, my patch was about signals
+    <youpi> not cancellation
+    <pinotree> k
+    <youpi> (even if that could be related, of course)
+    <paravoid> how did you see that?
+    <paravoid> what's the equivalent of strace?
+    <youpi> thread 3 is inside _hurd_select
+    <paravoid> thread 1 is blocked on join
+    <paravoid> but the code is
+    <paravoid>     if(gdmaps->reload_thread_spawned) {
+    <paravoid>         pthread_cancel(gdmaps->reload_tid);
+    <paravoid>         pthread_join(gdmaps->reload_tid, NULL);
+    <paravoid>     }
+    <paravoid> so cancel should have killed the thread
+    <youpi> cancelling a thread is a complex matter
+    <youpi> there are cancellation points
+    <youpi> e.g. a thread performing while(1); can't be cancelled
+    <paravoid> thread 3 is just a libev event loop
+    <youpi> yes, "just" calling poll, the most complex system call of unix :)
+    <youpi> paravoid: anyway, don't look for a bug in your program, it's most
+      likely a bug in glibc, thanks for the report
+    <paravoid> I think it all boils down to a problem cancelling a thread in
+      poll()
+    <youpi> yes
+    <youpi> paravoid: ok, actually with the latest libc it does work
+    <paravoid> oh?
+    <youpi> where latest = not uploaded yet :/
+    <paravoid> did you test this on exodar?
+    <youpi> pinotree: that's the libpthread_cancellation.diff I guess
+    <paravoid> because I commented out the join :)
+    <youpi> paravoid:  in the root, yes
+    <youpi> well, I tried my own program
+    <paravoid> oh, okay
+    <youpi> which is indeed hanging inside select (or just read) in the chroot
+    <youpi> but not in the root
+    <pinotree> ah, richard's patch
+    <paravoid> url?
+    <youpi> I've installed the build-dep in the root, if you want to try
+    <paravoid> strange that root is newer than the chroot :)
+    <youpi> paravoid: it's the usual eglibc debian source
+    <paravoid> tried in root, still fails
+    <youpi> could you keep the process running?
+    <paravoid> done
+    <youpi> Mmm, but the thread running gdmaps_reload_thread never set the
+      cancel type to async?
+    <youpi> that said I guess read and select are supposed to be cancellation
+      points
+    <youpi> thus cancel_deferred should be working, but they are not
+    <youpi> it seems it's cancellation points which have just not been
+      implemented
+    <youpi> (they happen to be one of the most obscure things in posix)
+
+
+## IRC, freenode, #hurd, 2013-04-15
+
+    <youpi> but yes, there is still an issue, with PTHREAD_CANCEL_DEFERRED
+    <youpi> how calls like read() or select() are supposed to test
+      cancellation?
+    <pinotree> iirc there are the LIBC_CANCEL_* macros in glibc
+    <pinotree> eg sysdeps/unix/sysv/linux/pread.c
+    <youpi> yes
+    <youpi> but in our libpthredaD?
+    <pinotree> could it be we lack the libpthread → glibc bridge of
+      cancellation stuff?
+    <youpi> we do have pthread_setcancelstate/type forwards
+    <youpi> but it seems the default LIBC_CANCEL_ASYNC is void
+    <pinotree> i mean, so when you cancel a thread, you can get that cancel
+      status in libc proper, just like it seems done with LIBC_CANCEL_* macros
+      and nptl
+    <youpi> as I said, the bridge is there
+    <youpi> we're just not using it in glibc
+    <youpi> I'm writing an open_issues page
+
+
+### IRC, freenode, #hurd, 2013-04-16
+
+    <braunr> youpi: yes, we said some time ago that it was lacking