From 6b366a25f9fd496777ff42932685924eb83696fc Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 24 Apr 2013 11:46:58 +0200 Subject: IRC. --- open_issues/gdb_attach.mdwn | 29 ++++++- open_issues/gnumach_memory_management.mdwn | 34 ++++++++ open_issues/libpthread_assertion_thread_prevp.mdwn | 45 +++++++++- open_issues/libpthread_cancellation_points.mdwn | 98 ++++++++++++++++++++++ 4 files changed, 201 insertions(+), 5 deletions(-) (limited to 'open_issues') 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 That is supposed to work. If the permission match. + + +# `gdb --pid [PID]` + +That is, not explicitly specifying an `executable-file`. + + +## IRC, OFTC, debian-hurd, 2013-04-15 + + I don't seem to be able to run gdb + that happened on the buildd and happens on exodar too + #0 0x010c07cc in ?? () + #1 0x010c1078 in ?? () + #2 0x0109eabf in ?? () + [...] + Backtrace stopped: previous frame inner to this frame (corrupt + stack?) + that's pid 24235 on exodar + I did gdb -p 24235 and then bt + just the output above + I don't know about gdb -p + I usually run gdb + /home/paravoid/gdnsd-1.8.1/plugins/meta/libgdmaps/t/.libs/lt-t17_extn_empty.bin + 24235 + okay, that indeed works + 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 46454207..509a06d1 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -2227,3 +2227,37 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. (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 + + oh nice, i've found a big scalability issue with my slab allocator + it shouldn't affect gnumach much though + + +## IRC, freenode, #hurd, 2013-04-19 + + braunr: is it fixable? + yes + well, i'll do it in x15 for a start + again, i don't think gnumach is much affected + it's a scalability issue + when millions of objects are in use + gnumach rarely has more than a few hundred thousands + it's also related to heavy multithreading/smp + and by multithreading, i also mean preemption + gnumach isn't preemptible and uniprocessor + if the resulting diff is clean enough, i'll push it to gnumach + though :) + + +### IRC, freenode, #hurd, 2013-04-21 + + ArneBab_: i fixed the scalability problems btw + + +## IRC, freenode, #hurd, 2013-04-20 + + well, there is also a locking error in the slab allocator, + although not a problem for a non preemptible kernel like gnumach + 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] [169/340/1] test_logging @@ -22,7 +23,8 @@ IRC, OFTC, #debian-hurd, 2011-10-21: __pthread_enqueue: Assertion `thread->prevp == 0' failed. sigh -IRC, freenode, #hurd, 2011-10-21: + +## IRC, freenode, #hurd, 2011-10-21 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: 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 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: yeah apparently prevp/next are used for lists of held waitcond/mutex/rwlock and free threads + + +# IRC, freenode, #hurd, 2013-03-20 + + aw + i hit the ext2fs.static: ./pthread/pt-internal.h:122: + __pthread_enqueue: Assertion `thread->prevp == 0' failed. + assertion + looks like there is a deadlock on assert + which might explain why i never saw progress when i tested that in + the past + + +## IRC, freenode, #hurd, 2013-04-21 + + damn, there still bugs in libpthread + (about prevp not being null when it should i mean) + braunr: found another trigger for that? + no + it's so random i wonder if it's not a completely unrelated + corruption + pinotree: also, i'm having more of these issues with my custom + hurd packages that let threads exit after some time from managing ports + (i removed the libports_stability patch) + i once had this : http://www.sceen.net/~rbraun/darnassus_crash.png + +[The assertion failure.] + + +## IRC, freenode, #hurd, 2013-04-23 + + 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 + + so, let me say a few things about the bug in the first place + the package builds and runs a test suite + the second test in the test suite blocks forever + a blocked pthread_join is what I see + I'm unsure why + have you seen anything like it before? + whenever the thread doesn't actually terminate, sure + what is the thread usually blocked on when you cancel it? + this is a hurd-specific issue + works on all other arches + could be just that all other archs have more relaxed behavior + thus the question of what exactly is supposed to be happening + apparently it is inside a select? + it seems select is not cancellable here + wasn't the patch you sent? + no, my patch was about signals + not cancellation + k + (even if that could be related, of course) + how did you see that? + what's the equivalent of strace? + thread 3 is inside _hurd_select + thread 1 is blocked on join + but the code is + if(gdmaps->reload_thread_spawned) { + pthread_cancel(gdmaps->reload_tid); + pthread_join(gdmaps->reload_tid, NULL); + } + so cancel should have killed the thread + cancelling a thread is a complex matter + there are cancellation points + e.g. a thread performing while(1); can't be cancelled + thread 3 is just a libev event loop + yes, "just" calling poll, the most complex system call of unix :) + paravoid: anyway, don't look for a bug in your program, it's most + likely a bug in glibc, thanks for the report + I think it all boils down to a problem cancelling a thread in + poll() + yes + paravoid: ok, actually with the latest libc it does work + oh? + where latest = not uploaded yet :/ + did you test this on exodar? + pinotree: that's the libpthread_cancellation.diff I guess + because I commented out the join :) + paravoid: in the root, yes + well, I tried my own program + oh, okay + which is indeed hanging inside select (or just read) in the chroot + but not in the root + ah, richard's patch + url? + I've installed the build-dep in the root, if you want to try + strange that root is newer than the chroot :) + paravoid: it's the usual eglibc debian source + tried in root, still fails + could you keep the process running? + done + Mmm, but the thread running gdmaps_reload_thread never set the + cancel type to async? + that said I guess read and select are supposed to be cancellation + points + thus cancel_deferred should be working, but they are not + it seems it's cancellation points which have just not been + implemented + (they happen to be one of the most obscure things in posix) + + +## IRC, freenode, #hurd, 2013-04-15 + + but yes, there is still an issue, with PTHREAD_CANCEL_DEFERRED + how calls like read() or select() are supposed to test + cancellation? + iirc there are the LIBC_CANCEL_* macros in glibc + eg sysdeps/unix/sysv/linux/pread.c + yes + but in our libpthredaD? + could it be we lack the libpthread → glibc bridge of + cancellation stuff? + we do have pthread_setcancelstate/type forwards + but it seems the default LIBC_CANCEL_ASYNC is void + 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 + as I said, the bridge is there + we're just not using it in glibc + I'm writing an open_issues page + + +### IRC, freenode, #hurd, 2013-04-16 + + youpi: yes, we said some time ago that it was lacking -- cgit v1.2.3