From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- .../libpthread/t/fix_have_kernel_resources.mdwn | 217 +++++++++++++++++++++ 1 file changed, 217 insertions(+) (limited to 'open_issues/libpthread') diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn index 4e35161f..6f09ea0d 100644 --- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn +++ b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn @@ -196,3 +196,220 @@ Address problem mentioned in [[/libpthread]], *Threads' Death*. ## IRC, freenode, #hurd, 2013-07-03 grmbl, i don't want to give up thread destruction .. + + +## IRC, freenode, #hurd, 2013-07-15 + + btw, my work on thread destruction is currently stalled + i don't have much free time right now + + +## IRC, freenode, #hurd, 2013-09-13 + + i think i know why my thread_terminate_deallocate patches leak one + receive port :> + but now i'm not sure of the proper solution + every time a thread is created and destroyed, a receive right is + leaked + i guess it's simply the reply port .. + grmbl + i guess i have to make it a simpleroutine ... + hm too bad, it's not the reply port :( + it's also leaking some memory + it doesn't seem related to my changes though + stacks, rights, and threads are correctly destroyed + some obscure state is left behind + i wonder how exception ports are dealt with + vminfo seems to confirm memory is leaking in the heap + humpf + oh silly me + i don't detach threads + well, detach them ;) + hm worse :p + now i get additional dead names + but it's a step forward + + +## IRC, freenode, #hurd, 2013-09-16 + + that thread port leak is so strange + the leaked port seems to be created when the new thread starts + running + so it looks like a port the kernel would implicitely create + hm could it be a thread-specific reply port ? + ah, yes, there is one of those + how come mach/mig-reply.c in glibc isn't thread-safe ? + it is overriden by sysdeps/mach/hurd/img-reply.c I guess + which uses a threadvar for the mig reply port + oh + talking of which, there is also last_value in + sysdeps/mach/strerror_l.c + strerror_thread_freeres is supposed to get called, but who knows + it does look to be that port + iirc that's the issue which prevents from letting us make threads + exit on idleness? + one of them + ok + maybe the only one, yes + i see memory leaks but they could be related/normal + (i.e. not actual leaks) + on the other hand, i also can't boot a hurd with my patch + but i consider removing such leaks a priority + does anyone know the semantic difference between + __mig_put_reply_port and __mig_dealloc_reply_port ? + i guess __mig_dealloc_reply_port is actually a destruction + operation, right ? + AIUI, dealloc is used when one wants the port not to be reused at + all + because it has been used as a reference for something, and can + still be currently in use + while put_reply would be when we're really done with it, and won't + use it again, and can thus be used as such + or at least something like that + heh + __mig_dealloc_reply_port calls __mach_port_mod_refs, which is a + RPC, and creates a new reply port when destroying the current one + bah + that's fine, it's a deref of the old port, which is not in the + reply_port variable any more + it's fine, but still a leak + well, dealloc does not completely deallocs, yes + that's not really the problem here + i've introduced a case that wasn't considered at the time, namely + that a thread can destroy itself + we probably need another function to be called from the thread exit + i'll simply try with mach_port_destroy + mach_port_destroy seems to be a RPC too ... + grmbl + isn't there a trap version somehow ? + not in libc + erf + at least i know what's wrong now :) + there still is a small memory leak i have to investigate + but outside the stack + the stack, the thread name and the thread are correctly destroyed + slabinfo confirms only one port leak and nothing else is leaked + ok so the port leak was indeed the thread-specific reply port, + taken care of + there are also memory leaks too + + +## IRC, freenode, #hurd, 2013-09-17 + + teythoon: on my side, i'm getting to know our threading + implementation better + closing to clean thread destruction + x15 ipc will hide reply ports ;p + memory leaks solved \o/ + now, have to fix memory release when joining + proper reference counting on detach/join/exit, let's see how it + goes .. + seems to work fine + + +## IRC, freenode, #hurd, 2013-09-18 + + ok i'll soon have gnumach and libc packages including proper + thread destruction :> + braunr: why did you have to touch gnumach? + to add a call allowing threads to release ports and memory + i.e. their last self reference, their reply port and their stack + let me public my current patches + braunr: thread_commit_suicide ? + hehe + initially thread_terminate_self but + it can be used by other threads too + to i named it thread_terminate_release + http://darnassus.sceen.net/~rbraun/0001-pthread_thread_halt.patch + + http://darnassus.sceen.net/~rbraun/0001-thread_terminate_release.patch + the pthread patch needs to be polished because it changes the + semantics of pthread_thread_halt + but other than that, it should be complete + pthread_thread_halt_reallyhalt + ok let's try these libc packages + old static ext2fs for the root, but other than that, it boots + let's try iceweasel + (i'll need to build a hurd package against this new libc, removing + the libports_stability patch which prevents thread destruction in servers + on the way) + prevents thread destruction o_O + yes + in libports only ;p + oh, *only* in libports, I assumed for a moment that it affected + almost every component of the Hurd... + *phew( + ... :) + that's why, after a burst of messages, say because of aptitude + (select), you may see a few hundred threads still hanging around + also why unused servers remain running even after several minutes, + where the normal timeout is 2mins + I wondered about that, some servers (symlink comes to mind) seem + to go away if unused (or that's how I read the code) + symlinks are usually not servers, since most of them actually + exist in file systems, and are implemented through an optimization + yes I know that + trans/symlink.c reads: + /* The timeout here is 10 minutes */ + err = mach_msg_server_timeout (fsys_server, 0, control, + MACH_RCV_TIMEOUT, 1000 * 60 * 10); + if (err == MACH_RCV_TIMED_OUT) + exit (0); + ok + hm, /hurd/symlink doesn't feel at all like a symlink... but + works like one + well, starting iceweasel makes X on my host freeze oO + bbl + /hurd/symlink translators do go away after being unused for 10 + minutes... this is funny if they are set up by hand instead of being + started from a passive translator record + magically vanishing symlinks ;) + + +## IRC, freenode, #hurd, 2013-09-19 + + hum, i can't rebuild a hurd package :( + braunr: with your thread destruction patches in libc? + yes but it's unrelated + In file included from ../../libdiskfs/boot-start.c:38:0: + ./fsys_reply_U.h:173:15: error: conflicting types for + ‘fsys_get_children’ + i didn't see a new libc debian release + hm, David reported that as well + + id:CAEvUa7=QzOiS41G5Vq8k4AiaN10jAPm+CL_205OHJnL0xpJXbw@mail.gmail.com + uh oh + it seems I didn't add a _reply suffix to the reply routines :/ + there's quite a bit of fallout from my patches, I kinda feel bad + :( + teythoon: what i'm wondering is what youpi did too, since he got + hurd binary packages + braunr: well neither he nor I noticed that b/c for us the + declarations were just missing + from libc you mean ? + or hum gnumach-common ? + not sure actually + no it's not a gnumach thing + hurd-dev then + the build system should have cought these, or mig... + also, i see you changed fsys_reply.defs, but nothing about + fsys_request.defs + I have no fsys_requests.defs + looks like there was no fsys_request.defs in the first place + ... *sigh* + do you know an application that often creates and destroys threads + ? + no, sorry + maybe some test suite + ah right + sysbench maybe + also, i've been hit by a lot more network deadlocks than usual + lately + fixing netdde has gained some priority in my todo list + + +## IRC, freenode, #hurd, 2013-09-20 + + oh, git is multithreaded + great + so i've actually tested my libpthread patch quite a lot -- cgit v1.2.3