diff options
Diffstat (limited to 'open_issues')
278 files changed, 34876 insertions, 153 deletions
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn new file mode 100644 index 00000000..797d540f --- /dev/null +++ b/open_issues/64-bit_port.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2011 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_gnumach open_issue_mig]] + +IRC, freenode, #hurd, 2011-10-16: + + <youpi> it'd be really good to have a 64bit kernel, no need to care about + addressing space :) + <braunr> yes a 64 bits kernel would be nice + <braunr> i guess it wouldn't be too hard to have a special mach kernel for + 64 bits processors, but 32 bits userland only + <youpi> well, it means tinkering with mig + <braunr> like old sparc systems :p + <youpi> to build the 32bit interface, not the 64bit one + <braunr> ah yes + <braunr> hm + <braunr> i'm not sure + <braunr> mig would assume a 32 bits kernel, like now + <youpi> and you'll have all kinds of discrepancies in vm_size_t & such + <braunr> yes + <braunr> the 64 bits type should be completely internal + <braunr> types* + <braunr> but it would be far less work than changing all the userspace bits + for 64 bit (ofc we'll do that some day but in the meanwhile ..) + <youpi> yes + <youpi> and it'd boost userland addrespace to 4GiB + <braunr> yes + <youpi> leaving time for a 64bit userland :) diff --git a/open_issues/active_vs_passive_symlink_translator.mdwn b/open_issues/active_vs_passive_symlink_translator.mdwn new file mode 100644 index 00000000..cbd9b077 --- /dev/null +++ b/open_issues/active_vs_passive_symlink_translator.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2011 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_documentation open_issue_hurd]] + +IRC, freenode, #hurd, 2011-07-25 + +Set an *active* (not *passive*) `/hurd/symlink` translator on a node. + + < antrik> that's strange: the file doesn't look like a symlink in ls output + -- but it behaves like one... + < antrik> using firmlink instead of symlink yields less confusing + results... + < gg0> how does it behaves like one? + < antrik> perhaps the symlink mechanism only fully works for a passive + symlink translator, not an active one + < antrik> gg0: if you access it, you actually get the linked file contents + < antrik> it's only ls that's confused + < antrik> it might be because ls -l uses O_NOFOLLOW, which results in + O_NOTRANS, so it sees the original file contents + < gg0> stat says it's still 12264 bytes + < antrik> stat also seems to use NOFOLLOW + < antrik> wc will show the "correct" size + < gg0> ok + < antrik> if you set it as passive translator, it works as expected... but + then you better don't forget removing it, as it won't go away after a + reboot :-) + < antrik> but as I said, you can just ignore the weirdness -- or use + firmlink instead + < antrik> the thing is, if symlink is set as a passive translator, the + filesystem handles it specially, so it really looks like a symlink to + programs using NOFOLLOW. that's not the case with an active symlink... so + programs using NOFOLLOW simply do not see the active symlink at all + < antrik> firmlink OTOH ignores NOFOLLOW, so you always see the linked-to + file + + * [[hurd/translator/short-circuiting]] diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn new file mode 100644 index 00000000..caf447dd --- /dev/null +++ b/open_issues/address_space_memory_mapping_entries.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +IRC, freenode, #hurd, 2011-05-07 + + <braunr> and as a last example: memory mapping is heavily used in the hurd, + but for some reason, the map entries in an address space are still on a + linked list + <braunr> a bare linked list + <braunr> which makes faults and page cache lookups even slower diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn index 23552301..7761ec61 100644 --- a/open_issues/adduser.mdwn +++ b/open_issues/adduser.mdwn @@ -34,3 +34,4 @@ errors, thus the warning. Copying files from `/etc/skel' ... [...] +Reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623199 diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn new file mode 100644 index 00000000..99b2d7b6 --- /dev/null +++ b/open_issues/alarm_setitimer.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="alarm/setitimer"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +`setitimer()`, called by `alarm()` when setting a new alarm, it is not able +to disable on its own the timer when the alarm is fired the first time. +On the other hand, manually invoking `alarm(0)` can cancel the running timer +for `SIGALRM`. + +See also the attached file: on other OSes (e.g. Linux) it blocks waiting +for a signal, while on GNU/Hurd it gets a new alarm and exits. + +[[alrm.c]] diff --git a/open_issues/alarm_setitimer/alrm.c b/open_issues/alarm_setitimer/alrm.c new file mode 100644 index 00000000..689020ee --- /dev/null +++ b/open_issues/alarm_setitimer/alrm.c @@ -0,0 +1,32 @@ +#include <signal.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +static const char msg[] = "< got alarm\n"; + +static void sighandler(int signo __attribute__((unused))) +{ + write(STDOUT_FILENO, msg, sizeof(msg) - 1); +} + +int main() +{ + struct sigaction sa; + sa.sa_handler = sighandler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + if (sigaction(SIGALRM, &sa, NULL) == -1) + return 1; + + printf("> alarm in 2 secs...\n"); + alarm(2); + pause(); + + printf("> alarm!\n"); + + pause(); + printf("> got a signal...\n"); + + return 0; +} diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn new file mode 100644 index 00000000..99ef170b --- /dev/null +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -0,0 +1,268 @@ +[[!meta copyright="Copyright © 2011, 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]]."]]"""]] + +[[!taglink open_issue_documentation]] + +A bunch of this should also be covered in other (introductionary) material, +like Bushnell's Hurd paper. All this should be unfied and streamlined. + +IRC, freenode, #hurd, 2011-03-08: + + <foocraft> I've a question on what are the "units" in the hurd project, if + you were to divide them into units if they aren't, and what are the + dependency relations between those units(roughly, nothing too pedantic + for now) + <antrik> there is GNU Mach (the microkernel); there are the server + libraries in the Hurd package; there are the actual servers in the same; + and there is the POSIX implementation layer in glibc + <antrik> relations are a bit tricky + <antrik> Mach is the base layer which implements IPC and memory management + <foocraft> hmm I'll probably allocate time for dependency graph generation, + in the worst case + <antrik> on top of this, the Hurd servers, using the server libraries, + implement various aspects of the system functionality + <antrik> client programs use libc calls to use the servers + <antrik> (servers also use libc to communicate with other servers and/or + Mach though) + <foocraft> so every server depends solely on mach, and no other server? + <foocraft> s/mach/mach and/or libc/ + <antrik> I think these things should be pretty clear one you are somewhat + familiar with the Hurd architecture... nothing really tricky there + <antrik> no + <antrik> servers often depend on other servers for certain functionality + +--- + +IRC, freenode, #hurd, 2011-03-12: + + <dEhiN> when mach first starts up, does it have some basic i/o or fs + functionality built into it to start up the initial hurd translators? + <antrik> I/O is presently completely in Mach + <antrik> filesystems are in userspace + <antrik> the root filesystem and exec server are loaded by grub + <dEhiN> o I see + <dEhiN> so in order to start hurd, you would have to start mach and + simultaneously start the root filesystem and exec server? + <antrik> not exactly + <antrik> GRUB loads all three, and then starts Mach. Mach in turn starts + the servers according to the multiboot information passed from GRUB + <dEhiN> ok, so does GRUB load them into ram? + <dEhiN> I'm trying to figure out in my mind how hurd is initially started + up from a low-level pov + <antrik> yes, as I said, GRUB loads them + <dEhiN> ok, thanks antrik...I'm new to the idea of microkernels, but a + veteran of monolithic kernels + <dEhiN> although I just learned that windows nt is a hybrid kernel which I + never knew! + <rm> note there's a /hurd/ext2fs.static + <rm> I belive that's what is used initially... right? + <antrik> yes + <antrik> loading the shared libraries in addition to the actual server + would be unweildy + <antrik> so the root FS server is linked statically instead + <dEhiN> what does the root FS server do? + <antrik> well, it serves the root FS ;-) + <antrik> it also does some bootstrapping work during startup, to bring the + rest of the system up + +--- + +Provide a cross-linked sources documentation, including generated files, like +RPC stubs. + + * <http://www.gnu.org/software/global/> + +--- + +[[Hurd_101]]. + +--- + +More stuff like [[hurd/IO_path]]. + +--- + +IRC, freenode, #hurd, 2011-10-18: + + <frhodes> what happens @ boot. and which translators are started in what + order? + <antrik> short version: grub loads mach, ext2, and ld.so/exec; mach starts + ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs + init. from there on, it's just standard UNIX stuff + +--- + +IRC, OFTC, #debian-hurd, 2011-11-02: + + <sekon_> is __dir_lookup a RPC ?? + <sekon_> where can i find the source of __dir_lookup ?? + <sekon_> grepping most gives out rvalue assignments + <sekon_> -assignments + <sekon_> but in hurs/fs.h it is used as a function ?? + <pinotree> it should be the mig-generated function for that rpc + <sekon_> how do i know how its implemented ?? + <sekon_> is there any way to delve deeprer into mig-generated functions + <tschwinge> sekon_: The MIG-generated stuff will either be found in the + package's build directory (if it's building it for themselves), or in the + glibc build directory (libhurduser, libmachuser; which are all the + available user RPC stubs). + <tschwinge> sekon_: The implementation can be found in the various Hurd + servers/libraries. + <tschwinge> sekon_: For example, [hurd]/libdiskfs/dir-lookup.c. + <tschwinge> sekon_: What MIG does is provide a function call interface for + these ``functions'', and the Mach microkernel then dispatches the + invocation to the corresponding server, for example a /hurd/ext2fs file + system (via libdiskfs). + <tschwinge> sekon_: This may help a bit: + http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html + +--- + +IRC, freenode, #hurd, 2012-01-08: + + <abique> can you tell me how is done in hurd: "ls | grep x" ? + <abique> in bash + <youpi> ls's standard output is a port to the pflocal server, and grep x's + standard input is a port to the pflocal server + <youpi> the connexion between both ports inside the pflocal server being + done by bash when it calls pipe() + <abique> youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists + ? + <youpi> sure, hurd is compatible with posix + <abique> so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at + the pflocal server, then connects both ends to T1 and T2, then start(T1), + start(T2) ? + <youpi> not exactly + <youpi> it's like on usual unix, bash creates the pipe before creating the + tasks + <youpi> then forks to create both of them, handling them each side of the + pipe + <abique> ok I see + <youpi> s/handling/handing/ + <abique> but when you do pipe() on linux, it creates a kernel object, this + time it's 2 port on the pflocal ? + <youpi> yes + <abique> how are spawned tasks ? + <abique> with fork() ? + <youpi> yes + <youpi> which is just task_create() and duplicating the ports into the new + task + <abique> ok + <abique> so it's easy to rewrite fork() with a good control of duplicated + fd + <abique> about threading, mutexes, conditions, etc.. are kernel objects or + just userland objects ? + <youpi> just ports + <youpi> (only threads are kernel objects) + <abique> so, about efficiency, are pipes and mutexes efficient ? + <youpi> depends what you call "efficient" + <youpi> it's less efficient than on linux, for sure + <youpi> but enough for a workable system + <abique> maybe hurd is the right place for a userland thread library like + pth or any fiber library + <abique> ? + <youpi> hurd already uses a userland thread library + <youpi> libcthreads + <abique> is it M:N ? + <youpi> libthreads, actually + <youpi> yes + <abique> nice + <abique> is the task scheduler in the kernel ? + <youpi> the kernel thread scheduler, yes, of course + <youpi> there has to be one + <abique> are the posix open()/readdir()/etc... the direct vfs or wraps an + hurd layer libvfs ? + <youpi> they wrap RPCs to the filesystem servers + <antrik> the Bushnell paper is probably the closest we have to a high-level + documentation of these concepts... + <antrik> the Hurd does not have a central VFS component at all. name + lookups are performed directly on the individual FS servers + <antrik> that's probably the most fundamental design feature of the Hurd + <antrik> (all filesystem operations actually, not only lookups) + +IRC, freenode, #hurd, 2012-01-09: + + <braunr> youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1 + <braunr> and no modern OS is a right place for any thread userspace + library, as they wouldn't have support to run threads on different + processors (unless processors can be handled by userspace servers, but + still, it requires intimate cooperation between the threading library and + the kernel/userspace server in any case + <youpi> braunr: in libthreads, they are M:N + <youpi> you can run threads on different processors by using several kernel + threads, there's no problem in there, a lot of projects do this + <braunr> a pure userspace library can't use kernel threads + <braunr> at least pth was explacitely used on systems like bsd at a time + when they didn't have kernel threads exactly for that reason + <braunr> explicitely* + <braunr> and i'm actually quite surprised to learn that we have an M:N + threading model :/ + <youpi> why do you say "can't" ? + <braunr> but i wanted to reply to abique and he's not around + <youpi> of course you need kernel threads + <youpi> but all you need is to bind them + <braunr> well, what i call a userspace threading library is a library that + completely implement threads without the support of the kernel + <braunr> or only limited support, like signals + <youpi> errr, you can't implement anything with absolutely no support of + the kernel + <braunr> pth used only SIGALRM iirc + <youpi> asking for more kernel threads to use more processors doesn't seem + much + <braunr> it's not + <braunr> but i'm refering to what abique said + <braunr> 01:32 < abique> maybe hurd is the right place for a userland + thread library like pth or any fiber library + <youpi> well, it's indeed more, because the glibc lets external libraries + provide their mutex + <youpi> while on linux, glibc doesn't + <braunr> i believe he meant removing thread support from the kernel :p + <youpi> ah + <braunr> and replying "nice" to an M:N threading model is also suspicious, + since experience seems to show 1:1 models are better + <youpi> "better" ???? + <braunr> yes + <youpi> well + <youpi> I don't have any time to argue about that + <youpi> because that'd be extremely long + <braunr> simpler, so far less bugs, and also less headache concerning posix + conformance + <youpi> but there's no absolute "better" here + <youpi> but less performant + <youpi> less flexible + <braunr> that's why i mention experience :) + <youpi> I mean experience too + <braunr> why less performant ? + <youpi> because you pay kernel transition + <youpi> because you don't know anything about the application threads + <youpi> etc. + <braunr> really ? + <youpi> yes + <braunr> i fail to see where the overhead is + <youpi> I'm not saying m:n is generally better than 1:1 either + <youpi> thread switch, thread creation, etc. + <braunr> creation is slower, i agree, but i'm not sure it's used frequently + enough to really matter + <youpi> it is sometimes used frequently enough + <youpi> and in those cases it would be a headache to avoid it + <braunr> ok + <braunr> i thought thread pools were used in those cases + <youpi> synchronized with kernel mutexes ? + <youpi> that's still slow + <braunr> it reduces to the thread switch overhead + <braunr> which, i agree is slightly slower + <braunr> ok, i's a bit less performant :) + <braunr> well don't futexes exist just for that too ? + <youpi> yes and no + <youpi> in that case they don't help + <youpi> because they do sleep + <youpi> they help only when the threads are living + <braunr> ok + <youpi> now as I said I don't have to talk much more, I have to leave :) diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn new file mode 100644 index 00000000..1cfacaf5 --- /dev/null +++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010 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 diff --git a/open_issues/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn new file mode 100644 index 00000000..fb8cfd01 --- /dev/null +++ b/open_issues/automatically_checking_port_deallocation.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 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_gnumach]] + +IRC, unknown channel, unknown date. + + <youpi> we really need something that is able to automatically check port deallocation + <youpi> at least for the trivial cases, for which we do have bugs I'm currently fixing... + <pochu> test suite? :) + <pochu> won't magically find them though, so not what you've asked for... + <youpi> test suites can trigger some of the bugs yes + <youpi> which is already a good thing + <youpi> of course the coverage can't be perfect + <youpi> one of the bugs I fixed happened only for setuid binaries for instance diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn new file mode 100644 index 00000000..47598071 --- /dev/null +++ b/open_issues/bash.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2009 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_porting]] + +# *bash* 4.0 vs. typing `C-c` (*SIGINT*) + +Will show `-bash: echo: write error: (ipc/mig) wrong reply message ID` unter +certain conditions. + +After having noticed that this error doesn't occur if starting *bash* with +`--norc`, I isolated it to the following command in `.bashrc`: + + case $TERM in + xterm* | rxvt*) + PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"';; + esac + +... and indeed: + + tschwinge@flubber:~ $ echo "$TERM" -- "$PROMPT_COMMAND" + xterm -- echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007" + tschwinge@flubber:~ $ ^C + -bash: echo: write error: (ipc/mig) wrong reply message ID + tschwinge@flubber:~ $ PROMPT_COMMAND= + tschwinge@flubber:~ $ ^C + tschwinge@flubber:~ $ + + bash-4.0$ PROMPT_COMMAND='echo >&2 -n foo\ ' + foo bash-4.0$ ^C + + bash-4.0$ PROMPT_COMMAND='echo >&1 -n foo\ ' + foo bash-4.0$ ^C + bash: echo: write error: (ipc/mig) wrong reply message ID + + bash-4.0$ PROMPT_COMMAND='/bin/echo >&1 -n foo\ ' + foo bash-4.0$ ^C + bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID + +So, there's something different with stdout in / after the SIGINT handler. diff --git a/open_issues/bash_busy-loop.mdwn b/open_issues/bash_busy-loop.mdwn new file mode 100644 index 00000000..5228ba33 --- /dev/null +++ b/open_issues/bash_busy-loop.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +I've first seen this problem after having had the following command line run +for a week, or two, or three: + +Start `screen`. Find PID of pfinet. + + $ while sleep 66; do echo "$(date)" " $(ps --no-header --format=hurd -p [PID])"; done | tee ps-pfinet + +Leave it running, detach from `screen`. + +Eventually, the main `bash` process will go bonkers and eat 100 % CPU time. +Reproduced on four different systems. + +A faster way to reproduce this, again inside `screen`; every three seconds, +write text in 10 MiB bursts to the terminal: + + $ while sleep 3; do date > tmp/tmp && yes "$(date)" | dd bs=1M count=10; done + +This one only needs like ten hours, before `bash` starts its busy-loop, from +which it can only be terminated with `SIGKILL`. At this point, the `term`, +`screen`, `fifo` processes also have used 40, 52, 25 minutes of CPU time, +respectively, but appear to be still working fine. + +I did not yet start debugging this. diff --git a/open_issues/bash_interrupted_system_call.mdwn b/open_issues/bash_interrupted_system_call.mdwn new file mode 100644 index 00000000..9feab6ff --- /dev/null +++ b/open_issues/bash_interrupted_system_call.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +IRC, unknown channel, unknown date. + + <virtuoso015> i seem to be getting this message from the shell "-bash: /dev/fd/62: Interrupted system call" + <virtuoso015> is it significant ? + <youpi> I've seen this issue already yes + <youpi> it's not + <youpi> it's bash not handling EINTR properly + <antrik> youpi: so this is actually a bug in bash, not Hurd generating a bogus error? + <youpi> well, it's Hurd generating an error which bash doesn't expect to see diff --git a/open_issues/bash_vs_screen_vs_sigint.mdwn b/open_issues/bash_vs_screen_vs_sigint.mdwn new file mode 100644 index 00000000..9672041c --- /dev/null +++ b/open_issues/bash_vs_screen_vs_sigint.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + + * [[bash]] + * [[screen]] diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn new file mode 100644 index 00000000..afdcfb73 --- /dev/null +++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn @@ -0,0 +1,132 @@ +[[!meta copyright="Copyright © 2010, 2011 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_documentation]] + +What are the benefits of a native GNU/Hurd system, now that Linux et al. can do +so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux +and other virtualization techiques, and so on. + +It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... + +IRC, #hurd, August / September 2010 + + <marcusb> ArneBab: but Neal and I were not happy with that alone. We were + looking for deeper improvements to the system, for, I think, sound + reasons. That is what brought us to the L4/Coyotos technologies + <marcusb> ArneBab: as you are writing a kernel in user space, you can still + do kernel improvements there + <marcusb> ArneBab: if you take it very far, you end up with a kernel that + runs Linux in user space (just flip the two) for the drivers + <marcusb> ArneBab: that is what the L4 people did with the DDE + +[[/DDE]]. + + <marcusb> ArneBab: so, with these different cuts, there are different + opportunities. on the one end, you can run Linux as normal and get some + of the Hurd features such as translators in some programs. At the other + end, you can do whatever you want and run some linux code for the drivers + or none at all. + <marcusb> ArneBab: one of the big questions then becomes: at which point + can the advantages offered by the Hurd be realized? + <marcusb> ArneBab: and that's not entirely clear to me + <marcusb> when I worked on this with Neal, we pushed further and further + into need-to-change-everything land + <marcusb> while the current efforts on the Hurd seem to be more equivalent + to the could-run-it-in-userspace-on-top-of-Linux camp + <ArneBab> marcusb: for that I think we need a way to move towards them step + by step. Would it be possible to get the advantages of better resource + allocation with a Viengoos in userspace, too? + <ArneBab> and when that is stable, just switch over? + <marcusb> ArneBab: I don't know. I suspect these people will know before + us: http://lxc.sourceforge.net/ + <ArneBab> something like implementing flip points: flip Linux with Hurd to + Hund with Linux. Flip Mach with L4 to L4 with Mach. + <ArneBab> lxc sounds interesting. + <marcusb> note that these efforts address security concerns more than other + concerns + <marcusb> so they will get isolation long before sharing is even considered + <marcusb> but some of the issues are the same + <marcusb> once you allow malware to do what it wants, it's a small step to + also allow the user to what he wants :) + <ArneBab> it kinda looks like hacking it where it doesn’t really fit again… + <ArneBab> there I ask myself when the point comes that doing a cleaner + design offsets the popularity + <ArneBab> they are pushing more and more stuff into userspace + <ArneBab> which is a good thing (to me) + <ArneBab> it’s hard to clearly describe how, but even though I like having + more stuff in userspace, the way it is bolted onto Linux doesn’t feel + good for me. + <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to + a non-fuse user + <ArneBab> while in the Hurd, these additional options are on eqal footing. + <marcusb> ArneBab: are they pushing more and more into user space? I don't + think so. I see more of the reverse, actually + <marcusb> or maybe both + <ArneBab> FUSE, lxd and scheduling in userspace move to userspace + <ArneBab> well, KMS moved to the kernel + <ArneBab> to avoid flickering when switching between X and the console? + <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in + Linux, too, or is that just a strange feeling of me? + <ArneBab> marcusb: and that splits the users into those who can get stuff + into the kernel and those who can only work in userspace – which I don’t + really like. + <ArneBab> That’s one more advantage of the Hurd: eqal footing for all + (except the Mach hackers, but they have a very limited terrain) + <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have + a principled objection to it (but just wanted a more general solution) + <marcusb> ArneBab: as a side note, although people keep complaining, the + linux kernel seems to be growing steadily, so getting stuff into the + kernel doesn't seem too hard. 8-O + +--- + +IRC, #hurd, 2010-12-28 + + <tim> but is monolithic so bad? + <sartakov> yep + <braunr> no it's not + <braunr> proof: it works very well for most people + [...] + <braunr> the real problem is extensibility and interfaces + <tim> :/ whats the huge advantage of micro-k + <braunr> extensibility + <tim> over? + <braunr> you can add a whole lot of new services for new purposes with new + interfaces without changing the kernel + <tim> oright + <braunr> it basically boils down to the original Unix idea: everything does + one thing well + [...] + <kilobug> well, I would say extensibility and fault-tolerance are the two + key advantages + <braunr> taht's a side effect + <braunr> there are fault taulerant monolithic kernels + [...] + <braunr> tolerant* + <braunr> and the hurd is for now a non fault-tolerant microkernel based OS + :/ + [...] + <kilobug> braunr: not really; you can't ensure fault tolerance for code + running in kernel space, code running in kernel space can do everything, + including reboot, crash, ... + [...] + <braunr> kilobug: right, a monolithick kernel is less folt-tolerant than a + well designed/implemented microkernel based os + <kilobug> braunr: well, the Hurd is buggy nowadays, but things like an + ext2fs translator doing a segfault and being restarted is a + fault-tolerance that would be almost impossible to have in Linux + <kilobug> braunr: sure, you can have fault-tolerance with FUSE, but FUSE is + applying micro-kernel paradigm to Linux + [...] + <braunr> the reason i don't care that much about fault tolerance is that + Linux obviously shows a monolithic kernel can run almost flawlessly if + well written + <braunr> but extensibility is really another matter diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn new file mode 100644 index 00000000..8d6b3a94 --- /dev/null +++ b/open_issues/binutils.mdwn @@ -0,0 +1,205 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 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 stable_URL open_issue_binutils]] + +Here's what's to be done for maintaining GNU Binutils. + +As these tools primarily deal with low-level parts of the target architecture +and the object file format (ELF ABI), which are essentially (at least meant to +be) the same, there shouldn't be many differences comparing the binutils +between the GNU/Hurd and GNU/Linux ports, for example. There are a few, +though, as explained below. + +[[!toc levels=2]] + + +# [[General information|/binutils]] + + +# [[Sources|source_repositories/binutils]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourceware/master +-i +/^commit |^---$|hurd|linux|nacl + +--> + +Last reviewed up to the [[Git mirror's dde164167b2db4c05d58b1941d610beb6d5ca99f +(2012-06-08) sources|source_repositories/binutils]]. + + * Globally + + * a.out (such as `ld/emulparams/i386linux.sh`, `ld/emultempl/linux.em`, + etc.), COFF, PE image support and 64-bit support are not interesting. + + * In the testsuites, `.exp` and `.d` files very likely should not only + care for `*-*-linux*`, but also `*-*-gnu*`. (If they need to be + conditionalized like this at all.) + + * `bfd/` + + * `config.bfd` + + * `i[3-7]86-*-gnu*` + + Comparing to `i[3-7]86-*-linux-*`: + + * `i386linux_vec` -- a.out. + + * `i386pei_vec` -- PE. + + * 64 bit. + + * `configure.host` + + Souldn't need anything. x86 Linux neither. + + * `configure.in` + + Linux: + + * `COREFILE=trad-core.lo` with `TRAD_HEADER='"hosts/i386linux.h"'` + + We don't have any such core file support configured. TODO: should + we? Where is this core file reading exactly used? GDB? + + * `i386linux_vec` -- a.out. + + * `i386pei_vec` -- PE. + + * `binutils/` + + * `configure.tgt` + + * `gas/` + + * `config/te-gnu.h` + + C.f. `te-linux.h`; search tree for `TE_LINUX` vs. `TE_GNU` usage. + + * `tc-i386.h` + + Sole `TE_LINUX` usage is for a.out. + + * `configure.tgt` + + * `ld/` + + * `configure.host` + + * `*-*-gnu*` + + TODO: resolve `crt0.o` vs. `crt1.o` issue. [[Testsuite + failures|binutils#static]]. + + * `configure.tgt` + + * `i[3-7]86-*-gnu*` + + Compare to `i[3-7]86-*-linux-*`, but don't need a.out (`i386linux`) + and 64 bit support. + + +# Build + +Here's a log of a binutils build run; this is from our [[Git repository's +e1104996559067c40207c803ab1a5847a4a05145 (2012-06-07) +sources|source_repositories/binutils]], run on kepler.SCHWINGE and +coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +This takes up around 120 MiB, and needs roughly 4 min on kepler.SCHWINGE and +15 min on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && make -k check 2>&1 | tee log_check + +--> + + +## Analysis + +x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask +out most of the differences that are due to GNU/Linux supporting more core file +formats, and more emulation vectors. + + $ ssh kepler.SCHWINGE 'cd tmp/source/binutils/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/binutils/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/binutils/linux/log_build.sed < toolchain/logs/binutils/linux/log_build) <(sed -f toolchain/logs/binutils/hurd/log_build.sed < toolchain/logs/binutils/hurd/log_build) > toolchain/logs/binutils/log_build.diff + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 70 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3 +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/binutils/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/binutils/ && cat hurd/master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/hurd/log_install + $ diff -wu <(sed -f toolchain/logs/binutils/linux/log_install.sed < toolchain/logs/binutils/linux/log_install) <(sed -f toolchain/logs/binutils/hurd/log_install.sed < toolchain/logs/binutils/hurd/log_install) > toolchain/logs/binutils/log_install.diff + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + +# Testsuite + + $ make -k check + [...] + +This needs roughly 3 min on kepler.SCHWINGE and 13 min on coulomb.SCHWINGE. + + $ ssh kepler.SCHWINGE 'cd tmp/source/binutils/ && cat hurd/master.build/*/*.sum hurd/master.build/*/*/*.sum | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/linux/sum + $ ssh coulomb.SCHWINGE 'cd tmp/binutils/ && cat hurd/master.build/*/*.sum hurd/master.build/*/*/*.sum | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/hurd/sum + $ diff -u -F ^Running toolchain/logs/binutils/linux/sum toolchain/logs/binutils/hurd/sum > toolchain/logs/binutils/sum.diff + + +## Analysis + + * <a name="static"><!-- stable_URL -->`FAIL: static [...]`</a> + + The testsuite isn't prepared for using `crt0.o` instead of `crt1.o` + depending on whether a static or dynamic executable is created. Documented + in `ld/configure.host`. Perhaps we should finally rewrite this messy code + in glibc? + + * <a name="64ksec">`FAIL: ld-elf/64ksec`</a> + + On the idle grubber, this one takes a few minutes wall time to complete + successfully ([[I/O system + weakness|performance/io_system/binutils_ld_64ksec]]), so assuming some + system load variation, the testsuite's timeout may trigger. + + * <a name="weak"><!-- stable_URL -->`FAIL: ELF weak [...]`</a> + + [[I|tschwinge]] suppose this is due to us having an override w.r.t. weak + symbol handling in glibc, needed for our external [[/libpthread]]. TODO: + document properly. diff --git a/open_issues/binutils_gold.mdwn b/open_issues/binutils_gold.mdwn new file mode 100644 index 00000000..9eeebf2d --- /dev/null +++ b/open_issues/binutils_gold.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010, 2011, 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_binutils open_issue_porting]] + +Have a look at gold / port as needed. + +Apparently it needs [[glibc/mremap]]. diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn new file mode 100644 index 00000000..6ab39b2e --- /dev/null +++ b/open_issues/boehm_gc.mdwn @@ -0,0 +1,437 @@ +[[!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]]."]]"""]] + +Here's what's to be done for maintaining Boehm GC. + +This one does need Hurd-specific configuration. + +It is, for example, used by [[/GCC]] (which has its own fork), so any changes +committed upstream should very like also be made there. + +[[!toc levels=2]] + + +# [[General information|/boehm_gc]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/master +-i +/^commit |^---$|hurd|linux|glibc + +--> + +Last reviewed up to the 5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) +sources, and for `libatomic_ops` to the +6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) sources. + + * `configure.ac` + + * `PARALLEL_MARK` is not enabled; doesn't make sense so far. + + * `*-*-kfreebsd*-gnu` defines `USE_COMPILER_TLS`. What's this, and + why does not other config? + + * TODO + + [ if test "$enable_gc_debug" = "yes"; then + AC_MSG_WARN("Should define GC_DEBUG and use debug alloc. in clients.") + AC_DEFINE([KEEP_BACK_PTRS], 1, + [Define to save back-pointers in debugging headers.]) + keep_back_ptrs=true + AC_DEFINE([DBG_HDRS_ALL], 1, + [Define to force debug headers on all objects.]) + case $host in + x86-*-linux* | i586-*-linux* | i686-*-linux* | x86_64-*-linux* ) + AC_DEFINE(MAKE_BACK_GRAPH) + AC_MSG_WARN("Client must not use -fomit-frame-pointer.") + AC_DEFINE(SAVE_CALL_COUNT, 8) + ;; + AM_CONDITIONAL([KEEP_BACK_PTRS], [test x"$keep_back_ptrs" = xtrue]) + + * `configure.host` + + Nothing. + + * `Makefile.am`, `include/include.am`, `cord/cord.am`, `doc/doc.am`, + `tests/tests.am` + + Nothing. + + * `include/gc_config_macros.h` + + Should be OK. + + * `include/private/gcconfig.h` + + Hairy. But should be OK. Search for *HURD*, compare to *LINUX*, + *I386* case. + + See `doc/porting.html` and `doc/README.macros` (and others) for + documentation. + + *LINUX* has: + + * `#define LINUX_STACKBOTTOM` + + Defined instead of `STACKBOTTOM` to have the value read from `/proc/`. + + * `#define HEAP_START (ptr_t)0x1000` + + May want to define it for us, too? + + * `#ifdef USE_I686_PREFETCH`, `USE_3DNOW_PREFETCH` --- [...] + + Apparently these are optimization that we also could use. Have a + look at *LINUX* for *X86_64*, which uses `__builtin_prefetch` + (which Linux x86 could use, too?). + + * TODO + + #if defined(LINUX) && defined(USE_MMAP) + /* The kernel may do a somewhat better job merging mappings etc. */ + /* with anonymous mappings. */ + # define USE_MMAP_ANON + #endif + + * TODO + + #if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) + /* Nptl allocates thread stacks with mmap, which is fine. But it */ + /* keeps a cache of thread stacks. Thread stacks contain the */ + /* thread control blocks. These in turn contain a pointer to */ + /* (sizeof (void *) from the beginning of) the dtv for thread-local */ + /* storage, which is calloc allocated. If we don't scan the cached */ + /* thread stacks, we appear to lose the dtv. This tends to */ + /* result in something that looks like a bogus dtv count, which */ + /* tends to result in a memset call on a block that is way too */ + /* large. Sometimes we're lucky and the process just dies ... */ + /* There seems to be a similar issue with some other memory */ + /* allocated by the dynamic loader. */ + /* This should be avoidable by either: */ + /* - Defining USE_PROC_FOR_LIBRARIES here. */ + /* That performs very poorly, precisely because we end up */ + /* scanning cached stacks. */ + /* - Have calloc look at its callers. */ + /* In spite of the fact that it is gross and disgusting. */ + /* In fact neither seems to suffice, probably in part because */ + /* even with USE_PROC_FOR_LIBRARIES, we don't scan parts of stack */ + /* segments that appear to be out of bounds. Thus we actually */ + /* do both, which seems to yield the best results. */ + + # define USE_PROC_FOR_LIBRARIES + #endif + + * TODO + + # if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) \ + && !defined(INCLUDE_LINUX_THREAD_DESCR) + /* Will not work, since libc and the dynamic loader use thread */ + /* locals, sometimes as the only reference. */ + # define INCLUDE_LINUX_THREAD_DESCR + # endif + + * TODO + + # if defined(UNIX_LIKE) && defined(THREADS) && !defined(NO_CANCEL_SAFE) \ + && !defined(PLATFORM_ANDROID) + /* Make the code cancellation-safe. This basically means that we */ + /* ensure that cancellation requests are ignored while we are in */ + /* the collector. This applies only to Posix deferred cancellation;*/ + /* we don't handle Posix asynchronous cancellation. */ + /* Note that this only works if pthread_setcancelstate is */ + /* async-signal-safe, at least in the absence of asynchronous */ + /* cancellation. This appears to be true for the glibc version, */ + /* though it is not documented. Without that assumption, there */ + /* seems to be no way to safely wait in a signal handler, which */ + /* we need to do for thread suspension. */ + /* Also note that little other code appears to be cancellation-safe.*/ + /* Hence it may make sense to turn this off for performance. */ + # define CANCEL_SAFE + # endif + + * `CAN_SAVE_CALL_ARGS` vs. -fomit-frame-pointer now being on by + default for Linux x86 IIRC? (Which is an [[!taglink + open_issue_gcc]] for not including us.) + + * TODO + + # if defined(REDIRECT_MALLOC) && defined(THREADS) && !defined(LINUX) + # error "REDIRECT_MALLOC with THREADS works at most on Linux." + # endif + + + *HURD* has: + + * `#define STACK_GROWS_DOWN` + + * `#define HEURISTIC2` + + Defined instead of `STACKBOTTOM` to have the value probed. + + Linux also has this: + + #if defined(LINUX_STACKBOTTOM) && defined(NO_PROC_STAT) \ + && !defined(USE_LIBC_PRIVATES) + /* This combination will fail, since we have no way to get */ + /* the stack base. Use HEURISTIC2 instead. */ + # undef LINUX_STACKBOTTOM + # define HEURISTIC2 + /* This may still fail on some architectures like IA64. */ + /* We tried ... */ + #endif + + Being on [[glibc]], we could perhaps do similar as `USE_LIBC_PRIVATES` + instead of `HEURISTIC2`. Pro: avoid `SIGSEGV` (and general fragility) + during probing at startup (if I'm understanding this correctly). Con: + 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]] + + * `#define SIG_SUSPEND SIGUSR1`, `#define SIG_THR_RESTART SIGUSR2` + + * We don't `#define MPROTECT_VDB` (WIP comment); but Linux neither. + + * Where does our `GETPAGESIZE` come from? Should we `#include + <unistd.h>` like it is done for *LINUX*? + + * `include/gc_pthread_redirects.h` + + * TODO + + Cancellation stuff is Linux-only. In other places, too. + + * `mach_dep.c` + + * `#define NO_GETCONTEXT` + + [[!taglink open_issue_glibc]], but this is not a real problem here, + because we can use the following GCC internal function without much + overhead: + + * `GC_with_callee_saves_pushed` + + The `HAVE_BUILTIN_UNWIND_INIT` case is ours. + + * `os_dep.c` + + * `read` + + Sure that it doesn't internally (in [[glibc]]) use `malloc`. Probably + only / mostly (?) a problem for `--enable-redirect-malloc` + configurations? Linux with threads uses `readv`. + + * TODO. + + * `dyn_load.c` + + For `DYNAMIC_LOADING`. TODO. + + * `pthread_support.c`, `pthread_stop_world.c` + + TODO. + + * TODO. + + Other files also contain *LINUX* and other conditionals. + + * `libatomic_ops/` + + * `configure.ac` + + Nothing. + + * `Makefile`, `src/Makefile`, `src/atomic_ops/Makefile`, + `src/atomic_ops/sysdeps/Makefile`, `doc/Makefile`, `tests/Makefile` + + Nothing. + + * `src/atomic_ops/sysdeps/gcc/x86.h` + + Nothing. + + * b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all + correct. + + * `mmap`, b64dd3bc1e5a23e677c96b478d55648a0730ab75 + + * `parallel mark`, 07c2b8e455c9e70d1f173475bbf1196320812154, pass + `--disable-parallel-mark` or enable for us, too? + + * `HANDLE_FORK`, e9b11b6655c45ad3ab3326707aa31567a767134b, + 806d656802a1e3c2b55cd9e4530c6420340886c9, + 1e882b98c2cf9479a9cd08a67439dab7f9622924 + + * Check `include/private/thread_local_alloc.h` re + `USE_COMPILER_TLS`/`USE_PTHREAD_SPECIFIC`. + + +# Build + +Here's a log of a binutils build run; this is from the +5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) sources, and for +`libatomic_ops` for the 6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) +sources, run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ (cd ../master/ && ln -sfn ../libatomic_ops/master libatomic_ops) + $ (cd ../master/ && autoreconf -vfi) + $ ../master/configure --prefix="$PWD".install SHELL=/bin/bash CC=gcc-4.6 CXX=g++-4.6 --enable-cplusplus --enable-gc-debug --enable-gc-assertions --enable-assertions 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. Using bash instead of dash as otherwise libtool explodes. + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and +X min on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && { make -k check 2>&1 | tee log_check; (cd libatomic_ops/ && make -k check) 2>&1 | tee log_check_; } + +--> + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_build.sed < toolchain/logs/boehm-gc/linux/log_build) <(sed -f toolchain/logs/boehm-gc/hurd/log_build.sed < toolchain/logs/boehm-gc/hurd/log_build) > toolchain/logs/boehm-gc/log_build.diff + + * only GNU/Linux: `configure: WARNING: "Explicit GC_INIT() calls may be + required."` + + * only GNU/Linux: `configure: WARNING: "Client must not use + -fomit-frame-pointer."` + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and X +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_install + $ diff -wu toolchain/logs/boehm-gc/linux/log_install toolchain/logs/boehm-gc/hurd/log_install > toolchain/logs/boehm-gc/log_install.diff + + +# Testsuite + + $ make -k check + [...] + $ (cd libatomic_ops/ && make -k check) + [...] + +This needs roughly X min on kepler.SCHWINGE and X min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_check + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_check + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_check.sed < toolchain/logs/boehm-gc/linux/log_check) <(sed -f toolchain/logs/boehm-gc/hurd/log_check.sed < toolchain/logs/boehm-gc/hurd/log_check) > toolchain/logs/boehm-gc/log_check.diff + +There are different configurations possible, but in general, the testsuite +restults of GNU/Linux and GNU/Hurd look very similar. + + * GNU/Hurd is missing `Call chain at allocation: [...]` output. + + `os_dep.c`:`GC_print_callers` + + +# TODO + + * Port stuff to [[GCC]], and test it there. + + * What are other applications to test Boehm GC? Also especially in + combination with [[/libpthread]] and dynamic loading of shared libraries? + + * There are patches (apparently not committed) that GCC itself can use + it, too: <http://gcc.gnu.org/wiki/Garbage_collection_tuning>. + + * There's been some talking about it on GNU guile mailing lists, and two + Git branches (2010-12-15: last change 2009-09). + + * <http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users> + + +## IRC, OFTC, #debian-hurd, 2012-02-05 + +[[!tag open_issue_porting]] + + <pinotree> youpi: i think i found out the possible cause of the ecl and + mono issuess + <pinotree> -s + <youpi> oh + <pinotree> basically, we don't have the realtime signals (so no + SIGRTMIN/SIGRTMAX defined), hence things use either SIGUSR1 or + SIGUSR2... which are used in libgc to resp. stop/resume threads when + "collecting" + <pinotree> i just patched ecl to use SIGINFO instead of SIGUSR1 (used when + no SIGRTMIN+2 is available), and it seems going on for a while + <youpi> uh, why would SIGINFO work better than SIGUSR1? + <pinotree> it was a test, i tried the first "not common" signal i saw + <pinotree> my test was, use any signal different than USR1/2 + <youpi> ah, sorry, I hadn't understood + <youpi> you mean there's a conflict between ecl and mono using SIGUSR1, as + well as libgc? + <pinotree> yes + <pinotree> for example, in ecl sources see src/c/unixint.d, + install_process_interrupt_handler() + <youpi> SIGINFO seems a sane choice + <youpi> SIGPWR could have been a better choice if it was available :) + <pinotree> i would have chose an "unassigned" number, say SIGLOST (the + bigger one) + 10, but it would be greater than _NSIG (and thus discarded) + <youpi> not a good idea indeed + <pinotree> it seems that linux, beside the range for rt signals, has some + "free space" + <pinotree> i'll start now another ecl build, from scratch this time, with + s/SIGUSR1/SIGINFO/ (making sure ctags won't bother), and if it works i'll + update svante's bug + + <pinotree> mmap(...PROT_NONE...) failed + <pinotree> hmm... + <pinotree> apparently enabling MMAP_ANON in mono's libgc copy was a good + step, let's see + + +### IRC, OFTC, #debian-hurd, 2012-03-18 + + <pinotree> youpi: mono is afflicted by the SIGUSR1/2 conflict with libgc + <youpi> pinotree: didn't we have a solution for that? + <pinotree> well, it works just for one signal + <pinotree> the ideal solution would be having a range for RT signals, and + make libgc use RTMIN+5/6, like done on most of other OSes + <youpi> but we don't have RT signals, do we? + <pinotree> right :( + + +### IRC, freenode, #hurd, 2012-03-21 + + <pinotree> civodul: given we have to realtime signals (so no range of + signals for them), libgc uses SIGUSR1/2 instead of using SIGRTMIN+5/6 for + its thread synchronization stuff + <pinotree> civodul: which means that if an application using libgc then + sets its own handlers for either of SIGUSR1/2, hell breaks + <civodul> pinotree: ok + <civodul> pinotree: is it a Debian-specific change, or included upstream? + <pinotree> libgc using SIGUSR1/2? upstream + <civodul> ok diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn new file mode 100644 index 00000000..e24d761b --- /dev/null +++ b/open_issues/bpf.mdwn @@ -0,0 +1,587 @@ +[[!meta copyright="Copyright © 2009, 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]]."]]"""]] + +[[!meta title=BPF]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +This is a collection of resources concerning *Berkeley Packet Filter*s. + + +# Documentation + + * Wikipedia: [[!wikipedia "Berkeley Packet Filter"]] + + * [The Packet Filter: An Efficient Mechanism for User-level Network + Code](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8755), + 1987, Jeffrey C. Mogul, Richard F. Rashid, Michael J. Accetta + + * [The BSD Packet Filter: A New Architecture for User-level Packet + Capture](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.7849), + 1992, Steven Mccanne, Van Jacobson + + * [Protocol Service Decomposition for High-Performance + Networking](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.8387), + 1993, Chris Maeda, Brian N. Bershad + + * [Efficient Packet Demultiplexing for Multiple Endpoints and Large + Messages](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.44), + 1994, Masanobu Yuhara Fujitsu, Masanobu Yuhara, Brian N. Bershad, Chris + Maeda, J. Eliot, B. Moss + + * ... and many more + + +# Implementation + + * [[community/HurdFr]] + + * <http://wiki.hurdfr.org/index.php/BPF> + + * <http://wiki.hurdfr.org/index.php/Reseau_dans_gnumach> + + * Git repository: <http://rcs-git.duckcorp.org/hurdfr/bpf.git/> + + The patch for [[GNU Mach|microkernel/mach/gnumach]] is expected to be + complete and functional, the [[hurd/translator]] less so -- amongst others, + there are unresolved issues concerning support of [[hurd/glibc/IOCTL]]s. + + * <http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html> + + * [[zhengda]] + + * [[!GNU_Savannah_bug 25054]] -- Kernel panic with eth-multiplexer + + * [[!GNU_Savannah_patch 6619]] -- pfinet uses the virtual interface + + * [[!GNU_Savannah_patch 6620]] -- pfinet changes its filter rules with + its IP address + + * [[!GNU_Savannah_patch 6621]] -- pfinet sets the mach device into the + promiscuous mode + + * [[!GNU_Savannah_patch 6622]] -- pfinet uses the BPF filter + + * [[!GNU_Savannah_patch 6851]] -- fix a bug in BPF + + +# IRC + +## IRC, freenode, #hurd, 2012-01-13 + + <braunr> hm, i think the bpf code needs a complete redesign :p + <braunr> unless it's actually a true hurdish way to do things + <braunr> antrik: i need your help :) + <braunr> antrik: I need advice on the bpf "architecture" + <braunr> the current implementation uses a translator installed at /dev/bpf + <braunr> which means packets from the kernel are copied to that translator + and then to client applications + <braunr> does that seem ok to you ? + <braunr> couldn't the translator be used to set a direct link between the + kernel and the client app ? + <braunr> which approach seems the more Hurdish to you ? (<= this is what I + need your help on) + <pinotree> braunr: so there would be a roundtrip like kernel → bpf + translator → pfinet? + <antrik> braunr: TBH, I don't see why we need a BPF translator at all... + <braunr> antrik: it handles the ioctls + <braunr> pinotree: pfinet isn't involved (it was merely modified to use the + "new" filter format to specify it used the old packet filter, and not + bpf) + <antrik> braunr: do we really need to emulate the ioctl()s? can't we assume + that all packages using BPF will just use libpcap? + <antrik> (and even if we *do* want to emulate ioctl()s, why can't we handle + this is libc?) + <braunr> antrik: that's what i'm wondering actually + <braunr> even if assuming all packages use libpcap, i'd like our bpf + interface to be close to what bsds have, and most importantly, what + libpcap expects from a bpf interface + <antrik> well, why? if we already have a library handling the abstraction, + I don't see much point in complicating the design and use by adding + another layer :-) + <braunr> so you would advise adapting libpcap to include a hurd specific + module ? + <antrik> there are two reasons for adding translators: more robustness or + more flexibility... so far I don't see how a BPF translator would add + either + <braunr> right + <antrik> yes + <braunr> so we'd end up with a bpf-like interface, the same instructions + and format, with different control calls + <antrik> right + <antrik> note that I had more or less the same desicion to make for KGI + (emulate Linux/BSD ioctl()s, or implement a backend in libggi for + handling Hurd-specific RPC; and after much consideration, I decided on + the latter) + + +## IRC, freenode, #hurd, 2012-01-16 + + <braunr> antrik: is there an existing facility to easily give a send right + to the device master port to a task ? + <braunr> another function of the bpf translator is to handle the /dev/bpf + node, and most importantly its permissions + <braunr> so that users which have read/write access to the node have access + to the packet filter + <braunr> i guess the translator could limit itself to that functionality + <braunr> and then provide a device port on which libpcap operates directly + by means of device_{g,s}et_status/device_set_filter + <antrik> braunr: I don't see the point in seperating permissions for filter + from permissions from general network device access... + <antrik> as for device master port, all root tasks can obtain it from proc + IIRC + <braunr> antrik: yes, but how do we allow non-root users to access that + facility ? + <braunr> on a unix like system, it's a matter of changing the permissions + of /dev/bpf + <antrik> with devnode, non-root users can get access to specific device + nodes, including network devices + <braunr> i can't imagine the hurd being less flexible for that + <braunr> ah devnode + <braunr> good + <antrik> so we can for example make /dev/eth0 accessible by users of some + group + <braunr> what's devnode exactly ? + <antrik> it's a very simple translator that implements an FS node that + looks somewhat like a file, but the only operation it supports is + obtaining a pseudo device master port, giving access to a specific Mach + device + <braunr> is it already part of the hurd ? + <braunr> or hurdextras maybe ? + <antrik> it's only in zhengda's branch + <braunr> ah + <antrik> needed for both eth-multipexer and DDE + <braunr> and bpf soon i guess + <antrik> indeed :-) + <braunr> "obtaining a pseudo device master port", i believe you meant a + pseudo device port + <antrik> I must admit that I don't remember exactly whether devnode proxies + device_open(), so clients direct get a port to the device in question, or + whether it implements a pseudo device master port... + <antrik> but definitely not a pseudo device port :-) + <braunr> i'm almost positive it gives the target device port, otherwise i + don't see the point + <braunr> i don't understand the user of the "pseudo" word here either + <braunr> s/user/use/ + <braunr> aiui, devnode should be started as root (or in any way which gives + it the device master port) + <antrik> the point is that the client doesn't need to know the Mach device + name, and also is not bound to actual kernel devices + <braunr> and when started, implement the required permissions before giving + clients a device port to the specific device it was installed for + <braunr> right + <braunr> but it mustn't be a proxy + <antrik> yes, devnode needs access to either the real master device port + (for kernel devices), or one provided by eth-multiplexer or the DDE + network driver + <braunr> well, a very simple proxy for deviceopen + <braunr> ok + <braunr> that seems exactly what i wanted to do + <braunr> we now need to see if we can integrate it separately + <braunr> create a separate branch that works for the current gnumach code, + and merge dde/other specific code later on + <antrik> you mean independent of eth-multiplexer or DDE? yes, it was + generally agreed that devnode is a good idea in any case. I have no idea + why there are no device nodes for network devices on other UNIX + systems... + <braunr> i've been wondering that for years too :) + <antrik> zhengda's branch has a pfinet modified to a) use devnode, and b) + use BPF + <braunr> why bpf ? + <braunr> for more specific filters maybe ? + <antrik> hm... don't remember whether there was any technical reason for + going with BPF; I guess it just seemed more reasonable to invest new work + in BPF rather than obsolete Mach-specific NPF... + <braunr> cspf could be removed altogether, i agree + <antrik> another plus side of his modified pfinet is that it actually sets + an appropriate filter for TCP/IP and the IP in use, rather than just + setting a dummy filter catching app packets (including those irrelevant + to the specific pfinet instance) + <antrik> err... catching all packets + <braunr> that's what i meant by "for more specific filters maybe ?" + <braunr> he was probably more comfortable with the bpf interface to write + his filter rules + <antrik> well, it would probably be doable with NPF too :-) so by itself + it's not a reason for switching to BPF... + <antrik> it's rather the other way around: as it was necessary to implement + filters in eth-multiplexer, and implementing BPF seemed more reasoable, + pfinet had to be changed to use BPF... + <braunr> antrik: where is zhengda's branch btw ? + <antrik> (I guess using proper filters with eth-multiplexer is not strictly + necessary; but it would be a major performance hit not to) + <antrik> it's in incubator.git + <antrik> but it's very messy + <braunr> ok + <antrik> at some point I asked him to provide cleaned up branches, and I'm + pretty sure he said he did, but I totally fail to remember where he + published them :-( + <braunr> hm, i don't like how devnode is "architectured" :/ + <braunr> but it makes things a little more easy to get working i guess + <LarstiQ> antrik: any idea what to grep the logs on for that? + <braunr> ok never mind, devnode is fine + <braunr> exactly what i need + <braunr> i wonder however if it shouldn't be improved to better handle + permissions + <braunr> ok, never mind either, permission handling is fine + <braunr> so what are we waiting for ? :) + <antrik> I remember that there were some issues with permission handling, + but I don't remember whether all were fixed :-( + <antrik> LarstiQ: hm... good question... + <braunr> ah ? + <braunr> hm actually, there could be issues for packet filters, yes + <braunr> i guess we want to allow e.g. read-only opens for capture only + <antrik> braunr: that would have to be handled by the actual BPF + implementation I'd say + <braunr> it should already be the case + <antrik> what's the problem then? + <braunr> but when the actual device_open() is performed, the appropriate + permissions must be provided + <braunr> and checking those is the responsibility of the proxy, devnode in + this case + <antrik> and it doesn't do that? + <braunr> apparently not + <braunr> the only check is against the device name + <braunr> i'll begin playing with that first + <antrik> I vaguely remember that there has been discussion about the + relation of underlying device open mode and devnode open mode... but I + don't remember the outcome. in fact it was probably one of the + discussions I never got around to follow up on... :-( + <antrik> before you begin playing, take a look at the relevant messages in + the ML archive :-) + <antrik> must have been around two years ago + <braunr> ok + <antrik> some thread with me and scolobb (Sergiu Ivanov +- spelling) and + probably zhengda + <antrik> there might also be some outstanding patch(es) from scolobb, not + sure + + +## IRC, freenode, #hurd, 2012-01-17 + + <braunr> antrik: i think i found the thread you mentioned about devnode + <braunr> neither sergiu nor zhengda considered the use of a read-only + device for packet filtering + <braunr> leading to assumptions such as "only receiving packets + <braunr> is not terribly useful, in view of the fact that you have to at + least + <braunr> request them, which implies *sending* packets :-) + <braunr> " + <braunr> IMO, devnode should definitely check its node permissions to build + the device open flags + <braunr> good news is that it doesn't depend on anything specific to other + incubator projects + <braunr> making it almost readily mergeable in the hurd + <braunr> i'm not sure devnode is an appropriate name though + <braunr> maybe something like device, or devproxy + <braunr> proxy-devopen maybe + <antrik> braunr: well, I don't remember the details of the disucssion; but + as I mentioned in some mail, I did actually want to write a followup, + just didn't get around to it... so I was definitely not in agreement with + some of the statements made by others. I just don't remember on which + point :-) + <antrik> which thread was it? + <antrik> anyways, this should in no way be specific to network + devices... the idea is simply that if the client has only read + permissions on the device node, it should only get to open the underlying + device for read. it's up to the kernel to handle the read-only status for + the device once it's opened + <antrik> as for the naming, the idea is that devnode simply makes Mach + devices accessible through FS nodes... so the name seemed appropriate + <antrik> you may be right though that just "device" might be more + straightforward... I don't agree on the other variants + <braunr> antrik: + http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00155.html + <braunr> antrik: i agree with the general idea behind permission handling, + i was just referring to their thoughts about it, which probably led to + the hard coded READ | WRITE flags + <antrik> braunr: unfortunately, I don't remember the context of the + discussion... would take me a while to get into this again :-( + <antrik> the discussion seems to be about eth-multiplexer as much as about + devnode (if not more), and I don't remember the exact interaction + + +## IRC, freenode, #hurd, 2012-01-18 + + <braunr> so, does anyone have an objection to getting devnode into the hurd + and calling it something else like e.g. device ? + <youpi> braunr: it's Zhengda's work, right? + <braunr> yes + <youpi> I'm completely for it, it just perhaps needs some cleanup + <braunr> i have a few changes to add to what already exists + <braunr> ok + <braunr> well i'm assigning myself to the task + <antrik> braunr: I'm still not convinced just "device" is preferable + <antrik> perhaps machdevice ;-) + <antrik> but otherwise, I'd LOVE to see it in :-) + <braunr> i don't know .. what if the device is actually eth-multiplexer or + a dde one ? + <braunr> it's not really "mach", is it ? + <braunr> or do we only refer to the interface ? + <youpi> that translator is only for mach devices + <braunr> so you consider dde devices as being mach devices too ? + <braunr> it's a simple proxy for device_open really + <youpi> will these devices use that translator? + <youpi> ah + <youpi> I thought it was using a mach-specific RPC + <braunr> so we can consider whatever we want + <antrik> braunr: yes, the translator is for Mach device interface only. it + might be provided by other servers, but it's still Mach devices + <youpi> then drop the mach, yes + <braunr> i'd tend to agree with antrik + <youpi> antrik: I'd say the device interface is part of the hur dinterfaces + <braunr> then machdev :p + <braunr> no, it's really part of the mach interface + <youpi> it's part of the mach interface, yes + <youpi> but also of the Hurd, no? + <antrik> DDE network servers also use the Mach device interface + <braunr> no + <youpi> can't we say it's part of it? + <youpi> I mean + <youpi> even if we change the kernel + <braunr> dde is the only thing that implements it besides the kernel that i + know of + <youpi> we will probably want to keep the same interface + <braunr> yes but that's a mach thing + <youpi> what we have now is not necessarily a reason + <antrik> as for other DDE drivers, I for my part believe they should export + proper Hurd (UNIX) device nodes directly... but for some reason zhengda + insisted on implementing it as Mach devices too :-( + <braunr> antrik: i agree with you on that too + <braunr> i was a bit surprised to see the same interface was reused + <braunr> youpi: we can, we just have to agree on what we'll do + <braunr> what do you mean by "even if we change the kernel" ? + <antrik> the problem with "machdev" is that it might suggest the translator + actually implements the device... not sure whether this would cause + serious confusion + <antrik> "devopen" might be another option + <antrik> or "machdevopen" to be entirely verbose ;-) + <braunr> an option i suggested earlier which you disagreed on :p + <braunr> but devopen is the one i'd choose + <antrik> youpi: as I already mentioned in the libburn thread, I don't + actually think the Mach device interface is very nice; IMHO we should get + rid of it as soon as we can, rather than port it to other + architectures... + <antrik> but even *if* we decided to reuse it after all, it would still be + the Mach device interface :-) + <braunr> actually, zheng da already suggested that name a long time ago + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00005.html + <braunr> no actually antrik did eh + <braunr> ok let's use devopen + <antrik> braunr: you suggested proxy-devopen, which I didn't like because + of the "proxy" part :-) + <braunr> not only, but i don't have the logs any more :p + <antrik> oh, I already suggested devopen once? didn't expect myself to be + that consistent... ;-) + <antrik> braunr: you suggested device, devproxy or proxy-devopen + <braunr> ah, ok + <braunr> devopen is better + <antrik> I wonder whether it's more important for clarity to have "mach" in + there or "open"... or whether it's really too unweildy to have both + + +## IRC, freenode, #hurd, 2012-01-21 + + <braunr> oh btw, i made devopen run today, it shouldn't be hard getting it + in properly + <braunr> patching libpcap will be somewhat trickier + <braunr> i don't even really need it, but it allows having user access to + mach devices, which is nice for the libpcap patch and tcpdump tests + <braunr> permission checking is actually its only purpose + <braunr> well, no, not really, it also allows opening devices implemented + by user space servers transparently + + +## IRC, freenode, #hurd, 2012-01-27 + + <braunr> hmm, bpf needs more work :( + <braunr> or we can use the userspace bpf filter in libpcap, so that it + works with both gnumach and dde drivers + <antrik> braunr: there is a userspace BPF implementation in libpcap? I'm + surprised that zhengda didn't notice it, and ported the one from gnumach + instead... + <antrik> what is missing in the kernel implementation? + <braunr> antrik: filling the bpf header + <braunr> frankly, i'm not sure we want to bother with the kernel + implementation + <braunr> i'd like it to work with both gnumach and dde drivers + <braunr> and in the long run, we'll be using userspace drivers anyway + <braunr> the bpf header was one of the things the defunct translator did + <braunr> which involved ugly memcpy()s :p + <antrik> braunr: well, if you want to get rid of the kernel implementation, + basically you would have to take up eth-multiplexer and get it into + mainline + <antrik> (and make sure it's used by default in Debian) + <antrik> I frankly believe it's the better design anyways... but quite a + major change :-) + <braunr> not that major to me + <braunr> in the meantime i'll use the libpcap embedded implementation + <braunr> we'll have something useful faster, with minimum work when + eth-multiplexer is available + <antrik> eth-multiplexer is ready for use, it just needs to go upstream + <antrik> though it's probably desirable to switch it to the BPF + implementation from libpcap + <braunr> using the libpcap implementation in libpcap and in eth-multiplexer + are two different things + <braunr> the latter is preferrable + <braunr> (and yes, by available, i meant upstream ofc) + <antrik> eth-mulitplexer is already using libpcap anyways (for compiling + the filters); I'm sure zhengda just didn't realize it has an actual BPF + implementation too... + <braunr> we want the filter implementation as close to the packet source as + possible + <antrik> I have been using eth-multiplexer for at least two years now + <braunr> hm, there is a "snoop" source type, using raw sockets + <braunr> too far from the packet source, but i'll try it anyway + <braunr> hm wrong, snoop was the solaris packet filter fyi + + +## IRC, freenode, #hurd, 2012-01-28 + + <braunr> nice, i have tcpdump working :) + <braunr> let's see if it's as simple with wireshark + <pinotree> \o/ + <braunr> pinotree: it was actually very simple + <pinotree> heh, POV ;) + <braunr> yep, wireshark works too + <braunr> promiscuous mode is harder to test :/ + <braunr> but that's a start + + +## IRC, freenode, #hurd, 2012-01-30 + + <braunr> ok so next step: get tcpreplay working + <antrik> braunr: BTW, when you checked the status of the kernel BPF code, + did you take zhengda's enhancements/fixes into account?... + <braunr> no + <braunr> when did i check it ? + <antrik> braunr: well, you said the kernel BPF code has serious + shortcomings. did you take zhengda's changes into account? + <braunr> antrik: ah, when i mention the issues, i considered the userspace + translator only + <braunr> antrik: and stuff like non blocking io, exporting a selectable + file descriptor + <braunr> antrik: deb http://ftp.sceen.net/debian-hurd experimental/ + <braunr> antrik: this is my easy to use repository with a patched + libpcap0.8 + <braunr> and a small and unoptimized pcap-hurd.c module + <braunr> it doesn't use devopen yet + <braunr> i thought it would be better to have packet filtering working + first as a debian patch, then get the new translator+final patch upstream + <jkoenig> braunr, tcpdump works great here (awesome!). I'm probably using + exactly the same setup and "hardware" as you do, though :-P + + +## IRC, freenode, #hurd, 2012-01-31 + + <braunr> antrik: i tend to think we need a bpf translator, or anything + between the kernel and libpcap to provide selectable file descriptors + <braunr> jkoenig: do you happen to know how mach_msg (as called in a + hello.c file without special macros or options) deals with signals ? + <braunr> i mean, is it wrapped by the libc in a version that sets errno ? + <jkoenig> braunr: no idea. + <pinotree> braunr: what's up with it? (not that i have an idea about your + actual question, just curious) + <braunr> pinotree: i'm improving signal handling in my pcap-hurd module + <braunr> i guess checking for MACH_RCV_INTERRUPTED will dio + <braunr> -INFO is correctly handled :) + <braunr> ok new patch seems fine + <antrik> braunr: selectable file descriptors? + <braunr> antrik: see pcap_fileno() for example + <braunr> it returns a file descriptor matching the underlying object + (usually a socket) that can be multiplexed in a select/poll call + <braunr> obviously a mach port alone can't do the job + <braunr> i've upgraded the libpcap0.8 package with improved signal handling + for tests + <antrik> braunr: no idea what you are talking about :-( + + +## IRC, freenode, #hurd, 2012-02-01 + + <braunr> antrik: you do know about select/poll + <braunr> antrik: you know they work with multiple selectable/pollable file + descriptors + <braunr> on most unix systems, packet capture sources are socket + descriptors + <braunr> they're selectable/pollable + <antrik> braunr: what are packet capture sources? + <braunr> antrik: objects that provide applications with packets :) + <braunr> antrik: a PF_PACKET socket on Linux for example, or a Mach device, + or a BPF file descriptor on BSD + <antrik> for a single network device? or all of them? + <antrik> AIUI the userspace BPF implementation in libpcap opens this + device, waits for packets, and if any arrive, decides depending on the + rules whether to pass them to the main program? + <braunr> antrik: that's it, but it's not the point + <braunr> antrik: the point is that, if programs need to include packet + sources in select/poll calls, they need file descriptors + <braunr> without a translator, i can't provide that + <braunr> so we either decide to stick with the libpcap patch only, and keep + this limitation, or we write a translator that enables this feature + <pinotree> braunr: are the two options exclusive? + <braunr> pinotree: unless we implement a complete bpf translator like i did + years ago, we'll need a patch in libpcap + <braunr> pinotree: the problem with my early translator implementation is + that it's buggy :( + <braunr> pinotree: and it's also slower, as packets are small enough to be + passed through raw copies + <antrik> braunr: I'm not sure what you mean when talking about "programs + including packet sources". programs only interact with packet sources + through libpcap, right? + <antrik> braunr: or are you saying that programs somehow include file + descriptors for packet sources (how do they obtain them?) in their main + loop, and explicitly pass control to libpcap once something arrives on + the respecitive descriptors? + <braunr> antrik: that's the idea, yes + <antrik> braunr: what is the idea? + <braunr> 20:38 < antrik> braunr: or are you saying that programs somehow + include file descriptors for packet sources (how do they obtain them?) in + their main loop, and explicitly pass control to libpcap once something + arrives on the respecitive descriptors? + <antrik> braunr: you didn't answer my question though :-) + <antrik> braunr: how do programs obtain these FDs? + <braunr> antrik: using pcap_fileno() for example + + +## IRC, freenode, #hurd, 2012-02-02 + + <antrik> braunr: oh right, you already mentioned that one... + <antrik> braunr: so you want some entity that exposes the device as + something more POSIXy, so it can be used in standard FS calls, unlike the + Mach devices used for pfinet + <antrik> this is probably a good sentiment in general... but I'm not in + favour of a special solution only for BPF. rather I'd take this as an + indication that we probably should expose network interfaces as something + file-like in general after all, and adapt pfinet, eth-multiplexer, and + DDE accordingly + <braunr> antrik: i agree + <braunr> antrik: eth-multiplexer would be the right place + + +## IRC, freenode, #hurd, 2012-04-24 + + <gnu_srs> braunr: Is BPF fully supported by now? Can it be used for + isc-dhcp? + <braunr> gnu_srs: bpf isn't supported at all + <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module + in libpcap + <braunr> if isc-dhcp can use libpcap, then fine + <braunr> (otherwise we could create a hurd-specific patch for dhcp that + uses the in-kernel bpf filter implementation) + <braunr> gnu_srs: can't it use a raw socket ? + <youpi> it can + <youpi> it's just that the shape of the patch to do so wasn't exactly how + they needed it + <youpi> so they have to rework it a bit + <youpi> and that takes time + <braunr> ok + <braunr> antrik: for now, we prefer encapsulating the system specific code + in libpcap, and let users of that library benefit from it + <braunr> instead of implementing the low level bpf interface, which + nonetheless has some system-specific variants .. diff --git a/open_issues/bsd_compatibility.mdwn b/open_issues/bsd_compatibility.mdwn new file mode 100644 index 00000000..5c916908 --- /dev/null +++ b/open_issues/bsd_compatibility.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2011 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_documentation]] + +IRC, freenode, #hurd, 2011-10-12: + + <pinotree> hm, why our sys/param.h #define's BSD? + <braunr> pinotree: because we're evil + <pinotree> is that correct? + <pinotree> (the define, not the evilness) + <braunr> pinotree: i think it's because the Hurd is closer to the BSD + interfaces, probably because of Mach (which is itself derived from + BSD4.2) + <pinotree> braunr: but mach being bsd-ish won't make the userland (glibc) + interfaces bsd-ish, will it? + <braunr> pinotree: no + <pinotree> braunr: so...? :) + <braunr> pinotree: i guesse there are bsdisms in the glibc hurd specific + code, possibly because of mach + <braunr> or they used to be bsdisms, before being standardized + <braunr> e.g. mmap + <pinotree> braunr: hrmm... + <antrik> braunr: the BSDisms are there on purpose... Hurd was originally + even meant to be binary-compatible with BSD + <antrik> nothing to do with Mach really + <braunr> antrik: ok diff --git a/open_issues/chroot_difference_from_linux.mdwn b/open_issues/chroot_difference_from_linux.mdwn new file mode 100644 index 00000000..f2009bd8 --- /dev/null +++ b/open_issues/chroot_difference_from_linux.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +\#hurd, freenode, 2010 + + <cfhammar> weird, even fd = open("/"), chroot("/tmp/chroot"), openat(fd, "/tmp/chroot/..) opens /tmp/chroot in linux + <pochu> cfhammar: isn't that expected? + <cfhammar> pochu: well, i didn't expect it :-) + <cfhammar> pochu: in hurd, /tmp gets opened, which i think is more natural + <pochu> cfhammar: oh right, didn't notice the ".." :-) diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn new file mode 100644 index 00000000..5345ed6b --- /dev/null +++ b/open_issues/clock_gettime.mdwn @@ -0,0 +1,71 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="clock_gettime"]] + +[[!tag open_issue_glibc open_issue_gnumach]] + +Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) + +It could be a mere matter of extending the mappable clock: add it to +`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and +make `clock_gettime` use it. + +BTW, also make `gettimeofday()` use it, since it's way more efficient and some +applications assume that it is. + +What about adding a nanosecond-precision clock, too? --[[tschwinge]] + +IRC, freenode, #hurd, 2011-08-26: + + < pinotree> youpi: thing is: apparently i found a simple way to have a + monotonic clock as mmap-able device inside gnumach + < pinotree> currently, in kern/mach_clock.c there's a variable 'time', + which gets increased on clock interrupt, and optionally modified by + host_set_time + < pinotree> () + < pinotree> if i add a new variable next to it, only increasing it on + interrupt but not modifying it at all otherwise, would that give me a + monotonic clock? + < pinotree> at least on sme basic tests i did, it seems it could work that + way + < youpi> yes, it should work + < braunr> sure + < youpi> and that's the way I was considering implementing it + +IRC, freenode, #hurd, 2011-09-06: + + <pinotree> yeah, i had a draft of improved idea for also handling + nanoseconds + <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well. + <tschwinge> pinotree, youpi: This memory page is all-zero by default, + right? + <tschwinge> Can't we then say that its last int is a version code, and if + it is 0 (as it is now), we only have the normal mapped time field, if it + is 1, we also have the monotonic cliock and ns precision on address 8 and + 16 (or whatever)? + <tschwinge> In case that isn't your plan anyway. + <youpi> it's all-zero, yes + <tschwinge> Or, we say if a field is != 0 it is valid. + <youpi> making the last int a version code limits the size to one page + <youpi> I was thinking a field != 0 being valid is simpler + <youpi> but it's probably a problem too + <youpi> in that glibc usually caches whether interfaces are supported + <tschwinge> Wrap-around? + <youpi> for some clocks, it may be valid that the value is 0 + <youpi> wrap-around is another issue too + <tschwinge> Well, then we can do the version-field thing, but put it right + after the current time field (address 8, I think)? + <youpi> yes + <youpi> it's a bit ugly, but it's hidden behind the structure + <tschwinge> It's not too bad, I think. + <youpi> yes + <tschwinge> And it will forever be a witness of the evolving of this + map_time interface. :-) diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn new file mode 100644 index 00000000..00915651 --- /dev/null +++ b/open_issues/code_analysis.mdwn @@ -0,0 +1,135 @@ +[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]] + +In the topic of *code analysis* or *program analysis* ([[!wikipedia +Program_analysis_(computer_science) desc="Wikipedia article"]]), there is +static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia +article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis +desc="Wikipedia article"]]). This topic overlaps with [[performance +analysis|performance]], [[formal_verification]], as well as general +[[debugging]]. + +[[!toc]] + + +# Bounty + +There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks. + + +# Static + + * [[GCC]]'s warnings. Yes, really. + + * GCC plugins can be used for additional semantic analysis. For example, + <http://lwn.net/Articles/457543/>, and search for *kernel context* in + the comments. + + * Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out* + specifiers, and have it emit useful warnings in case these are pointing + to uninitialized data (for *in* only). + + * [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]]. If + these are used, care must be taken to update them reliably, [[!message-id + "1123688017.3905.22.camel@buko.sinrega.org"]]. This could be checked by a + static analysis tool. + + * [Static Source Code Analysis Tools for C](http://spinroot.com/static/) + + * [[!wikipedia List_of_tools_for_static_code_analysis]] + + * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/) + + For example, [Debian's hurd_20110319-2 + package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html) + (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious; + the realloc issues are for real*). + + * Coccinelle + + * <http://lwn.net/Articles/315686/> + + * <http://www.google.com/search?q=coccinelle+analysis> + + * clang + + * <http://www.google.com/search?q=clang+analysis> + + * Linux' sparse + + * <https://sparse.wiki.kernel.org/> + + * <http://klee.llvm.org/> + + * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html> + + * [Smatch](http://smatch.sourceforge.net/) + + * [Parfait](http://labs.oracle.com/projects/parfait/) + + * <http://lwn.net/Articles/344003/> + + * [Saturn](http://saturn.stanford.edu/) + + * [Flawfinder](http://www.dwheeler.com/flawfinder/) + + * [sixgill](http://sixgill.org/) + + * [Coverity](http://www.coverity.com/) (nonfree?) + + +# Dynamic + + * [[community/gsoc/project_ideas/Valgrind]] + + * <http://en.wikipedia.org/wiki/Electric_Fence> + + * <http://sourceforge.net/projects/duma/> + + * <http://wiki.debian.org/Hardening> + + * <https://wiki.ubuntu.com/CompilerFlags> + + * IRC, freenode, #glibc, 2011-09-28 + + <vsrinivas> two things you can do -- there is an environment variable + (DEBUG_MALLOC_ iirc?) that can be set to 2 to make ptmalloc (glibc's + allocator) more forceful and verbose wrt error checking + <vsrinivas> another is to grab a copy of Tor's source tree and copy out + OpenBSD's allocator (its a clearly-identifyable file in the tree); + LD_PRELOAD it or link it into your app, it is even more aggressive + about detecting memory misuse. + <vsrinivas> third, Red hat has a gdb python plugin that can instrument + glibc's heap structure. its kinda handy, might help? + <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry. + + * In context of [[!message-id + "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue + mentioned in [[gnumach_page_cache_policy]]: + + IRC, freenode, #hurd, 2012-07-08: + + <youpi> braunr: there's actually already an ifdef REDZONE in libthreads + + It's `RED_ZONE`. + + <youpi> except it seems clumsy :) + <youpi> ah, no, the libthreads code properly sets the guard, just for + grow-up stacks + + * Input fuzzing + + Not a new topic; has been used (and a paper published) for early UNIX + tools, I[[I|tschwinge]]RC. + + * <http://caca.zoy.org/wiki/zzuf> + + What about some [[RPC]] fuzzing? diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn new file mode 100644 index 00000000..f8a0657d --- /dev/null +++ b/open_issues/code_analysis/discussion.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2011, 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_documentation]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-12-04 + + <mcsim> has anyone used splice on hurd? + <mcsim> splice -> splint + <youpi> not that I know of + <mcsim> this is tool for statically checking C programs + <mcsim> seems I made it work + <braunr> hm i realli i personnally dislike such tools a lot, but sometimes + it might help + <braunr> hello hurd people + <mcsim> braunr: hello + <braunr> mcsim: duma may be helpful as replacement for the memcheck part of + valgrind + <mcsim> defpager uses it's own dynamic memory allocator, which uses + vm_allocate/vm_deallocate as backing store? Am I able to use duma in such + case? + <braunr> you will have to adapt it + <braunr> but it's already designed to handle custom allocators + <braunr> iirc + <braunr> btw, are there special flags for that memory which the pager + allocates ? + <braunr> e.g. to use wired memory ? + <mcsim> yes, wired memory + <braunr> you'll have to change that in duma then + <braunr> but apart from such details, it should be straightforward + <antrik> braunr: I have no idea about duma; but if you think it's a useful + tool, please add it to open_issues/code_analysis.mdwn + <antrik> (I guess we should have a "proper" page listing useful debugging + tools...) diff --git a/open_issues/contributing.mdwn b/open_issues/contributing.mdwn new file mode 100644 index 00000000..7ae742f0 --- /dev/null +++ b/open_issues/contributing.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2010 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_documentation]] + +This should be integrated into [[/contributing]]. + +--- + +Every now and then, people show up who have an inward urge to contribute to the +GNU Hurd, but have some difficulties about how to do that. + +For example, IRC, #hurd, 2010-10-06: + + <rah> I find it difficult to find the will to contribute to the hurd while hurd != hurd-ng + <pochu> hurd-ng? + <pochu> ah, http://www.gnu.org/software/hurd/hurd/ng.html + <pochu> rah: you may want to work on achieving that then + <rah> pochu: I'm not in a position to do OS research + <antrik> rah: if you are not into OS research, why do you need it to be ngHurd? :-) + <rah> antrik: I don't want to work on software which I know is already obsolete + <tschwinge> rah: My position on that can be found here; you may want to think about it. http://lists.gnu.org/archive/html/bug-hurd/2007-07/msg00111.html + <antrik> rah: the existing Hurd implementation is not any more obsolete than any other large software project + <antrik> there are always things that could be redone in a better way some time in the future + <antrik> but we have to start somewhere + <antrik> software development is a dynamic process + <antrik> trying to come up with a perfect design before you write any code will never lead anywhere, ever + <rah> antrik: of course, but when you know your start is wrong, have identified its problems, and are in the process of designing a second attempt, working on the first seems pointless + <antrik> rah: well, do you know all these things? because I do not + <antrik> what the experiments with new Hurd designs proved so far is that nobody is in a position to claim, "I have a better design" + <antrik> it's not hard to come up with a design that is better in some points -- but it's damn hard to come up with one that's not lacking in others + <antrik> the existing Hurd design is actually the only one which we *know* to work + <antrik> while research on improving the design is certainly beneficial, it's not like there is something new ready to replace the existing design at any moment + <antrik> and frankly, I'm more and more convinced that only iterative changes can ever result in any real improvement + <antrik> (and doing these changes requires a certain momentum, which we will never gain unless we actually have something usable first) + <LarstiQ> rah: afaik, not much is being done of designing another attempt + <rah> antrik: yes, I know all these things diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn new file mode 100644 index 00000000..7ed4afbf --- /dev/null +++ b/open_issues/crash_server.mdwn @@ -0,0 +1,195 @@ +[[!meta copyright="Copyright © 2009, 2010, 2011 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_hurd]] + +Given an `a.out` executable that only does `raise (SIGABRT)`, invoking that +one... + + * ... against `crash-dump-core` will... + + * ... not overwrite existing `core` files. + + Is this reasonable? Linux does overwrite them, for example. + + * ... show big variances in running-time behavior: + + $ TIMEFORMAT='real %R user %U system %S' + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 1.350 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 22.771 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 1.367 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 5.789 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 22.664 user 0.010 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:01 core + + * ... produce a huge `core` file: + + $ du -hs core + 17M core + + On Linux, the `core` file occupies 76 KiB of disk space, which seems + much more reasonable. This is possibly related with the default 128MiB + heap preallocation. + + * ... does not always produce a useful backtrace: + + `abort();` + + $ gdb test core + warning: core file may not match specified executable file. + [New Thread 86678] + warning: Wrong size fpregset in core file. + ... + Core was generated by `./test'. + Program terminated with signal 6, Aborted. + warning: Wrong size fpregset in core file. + (gdb) bt + #0 0x00000000 in ?? () + #1 0x011f593f in __msg_sig_post (process=72, signal=6, sigcode=0, refport=1) + at /build/buildd-eglibc_2.10.2-7-hurd-i386-iGL6op/eglibc-2.10.2/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:144 + #2 0x0109a433 in kill_port (pid=<value optimized out>) + at ../sysdeps/mach/hurd/kill.c:68 + #3 kill_pid (pid=<value optimized out>) at ../sysdeps/mach/hurd/kill.c:105 + #4 0x0109a69f in __kill (pid=21142, sig=6) at ../sysdeps/mach/hurd/kill.c:139 + #5 0x01099af6 in raise (sig=6) at ../sysdeps/posix/raise.c:27 + #6 0x0109de59 in abort () at abort.c:88 + #7 0x0804849f in main () + + `char *foo = 0; *foo = 1;` + + $ gdb test core + Program terminated with signal 11, Segmentation fault. + warning: Wrong size fpregset in core file. + #0 0x00000000 in ?? () + (gdb) bt + #0 0x00000000 in ?? () + #1 0x0108565b in __libc_start_main (main=0x8048464 <main>, argc=1, ubp_av=0x1023e64, + init=0x8048490 <__libc_csu_init>, fini=0x8048480 <__libc_csu_fini>, rtld_fini=0xea20 <_dl_fini>, + stack_end=0x1023e5c) at libc-start.c:251 + #2 0x080483d1 in _start () + + `raise (SIGABRT);` + + $ gdb a.out core + warning: core file may not match specified executable file. + [New Thread 76651] + + warning: Wrong size fpregset in core file. + Reading symbols from /lib/libc.so.0.3...[...] + Core was generated by `./a.out'. + Program terminated with signal 6, Aborted. + + warning: Wrong size fpregset in core file. + #0 0x00000000 in ?? () + (gdb) bt + #0 0x00000000 in ?? () + Cannot access memory at address 0x17 + + [[!tag open_issue_gdb]] Probably [[GDB]] doesn't manage to dig in the stack properly. + + * ... against `crash-suspend` will... + + * ... not work at all: + + $ CRASHSERVER=/servers/crash-suspend ./a.out + $ [returns to the shell and doesn't suspended] + + * ... show big variances in running-time behavior: + + $ TIMEFORMAT='real %R user %U system %S' + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.381 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.332 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 21.228 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.323 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 22.279 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.362 user 0.000 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 21.110 user 0.000 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.350 user 0.000 system 0.020 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + + * ... can reliably crash GNU Mach: + + This happens if a `core` file is already present (and won't get + overwritten; see above). I reproduced this three times. + + $ TIMEFORMAT='real %R user %U system %S' + $ time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted + real 2.856 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + + panic: zalloc: zone kalloc.8192 exhausted + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006aba8,4d0f7e9c,200209b0,0,0) + 0x20020a4d(2006b094,2006ae40,2000,20016803,4a5f4114) + 0x2002bca5(49a03564,1,0,9,1000) + 0x20022f4c(2000,4a5f45d4,4a84879c,49a46564,4ac43e78) + 0x20021e65(4ac43e78,4a5f45d4,4a5f4114,0,0) + 0x2005309d(2106ba9c,3,38,28,1783) + Bad frame pointer: 0x2106ba78 + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020a4d 0x2002bca5 0x20022f4c 0x20021e65 0x2005309d + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + panic + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:148 + zalloc + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/zalloc.c:470 + kalloc + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/kalloc.c:185 + ipc_kobject_server + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:76 + mach_msg_trap + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367 + +--- + +If someone is working in this area, they may want to have a look at +[[GDB_gcore]], and port <http://code.google.com/p/google-coredumper/>, too. diff --git a/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn new file mode 100644 index 00000000..4076d8d0 --- /dev/null +++ b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +IRC, unknown channel, unknown date: + + <antrik> I have a theory + <antrik> when the system is under CPU load, the ext2 locking issues are more likely to happen + <antrik> I'm under the impression, that when doing something disk-intensive (like a compile job) *considerably* more often causes crashes, when doing *any* other activity in parallel -- be it other compile jobs, or CPU-only activities + <antrik> thinking about it, I'm not sure whether CPU-intensive is the decisive criterium, or maybe RPC-intensive... + <antrik> CPU load doesn't seem to have any effect -- neither alone, nor in combination with other testcases diff --git a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn new file mode 100644 index 00000000..b94c0c1d --- /dev/null +++ b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2010 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 open_issue_gcc]] + + $ gcc -o /dev/null -x c /dev/null + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 13 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22 + /usr/lib/gcc/i486-gnu/4.4.5/../../../crt1.o: In function `_start': + (.text+0x18): undefined reference to `main' + collect2: ld returned 1 exit status + +Likewise for `-static`, `crt0.o`. diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn new file mode 100644 index 00000000..2f02579e --- /dev/null +++ b/open_issues/dbus.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2011, 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_hurd]] + +The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and socket credentials +[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in +[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms. + +--- + +IRC, freenode, #hurd, 2011-11-26: + + <antrik> BTW, how much effort is necessary to fix dbus? + <pinotree> basically, have pflocal know who's the sender + (pid/uid/gid/groups) in the socket send op + +IRC, freenode, #hurd, 2011-12-16: + + <braunr> pinotree: what's the problem with dbus ? + <pinotree> braunr: select() returning 0 changed fd's with very short (eg < + 1ms) timeouts when there are actually events; + +[[select]]. + + <pinotree> and missing socket credentials + +[[sendmsg_scm_creds]]. + + <braunr> oh + <braunr> which socket creds interface ? + <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on + {recv,send}msg() + <braunr> ok + <braunr> SCM_RIGHTS too ? + <braunr> the select issue seems weird though + <pinotree> hm no, that's for passing fd's to other processes + <braunr> is it specific to pflocal or does dbus use pfinet too ? + <pinotree> iirc on very short timeouts the application has no time waiting + for the reply of servers + <braunr> i see + <pinotree> braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358 + <braunr> thanks + <pinotree> (the interesting messages are from #53 and on) + <braunr> 2000 eh ... :) + <braunr> hm i agree with neal, i don't understand why the timeout is given + to the kernel as part of the mach_msg call + +IRC, freenode, #hurd, 2011-12-20: + + <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus + <braunr> only SCM_RIGHTS + <pinotree> braunr: yes, that one + <braunr> oh + <braunr> i thought you said the opposite last time + <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and + _dbus_read_credentials_socket (with #define HAVE_CMSGCRED) + <braunr> hm + <braunr> which version ? + <braunr> i don't see anything in 1.4.16 + <pinotree> 1.4.16 + <braunr> grmbl + <braunr> ah, i see + <braunr> SCM_CREDS + <pinotree> if you want, i have a simplier .c source with it + <braunr> no i'm just gathering info + <pinotree> ok + <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ? + <braunr> bsd vs sysv ? + <braunr> oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html + <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus + <braunr> dbus + <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's + <braunr> yes + <braunr> but it's used by dbus + <braunr> so if we can get it, it should help too + <pinotree> there's a preliminary patch for it done by emilio time ago, and + iirc it's applied to debian's glibc + <braunr> ah, he changed the libc + <braunr> right, that's the only sane way + <pinotree> iirc roland didn't like one or more parts of it (but i could be + wrong) + <braunr> ok diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn new file mode 100644 index 00000000..a94e1fed --- /dev/null +++ b/open_issues/dbus_in_linux_kernel.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +Might be interesting to watch how this develops. + +IRC, #hurd, August / September 2010 + + <neal> check this out: + <neal> someone is working on implementing dbus in linux + <neal> linux finally gets mach ipc ;-) + <marcusb> it's old news though, unless there is an update + <marcusb> and I think it was only the client? + <neal> youpi : someone is adding dbus ipc to the linux kernel + <neal> marcusb: I just heard about it. + <youpi> (it's crazy how this drives backward compared to a hurdish approach) + <youpi> what is the motivation for moving to the kernel? + <neal> context switch overhead + <azeem_> they wanna use it to talk to device drivers? :) + <kilobug> well, they did that with the in-kernel web server, but they + abandonned it later on + <neal> azeem: I don't think so. + <neal> dbus in the kernel is actually good for the Hurd as dbus IPC is + basically neutered Mach IPC + <marcusb> I don't think anybody wants to put the dbus server in the kernel + <neal> well, there is at least one person + <marcusb> maybe this is a different news from the one I read + <neal> Alban Crequy (albanc) is working out. He works for collabora, fwiw + +<http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/> + + <marcusb> what I read was about hal etc + <marcusb> so that you don't need a user space daemon to glue the kernel to the + dbus world + <neal> I don't think that is what he is talking about + <marcusb> I can't find it anymore though. I mentioned it in this channel at + the time though, so it should be in the backlog + <marcusb> neal, yeah could very well be a separate thing + <marcusb> neal, dbus does have marginal support for fd passing though, and some + attempts on the mailing list to make "fds" an official type in the message + failed (as far as I could see, I didn't read the whole discussion) + <marcusb> so no mach ipc just yet + <neal> wrong + <neal> FD handling is in 1.4 + <neal> type o, if I'm not mistaken + <marcusb> then the discussion moved on from initial rejection + <neal> no, 'h' + <marcusb> I'm out of date by two months + <marcusb> ok + <guillem> neal: AFAIR Marcel Holtmann talked about dbus in-kernel several years + ago, but he never ended up implementing it, or there were rumors he had + private "working code" + + * Related Mailing List Discussion + + * [\[PATCH 0/5\] RFC: Multicast and filtering features on + AF_UNIX](http://article.gmane.org/gmane.linux.kernel/1040481), + 2010-09-24 diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn new file mode 100644 index 00000000..aff988d5 --- /dev/null +++ b/open_issues/dde.mdwn @@ -0,0 +1,463 @@ +[[!meta copyright="Copyright © 2010, 2011, 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_hurd open_issue_gnumach]] + +[[General Information|/dde]]. + +Still waiting for interface finalization and proper integration. + +[[!toc]] + + +# Disk Drivers + +Not yet supported. + +The plan is to use [[libstore_parted]] for accessing partitions. + + +## Booting + +A similar problem is described in +[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented. + + +# Upstream Status + + +## IRC, freenode, #hurd, 2012-02-08 + +At the microkernel davroom at [[community/meetings/FOSDEM_2012]]: + + <antrik> there was quite some talk about DDE. I learnt that there are newer + versions in Genode and in Minix (as opposed to the DROPS one we are + using) + <antrik> but apparently none of the guys involved is interested in creating + a proper upstream project with central repository and communication + channels :-( + <antrik> the original DDE creator was also there, but said he isn't working + on it anymore + <tschwinge> OK, and the other two projects basically have their own forks. + <tschwinge> Or are they actively cooperating? + <tschwinge> (If you know about it.) + <antrik> well, Genode is also part of the Dresden L4 group; but apart from + that, I'd rather call it a fork... + <antrik> hm... actually, I'm not sure anymore whether the guy I talked to + was from Genode or Nova... + <antrik> (both from the Dresdem L4 group) + + +## IRC, freenode, #hurd, 2012-02-19 + + <youpi> antrik: do we know exactly which DDE version Zheng Da took as a + base ? + <youpi> (so as to be able to merge new changes easily) + <antrik> youpi: not sure... but from what I gathered at FOSDEM, the version + he based on (from DROPS) is not really actively developed right now; if + we want to go for newer versions, we probably have to look at other + projects (like Genode or Nova or Minix) + <youpi> there's no central project for dde ? + <youpi> that sucks + <antrik> no... and nobody seemed interested in having one :-( + <youpi> pff + <antrik> which makes me seriously question the original decision to build + on DDE... + <braunr> .. + <antrik> if we have to basically maintain it ourselfs anyways, we could + just as well have gone with custom glue + <youpi> well, the advantage of DDE is that it already exists now + <antrik> on the positive side, one of the projcets (not sure which) + apparently have both USB and SATA working with some variant of DDE + + +# IRC, OFTC, #debian-hurd, 2012-02-15 + + <pinotree> i have no idea how the dde system works + <youpi> gnumach patch to provide access to physical memory and interrupts + <youpi> then userland accesses i/o ports by hand to drive things + <youpi> but that assumes that no kernel driver is interfering + <youpi> so one has to disable kernel drivers + <pinotree> how are dde drivers used? can they be loaded on their own + automatically, or you have to settrans yourself to setup a device? + <youpi> there's no autoloader for now + <youpi> we'd need a bus arbitrer that'd do autoprobing + <pinotree> i see + <pinotree> (you see i'm not really that low level, so pardon the flood of + posssibly-noobish questions ;) ) + <youpi> I haven't set it up yet, but IIRC you need to specify which driver + to be used + <youpi> well, I mostly have the same questions actually :) + <youpi> I just have some guesswork here :) + <pinotree> i wonder whether the following could be feasible: + <youpi> I'm wondering how we'll manage to make it work in d-i + <pinotree> a) you create a package which would b-d on linux-source, build a + selection of (network only for now) drivers and install them in + /hurd/dde/ + <youpi> probably through a choice at the boot menu + <youpi> I wouldn't dare depending on linux-source + <youpi> dde is usually not up-to-date + <pinotree> b) add a small utility over the actual fsys_settrans() which + would pick the driver from /hurd/dde/ + <pinotree> ... so you could do `set-dde-driver b43 <device>` (or something + like that) + <youpi> we can provide something like b) yes + <youpi> although documenting the settrans should be fine enough ;) + <pinotree> the a) would help/ease with the fact that you need to compile on + your own the drivers + <pinotree> otherwise we would need to create a new linux-dde-sources-X.Y.Z + only with the sources of the drivers we want from linux X.Y.Z + <pinotree> (or hurd-dde-linux-X.Y.Z) + <CIA-4> samuel.thibault * raccdec3 gnumach/debian/ (changelog + patches/70_dde.patch patches/series): + <CIA-4> Add DDE experimental support + <CIA-4> * debian/patches/70_dde.patch: Add experimental support for irq + passing and + <CIA-4> physical memory allocation for DDE. Also adds nonetdev boot + parameter to + <CIA-4> disable network device drivers. + <youpi> ok, boots fine with the additional nonetdev option + <youpi> now I need to try that dde hurd branch :) + <CIA-4> samuel.thibault * rf8b9426 gnumach/debian/patches/70_dde.patch: Add + experimental.defs to gnuamch-dev + + +# IRC, freenode, #hurd, 2012-02-19 + + * youpi got dde almost working + <youpi> it's able to send packets, but apparently not receive them + <youpi> (e1000) + <youpi> ok, rtl8139 works + <youpi> antrik: the wiki instructions are correct + <youpi> with e1000 I haven't investigated + <antrik> (Archhurd guys also reported problems with e1000 IIRC... the one I + built a while back works fine though on my T40p with real e1000 NIC) + <antrik> maybe I should try with current versions... something might got + broken by later changes :-( + <youpi> at least testing could tell the changeset which breaks it + <youpi> Mmm, it's very odd + <youpi> with the debian package, pfinet's call to device_set_filter returns + D_INVALID_OPERATION + <youpi> and indeed devnode.c returns that + <youpi> ah but it's libmachdev which is supposed to answer here + <antrik> youpi: so, regarding the failing device_set_filter... I guess you + are using some wrong combination of gnumach and pfinet + <youpi> no it's actually that my pfinet was not using bpf + <youpi> I've now fixed it + <antrik> the DDE drivers rely on zhengda's modified pfinet, which uses + devnode, but also switched to using proper BPF filters. so you also need + his BPF additions/fixes in gnumach + <antrik> OK + <youpi> that's the latter + <youpi> I had already fixed the devnode part + <youpi> but hadn't seen that the filter was different + <antrik> err... did I say gnumach? that of course doesn't come into play + here + <antrik> so yes, you just need a pfinet using BPF + <youpi> libmachdev does ;) + <antrik> I'm just using pfinet from zhengda's DDE branch... I think devnode + and BPF are the only modifications + <youpi> there's also a libpcap modification in the incubator + <youpi> probably for tcpdump etc. + <antrik> libpcap is used by the modified pfinet to compile the filter rule + <youpi> why does pfinet need to compile the rule ? + <youpi> it's libbpf which is used in the dde driver + <antrik> it doesn't strictly need to... but I guess zhengda considered it + more elegant to put the source rule in pfinet on compile it live, rather + than the compiled blob + <antrik> I probably discussed this with him myself a few years back... but + my memory on this is rather hazy ;-) + <antrik> err... and compile it live + <youpi> ah, right, it's only used when asking pfinet to change its filter + <youpi> but it does not need it for the default filter + <youpi> which is hardcoded + <antrik> I see + <antrik> when would pfinet change its filter? + * youpi now completely converting his hurd box to debian packages with dde + support + <youpi> on SIOCSIFADDR apparently + <youpi> to set "arp or (ip host %s)", + <antrik> well, that sounds like the default filter... + <youpi> the default filter does not choose an IP + <antrik> oh, right... pfinet has to readjust the filter when setting the IP + <youpi> arg we lack support for kernel options for gnumach in update-grub + <antrik> again, I have a vague recollection of discussing this + * youpi crosses fingers + <youpi> yay, works + <antrik> so we *do* need libpcap in pfinet to set proper rules... though I + guess it can also work with a static catchall rule (like it did before + zhengda's changes), only less efficient + <youpi> well in the past we were already catching everything anyway, so at + least it's not a regression :) + <antrik> right + + +# IRC, freenode, #hurd, 2012-02-19 + + <youpi> antrik: we should probably add a gsoc idea on pci bus arbitration + <youpi> DDE is still experimental for now so it's ok that you have to + configure it by hand, but it should be automatic at some ponit + + +## IRC, freenode, #hurd, 2012-02-21 + + <braunr> i'm not familiar with the new gnumach interface for userspace + drivers, but can this pci enumerator be written with it as it is ? + <braunr> (i'm not asking for a precise answer, just yes - even probably - + or no) + <braunr> (idk or utsl will do as well) + <youpi> I'd say yes + <youpi> since all drivers need is interrupts, io ports and iomem + <youpi> the latter was already available through /dev/mem + <youpi> io ports through the i386 rpcs + <youpi> the changes provide both interrupts, and physical-contiguous + allocation + <youpi> it should be way enough + <braunr> youpi: ok + <braunr> youpi: thanks for the details :) + <antrik> braunr: this was mentioned in the context of the interrupt + forwarding interface... the original one implemented by zhengda isn't + suitable for a PCI server; but the ones proposed by youpi and tschwinge + would work + <antrik> same for the physical memory interface: the current implementation + doesn't allow delegation; but I already said that it's wrong + + +# IRC, freenode, #hurd, 2012-02-20 + + <youpi> I was a bit wary of including the ton of dde headers in hurd-dev + <youpi> maybe adding another package for that + <youpi> but that would have delayed introducing the dde binaries + <youpi> probably we can do that for next upload + <pinotree> i can try to work on it, if is feasible (ie if the dde drivers + can currently be built from outside the hurd source tree) + <youpi> it should be, it's a matter of pointing its makefile to a place + where the make scripts and include headers are + <youpi> (and the libraries) + <pinotree> ok + <antrik> youpi: you mean DDEKit headers? + <antrik> pinotree: actually it doesn't matter where the dde-ified Linux + drivers are built -- libdde_linux26 and the actual drivers use a + completetly different build system anyways + <antrik> in fact we concluded at some point that they should live in a + separate repository -- but that change never happened + <antrik> only the base stuff (ddekit, libmachdev etc.) belong in the Hurd + source tree + <youpi> antrik: yes + <youpi> antrik: err, not really completely different + <youpi> the actual drivers' Makefile include the libdde_linux26 mk files + <youpi> the build itself is separate, though + <antrik> youpi: yes, I mean both libdde_linux26 and the drivers use a build + system that is completely distinct from the Hurd one + <youpi> ah, yes + <youpi> libdde_linux26 should however be shipped in the system + <antrik> ideally libdde_linux26 and all the drivers should be built in one + go I'd say... + <youpi> it should be easily feasible to also have a separate driver too + <youpi> e.g. to quickly try a 2.6 driver + <antrik> youpi: I'm not sure about that. it's not even dynamically linked + IIRC?... + <youpi> with scripts to build it + <youpi> it's not + <youpi> but that doesn't mean it can't be separate + <youpi> .a files are usually shipped in -dev packages + <antrik> youpi: ideally we should try to come with a build system that + reuses the original Linux makefile snippets to build all the drivers + automatically without any manual per-driver work + <youpi> there's usually no modification of the drivers themselves? + <youpi> but yeah + <youpi> "ideally", when somebody takes the time to do it + <antrik> unfortunately, it's necessary to include one particular + Hurd/DDE-specific header file in each driver :-( + <youpi> can't it be done through gcc's -include option? + <antrik> zhengda didn't find a way to avoid this... though I still hope + that it must be possible somehow + <antrik> I think the problem is that it has to be included *after* the + other Linux headers. don't remember the details though + <youpi> uh + <youpi> well, a good script can add a line after the last occurrence of + #include + <antrik> yeah... rather hacky, but might work + <youpi> even with a bit of grep, tail, cut, and sed it should work :) + <antrik> note that this is Hurd-specific; the L4 guys didn't need that + <youpi> what is it? + <antrik> don't remember off-hand + + +# IRC, freenode, #hurd, 2012-02-22 + + <youpi> antrik: AIUI, it should be possible to include all network drivers + in just one binary? + <youpi> that'd permit to use it in d-i + <youpi> and completely replace the mach drivers + <youpi> we just need to make sure to include at least what the mach drivers + cover + <youpi> (all DDE network drivers, I mean) + <youpi> of course that doesn't hinder from people to carefully separate + drivers in several binaries if they wish + <youpi> antrik: it does link at least, I'll give a try later + <youpi> yes it works! + <youpi> that looks like a plan + <youpi> throw all network drivers in a /hurd/dde_net + <youpi> settrans it on /dev/dde_net, and settrans devnode on /dev/eth[0-9] + <youpi> I'm also uploading a version of hurd which includes headers & + libraries, so you just need a make in dde_{e100,e1000,etc,net} + <youpi> (uploading it with the dde driver itself :) ) + <youpi> btw, a nice thing is that we don't really care that all drivers are + stuffed into a single binary, since it's a normal process only the useful + pages are mapped and actually take memory :) + <Tekk_> is that really a nice thing though? compared to other systems I + mean + <Tekk_> I know on linux it only loads the modules I need, for example. It's + definitely a step up for hurd though :D + <youpi> that's actually precisely what I mean + <youpi> you don't need to load only the modules you need + <youpi> you just load them all + <youpi> and paging eliminates automatically what's not useful + <youpi> even parts of the driver that your device will not need + <Tekk_> ooh + <Tekk_> awesome + <youpi> (actually, it's not even loaded, but the pci tables of the drivers + are loaded, then paged out) + + +# IRC, freenode, #hurd, 2012-02-24 + + <youpi> antrik_: about the #include <ddekit/timer.h>, I see the issue, it's + about jiffies + <youpi> it wouldn't be a very good thing to have a jiffies variable which + we'd have to update 100times per second + <youpi> so ZhengDa preferred to make jiffies a macro which calls a function + which reads the mapped time + <youpi> however, that break any use of the work "jiffies", e.g. structure + members & such + <youpi> actually it's not only after headers that the #include has to be + done, but after any code what uses the word "jiffies" for something else + than the variable + <youpi> pb is: it has to be done *before* any code that uses the word + "jiffies" for the variable, e.g. inline functions in headers + <youpi> in l4dde, there's already the jiffies variable so it's not a + problem + + +# IRC, OFTC, #debian-hurd, 2012-02-27 + + <tschwinge> I plan to do some light performance testing w.r.t. DDE + Ethernet. That is DDE vs. Mach, etc. + <youpi> that'd be good, indeed + <youpi> I'm getting 4MiB/s with dde + <youpi> I don't remember with mach + <tschwinge> Yes. It just shouldn't regress too much. + <tschwinge> Aha, OK. + + +## IRC, freenode, #hurd, 2012-02-27 + + <youpi> tschwinge: nttcp tells me ~80Mbps for mach-rtl8139, ~72Mbps for + dde-rtl8139, ~72Mbps for dde-e1000 + <youpi> civodul: ↑ btw + <ArneBab> youpi: so the dde network device is not much slower than the + kernel-one? + <civodul> youpi: yes, looks good + <ArneBab> rather almost the same speed + <youpi> apparently + <ArneBab> that’s quite a deal. + <ArneBab> what speed should it have as maximum? + <ArneBab> (means: does the mach version get out all that’s possible?) + <ArneBab> differently put: What speed would GNU/Linux get? + <youpi> I'm checking that right now + <ArneBab> cool! + <ArneBab> we need those numbers for the moth after the next + <youpi> Mmm, I'm not sure you really want the linux number :) + <youpi> 1.6Gbps :) + <ArneBab> oh… + <youpi> let me check with udp rather than tcp + <ArneBab> so the Hurd is a “tiny bit” worse at using the network… + <youpi> it might simply be an issue with tcp tuning in pfinet + <ArneBab> hm, yes + <ArneBab> tcp is not that cheap + <ArneBab> and has some pretty advanced stuff for getting to high speeds + <youpi> well, I'm not thinking about being cheap + <youpi> but using more recent tuning + <youpi> that does not believe only 1Mbps network cards exist :) + <ArneBab> like adaptive windows and such? + <ArneBab> :) + <youpi> yes + * ArneBab remembers that TCP was invented when the connections went over + phone lines - by audio :) + <youpi> yep + <ArneBab> what’s the system load while doing the test? + <youpi> yes, udp seems not so bad + <ArneBab> ah, cool! + <youpi> it's very variable (300-3000Mbps), but like on linux + <ArneBab> that pushing it into user space has so low cost is pretty nice. + * ArneBab thinks that that’s a point where Hurd pays off + <youpi> that's actually what AST said to fosdem + <youpi> he doesn't care about putting an RPC for each and every port i/o + <youpi> because hardware is slow anyway + <ArneBab> jupp + <ArneBab> but it is important to see that in real life + + +# IRC, freenode, #hurd, 2012-04-01 + + <youpi> antrik: I wonder whether you could actually not route the IRQs to a + non-zero ring, AIUI you can in the x86 IDT table + <antrik> youpi: you mean having a userspace server for each (non-timer) + interrupt? + <antrik> youpi: how would a userspace IRQ handler interact with the + scheduler? + <youpi> antrik: it doesn't necessarily have to + <youpi> provided that it's trusted + <antrik> youpi: how would you do CPU time accounting if there is no + interaction with the scheduler?... + <youpi> antrik: you don't necessarily want to care about it + <antrik> youpi: well, that would mean that all drivers handling interrupts + would have to be trusted to not use more than a very small part of CPU + time... + <youpi> yes + <youpi> which is usually needed for interrupt handlers anyway + <antrik> youpi: nah, the bottom handler only has to do very basic stuff; + afterwards, we can pass off to "normal" driver processes, scheduled just + like other processes... but that requires some interaction between the + IRQ handler and the scheduler I think + <youpi> the IRQ handler can wake up a thread, yes + <youpi> no need for anything special there + <antrik> so the userspace IRQ server would just decide what process to wake + up, and then call the scheduler to do a normal task switch? I guess + that's possible; but I'm not sure it would buy much... + <youpi> it would permit userland to quickly react to the IRQ + <youpi> such as acknowledge it to the hardware etc. + <antrik> yeah, but my point is that I don't see much benefit in having this + part of the code isolated in a userspace process... it has to be trusted + anyways, and it's pretty trivial too + <youpi> I never said it was a good idea + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> oh i forgot about my work on pcap + <braunr> is devnode (or devopen or whatever) in the upstream repository now + ? + <antrik> can't say for sure, but I'd be surprised... don't remember seeing + any movement in that regard :-( + <braunr> wasn't it needed for dde ? + <antrik> hm... good point + + +# virtio + + +## IRC, freenode, #hurd, 2012-07-01 + + <braunr> hm, i haven't looked but, does someone know if virtio is included + in netdde ? + <youpi> braunr: nope, there's an underlying virtio layer needed before diff --git a/open_issues/debian_cross_toolchain.mdwn b/open_issues/debian_cross_toolchain.mdwn new file mode 100644 index 00000000..e0665466 --- /dev/null +++ b/open_issues/debian_cross_toolchain.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +Have a look at the Debian *Cross Toolchain* project, +<https://alioth.debian.org/projects/crosstoolchain/>, +<http://wiki.debian.org/ToolChain/Cross>. diff --git a/open_issues/debootstrap.mdwn b/open_issues/debootstrap.mdwn new file mode 100644 index 00000000..8e6c4900 --- /dev/null +++ b/open_issues/debootstrap.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +\#hurd, freenode, 2010 + + <azeem_> you know, you would really help the Hurd if you tried debootstrap instead + <tschwinge> Oh? Does that have everying in place by now? + <azeem_> applying the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498731#25 + <azeem_> they are waiting for feedbacl + <azeem_> feedback* + +\#hurd, freenode, June (?) 2010 + + <azeem_> jd823592: if you want to use debootstrap, you should apply a patch + <azeem_> and test + <azeem_> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=debootstrap_hurd.patch;att=1;bug=498731 + <azeem_> we desperately need somebody to test the patch diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn new file mode 100644 index 00000000..b2d49b26 --- /dev/null +++ b/open_issues/debugging.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + + +# Existing + +We have debugging infrastructure. For example: + + * [[GDB]] + + * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]] + + * [[GNU Hurd debugging|hurd/debugging]], including + [[hurd/debugging/rpctrace]], and more. + + +# To Do + + * [[ltrace]] + + * [[latrace]] + + * [[profiling]] + + * *Checkpoint/restart allows the state of a set of processes to be saved to + persistent storage, then restarted at some future time* -- quoting from + Jonathan Corbet's [2010 Linux Kernel Summit + report](http://lwn.net/Articles/412749/). + + This is surely a very useful facility to have for reproducing failures, for + example. But on the other hand it's questionable how it can help with + debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions, + as their state is typically spread between several processes. + + Continues: <http://lwn.net/Articles/414264/>, which introduces + <http://dmtcp.sourceforge.net/>. + + * [[crash_server}}, [[GDB_gcore]], + <http://code.google.com/p/google-coredumper/> + + * [[community/gsoc/project_ideas/libdiskfs_locking]] + + * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> -- + just two examples; there's a lot of such stuff for Linux. + + * [[debugging_gnumach_startup_QEMU_GDB]] diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn new file mode 100644 index 00000000..e3a6b648 --- /dev/null +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -0,0 +1,116 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="Debugging GNU Mach's startup in QEMU with GDB"]] + +[[!tag open_issue_gdb open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2011-07-14 + + <mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints + in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then + I start qemu with patched gnumach kernel and stop at gdt_init. When I + enter command "continue" in gdb, qemu hangs. But when I go step by step, + using command "next", I freely reach idt_init. What can cause this + problem? + <braunr> hm + <braunr> not sure + <braunr> let me try + <braunr> mcsim: works for me :/ + <mcsim> it works without my patch, but with it qemu hangs + <braunr> oh, i thought it worked when not using continue + <mcsim> with my patch I can reach idt_init only using next + <mcsim> and without all works fine + <braunr> mcsim: are you sure you correctly built it with debugging symbols + ? + <mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0 + <braunr> hm + <braunr> i have internal kvm errors actually + <braunr> mcsim: do you use kvm ? + <braunr> mcsim: and why break on those functions ? + <braunr> i'm not sure the address space is already fine at this point + <mcsim> no. I don't have hardware virtualisation support. + <braunr> hm actually, you won't be able to use gdb + <braunr> i just remembered how gnumach is linked and mapped :/ + <braunr> the addresses in the elf image are low addresses, matching the + image as it is loaded by the boot loader + <mcsim> I was wondering why qemu hangs. + <braunr> then the kernel uses segmentation to map itself at 2 (or 3 + previously) GiB + <braunr> well, if the addresses are wrong, your breakpoints are wrong + <braunr> i even wonder how it can work when stepping + <braunr> i don't have the issue with x15 because of its linker script + <mcsim> Are there any ways of such debugging without qemu? + <braunr> i don't think so + <braunr> as antrik told you, the in kernel debugger needs many services + running before being usable + <braunr> you'll have to use printf, and there may be steps during bootstrap + when even that isn't available + <mcsim> So I need computer with hardware virtualisation? + <braunr> well, of course stepping works, since the breakpoints are relative + <braunr> no + <braunr> kvm has nothing to do with the problem + <braunr> it's just that the problem appears differently with kvm enabled + <mcsim> ok. thank you. + <braunr> good luck + <antrik> braunr: would it be hard to "fix" gnumach to avoid the + segmentation magic?... + <braunr> antrik: because of the linux drivers, it may + <antrik> or alternatively, implement something in GDB to deal with that?... + <braunr> antrik: i didn't study that part enough to know for sure + <antrik> uhm... why would the Linux drivers depend on that? does Linux also + do such magic?... + <braunr> well it should simply be a matter of shifting the address by a + fixed offset + <braunr> antrik: linux drivers rely on physical memory being allocated + through kmalloc + <braunr> so there must be a direct mapping between virtual kernel memory + and physical memory + <braunr> they don't specifically need that segmentation settings + <braunr> so if you remove the offset implemented through segmentation, you + have to replace it with page mapping + <braunr> and i don't know how much needs to be done for that + <braunr> you also need to link the kernel differently + <antrik> hm, OK + <antrik> so adding GDB support for the offset would probably be easier... + <braunr> yes + <braunr> but using the offset must only be done once segmentation is set up + <braunr> so you must break after gdt_init + <braunr> not on it + <braunr> mcsim: why do you break on these functions btw ? + <mcsim> I just wanted to find out why qemu hangs + <braunr> yes but why those ? + <mcsim> I found out that before gdt_init all workes fine, but after qemu + hangs. So idt_init is just the next function + <braunr> ok + <braunr> and does your patch change something to how segmentation is + initialized ? + <mcsim> now + <mcsim> no + <braunr> try to build it with the regular cflags + <braunr> i don't know if gnumach can work with -O0 + <mcsim> I've tried. But all the same + <mcsim> Regular are -g -O2 + <braunr> can you make your patch available ? + <mcsim> yes + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <antrik> well, if the segmentation stuff is the thing GDB has problems + with, I don't see how it can work without your patch... + <braunr> without ? + <antrik> well, the patch shouldn't affect the segmentation... so I don't + see how it can make a difference + <braunr> he said qemu hanged + <braunr> so let's not introduce gdb yet + <braunr> qemu can hang for other reasons + <antrik> oh, right, without GDB... + <antrik> though if that's what he meant, his statement was very misleading + at least diff --git a/open_issues/default_pager.mdwn b/open_issues/default_pager.mdwn new file mode 100644 index 00000000..9a8e9412 --- /dev/null +++ b/open_issues/default_pager.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2011, 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_gnumach]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-08-31 + + <antrik> braunr: do you have any idea what could cause the paging errors + long before swap is exhausted? + <braunr> antrik: not really, but i know every project based on the mach vm + have rewritten their swap pager + <antrik> (and also I/O performance steadily dropping before that point is + reached?) + +[[performance/degradation]], [[ext2fs_page_cache_swapping_leak]]. + + <antrik> hm + <braunr> there could too many things + <antrik> perhaps we could "borrow" from one of them? :-) + <braunr> map entry fragmentation for example + <braunr> the freebsd one is the only possible candidate + <braunr> uvm is too different + <braunr> dragonflybsd maybe, but it's very close to freebsd + <braunr> i didn't look at darwin/xnu + + +# [[trust_the_behavior_of_translators]] diff --git a/open_issues/dev_zero_size.mdwn b/open_issues/dev_zero_size.mdwn new file mode 100644 index 00000000..20c5147e --- /dev/null +++ b/open_issues/dev_zero_size.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +IRC, freenode, #hurd, 2011-10-18: + + <pinotree> i guess it is not normal for /dev/zero have a size of + (size_t)-1, no? + <pinotree> (it isn't (size_t)-1, but (long long)-1) + +2011-10-19: + + <pinotree> see the size you get with `stat /dev/zero` diff --git a/open_issues/device_drivers_and_io_systems.mdwn b/open_issues/device_drivers_and_io_systems.mdwn new file mode 100644 index 00000000..5bda0213 --- /dev/null +++ b/open_issues/device_drivers_and_io_systems.mdwn @@ -0,0 +1,94 @@ +[[!meta copyright="Copyright © 2009, 2011 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_gnumach open_issue_hurd]] + +This is a collection of resources concerning *device drivers* and *I/O systems* +in general. + +Also see [[user-space device drivers]]. +[[community/gsoc/project ideas/driver glue code]]. + +[[!toc levels=2]] + + +# Documentation + + * [An I/O System for Mach + 3.0](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.3210), + 1991, Alessandro Forin, David Golub, Brian Bershad + + * [Linux Device Driver Emulation in + Mach](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7252), + 1996, Shantanu Goel, Dan Duchamp + + * [Eliminating receive livelock in an interrupt-driven + kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.8257), + 1997, Jeffrey Mogul, Dec Western, Jeffrey C. Mogul, K. K. Ramakrishnan + + * [IO-Lite: A Unified I/O Buffering and Caching + System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4224), + 1997, Vivek S. Pai, Peter Druschel, Willy Zwaenepoel + + * [The Flux OSKit: A substrate for kernel and language + research](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.534), + 1997, Bryan Ford, Godmar Back, Greg Benson, Jay Lepreau, Albert Lin, Olin + Shivers + + * [Reuse Linux Device Drivers in Embedded + Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.6951), + 1998, Chi-wei Yang, Paul C. H. Lee, Ruei-Chuan Chang + + * [THINK: A Software Framework for Component-based Operating System + Kernels](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.133.9239), + 2002, Jean-Philippe Fassino, Jean-Bernard Stefani, Julia Lawall, Gilles + Muller + + * [An I/O Architecture for Microkernel-Based Operating + Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.4337), + 2003, Hermann Haertig, Jork Loeser, Jork Löser, Frank Mehnert, Lars + Reuther, Martin Pohlack, Alexander Warg + + * [High-Speed I/O: The Operating System as a Signalling + Mechanism](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.6991), + 2003, Matthew Burnside, Angelos D. Keromytis + + * [Unmodified device driver reuse and improved system dependability via + virtual + machines](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.5317), + 2004, Joshua Levasseur, Volkmar Uhlig, Jan Stoess, Stefan Götz + + +# External Projects + + * [[/DDE]] + + * [Building Linux Device Drivers on + FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html) + + * [Project UDI](http://www.projectudi.org/), a multi-company effort to define + a Uniform Driver Interface + + * [The Free Software Movement and + UDI](http://www.gnu.org/philosophy/udi.html) + + * [OSKit](http://www.cs.utah.edu/flux/oskit/) + + * [Unofficial OSKit source](http://www.nongnu.org/oskit/) on Savannah + + * [[microkernel/Mach]]-like + + It might be possible to integrate these systems' device drivers, as they're + expected to mostly be using the same interfaces as the current in-kernel + Mach drivers are. + + * OSF Mach + + * Darwin diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn new file mode 100644 index 00000000..64866eb5 --- /dev/null +++ b/open_issues/dir-lookup_authority.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> I have discovered a bug in the dir-lookup protocol though + <cfhammar> Currently, I'm investigating the bug a bit further + <cfhammar> when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup + <cfhammar> e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable + <cfhammar> if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to + <cfhammar> this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup + <antrik> cfhammar: I'm not sure this is a bug + <cfhammar> I have a test case that triggers the bug, and another that doesn't which currently confuses me + <antrik> cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority + <antrik> it's kinda consistent with passing normal FDs + <cfhammar> antrik: it should only allow accesses to entries not sub-entries + <cfhammar> antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix + <cfhammar> also note that a more common scenario is a process that opens a directory and then drops authority + <cfhammar> probably more common, that is + <antrik> cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs + <antrik> but if it is, it would indeed be good to know what POSIX says about this + <antrik> cfhammar: I don't see how this is related?... + <cfhammar> antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to + <antrik> cfhammar: interesting point... + <antrik> cfhammar: do you think this is fixable? + <cfhammar> antrik: Not without (defacto) changing the interface + <cfhammar> e.g only looking up a singe path component at a time + <cfhammar> or doing the auth check lazily on io_reauthenticate + <antrik> cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether... + <cfhammar> antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-( + <cfhammar> diskfs_S_dir_lookup is a very large function, for example + <antrik> cfhammar: OK + <antrik> cfhammar: I wonder whether there is a possible transition path without breaking all existing installations... + <cfhammar> we could provide a new RPC while supporting the old one + <cfhammar> note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine + <antrik> cfhammar: have you posted your findings to the ML yet? + <cfhammar> No, I'm still investigating why my second test-case doesn't trigger the bug + <cfhammar> Intrestingly it's the one using all POSIX functions... + <cfhammar> Perhaps its a bug that maskes the lookup bug ;-) + <antrik> I guess there is some quirk which you do not fully understand yet :-) + <cfhammar> Oh, there's always a new quirk to find in the Hurd :-) + <cfhammar> antrik: seems that dir_lookup isn't buggy after all + <cfhammar> antrik: as all FDs are reauthenticated on setauth + <antrik> ah + <cfhammar> antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered + <antrik> yeah, that's the idea behind the auth protocol... + <antrik> users obtain specific capabilities by authenticating generic ports against their own ID + <cfhammar> I didn't really have a coherent view on how open flags are handled on reauth + <cfhammar> it seems open flags always win, so that a O_READ port that is unauthed is still readable + <antrik> not sure what you mean + <cfhammar> if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it + <cfhammar> (as it should be) + <cfhammar> by contrast permission to do lookups in a directory is determined by who authed it + <cfhammar> so I won't be able to do lookups after a reauth, if it's not permitted by the file bits + <youpi> Mmm, openat should however be able to + <youpi> since you've first opened the directory with the auth + <cfhammar> it isn't since open FDs are reauthed on setauth + <cfhammar> not sure whether it should though, Linux behaves the same way atleast + <cfhammar> though it could be done with POSIX.2008's O_SEARCH open flag diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn new file mode 100644 index 00000000..d03b733c --- /dev/null +++ b/open_issues/e2fsck_i_file_acl_hi.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +IRC, unknown channel, unknown date. + + <Duck> something's broken in ext2, fsck, or the like + <Duck> /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0. + <Duck> youpi: the other problem is probably related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526524 + <Duck> i'll just check when it is fixed + <antrik> youpi: I've seen a lot of these fsck errors since the upgrade to 1.41.x + <antrik> youpi: seems to happen whenever a passive translator is still active while the machine reboots + <Duck> antrik: ho, so in my example this could be related to procfs then + <antrik> Duck: don't know... I got it with various terminal-related nodes + <antrik> other translators get terminated before ext2 it seems, so the problem doesn't happen there + <antrik> unless the machine crashes of course + <antrik> ah, right, it told you that it's the /proc node :-) + <antrik> was it the only node it complained about? + <antrik> Duck: ^ + <Duck> antrik: yes, the only one + <youpi> so it's most probably i + <youpi> t + <Duck> but currently i don't have much translators around besides the base install + <antrik> that's strange... my theory about translators active at reboot seems wrong then + <youpi> well, maybe procps is not behaving properly + <youpi> procfs* + <antrik> youpi: I doubt it. I regularily get the same issue with various term nodes; and when the machine crashes rather than rebooting cleanly, many other nodes as well + <youpi> k + <antrik> but it's always passive translator nodes + +This is due to an erroneous read/write from e2fsck, see +<http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406>. diff --git a/open_issues/elinks.mdwn b/open_issues/elinks.mdwn new file mode 100644 index 00000000..ee372971 --- /dev/null +++ b/open_issues/elinks.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 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_porting]] + +IRC, unknown channel, 2008-05-26 and later + + <paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000. Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range. Have there been problems because of this? + <youpi> eeerf + <youpi> I had never seen a program assuming that + <youpi> that sucks + <paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects. + <youpi> fixed where ? + <paakku> in elinks + <youpi> k + <paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable. + <paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report. + + <kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values. I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix. If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013 + <kahmalo> or to one of our mailing lists. + <kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd. Has any decision been made on how that will be fixed? diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn new file mode 100644 index 00000000..cdd1b10d --- /dev/null +++ b/open_issues/emacs.mdwn @@ -0,0 +1,1527 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +[[!meta title="GNU Emacs"]] + +[[!tag open_issue_porting]] + +GNU Emacs mostly does work, however there are a few issues. + + * `dired` on a directory hangs. (Use `C-g C-g` to break the unresponsive + operation.) + + * Configuration in `src/s/`: `gnu.h` uses `bsd-common.h`. `gnu-kfreebsd.h` + uses `gnu-linux.h` -- we probably should too. + + * `gnu-linux.h` makes a few things depend on `/proc` (also see + `HAVE_PROCFS`) -- either resort to our own ways, or enhance our + [[hurd/translator/procfs]] accordingly. + + * `sysdep.c` + + * Got a hang when compiling GNU Emacs 23, when it was compiling `.el` to + `.elc` files. Looked like busy-looping inside glibc. This was not + reproducible so far. + + * Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in `ext2fs` on + `/media/data` when resuming emacs23 build in `~/tmp/emacs/emacs23-*/` + (`dpkg-buildpackage -B -uc -nc 2>&1 | tee L`). No modifications to + `emacs23-*` so far, I think. Hangs always in the same place, it seems, and + reproducible. Tarred to `emacs23-23.1+1.tar.bz2` (beware: empty and + zero-permission files: + `emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el`, + `emacs23-23.1+1/.pc/autofiles.diff/src/config.in~`). At hang-time: the + rootfs is fine (`syncfs -c -s /` works; `syncfs` involving `/media/data` + hangs). Plan: GDB on that ext2fs, and see what's hanging / locked. [[!tag + open_issue_hurd]] + + +--- + +# 2010-10-11 + +Apparently, none of the Debian emacs packages are installable at the moment. + +Try to compile bzr trunk. + +System (sort-of) crashed during build. Perhaps while / or shortly after +dumping `src/emacs`, as there was such a zero-sized file. (Log file doesn't +show anything useful.) Removed the truncated `src/emacs`, continued build: + + [...] + Compiling /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el + Parsing *srecode-map-tmp* (LALR)... + Parsing *srecode-map-tmp* (LALR)...done + Segmentation fault + make[2]: *** [cedet/srecode/mode.elc] Error 139 + make[2]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' + make[1]: *** [compile-main] Error 2 + make[1]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' + make: *** [lisp] Error 2 + +Command line: + + $ EMACSLOADPATH=/home/tschwinge/tmp/emacs/trunk/lisp LC_ALL=C /home/tschwinge/tmp/emacs/trunk.build/src/emacs -batch --no-site-file -f batch-byte-compile /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el + +GDB: + + Program received signal SIGSEGV, Segmentation fault. + mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 + 5343 if (STRING_MARKED_P (ptr)) + (gdb) bt + #0 mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 + #1 0x0818080f in Fgarbage_collect () at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:4993 + #2 0x08196db3 in Ffuncall (nargs=1, args=0x23fce70) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2987 + #3 0x081ce8e1 in Fbyte_code (bytestr=139696577, vector=141708997, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #4 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #5 0x08196bb3 in Ffuncall (nargs=1, args=0x23fcff0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #6 0x081ce8e1 in Fbyte_code (bytestr=139922913, vector=141583493, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #7 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #8 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd170) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #9 0x081ce8e1 in Fbyte_code (bytestr=140515737, vector=141583205, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #10 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #11 0x08196bb3 in Ffuncall (nargs=2, args=0x23fd2f0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #12 0x081ce8e1 in Fbyte_code (bytestr=139911193, vector=139312997, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #13 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #14 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #15 0x081ce8e1 in Fbyte_code (bytestr=136508105, vector=136508125, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #16 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #17 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #18 0x081ce8e1 in Fbyte_code (bytestr=136508849, vector=136508869, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #19 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #20 0x08195bff in apply_lambda (fun=136508805, args=139814646, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #21 0x08195ef4 in Feval (form=139814582) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #22 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139636697, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #23 0x081bbad7 in Fload (file=140023529, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #24 0x081a1357 in Frequire (feature=141037690, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #25 0x08196d83 in Ffuncall (nargs=2, args=0x23fdb90) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #26 0x081ce8e1 in Fbyte_code (bytestr=140023705, vector=141489853, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #27 0x08196304 in Feval (form=141177630) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 + #28 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=140023785, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #29 0x081bbad7 in Fload (file=139743441, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #30 0x081a1357 in Frequire (feature=140528330, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #31 0x08196d83 in Ffuncall (nargs=2, args=0x23fe030) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #32 0x081ce8e1 in Fbyte_code (bytestr=139743489, vector=139592949, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #33 0x08196304 in Feval (form=139785254) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 + #34 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139743569, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #35 0x081bbad7 in Fload (file=139985769, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #36 0x081a1357 in Frequire (feature=140528282, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #37 0x08196d83 in Ffuncall (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #38 0x0819879e in Fapply (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2453 + #39 0x08196e26 in Ffuncall (nargs=3, args=0x23fe5c0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2971 + #40 0x081ce8e1 in Fbyte_code (bytestr=139665665, vector=140243293, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #41 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #42 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe730) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #43 0x081ce8e1 in Fbyte_code (bytestr=139663633, vector=140113917, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #44 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #45 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe8a0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #46 0x081ce8e1 in Fbyte_code (bytestr=139651313, vector=141733317, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #47 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #48 0x08196bb3 in Ffuncall (nargs=1, args=0x23fea20) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #49 0x081961cd in Feval (form=142062606) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2324 + #50 0x08198ec2 in internal_lisp_condition_case (var=139619738, bodyform=142062606, handlers=142059126) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 + #51 0x081cdb3a in Fbyte_code (bytestr=139651065, vector=138947149, maxdepth=64) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 + #52 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #53 0x08196bb3 in Ffuncall (nargs=3, args=0x23fed10) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #54 0x081ce8e1 in Fbyte_code (bytestr=139638617, vector=140190309, maxdepth=32) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #55 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #56 0x08195bff in apply_lambda (fun=141815293, args=139024998, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #57 0x08195ef4 in Feval (form=139025038) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #58 0x08198ec2 in internal_lisp_condition_case (var=138727490, bodyform=139025038, handlers=138994086) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 + #59 0x081cdb3a in Fbyte_code (bytestr=141397873, vector=139422605, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 + #60 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #61 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff150) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #62 0x081ce8e1 in Fbyte_code (bytestr=141396361, vector=138448733, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #63 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #64 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff2d0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #65 0x081ce8e1 in Fbyte_code (bytestr=136699577, vector=136699597, maxdepth=40) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #66 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #67 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #68 0x081ce8e1 in Fbyte_code (bytestr=136685793, vector=136685813, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #69 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #70 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #71 0x081ce8e1 in Fbyte_code (bytestr=136683265, vector=136683285, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #72 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #73 0x08195bff in apply_lambda (fun=136683245, args=138364586, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #74 0x08195ef4 in Feval (form=138740766) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #75 0x0812dd83 in top_level_2 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1336 + #76 0x081951dc in internal_condition_case (bfun=0x812dd70 <top_level_2>, handlers=138394034, hfun=0x8132020 <cmd_error>) + at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1460 + #77 0x08131de5 in top_level_1 (ignore=138364586) at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1344 + #78 0x081952a9 in internal_catch (tag=138392170, func=0x8131d80 <top_level_1>, arg=138364586) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1204 + #79 0x08131e53 in command_loop () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1299 + #80 0x0813220a in recursive_edit_1 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:929 + #81 0x08132332 in Frecursive_edit () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:991 + #82 0x0812727b in main (argc=<value optimized out>, argv=0x23ffad8) at /home/tschwinge/tmp/emacs/trunk/src/emacs.c:1718 + +Next: restarted from scratch, rebuilt without optimizations. +`--prefix=$PWD.install --build=i686-pc-gnu --enable-asserts +--enable-checking=all CFLAGS=-g` + + $ make + [...] + Dumping under the name emacs [sits here for a long time] + + $ vmstat + pagesize: 4K + size: 324M + free: 9.16M + active: 56M + inactive: 242M + wired: 17.6M + zero filled: 8.75G + reactivated: 0 + pageins: 289M + pageouts: 371M + page faults: 12508128 + cow faults: 1411724 + memobj hit ratio: 99% + swap size: 512M + swap free: 512M + +Apparently low memory, but doesn't swap out. + +Uses a lot of CPU time, as observed with `xm top`. + +Creating another `screen` window as user tschwinge doesn't get to the shell +prompt. + +Running `vmstat` works in a `screen` window that is already open, but running +`ps -Af` just hangs; adding `-M` helps. + +Perhaps the /media/data/ file system (which backs /home/) is in a inconsistent +state / deadlocked? + +More specifically, this does not work / does not exit: + + login> syncfs -s -c /media/data/ & + [2] 10785 + +But this works: + + login> syncfs -s -c / & + [3] 10786 + login> + [3]+ Done syncfs -s -c / + +Thus, the rootfs still is responsive; /media/data/ is not. + + login> ps -F hurd-long -T -M -w -A & + [4] 10796 + login> PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc + 0 0.0 0:00.00 0:00.13 + 1 0.0 0:00.30 0:03.55 + 2 0.0 0:00.30 0:04.21 + 3 0.0 0:00.65 0:06.88 + 4 0.0 0:00.02 0:00.31 + 5 0.0 0:00.32 0:03.72 + 6 0.0 0:00.00 0:00.23 + 7 0.0 0:00.00 0:00.03 + 8 0.0 0:00.30 0:03.17 + 9 0.0 0:00.47 0:04.69 + 10 0.0 0:00.62 0:06.42 + 11 0.0 0:00.40 0:05.91 + 12 0.0 0:00.47 0:04.18 + 13 0.0 0:00.10 0:00.73 + 14 0.0 0:00.56 0:05.97 + 15 0.0 0:00.26 0:04.61 + 1 0 1 1 1 1 146M 368K 0.0 0:00.00 0:00.03 /hurd/init root=device:hd0 + 0 0.0 0:00.00 0:00.03 + 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 + 0 0.0 0:00.00 0:00.00 + 1 92.6 0:00.00 46:33.66 + 2 0.0 0:00.00 0:12.07 + 3 0.0 0:00.00 0:00.05 + 4 0.0 0:00.00 0:00.02 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.01 + 3 0 1 1 1 173 409M 15.7M 0.2 4:39.39 34:08.86 ext2fs -A --multiboot-command-line=root=device:hd0 --host-priv-port=1 --device-master-port=2 -- + [165CM-exec-server-task=3 -T typed device:hd0 + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:21.78 2:32.67 + 2 0.0 0:00.15 0:01.33 + 3 0.0 0:00.07 0:01.13 + 4 0.0 0:22.09 2:32.56 + 5 0.0 0:00.11 0:01.30 + 6 0.0 0:21.57 2:32.78 + 7 0.2 0:04.10 0:54.37 + 8 0.0 0:00.00 0:00.01 + 9 0.0 0:20.96 2:30.00 + 10 0.0 0:00.09 0:01.05 + 11 0.0 0:00.09 0:00.94 + 12 0.0 0:21.59 2:32.40 + 13 0.0 0:21.50 2:32.02 + 14 0.0 0:00.00 0:00.92 + 15 0.0 0:00.07 0:00.60 + 16 0.0 0:00.09 0:00.86 + 17 0.0 0:00.04 0:00.88 + 18 0.0 0:00.13 0:00.91 + 19 0.0 0:00.04 0:00.91 + 20 0.0 0:00.02 0:00.89 + 21 0.0 0:00.08 0:00.97 + 22 0.0 0:00.05 0:00.84 + 23 0.0 0:00.04 0:00.86 + 24 0.0 0:00.09 0:00.86 + 25 0.0 0:00.11 0:00.88 + 26 0.0 0:00.04 0:00.64 + 27 0.0 0:21.10 2:32.22 + 28 0.0 0:20.32 2:29.92 + 29 0.0 0:20.58 2:31.51 + 30 0.0 0:20.50 2:32.72 + 31 0.0 0:21.05 2:30.05 + 32 0.0 0:19.78 2:33.40 + 33 0.0 0:20.55 2:31.88 + 34 0.0 0:00.00 0:00.06 + 35 0.0 0:00.00 0:00.07 + 36 0.0 0:00.00 0:00.02 + 37 0.0 0:00.01 0:00.05 + 38 0.0 0:00.00 0:00.03 + 39 0.0 0:00.00 0:00.02 + 40 0.0 0:00.00 0:00.06 + 41 0.0 0:00.02 0:00.02 + 42 0.0 0:00.00 0:00.03 + 43 0.0 0:00.00 0:00.05 + 44 0.0 0:00.00 0:00.07 + 45 0.0 0:00.00 0:00.02 + 46 0.0 0:00.00 0:00.02 + 47 0.0 0:00.00 0:00.04 + 48 0.0 0:00.00 0:00.03 + 49 0.0 0:00.00 0:00.03 + 50 0.0 0:00.00 0:00.05 + 51 0.0 0:00.00 0:00.05 + 52 0.0 0:00.00 0:00.04 + 53 0.0 0:00.00 0:00.04 + 54 0.0 0:00.00 0:00.02 + 55 0.0 0:00.00 0:00.03 + 56 0.0 0:00.01 0:00.01 + 57 0.0 0:00.03 0:00.01 + 58 0.0 0:00.01 0:00.00 + 59 0.0 0:00.00 0:00.00 + 60 0.0 0:00.00 0:00.00 + 61 0.0 0:00.00 0:00.03 + 62 0.0 0:00.00 0:00.00 + 63 0.0 0:00.00 0:00.08 + 64 0.0 0:00.00 0:00.06 + 65 0.0 0:00.01 0:00.00 + 66 0.0 0:00.00 0:00.07 + 67 0.0 0:00.00 0:00.01 + 68 0.0 0:00.02 0:00.02 + 69 0.0 0:00.01 0:00.02 + 70 0.0 0:00.01 0:00.01 + 71 0.0 0:00.01 0:00.04 + 72 0.0 0:00.00 0:00.01 + 73 0.0 0:00.01 0:00.00 + 74 0.0 0:00.00 0:00.06 + 75 0.0 0:00.00 0:00.04 + 76 0.0 0:00.02 0:00.05 + 77 0.0 0:00.00 0:00.03 + 78 0.0 0:00.00 0:00.02 + 79 0.0 0:00.00 0:00.05 + 80 0.0 0:00.01 0:00.00 + 81 0.0 0:00.00 0:00.02 + 82 0.0 0:00.00 0:00.03 + 83 0.0 0:00.00 0:00.00 + 84 0.0 0:00.00 0:00.00 + 85 0.0 0:00.00 0:00.04 + 86 0.0 0:00.00 0:00.04 + 87 0.0 0:00.00 0:00.02 + 88 0.0 0:00.01 0:00.00 + 89 0.0 0:00.00 0:00.04 + 90 0.0 0:00.00 0:00.04 + 91 0.0 0:00.00 0:00.05 + 92 0.0 0:00.00 0:00.02 + 93 0.0 0:00.00 0:00.03 + 94 0.0 0:00.00 0:00.02 + 95 0.0 0:00.00 0:00.01 + 96 0.0 0:00.00 0:00.02 + 97 0.0 0:00.00 0:00.03 + 98 0.0 0:00.00 0:00.05 + 99 0.0 0:00.00 0:00.04 + 100 0.0 0:00.00 0:00.03 + 101 0.0 0:00.00 0:00.01 + 102 0.0 0:00.00 0:00.01 + 103 0.0 0:00.00 0:00.05 + 104 0.0 0:00.00 0:00.06 + 105 0.0 0:00.01 0:00.04 + 106 0.0 0:00.00 0:00.00 + 107 0.0 0:00.01 0:00.02 + 108 0.0 0:00.00 0:00.00 + 109 0.0 0:00.00 0:00.02 + 110 0.0 0:00.00 0:00.01 + 111 0.0 0:00.00 0:00.02 + 112 0.0 0:00.01 0:00.04 + 113 0.0 0:00.01 0:00.01 + 114 0.0 0:00.00 0:00.02 + 115 0.0 0:00.01 0:00.02 + 116 0.0 0:00.01 0:00.03 + 117 0.0 0:00.00 0:00.03 + 118 0.0 0:00.01 0:00.01 + 119 0.0 0:00.00 0:00.01 + 120 0.0 0:00.00 0:00.05 + 121 0.0 0:00.00 0:00.02 + 122 0.0 0:00.00 0:00.02 + 123 0.0 0:00.00 0:00.04 + 124 0.0 0:00.00 0:00.04 + 125 0.0 0:00.00 0:00.02 + 126 0.0 0:00.00 0:00.02 + 127 0.0 0:00.01 0:00.01 + 128 0.0 0:00.00 0:00.01 + 129 0.0 0:00.01 0:00.03 + 130 0.0 0:00.01 0:00.05 + 131 0.0 0:00.00 0:00.02 + 132 0.0 0:00.00 0:00.03 + 133 0.0 0:00.00 0:00.03 + 134 0.0 0:00.00 0:00.02 + 135 0.0 0:00.00 0:00.00 + 136 0.0 0:00.00 0:00.01 + 137 0.0 0:00.01 0:00.03 + 138 0.0 0:00.00 0:00.03 + 139 0.0 0:00.00 0:00.02 + 140 0.0 0:00.01 0:00.01 + 141 0.0 0:00.01 0:00.02 + 142 0.0 0:00.00 0:00.00 + 143 0.0 0:00.00 0:00.02 + 144 0.0 0:00.01 0:00.00 + 145 0.0 0:00.00 0:00.01 + 146 0.0 0:00.00 0:00.00 + 147 0.0 0:00.00 0:00.00 + 148 0.0 0:00.00 0:00.03 + 149 0.0 0:00.00 0:00.00 + 150 0.0 0:00.00 0:00.01 + 151 0.0 0:00.00 0:00.00 + 152 0.0 0:00.00 0:00.01 + 153 0.0 0:00.00 0:00.00 + 154 0.0 0:00.00 0:00.00 + 155 0.0 0:00.00 0:00.00 + 156 0.0 0:00.00 0:00.00 + 157 0.0 0:00.00 0:00.01 + 158 0.0 0:00.00 0:00.00 + 159 0.0 0:00.00 0:00.01 + 160 0.0 0:00.00 0:00.01 + 161 0.0 0:00.00 0:00.00 + 162 0.0 0:00.00 0:00.00 + 163 0.0 0:00.00 0:00.00 + 164 0.0 0:00.00 0:00.01 + 165 0.0 0:00.00 0:00.00 + 166 0.0 0:00.00 0:00.00 + 167 0.0 0:00.00 0:00.00 + 168 0.0 0:00.00 0:00.00 + 169 0.0 0:00.00 0:00.00 + 170 0.0 0:00.00 0:00.00 + 171 0.0 0:00.00 0:00.00 + 172 0.0 0:00.00 0:00.00 + 4 0 3 1 1 6 131M 1.32M 0.0 0:02.20 0:26.26 /hurd/exec + 0 0.0 0:00.43 0:05.32 + 1 0.0 0:00.41 0:05.54 + 2 0.0 0:00.44 0:05.38 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.45 0:05.05 + 5 0.0 0:00.44 0:04.95 + 5 0 1 1 1 6 130M 580K 0.0 0:01.17 0:14.92 /hurd/auth + 0 0.0 0:00.20 0:02.99 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.24 0:03.03 + 3 0.0 0:00.18 0:02.86 + 4 0.0 0:00.22 0:03.01 + 5 0.0 0:00.31 0:03.01 + 6 0 1 6 6 2 147M 1.09M 0.0 0:00.01 0:00.13 /bin/bash /libexec/runsystem root=device:hd0 + 0 0.0 0:00.01 0:00.13 + 1 0.0 0:00.00 0:00.00 + 7 0 3 1 1 7 130M 880K 0.1 0:00.35 0:10.10 /hurd/term /dev/console device console + 0 0.0 0:00.07 0:01.15 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:00.14 0:03.10 + 3 0.1 0:00.10 0:01.87 + 4 0.0 0:00.01 0:00.50 + 5 0.0 0:00.00 0:01.54 + 6 0.0 0:00.02 0:01.91 + 9 0 3 1 1 19 131M 1.13M 0.0 0:05.41 1:17.29 /hurd/pflocal + 0 0.0 0:00.06 0:00.48 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.05 0:00.48 + 3 0.0 0:00.78 0:09.10 + 4 0.0 0:00.49 0:06.13 + 5 0.0 0:00.56 0:07.07 + 6 0.0 0:00.30 0:03.41 + 7 0.0 0:00.47 0:05.58 + 8 0.0 0:00.27 0:06.00 + 9 0.0 0:00.04 0:00.47 + 10 0.0 0:00.43 0:06.17 + 11 0.0 0:00.70 0:09.21 + 12 0.0 0:00.00 0:00.04 + 13 0.0 0:00.59 0:10.75 + 14 0.0 0:00.14 0:01.86 + 15 0.0 0:00.04 0:01.49 + 16 0.0 0:00.02 0:00.76 + 17 0.0 0:00.22 0:05.59 + 18 0.0 0:00.16 0:02.62 + 12 0 1 12 12 6 129M 1.2M 0.0 0:00.00 0:00.06 /hurd/mach-defpager + 0 0.0 0:00.00 0:00.06 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.00 + 14 0 3 1 1 3 131M 504K 0.0 0:00.00 0:00.05 /hurd/storeio hd1 + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 18 0 3 1 1 3 131M 512K 0.0 0:00.39 0:06.71 /hurd/storeio hd0 + 0 0.0 0:00.13 0:01.66 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.25 0:05.04 + 19 0 3 1 1 3 131M 656K 0.0 0:00.27 0:04.89 /hurd/storeio hd2 + 0 0.0 0:00.10 0:01.48 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.16 0:03.41 + 21 0 3 1 1 4 130M 648K 0.0 0:00.55 0:06.94 /hurd/null + 0 0.0 0:00.24 0:02.09 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.08 0:02.16 + 3 0.0 0:00.22 0:02.68 + 22 0 3 1 1 4 130M 820K 0.0 0:00.00 0:00.05 /hurd/procfs + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 71 1 1 71 71 2 146M 728K 0.0 0:00.00 0:00.03 /usr/sbin/atd + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 77 0 3 1 1 4 130M 896K 0.0 0:00.00 0:00.02 /hurd/streamio kmsg + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 117 0 1 117 117 2 146M 1.02M 0.0 0:00.00 0:00.04 /usr/sbin/cron + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 122 101 1 122 122 2 7.75M 1.07M 0.0 0:00.00 0:00.05 /usr/bin/dbus-daemon --system + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 128 0 3 1 1 4 130M 908K 0.0 0:00.00 0:00.02 /hurd/fifo + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 131 8 1 6 6 2 147M 880K 0.0 0:00.01 0:00.07 /usr/sbin/nullmailer-send -d + 0 0.0 0:00.01 0:00.07 + 1 0.0 0:00.00 0:00.00 + 139 0 3 1 1 19 133M 2.19M 0.3 0:18.66 1:17.98 /hurd/pfinet -i eth0 -a 192.168.10.63 -g 192.168.10.1 -m 255.255.255.0 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.1 0:12.72 0:14.56 + 3 0.2 0:01.65 0:12.23 + 4 0.0 0:01.67 0:18.56 + 5 0.0 0:00.50 0:05.93 + 6 0.0 0:00.40 0:06.16 + 7 0.0 0:00.57 0:05.95 + 8 0.0 0:00.30 0:04.15 + 9 0.0 0:00.15 0:01.92 + 10 0.0 0:00.13 0:01.45 + 11 0.0 0:00.14 0:01.47 + 12 0.0 0:00.07 0:01.06 + 13 0.0 0:00.08 0:01.23 + 14 0.0 0:00.08 0:00.92 + 15 0.0 0:00.03 0:00.63 + 16 0.0 0:00.03 0:00.45 + 17 0.0 0:00.05 0:00.72 + 18 0.0 0:00.03 0:00.49 + 140 0 3 1 1 3 131M 1.16M 0.0 0:00.00 0:00.05 /hurd/storeio --no-cache time + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 142 0 1 142 142 2 10.5M 1.23M 0.0 0:00.00 0:00.05 /usr/sbin/sshd + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 157 0 3 1 1 6 130M 1M 0.0 0:00.02 0:00.01 /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.01 0:00.00 + 158 0 6 158 158 2 146M 824K 0.0 0:00.00 0:00.01 /libexec/runttys + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 159 0 3 1 1 15 133M 1.67M 0.0 0:00.01 0:00.06 /hurd/console + 0 0.0 0:00.01 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.00 + 7 0.0 0:00.00 0:00.02 + 8 0.0 0:00.00 0:00.00 + 9 0.0 0:00.00 0:00.00 + 10 0.0 0:00.00 0:00.00 + 11 0.0 0:00.00 0:00.00 + 12 0.0 0:00.00 0:00.01 + 13 0.0 0:00.00 0:00.00 + 14 0.0 0:00.00 0:00.00 + 160 - 158 160 160 2 147M 1.82M 0.0 0:00.02 0:00.16 -login prompt (bash) + 0 0.0 0:00.02 0:00.14 + 1 0.0 0:00.00 0:00.02 + 161 - 158 161 161 2 147M 1.78M 0.0 0:00.00 0:00.07 -login prompt (bash) + 0 0.0 0:00.00 0:00.07 + 1 0.0 0:00.00 0:00.00 + 162 - 158 162 162 2 147M 1.78M 0.0 0:00.01 0:00.07 -login prompt (bash) + 0 0.0 0:00.01 0:00.07 + 1 0.0 0:00.00 0:00.00 + 163 - 158 163 163 2 147M 1.78M 0.0 0:00.00 0:00.03 -login prompt (bash) + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + 164 - 158 164 164 2 147M 1.78M 0.0 0:00.02 0:00.03 -login prompt (bash) + 0 0.0 0:00.02 0:00.03 + 1 0.0 0:00.00 0:00.00 + 165 - 158 165 165 2 147M 1.78M 0.0 0:00.00 0:00.08 -login prompt (bash) + 0 0.0 0:00.00 0:00.08 + 1 0.0 0:00.00 0:00.00 + 166 - 158 166 166 2 147M 1.78M 0.0 0:00.01 0:00.01 -login prompt (bash) + 0 0.0 0:00.01 0:00.01 + 1 0.0 0:00.00 0:00.00 + 167 0 3 1 1 6 130M 1016K 0.0 0:00.01 0:00.11 /hurd/term /dev/tty2 hurdio /dev/vcs/2/console + 0 0.0 0:00.01 0:00.06 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.01 + 4 0.0 0:00.00 0:00.03 + 5 0.0 0:00.00 0:00.00 + 168 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty3 hurdio /dev/vcs/3/console + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.01 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.01 + 169 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty5 hurdio /dev/vcs/5/console + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.04 + 5 0.0 0:00.00 0:00.00 + 170 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.05 /hurd/term /dev/tty4 hurdio /dev/vcs/4/console + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.00 0:00.00 + 171 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.01 /hurd/term /dev/tty6 hurdio /dev/vcs/6/console + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.00 + 172 0 3 1 1 4 130M 892K 0.0 0:00.00 0:00.01 /hurd/password + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 173 0 142 173 173 3 10.7M 3.09M 0.0 0:02.09 0:12.63 /usr/sbin/sshd -R + 0 0.0 0:02.09 0:12.63 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.0 1:34.24 6:26.66 + 3 0.0 0:00.04 0:00.31 + 4 0.0 0:00.13 0:00.47 + 5 0.0 0:00.05 0:00.57 + 6 0.0 1:36.91 6:26.41 + 7 0.0 0:12.98 0:34.83 + 8 0.0 1:37.85 6:26.20 + 9 0.0 1:35.07 6:17.07 + 10 0.0 0:00.05 0:00.50 + 11 0.0 0:00.04 0:00.48 + 12 0.0 0:00.07 0:00.55 + 13 0.0 0:00.03 0:00.46 + 14 0.0 0:00.03 0:00.42 + 15 0.0 0:00.06 0:00.32 + 16 0.0 0:00.05 0:00.56 + 17 0.0 0:00.05 0:00.50 + 18 0.0 0:00.05 0:00.48 + 19 0.0 0:00.03 0:00.37 + 20 0.0 0:00.08 0:00.48 + 21 0.0 0:00.01 0:00.52 + 22 0.0 0:00.02 0:00.44 + 23 0.0 0:00.02 0:00.44 + 24 0.0 0:00.03 0:00.31 + 25 0.0 0:00.05 0:00.32 + 26 0.0 0:00.04 0:00.37 + 27 0.0 0:00.00 0:00.31 + 28 0.0 0:00.03 0:00.23 + 29 0.0 0:00.05 0:00.33 + 30 0.0 0:00.04 0:00.31 + 31 0.0 0:00.01 0:00.29 + 32 0.0 0:00.07 0:00.27 + 33 0.0 0:00.05 0:00.28 + 34 0.0 0:00.04 0:00.23 + 35 0.0 0:00.04 0:00.46 + 36 0.0 0:00.02 0:00.31 + 37 0.0 0:00.02 0:00.38 + 38 0.0 0:00.06 0:00.29 + 39 0.0 0:00.03 0:00.22 + 40 0.0 0:00.02 0:00.28 + 41 0.0 0:00.03 0:00.26 + 42 0.0 0:00.05 0:00.39 + 43 0.0 0:00.06 0:00.37 + 44 0.0 0:00.03 0:00.36 + 45 0.0 0:00.04 0:00.20 + 46 0.0 0:00.02 0:00.28 + 47 0.0 0:00.01 0:00.29 + 48 0.0 0:00.03 0:00.23 + 49 0.0 0:00.04 0:00.22 + 50 0.0 0:00.07 0:00.25 + 51 0.0 0:00.00 0:00.33 + 52 0.0 0:00.05 0:00.49 + 53 0.0 0:00.02 0:00.31 + 54 0.0 0:00.00 0:00.27 + 55 0.0 0:00.06 0:00.25 + 56 0.0 0:00.05 0:00.35 + 57 0.0 0:00.01 0:00.28 + 58 0.0 0:00.06 0:00.25 + 59 0.0 0:00.05 0:00.30 + 60 0.0 0:00.03 0:00.36 + 61 0.0 0:00.04 0:00.31 + 62 0.0 0:00.05 0:00.18 + 63 0.0 0:00.02 0:00.31 + 64 0.0 0:00.00 0:00.27 + 65 0.0 0:00.02 0:00.26 + 66 0.0 0:00.00 0:00.31 + 67 0.0 0:00.00 0:00.15 + 68 0.0 0:00.04 0:00.32 + 69 0.0 0:00.04 0:00.21 + 70 0.0 0:00.01 0:00.31 + 71 0.0 0:00.05 0:00.22 + 72 0.0 0:00.01 0:00.28 + 73 0.0 0:00.04 0:00.31 + 74 0.0 0:00.06 0:00.20 + 75 0.0 0:00.04 0:00.38 + 76 0.0 0:00.03 0:00.37 + 77 0.0 0:00.06 0:00.32 + 78 0.0 0:00.04 0:00.22 + 79 0.0 0:00.04 0:00.25 + 80 0.0 0:00.04 0:00.29 + 81 0.0 0:00.07 0:00.31 + 82 0.0 0:00.04 0:00.27 + 83 0.0 0:00.04 0:00.23 + 84 0.0 0:00.02 0:00.37 + 85 0.0 0:00.03 0:00.24 + 86 0.0 0:00.01 0:00.29 + 87 0.0 0:00.03 0:00.24 + 88 0.0 0:00.01 0:00.31 + 89 0.0 0:00.03 0:00.39 + 90 0.0 0:00.00 0:00.30 + 91 0.0 0:00.03 0:00.32 + 92 0.0 0:00.00 0:00.24 + 93 0.0 0:00.03 0:00.32 + 94 0.0 0:00.04 0:00.30 + 95 0.0 0:00.00 0:00.33 + 96 0.0 0:00.02 0:00.24 + 97 0.0 0:00.01 0:00.26 + 98 0.0 0:00.04 0:00.33 + 99 0.0 0:00.03 0:00.26 + 100 0.0 0:00.05 0:00.29 + 101 0.0 0:00.05 0:00.34 + 102 0.0 0:00.04 0:00.38 + 103 0.0 0:00.00 0:00.22 + 104 0.0 0:00.03 0:00.38 + 105 0.0 0:00.01 0:00.43 + 106 0.0 0:00.03 0:00.37 + 107 0.0 0:00.05 0:00.31 + 108 0.0 0:00.02 0:00.31 + 109 0.0 0:00.00 0:00.26 + 110 0.0 0:00.03 0:00.27 + 111 0.0 0:00.03 0:00.25 + 112 0.0 0:00.02 0:00.30 + 113 0.0 0:00.05 0:00.23 + 114 0.0 0:00.02 0:00.32 + 115 0.0 0:00.02 0:00.29 + 116 0.0 0:00.04 0:00.22 + 117 0.0 0:00.04 0:00.26 + 118 0.0 0:00.02 0:00.36 + 119 0.0 0:00.03 0:00.31 + 120 0.0 0:00.04 0:00.26 + 121 0.0 0:00.05 0:00.28 + 122 0.0 0:00.01 0:00.27 + 123 0.0 0:00.03 0:00.34 + 124 0.0 0:00.03 0:00.36 + 125 0.0 0:00.02 0:00.33 + 126 0.0 0:00.04 0:00.36 + 127 0.0 0:00.00 0:00.41 + 128 0.0 0:00.02 0:00.33 + 129 0.0 0:00.07 0:00.32 + 130 0.0 0:00.03 0:00.29 + 131 0.0 0:00.00 0:00.34 + 132 0.0 0:00.04 0:00.28 + 133 0.0 0:00.04 0:00.24 + 134 0.0 0:00.03 0:00.35 + 135 0.0 0:00.04 0:00.38 + 136 0.0 0:00.04 0:00.37 + 137 0.0 0:00.04 0:00.26 + 138 0.0 0:00.00 0:00.26 + 139 0.0 0:00.06 0:00.40 + 140 0.0 1:23.58 6:28.86 + 141 0.0 0:25.74 1:55.97 + 142 0.0 0:00.00 0:00.00 + 143 0.0 0:00.00 0:00.00 + 144 0.0 0:00.00 0:00.00 + 145 0.0 0:00.00 0:00.00 + 146 0.0 0:00.00 0:00.00 + 147 0.0 0:00.00 0:00.00 + 148 0.0 0:00.00 0:00.00 + 149 0.0 0:00.00 0:00.00 + 150 0.0 0:00.00 0:00.00 + 151 0.0 0:00.00 0:00.00 + 152 0.0 0:00.00 0:00.00 + 153 0.0 0:00.00 0:00.00 + 154 0.0 0:00.00 0:00.00 + 155 0.0 0:00.00 0:00.00 + 156 0.0 0:00.00 0:00.00 + 157 0.0 0:00.00 0:00.00 + 158 0.0 0:00.00 0:00.00 + 159 0.0 0:00.00 0:00.00 + 160 0.0 0:00.00 0:00.00 + 161 0.0 0:00.00 0:00.00 + 162 0.0 0:00.00 0:00.00 + 163 0.0 0:00.00 0:00.00 + 164 0.0 0:00.00 0:00.00 + 165 0.0 0:00.00 0:00.00 + 166 0.0 0:00.00 0:00.00 + 167 0.0 0:00.00 0:00.00 + 168 0.0 0:00.00 0:00.00 + 169 0.0 0:00.00 0:00.00 + 170 0.0 0:00.00 0:00.00 + 171 0.0 0:00.00 0:00.00 + 172 0.0 0:00.00 0:00.00 + 173 0.0 0:00.00 0:00.00 + 174 0.0 0:00.00 0:00.00 + 175 0.0 0:00.00 0:00.00 + 176 0.0 0:00.00 0:00.00 + 177 0.0 0:00.00 0:00.00 + 178 0.0 0:00.00 0:00.00 + 179 0.0 0:00.00 0:00.00 + 180 0.0 0:00.00 0:00.00 + 181 0.0 0:00.00 0:00.00 + 182 0.0 0:00.00 0:00.00 + 183 0.0 0:00.00 0:00.00 + 184 0.0 0:00.00 0:00.00 + 185 0.0 0:00.00 0:00.00 + 186 0.0 0:00.00 0:00.00 + 187 0.0 0:00.00 0:00.00 + 188 0.0 0:00.00 0:00.00 + 189 0.0 0:00.00 0:00.00 + 190 0.0 0:00.00 0:00.00 + 191 0.0 0:00.00 0:00.00 + 192 0.0 0:00.00 0:00.00 + 193 0.0 0:00.00 0:00.00 + 194 0.0 0:00.00 0:00.00 + 195 0.0 0:00.00 0:00.00 + 196 0.0 0:00.00 0:00.00 + 197 0.0 0:00.00 0:00.00 + 198 0.0 0:00.00 0:00.00 + 199 0.0 0:00.00 0:00.00 + 200 0.0 0:00.00 0:00.00 + 201 0.0 0:00.00 0:00.00 + 202 0.0 0:00.00 0:00.00 + 203 0.0 0:00.00 0:00.00 + 204 0.0 0:00.00 0:00.00 + 205 0.0 0:00.00 0:00.00 + 206 0.0 0:00.00 0:00.00 + 207 0.0 0:00.00 0:00.00 + 208 0.0 0:00.00 0:00.00 + 209 0.0 0:00.00 0:00.00 + 210 0.0 0:00.00 0:00.00 + 211 0.0 0:00.00 0:00.00 + 212 0.0 0:00.00 0:00.00 + 213 0.0 0:00.00 0:00.00 + 214 0.0 0:00.00 0:00.00 + 215 0.0 0:00.00 0:00.00 + 216 0.0 0:00.00 0:00.00 + 217 0.0 0:00.00 0:00.00 + 218 0.0 0:00.00 0:00.00 + 219 0.0 0:00.00 0:00.00 + 220 0.0 0:00.00 0:00.00 + 221 0.0 0:00.00 0:00.00 + 222 0.0 0:00.00 0:00.00 + 223 0.0 0:00.00 0:00.00 + 224 0.0 0:00.00 0:00.00 + 225 0.0 0:00.00 0:00.00 + 226 0.0 0:00.00 0:00.00 + 227 0.0 0:00.00 0:00.00 + 228 0.0 0:00.00 0:00.00 + 229 0.0 0:00.00 0:00.00 + 230 0.0 0:00.00 0:00.00 + 231 0.0 0:00.00 0:00.00 + 232 0.0 0:00.00 0:00.00 + 233 0.0 0:00.00 0:00.00 + 234 0.0 0:00.00 0:00.00 + 235 0.0 0:00.00 0:00.00 + 236 0.0 0:00.00 0:00.00 + 237 0.0 0:00.00 0:00.00 + 238 0.0 0:00.00 0:00.00 + 239 0.0 0:00.00 0:00.00 + 240 0.0 0:00.00 0:00.00 + 241 0.0 0:00.00 0:00.00 + 242 0.0 0:00.00 0:00.00 + 243 0.0 0:00.00 0:00.00 + 244 0.0 0:00.00 0:00.00 + 245 0.0 0:00.00 0:00.00 + 246 0.0 0:00.00 0:00.00 + 247 0.0 0:00.00 0:00.00 + 248 0.0 0:00.00 0:00.00 + 249 0.0 0:00.00 0:00.00 + 250 0.0 0:00.00 0:00.00 + 251 0.0 0:00.00 0:00.00 + 252 0.0 0:00.00 0:00.00 + 253 0.0 0:00.00 0:00.00 + 254 0.0 0:00.00 0:00.00 + 255 0.0 0:00.00 0:00.00 + 256 0.0 0:00.00 0:00.00 + 257 0.0 0:00.00 0:00.00 + 258 0.0 0:00.00 0:00.00 + 259 0.0 0:00.00 0:00.00 + 260 0.0 0:00.00 0:00.00 + 261 0.0 0:00.00 0:00.00 + 262 0.0 0:00.00 0:00.00 + 263 0.0 0:00.00 0:00.00 + 264 0.0 0:00.00 0:00.00 + 265 0.0 0:00.00 0:00.00 + 266 0.0 0:00.00 0:00.00 + 267 0.0 0:00.00 0:00.00 + 268 0.0 0:00.00 0:00.00 + 269 0.0 0:00.00 0:00.00 + 270 0.0 0:00.00 0:00.00 + 271 0.0 0:00.00 0:00.00 + 272 0.0 0:00.00 0:00.00 + 273 0.0 0:00.00 0:00.00 + 274 0.0 0:00.00 0:00.00 + 275 0.0 0:00.00 0:00.00 + 276 0.0 0:00.00 0:00.00 + 277 0.0 0:00.00 0:00.00 + 278 0.0 0:00.00 0:00.00 + 279 0.0 0:00.00 0:00.00 + 280 0.0 0:00.00 0:00.00 + 281 0.0 0:00.00 0:00.00 + 282 0.0 0:00.00 0:00.00 + 283 0.0 0:00.00 0:00.00 + 284 0.0 0:00.00 0:00.00 + 285 0.0 0:00.00 0:00.00 + 286 0.0 0:00.00 0:00.00 + 287 0.0 0:00.00 0:00.00 + 288 0.0 0:00.00 0:00.00 + 289 0.0 0:00.00 0:00.00 + 290 0.0 0:00.00 0:00.00 + 291 0.0 0:00.00 0:00.00 + 292 0.0 0:00.00 0:00.00 + 293 0.0 0:00.00 0:00.00 + 294 0.0 0:00.00 0:00.00 + 295 0.0 0:00.00 0:00.00 + 296 0.0 0:00.00 0:00.00 + 297 0.0 0:00.00 0:00.00 + 298 0.0 0:00.00 0:00.00 + 299 0.0 0:00.00 0:00.00 + 300 0.0 0:00.00 0:00.00 + 301 0.0 0:00.00 0:00.00 + 302 0.0 0:00.00 0:00.00 + 303 0.0 0:00.00 0:00.00 + 304 0.0 0:00.00 0:00.00 + 305 0.0 0:00.00 0:00.00 + 306 0.0 0:00.00 0:00.00 + 307 0.0 0:00.00 0:00.00 + 308 0.0 0:00.00 0:00.00 + 309 0.0 0:00.00 0:00.00 + 310 0.0 0:00.00 0:00.00 + 311 0.0 0:00.00 0:00.00 + 312 0.0 0:00.00 0:00.00 + 313 0.0 0:00.00 0:00.00 + 314 0.0 0:00.00 0:00.00 + 315 0.0 0:00.00 0:00.00 + 316 0.0 0:00.00 0:00.00 + 317 0.0 0:00.00 0:00.00 + 318 0.0 0:00.00 0:00.00 + 319 0.0 0:00.00 0:00.00 + 320 0.0 0:00.00 0:00.00 + 321 0.0 0:00.00 0:00.00 + 322 0.0 0:00.00 0:00.00 + 323 0.0 0:00.00 0:00.00 + 324 0.0 0:00.00 0:00.00 + 325 0.0 0:00.00 0:00.00 + 326 0.0 0:00.00 0:00.00 + 327 0.0 0:00.00 0:00.00 + 328 0.0 0:00.00 0:00.00 + 329 0.0 0:00.00 0:00.00 + 330 0.0 0:00.00 0:00.00 + 331 0.0 0:00.00 0:00.00 + 332 0.0 0:00.00 0:00.00 + 333 0.0 0:00.00 0:00.00 + 334 0.0 0:00.00 0:00.00 + 335 0.0 0:00.00 0:00.00 + 336 0.0 0:00.00 0:00.00 + 337 0.0 0:00.00 0:00.00 + 338 0.0 0:00.00 0:00.00 + 339 0.0 0:00.00 0:00.00 + 340 0.0 0:00.00 0:00.00 + 341 0.0 0:00.00 0:00.00 + 342 0.0 0:00.00 0:00.00 + 343 0.0 0:00.00 0:00.00 + 344 0.0 0:00.00 0:00.00 + 345 0.0 0:00.00 0:00.00 + 346 0.0 0:00.00 0:00.00 + 347 0.0 0:00.00 0:00.00 + 348 0.0 0:00.00 0:00.00 + 349 0.0 0:00.00 0:00.00 + 350 0.0 0:00.00 0:00.00 + 351 0.0 0:00.00 0:00.00 + 352 0.0 0:00.00 0:00.00 + 353 0.0 0:00.00 0:00.00 + 354 0.0 0:00.00 0:00.00 + 355 0.0 0:00.00 0:00.00 + 356 0.0 0:00.00 0:00.00 + 357 0.0 0:00.00 0:00.00 + 358 0.0 0:00.00 0:00.00 + 359 0.0 0:00.00 0:00.00 + 360 0.0 0:00.00 0:00.00 + 361 0.0 0:00.00 0:00.00 + 362 0.0 0:00.00 0:00.00 + 363 0.0 0:00.00 0:00.00 + 364 0.0 0:00.00 0:00.00 + 365 0.0 0:00.00 0:00.00 + 366 0.0 0:00.00 0:00.00 + 367 0.0 0:00.00 0:00.00 + 368 0.0 0:00.00 0:00.00 + 369 0.0 0:00.00 0:00.00 + 370 0.0 0:00.00 0:00.00 + 371 0.0 0:00.00 0:00.03 + 372 0.0 0:00.00 0:00.00 + 373 0.0 0:00.00 0:00.00 + 374 0.0 0:00.00 0:00.00 + 375 0.0 0:00.00 0:00.00 + 376 0.0 0:00.00 0:00.00 + 377 0.0 0:00.00 0:00.00 + 378 0.0 0:00.00 0:00.00 + 379 0.0 0:00.00 0:00.00 + 380 0.0 0:00.00 0:00.00 + 381 0.0 0:00.00 0:00.00 + 382 0.0 0:00.00 0:00.00 + 383 0.0 0:00.00 0:00.00 + 384 0.0 0:00.00 0:00.00 + 385 0.0 0:00.00 0:00.00 + 386 0.0 0:00.00 0:00.00 + 387 0.0 0:00.00 0:00.00 + 388 0.0 0:00.00 0:00.00 + 389 0.0 0:00.00 0:00.00 + 390 0.0 0:00.00 0:00.00 + 391 0.0 0:00.00 0:00.00 + 392 0.0 0:00.00 0:00.00 + 393 0.0 0:00.00 0:00.00 + 394 0.0 0:00.00 0:00.00 + 395 0.0 0:00.00 0:00.00 + 396 0.0 0:00.00 0:00.00 + 397 0.0 0:00.00 0:00.00 + 398 0.0 0:00.00 0:00.00 + 399 0.0 0:00.00 0:00.00 + 400 0.0 0:00.00 0:00.00 + 401 0.0 0:00.00 0:00.00 + 402 0.0 0:00.00 0:00.00 + 403 0.0 0:00.00 0:00.00 + 404 0.0 0:00.00 0:00.00 + 405 0.0 0:00.00 0:00.00 + 406 0.0 0:00.00 0:00.00 + 407 0.0 0:00.00 0:00.00 + 408 0.0 0:00.00 0:00.00 + 409 0.0 0:00.00 0:00.00 + 410 0.0 0:00.00 0:00.00 + 411 0.0 0:00.00 0:00.00 + 412 0.0 0:00.00 0:00.00 + 413 0.0 0:00.00 0:00.00 + 414 0.0 0:00.00 0:00.00 + 415 0.0 0:00.00 0:00.00 + 416 0.0 0:00.00 0:00.00 + 417 0.0 0:00.00 0:00.00 + 418 0.0 0:00.00 0:00.00 + 419 0.0 0:00.00 0:00.00 + 420 0.0 0:00.00 0:00.00 + 421 0.0 0:00.00 0:00.00 + 422 0.0 0:00.00 0:00.00 + 423 0.0 0:00.00 0:00.00 + 424 0.0 0:00.00 0:00.00 + 425 0.0 0:00.00 0:00.00 + 426 0.0 0:00.00 0:00.00 + 427 0.0 0:00.00 0:00.00 + 428 0.0 0:00.00 0:00.00 + 429 0.0 0:00.00 0:00.00 + 430 0.0 0:00.00 0:00.00 + 431 0.0 0:00.00 0:00.00 + 432 0.0 0:00.00 0:00.00 + 433 0.0 0:00.00 0:00.00 + 434 0.0 0:00.00 0:00.00 + 435 0.0 0:00.00 0:00.00 + 436 0.0 0:00.00 0:00.00 + 437 0.0 0:00.00 0:00.00 + 438 0.0 0:00.00 0:00.00 + 439 0.0 0:00.00 0:00.00 + 440 0.0 0:00.00 0:00.00 + 441 0.0 0:00.00 0:00.00 + 442 0.0 0:00.00 0:00.00 + 443 0.0 0:00.00 0:00.00 + 444 0.0 0:00.00 0:00.00 + 445 0.0 0:00.00 0:00.00 + 446 0.0 0:00.00 0:00.00 + 447 0.0 0:00.00 0:00.00 + 448 0.0 0:00.00 0:00.00 + 449 0.0 0:00.00 0:00.00 + 450 0.0 0:00.00 0:00.00 + 451 0.0 0:00.00 0:00.00 + 452 0.0 0:00.00 0:00.00 + 453 0.0 0:00.00 0:00.00 + 454 0.0 0:00.00 0:00.00 + 455 0.0 0:00.00 0:00.00 + 456 0.0 0:00.00 0:00.00 + 457 0.0 0:00.00 0:00.00 + 458 0.0 0:00.00 0:00.00 + 459 0.0 0:00.00 0:00.00 + 460 0.0 0:00.00 0:00.00 + 461 0.0 0:00.00 0:00.00 + 462 0.0 0:00.00 0:00.00 + 463 0.0 0:00.00 0:00.00 + 464 0.0 0:00.00 0:00.00 + 465 0.0 0:00.00 0:00.00 + 466 0.0 0:00.00 0:00.00 + 467 0.0 0:00.00 0:00.00 + 468 0.0 0:00.00 0:00.00 + 469 0.0 0:00.00 0:00.00 + 470 0.0 0:00.00 0:00.00 + 471 0.0 0:00.00 0:00.00 + 472 0.0 0:00.00 0:00.00 + 473 0.0 0:00.00 0:00.00 + 474 0.0 0:00.00 0:00.00 + 475 0.0 0:00.00 0:00.00 + 476 0.0 0:00.00 0:00.00 + 477 0.0 0:00.00 0:00.00 + 478 0.0 0:00.00 0:00.00 + 479 0.0 0:00.00 0:00.00 + 480 0.0 0:00.00 0:00.00 + 481 0.0 0:00.00 0:00.00 + 482 0.0 0:00.00 0:00.00 + 483 0.0 0:00.00 0:00.00 + 484 0.0 0:00.00 0:00.00 + 485 0.0 0:00.00 0:00.00 + 486 0.0 0:00.00 0:00.00 + 487 0.0 0:00.00 0:00.00 + 488 0.0 0:00.00 0:00.00 + 489 0.0 0:00.00 0:00.00 + 490 0.0 0:00.00 0:00.00 + 491 0.0 0:00.00 0:00.00 + 492 0.0 0:00.00 0:00.00 + 493 0.0 0:00.00 0:00.00 + 494 0.0 0:00.00 0:00.00 + 495 0.0 0:00.00 0:00.00 + 496 0.0 0:00.00 0:00.00 + 497 0.0 0:00.00 0:00.00 + 498 0.0 0:00.00 0:00.00 + 499 0.0 0:00.00 0:00.00 + 500 0.0 0:00.00 0:00.00 + 501 0.0 0:00.00 0:00.00 + 502 0.0 0:00.00 0:00.00 + 503 0.0 0:00.00 0:00.00 + 504 0.0 0:00.00 0:00.00 + 505 0.0 0:00.00 0:00.00 + 506 0.0 0:00.00 0:00.00 + 507 0.0 0:00.00 0:00.00 + 508 0.0 0:00.00 0:00.00 + 509 0.0 0:00.00 0:00.00 + 510 0.0 0:00.00 0:00.00 + 511 0.0 0:00.00 0:00.00 + 512 0.0 0:00.00 0:00.00 + 513 0.0 0:00.00 0:00.00 + 514 0.0 0:00.00 0:00.00 + 515 0.0 0:00.00 0:00.00 + 516 0.0 0:00.00 0:00.00 + 517 0.0 0:00.00 0:00.00 + 518 0.0 0:00.00 0:00.00 + 519 0.0 0:00.00 0:00.00 + 520 0.0 0:00.00 0:00.00 + 521 0.0 0:00.00 0:00.00 + 522 0.0 0:00.00 0:00.00 + 523 0.0 0:00.00 0:00.00 + 524 0.0 0:00.00 0:00.00 + 525 0.0 0:00.00 0:00.00 + 526 0.0 0:00.00 0:00.00 + 527 0.0 0:00.00 0:00.00 + 528 0.0 0:00.00 0:00.00 + 529 0.0 0:00.00 0:00.00 + 530 0.0 0:00.00 0:00.00 + 531 0.0 0:00.00 0:00.00 + 532 0.0 0:00.00 0:00.00 + 533 0.0 0:00.00 0:00.00 + 534 0.0 0:00.00 0:00.00 + 535 0.0 0:00.00 0:00.00 + 536 0.0 0:00.00 0:00.00 + 537 0.0 0:00.00 0:00.00 + 538 0.0 0:00.00 0:00.00 + 539 0.0 0:00.00 0:00.00 + 540 0.0 0:00.00 0:00.00 + 541 0.0 0:00.00 0:00.00 + 542 0.0 0:00.00 0:00.00 + 543 0.0 0:00.00 0:00.00 + 544 0.0 0:00.00 0:00.00 + 545 0.0 0:00.00 0:00.00 + 546 0.0 0:00.00 0:00.00 + 547 0.0 0:00.00 0:00.00 + 548 0.0 0:00.00 0:00.00 + 549 0.0 0:00.00 0:00.00 + 550 0.0 0:00.00 0:00.00 + 551 0.0 0:00.00 0:00.00 + 552 0.0 0:00.00 0:00.00 + 553 0.0 0:00.00 0:00.00 + 554 0.0 0:00.00 0:00.00 + 555 0.0 0:00.00 0:00.00 + 556 0.0 0:00.00 0:00.00 + 557 0.0 0:00.00 0:00.00 + 558 0.0 0:00.00 0:00.00 + 559 0.0 0:00.00 0:00.00 + 560 0.0 0:00.00 0:00.00 + 561 0.0 0:00.00 0:00.00 + 562 0.0 0:00.00 0:00.00 + 563 0.0 0:00.00 0:00.00 + 564 0.0 0:00.00 0:00.00 + 565 0.0 0:00.00 0:00.00 + 566 0.0 0:00.00 0:00.00 + 567 0.0 0:00.00 0:00.00 + 568 0.0 0:00.00 0:00.00 + 569 0.0 0:00.00 0:00.00 + 570 0.0 0:00.00 0:00.00 + 571 0.0 0:00.00 0:00.00 + 572 0.0 0:00.00 0:00.00 + 573 0.0 0:00.00 0:00.00 + 574 0.0 0:00.00 0:00.00 + 575 0.0 0:00.00 0:00.00 + 576 0.0 0:00.00 0:00.00 + 577 0.0 0:00.00 0:00.00 + 578 0.0 0:00.00 0:00.00 + 579 0.0 0:00.00 0:00.00 + 580 0.0 0:00.00 0:00.00 + 581 0.0 0:00.00 0:00.00 + 582 0.0 0:00.00 0:00.00 + 583 0.0 0:00.00 0:00.00 + 584 0.0 0:00.00 0:00.00 + 585 0.0 0:00.00 0:00.00 + 586 0.0 0:00.00 0:00.00 + 587 0.0 0:00.00 0:00.00 + 588 0.0 0:00.00 0:00.00 + 589 0.0 0:00.00 0:00.00 + 590 0.0 0:00.00 0:00.00 + 591 0.0 0:00.00 0:00.00 + 592 0.0 0:00.00 0:00.00 + 593 0.0 0:00.00 0:00.00 + 594 0.0 0:00.00 0:00.00 + 595 0.0 0:00.00 0:00.00 + 596 0.0 0:00.00 0:00.00 + 597 0.0 0:00.00 0:00.00 + 598 0.0 0:00.00 0:00.00 + 599 0.0 0:00.00 0:00.00 + 600 0.0 0:00.00 0:00.00 + 601 0.0 0:00.00 0:00.00 + 602 0.0 0:00.00 0:00.00 + 603 0.0 0:00.00 0:00.00 + 604 0.0 0:00.00 0:00.00 + 605 0.0 0:00.00 0:00.00 + 606 0.0 0:00.00 0:00.00 + 607 0.0 0:00.00 0:00.00 + 608 0.0 0:00.00 0:00.00 + 609 0.0 0:00.00 0:00.00 + 610 0.0 0:00.00 0:00.00 + 611 0.0 0:00.00 0:00.00 + 612 0.0 0:00.00 0:00.00 + 613 0.0 0:00.00 0:00.00 + 614 0.0 0:00.00 0:00.00 + 615 0.0 0:00.00 0:00.00 + 616 0.0 0:00.00 0:00.00 + 617 0.0 0:00.00 0:00.00 + 618 0.0 0:00.00 0:00.00 + 619 0.0 0:00.00 0:00.00 + 620 0.0 0:00.00 0:00.00 + 621 0.0 0:00.00 0:00.00 + 622 0.0 0:00.00 0:00.00 + 623 0.0 0:00.00 0:00.00 + 624 0.0 0:00.00 0:00.00 + 625 0.0 0:00.00 0:00.00 + 626 0.0 0:00.00 0:00.00 + 627 0.0 0:00.00 0:00.00 + 628 0.0 0:00.00 0:00.00 + 629 0.0 0:00.00 0:00.00 + 630 0.0 0:00.00 0:00.00 + 631 100.3 8:11.86 17:35.07 + 175 0 3 1 1 6 130M 1.08M 0.0 0:03.06 0:33.84 /hurd/term /dev/ptyp0 pty-master /dev/ttyp0 + 0 0.0 0:00.80 0:07.55 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.56 0:05.97 + 3 0.0 0:00.50 0:06.99 + 4 0.0 0:00.56 0:06.99 + 5 0.0 0:00.62 0:06.32 + 176 1000 173 176 176 2 148M 2.19M 0.0 0:00.08 0:00.54 -bash + 0 0.0 0:00.08 0:00.47 + 1 0.0 0:00.00 0:00.07 + 284 1000 1 284 284 2 20.5M 700K 0.0 0:00.00 0:00.00 ssh-agent + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 302 1000 176 302 176 3 148M 1.37M 0.0 0:00.03 0:00.14 screen -S S_main + 0 0.0 0:00.02 0:00.07 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.01 0:00.06 + 304 1000 302 304 304 3 148M 2.45M 0.0 0:02.86 0:13.03 SCREEN -S S_main + 0 0.0 0:02.86 0:12.97 + 1 0.0 0:00.00 0:00.03 + 2 0.0 0:00.00 0:00.02 + 305 1000 3 1 1 5 130M 960K 0.0 0:01.57 0:15.62 /hurd/fifo + 0 0.0 0:00.31 0:04.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.31 0:03.95 + 3 0.0 0:00.45 0:03.78 + 4 0.0 0:00.49 0:03.84 + 306 0 3 1 1 5 130M 1.02M 0.0 0:01.42 0:16.72 /hurd/term /dev/ptyp1 pty-master /dev/ttyp1 + 0 0.0 0:00.43 0:06.13 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.40 0:04.77 + 3 0.0 0:00.00 0:00.14 + 4 0.0 0:00.59 0:05.67 + 309 1000 304 309 309 2 148M 2.12M 0.0 0:00.02 0:00.09 /bin/bash + 0 0.0 0:00.02 0:00.09 + 1 0.0 0:00.00 0:00.00 + 319 1000 309 319 309 2 153M 7.29M 0.0 0:00.33 0:00.74 emacs + 0 0.0 0:00.33 0:00.74 + 1 0.0 0:00.00 0:00.00 + 320 0 3 1 1 6 130M 1.48M 0.0 0:03.25 0:38.79 /hurd/term /dev/ptyp2 pty-master /dev/ttyp2 + 0 0.0 0:00.60 0:07.07 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.69 0:08.43 + 3 0.0 0:00.78 0:07.78 + 4 0.0 0:00.55 0:07.98 + 5 0.0 0:00.60 0:07.52 + 323 1000 304 323 323 2 148M 2.19M 0.0 0:00.12 0:00.60 /bin/bash + 0 0.0 0:00.12 0:00.54 + 1 0.0 0:00.00 0:00.06 + 411 0 3 1 1 5 130M 1.02M 0.0 0:01.17 0:16.40 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:00.42 0:03.74 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.15 0:02.70 + 3 0.0 0:00.24 0:05.48 + 4 0.0 0:00.33 0:04.45 + 414 1000 304 414 414 2 148M 2.13M 0.0 0:00.05 0:00.23 /bin/bash + 0 0.0 0:00.04 0:00.21 + 1 0.0 0:00.00 0:00.02 + 425 0 3 1 1 3 130M 872K 0.0 0:00.02 0:00.05 /hurd/proxy-defpager + 0 0.0 0:00.02 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.01 + 3087 0 3 1 1 5 130M 1.02M 0.0 0:00.23 0:01.39 /hurd/term /dev/ptyp4 pty-master /dev/ttyp4 + 0 0.0 0:00.05 0:00.39 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.07 0:00.43 + 3 0.0 0:00.07 0:00.31 + 4 0.0 0:00.04 0:00.26 + 3648 0 3 1 1 3 130M 876K 0.0 0:00.00 0:00.05 /hurd/crash --kill + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 5512 0 3 1 1 5 130M 1.01M 0.0 0:00.05 0:00.70 /hurd/term /dev/ptyp5 pty-master /dev/ttyp5 + 0 0.0 0:00.00 0:00.26 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.03 0:00.16 + 3 0.0 0:00.02 0:00.14 + 4 0.0 0:00.00 0:00.14 + 10286 1000 323 10286 323 2 135M 1.28M 0.0 0:00.06 0:00.20 make + 0 0.0 0:00.06 0:00.20 + 1 0.0 0:00.00 0:00.00 + 10287 1000 323 10286 323 2 147M 884K 0.0 0:00.00 0:00.33 tee standard output L_ LC_PAPER=en_US.utf8 LC_ADDRESS=en_US.utf8 SSH_AGENT_PID=284 LC_MONETARY= + [165CM=en_US.utf8 SP_REPLACE_LINKS=n SHELL=/bin/bash TERM=screen SP_STOP_AFTER=build HISTSIZE=10000 SSH_CLIENT=192.168.10.60 55972 22 LC_NUMERIC=en_US.utf8 OLDPWD=/home/tsch + [165CMhwinge SSH_TTY=/dev/ttyp0 USER=tschwinge HISTFILESIZE=10000 LD_LIBRARY_PATH= LC_TELEPHONE=en_US.utf8 SP_COMPAT=n LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01; + [165CM;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=0 + [165CM01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31: + [165CM:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35 + [165CM5:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=0 + [165CM01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm + [165CMm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.an + [165CMnx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*. + [165CM.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: SSH_AUTH_SOCK=/home/tschwinge/.ssh/auth_sock.grubber.bddebian.com TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal + [165CMl:\^K^J:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\^K^J:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\^K^J:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH + [165CMH:up=\EM:\^K^J:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\^K^J:li#50:co#166:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\^K^J:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E + [165CME[P:DC=\E[%dP:\^K^J:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\^K^J:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\^K^J:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E + [165CME[24m:so=\E[3m:\^K^J:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\^K^J:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\^K^J:vb=\Eg:G0:as=\E(0:ae=\E(B:\^K^J:ac=\1 + [165CM140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\^K^J:po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\^K^J:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E + [165CME[18~:k8=\E[19~:\^K^J:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:\^K^J:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:\^K^J:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:k + [165CMkb=\177:K2=\EOE:\^K^J:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:*7=\E[1;2F:\^K^J:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\^K^J:%i=\E[1;2C:kh=\E[1~:@1=\E[ + [165CM[1~:kH=\E[4~:@7=\E[4~:\^K^J:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\^K^J:kr=\EOC:kl=\EOD:km: have_bash_profile=y SPF_SOURCE_DEBUG=y PATH=/home/tschwinge/c + [165CMcommand:/home/tschwinge/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/mail/tschwinge LC_MESSAGES=en_US.utf8 SP_TARDIR=/ + [165CM/home/tschwinge/tmp/source/package STY=304.S_main LC_COLLATE=C LC_IDENTIFICATION=en_US.utf8 SP_FOREIGN_DIR=/home/tschwinge/shared.old/package/host/schwinge.homeip.net/ + [165CM/sp-foreign-snippets/snippets PWD=/home/tschwinge/tmp/emacs/trunk.build _LD_LIBRARY_PATH= EDITOR=emacsclient LANG=en_US.utf8 TZ=Europe/Berlin LC_MEASUREMENT=en_US.utf + [165CMf8 KRB5CCNAME=/tmp/krb5cc.tschwinge HISTCONTROL=ignoreboth HOME=/home/tschwinge SHLVL=2 SPF_COMPAT=n LOGNAME=tschwinge LESS=-M -R CVS_RSH=ssh WINDOW=1 SSH_CONNECTION=1 + [165CM192.168.10.60 55972 192.168.10.63 22 LC_CTYPE=en_US.utf8 LESSOPEN=| /usr/bin/lesspipe %s EMAIL=thomas@schwinge.name ALTERNATE_EDITOR=joe LC_TIME=en_US.utf8 LESSCLOSE=/ + [165CM/usr/bin/lesspipe %s %s SPF_SOURCE_DATA_DIR=/home/tschwinge/shared.old/source/package/misc/spf LC_NAME=en_US.utf8 _=/usr/bin/tee + 0 0.0 0:00.00 0:00.33 + 1 0.0 0:00.00 0:00.00 + 10377 1000 10286 10286 323 2 146M 828K 0.0 0:00.00 0:00.00 /bin/sh -c boot=bootstrap-emacs; \^Kif [ ! -x "src/$boot" ]; then + [165CM \^K cd src; make all \^K CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1' \^K LDFLA + [165CMAGS='-Wl,-znocombreloc ' MAKE='make' BOOTSTRAPEMACS="$boot"; \^Kfi; + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 10378 1000 10377 10286 323 2 135M 1.65M 0.0 0:00.71 0:02.12 make all CC=gcc CFLAGS=-g CPPFLAGS=-DXASSERTS=1 LDFLAGS=-Wl,-znocombreloc MAKE=make BOOTSTRAPE + [165CMEMACS=bootstrap-emacs + 0 0.0 0:00.71 0:01.92 + 1 0.0 0:00.00 0:00.19 + 10770 1000 10378 10286 323 2 146M 852K 0.0 0:00.00 0:00.03 /bin/sh -c if test "no" = "yes"; then \^K ln -f temacs bootstrap-emacs; \^Kelse \^K `/bin/pwd + [165CMd`/temacs --batch --load loadup bootstrap || exit 1; \^K mv -f emacs bootstrap-emacs; \^Kfi + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + 10772 1000 10770 10286 323 3 180M 38.8M 0.0 1:16.35 0:05.27 /media/data/home/tschwinge/tmp/emacs/trunk.build/src/temacs --batch --load loadup bootstrap + 0 0.0 1:16.35 0:05.27 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 10778 1000 304 304 304 2 148M 396K 0.0 0:00.00 0:00.00 SCREEN -S S_main + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 10784 - 160 10784 160 2 146M 672K 0.0 0:00.00 0:00.01 syncfs -s + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 10785 - 160 10785 160 2 146M 672K 0.0 0:00.00 0:00.02 syncfs -s -c /media/data/ + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 10787 0 160 10787 160 2 146M 876K 0.0 0:00.00 0:00.06 ps -Af + 0 0.0 0:00.00 0:00.06 + 1 0.0 0:00.00 0:00.00 + 10795 8 131 6 6 2 147M 1.38M 0.1 0:00.02 0:00.04 /usr/lib/nullmailer/qmqp -d -s mail.schwinge.homeip.net + 0 0.1 0:00.02 0:00.04 + 1 0.0 0:00.00 0:00.00 + 10796 0 160 10796 160 2 146M 1.23M 0.0 0:00.00 0:00.08 ps -F hurd-long -T -M -w -A + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + + [4]+ Done ps -F hurd-long -T -M -w -A + login> + +TH# 631 of PID 174 (which is indeed ext2fs for /media/data) looks very +suspicious, likely together in combination with TH# 1 of PID 2 (GNU Mach), so +likely some IPC ping-pong? + + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc + [...] + 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 + 0 0.0 0:00.00 0:00.00 + 1 92.6 0:00.00 46:33.66 + 2 0.0 0:00.00 0:12.07 + 3 0.0 0:00.00 0:00.05 + 4 0.0 0:00.00 0:00.02 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.01 + [...] + 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.0 1:34.24 6:26.66 + 3 0.0 0:00.04 0:00.31 + [...] + 630 0.0 0:00.00 0:00.00 + 631 100.3 8:11.86 17:35.07 + [...] + +Attaching GDB hangs. Should have used noninvasive mode... + +Having a look again after an hour or two, GNU Mach's thread 1's (system) time +count has gone up to nearly 120 minutes, and ext2fs' thread 631's is up to 12 +minutes user and 26 minutes system time. + +I was able to get another root shell via plain `ssh root@grubber`, and I'm able +to attach GDB in noninvasive mode. Hopefully the first unsuccessful (but still +running) GDB didn't cause any interference. + +Due to differences in [[thread_numbering_of_ps_and_gdb]], GDB's thread 632 +(which is the last one anyways) should be the offending one. GDB's thread 631 +and earlier ones (manually checked down to 600) are sitting in `mach_msg_trap`. + + (gdb) thread apply 632 bt + + Thread 632 (Thread 174.632): + #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 + #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 + #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 + #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 + #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 + #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 + #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 + #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 + #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 + #9 0x00000000 in ?? () + + (gdb) thread apply 632 bt full + + Thread 632 (Thread 174.632): + #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 + No locals. + #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 + err = <value optimized out> + #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 + base = 321454080 + #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 + child = 0x83774a8 + n = <value optimized out> + #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 + t = 0x8377430 + #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 + status = <value optimized out> + pi = 0x0 + link = {thread = 2050, next = 0x0, prevp = 0x2000, notifies = 0x12, interrupted_next = 0x0} + __PRETTY_FUNCTION__ = "internal_demuxer" + lock = -1073758644 + nreqthreads = -1073750240 + totalthreads = 137852072 + bucket = 0x10b1c64 + demuxer = 0x10b01eb <alloc_stack+11> + #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 + request = 0xbfffdf20 + reply = 0xbfffbf10 + mr = 3 + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805f6c0 + lock = 0 + totalthreads = 497 + nreqthreads = 1 + #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 + t = 0x8376bd8 + #9 0x00000000 in ?? () + No symbol table info available. + +May this simply be an out-of-memory situation where Mach won't / can't satisfy +libports / libthreads demand? (Looks like the latter library is currently +creating a new thread.) If yes, should the code be prepared for that? Is it +perhaps prepared (I did not yet have a look), and re-tries again and again? +Why doesn't Mach page out some pages to make memory available? + +This is stock GNU Mach from Git, no patches, configured for Xen domU usage. diff --git a/open_issues/error_message_disk_full.mdwn b/open_issues/error_message_disk_full.mdwn new file mode 100644 index 00000000..f72cd66a --- /dev/null +++ b/open_issues/error_message_disk_full.mdwn @@ -0,0 +1,14 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +IRC, unknown channel, unknown date: + + <antrik> /usr/bin/install: writing `/usr/src/gnumach-20060408.dfsg.1/debian/gnumach-dbg/boot/gnumach': (os/kern) memory error + <antrik> interesting way to tell that the disk is full ;-) diff --git a/open_issues/etc_fstab.mdwn b/open_issues/etc_fstab.mdwn new file mode 100644 index 00000000..eb2a34f9 --- /dev/null +++ b/open_issues/etc_fstab.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +[[!meta title="/etc/fstab"]] + +Even though we don't need a `/etc/fstab` for mounting filesystems +(passive [[hurd/translator]]s to the rescue; they have problems on their +own, see the [[hurd/critique]]), we still need this file for `fsck -a` +and `swapon -a` to function. + +[[!tag open_issue_hurd]] diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn new file mode 100644 index 00000000..47d1560a --- /dev/null +++ b/open_issues/exec.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang + <youpi> support in exec* I meant + + <youpi> now a funny bug: if I disable gzip/bzip2 support from exec + <youpi> trying to run a zero-byte file hangs + +--- + +May want to have a look at using BFD / libiberty/simpleobject. diff --git a/open_issues/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn new file mode 100644 index 00000000..369875fe --- /dev/null +++ b/open_issues/ext2fs_deadlock.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +On 2010-10-26, [[I|tschwinge]]'ve been doing the following: `cp -a +../tmpdir/dump*.o ./` (65 files), changed my mind, hit `C-c`, continued with +`cp -a ../tmpdir/dump*.o ./` (to preserve timestamps), wondered why this takes +so long, hit `C-c` again, then found the FS deadlocked (using no CPU; but +`syncfs -s -c` wouldn't finish, for example). Judging from the files' +timestamps (after rebooting and `fsck`), I would assume that it already hung at +the second `cp`'s time, and the deadlock thus is not due to the second `C-c`, +but due to the first one. + + # gdb /hurd/ext2fs + [...] + (gdb) set noninvasive on + (gdb) attach 177 + [...] + [New Thread 177.535] + Reading symbols [...] + (gdb) info threads + [all the same from 177.535 down to...] + 11 Thread 177.11 0x010e3efc in mach_msg_trap () + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 10 Thread 177.10 0x010e3efc in mach_msg_trap () + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + [doesn't continue with thread 9, but hangs, taking all CPU time] + +New GDB instance, again noninvasive, I'm able to continue. + +Here are backtraces for threads [[1 to 8|bt_1-8]] and [[10 to 535|bt_10-535]], +I didn't succeed to get any information about thread 9 (which thus would +probably be the most interesting one...) -- GDB would always hang when +accessing it, no matter whether noninvasive mode or not. (Didn't have time to +pull the information out of the process' memory manually (how to do that, +anyways?), and also didn't have time to continue with debugging GDB itself, but +this sounds like a [[!taglink open_issue_gdb]]...) + +--- + +IRC, #hurd, 2010-10-27 + + <youpi> thread 8 hung on ports_begin_rpc + <youpi> that's probably where one could investigated first + <youpi> yes, a lot of threads are hung on that + <tschwinge> You mean 0x10b9488, right? + <youpi> yes diff --git a/open_issues/ext2fs_deadlock/bt_1-8 b/open_issues/ext2fs_deadlock/bt_1-8 new file mode 100644 index 00000000..f3045fb4 --- /dev/null +++ b/open_issues/ext2fs_deadlock/bt_1-8 @@ -0,0 +1,88 @@ + +Thread 1 (Thread 177.1): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x131fd54, option=2, send_size=0, rcv_size=24, rcv_name=10, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af2d8 in condition_wait (c=0x10b1e80, m=0x10b1e50) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:783 +#4 0x010afc7f in cthread_exit (result=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:393 +#5 0x0804e9e5 in main (argc=2, argv=0x131fec4) at /home/sthibaul-guest/hurd-debian/./ext2fs/ext2fs.c:204 + +Thread 2 (Thread 177.2): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x132df20, option=3, send_size=40, rcv_size=4096, rcv_name=12, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x10f5930 <msgport_server>, max_size=4096, rcv_name=12, option=0, timeout=0) at msgserver.c:151 +#3 0x010e4efb in __mach_msg_server (demux=0x10f5930 <msgport_server>, max_size=4096, rcv_name=12) at msgserver.c:196 +#4 0x010f58ff in _hurd_msgport_receive () at msgportdemux.c:68 +#5 0x010b0058 in cthread_body (self=0x805ed38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#6 0x00000000 in ?? () + +Thread 3 (Thread 177.3): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x133bd18, option=2, send_size=0, rcv_size=24, rcv_name=22, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x133be70, outheadp=0x133de80) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=1) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b4fc7 in ports_manage_port_operations_multithread (bucket=0x805f6c0, demuxer=0x103d9b0 <diskfs_demuxer>, hook=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:164 +#9 0x0104b256 in master_thread_function (demuxer=0x103d9b0) at /home/sthibaul-guest/hurd-debian/./libdiskfs/init-first.c:37 +#10 0x010b0058 in cthread_body (self=0x805f800) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#11 0x00000000 in ?? () + +Thread 4 (Thread 177.4): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x134de80, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=1) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b4fc7 in ports_manage_port_operations_multithread (bucket=0x805f8f0, demuxer=0x105ad80 <pager_demuxer>, hook=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:164 +#5 0x01041904 in service_paging_requests (arg=0x805f8f0) at /home/sthibaul-guest/hurd-debian/./libdiskfs/disk-pager.c:41 +#6 0x010b0058 in cthread_body (self=0x805f9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#7 0x00000000 in ?? () + +Thread 5 (Thread 177.5): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x135df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8060a40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 6 (Thread 177.6): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x136bbb8, option=2, send_size=0, rcv_size=24, rcv_name=34, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8292d98) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11852, seqno=93, control=4806, offset=0, data=83726336, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11852, seqno=93, control=4806, offset=0, data=83726336, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x136df20, OutHeadP=0x136bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x136df20, outp=0x136bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x136df20, outheadp=0x136bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x80614f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 7 (Thread 177.7): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x137bdb8, option=2, send_size=0, rcv_size=24, rcv_name=38, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x137df20, outheadp=0x137bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8061d88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 8 (Thread 177.8): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x138fe80, option=2, send_size=0, rcv_size=24, rcv_name=44, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4b48 in ports_begin_rpc (portstruct=0x80625a0, msg_id=0, info=0x138ff68) at /home/sthibaul-guest/hurd-debian/./libports/begin-rpc.c:33 +#5 0x01052c15 in periodic_sync (interval=5) at /home/sthibaul-guest/hurd-debian/./libdiskfs/sync-interval.c:100 +#6 0x010b0058 in cthread_body (self=0x8062698) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#7 0x00000000 in ?? () diff --git a/open_issues/ext2fs_deadlock/bt_10-535 b/open_issues/ext2fs_deadlock/bt_10-535 new file mode 100644 index 00000000..79ed145a --- /dev/null +++ b/open_issues/ext2fs_deadlock/bt_10-535 @@ -0,0 +1,5240 @@ + +Thread 10 (Thread 177.10): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13adf20, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 11 (Thread 177.11): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=87, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13bdf20, outheadp=0x13bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x806b578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 12 (Thread 177.12): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8069bf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 13 (Thread 177.13): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806a4e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 14 (Thread 177.14): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 15 (Thread 177.15): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=46, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13fdf20, outheadp=0x13fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8070e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 16 (Thread 177.16): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x140bbb8, option=2, send_size=0, rcv_size=24, rcv_name=165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35c80) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1, initializing=0) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x140df20, OutHeadP=0x140bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x140df20, outp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x140df20, outheadp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8070f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 17 (Thread 177.17): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x141bdb8, option=2, send_size=0, rcv_size=24, rcv_name=159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x141df20, outheadp=0x141bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80731b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 18 (Thread 177.18): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x142bdb8, option=2, send_size=0, rcv_size=24, rcv_name=175, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x142bf10, outheadp=0x142df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8073f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 19 (Thread 177.19): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x143df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8070df8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 20 (Thread 177.20): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x144df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073c60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 21 (Thread 177.21): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x145df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 22 (Thread 177.22): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x146df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073af0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 23 (Thread 177.23): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x147bbb8, option=2, send_size=0, rcv_size=24, rcv_name=187, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260de8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1, initializing=0) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x147df20, OutHeadP=0x147bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x147df20, outp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x147df20, outheadp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +Quit + +Thread 10 (Thread 177.10): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13adf20, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 11 (Thread 177.11): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=87, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13bdf20, outheadp=0x13bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x806b578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 12 (Thread 177.12): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8069bf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 13 (Thread 177.13): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806a4e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 14 (Thread 177.14): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 15 (Thread 177.15): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=46, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13fdf20, outheadp=0x13fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8070e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 16 (Thread 177.16): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x140bbb8, option=2, send_size=0, rcv_size=24, rcv_name=165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35c80) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x140df20, OutHeadP=0x140bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x140df20, outp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x140df20, outheadp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8070f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 17 (Thread 177.17): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x141bdb8, option=2, send_size=0, rcv_size=24, rcv_name=159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x141df20, outheadp=0x141bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80731b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 18 (Thread 177.18): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x142bdb8, option=2, send_size=0, rcv_size=24, rcv_name=175, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x142bf10, outheadp=0x142df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8073f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 19 (Thread 177.19): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x143df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8070df8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 20 (Thread 177.20): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x144df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073c60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 21 (Thread 177.21): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x145df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 22 (Thread 177.22): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x146df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073af0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 23 (Thread 177.23): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x147bbb8, option=2, send_size=0, rcv_size=24, rcv_name=187, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260de8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x147df20, OutHeadP=0x147bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x147df20, outp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x147df20, outheadp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8071588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 24 (Thread 177.24): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x148df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80716e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 25 (Thread 177.25): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x149df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071838) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 26 (Thread 177.26): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 27 (Thread 177.27): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8074d80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 28 (Thread 177.28): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14cbc6c, option=3, send_size=24, rcv_size=32, rcv_name=209, timeout=0, notify=0) at msg.c:110 +#2 0x012d73dc in __thread_suspend (target_thread=66) at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/RPC_thread_suspend.c:85 +#3 0x01100e07 in hurd_thread_cancel (thread=66) at thread-cancel.c:57 +#4 0x010b5b2a in ports_interrupt_rpcs (portstruct=0x8137000) at /home/sthibaul-guest/hurd-debian/./libports/interrupt-rpcs.c:35 +#5 0x010b6434 in ports_S_interrupt_operation (port=11806, seqno=7) at /home/sthibaul-guest/hurd-debian/./libports/interrupt-operation.c:37 +#6 0x010b7a40 in _Xinterrupt_operation (InHeadP=0x14cdf20, OutHeadP=0x14cbf10) at interruptServer.c:74 +#7 0x010b79b4 in ports_interrupt_server (InHeadP=0xd1, OutHeadP=0xffffffe7) at interruptServer.c:113 +#8 0x0103da44 in diskfs_demuxer (inp=0x14cdf20, outp=0x14cbf10) at /home/sthibaul-guest/hurd-debian/./libdiskfs/demuxer.c:38 +#9 0x010b5163 in internal_demuxer (inp=0x14cdf20, outheadp=0x14cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#10 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#11 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#12 0x010b0058 in cthread_body (self=0x8079e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#13 0x00000000 in ?? () + +Thread 29 (Thread 177.29): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=294, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4812, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x14ddf20, outheadp=0x14dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807fee0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 30 (Thread 177.30): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=297, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11858, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x14edf20, outheadp=0x14ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807f960) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 31 (Thread 177.31): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x807f0a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 32 (Thread 177.32): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x150bdb8, option=2, send_size=0, rcv_size=24, rcv_name=312, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6314, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x150df20, outheadp=0x150bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807b5d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 33 (Thread 177.33): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x151bdb8, option=2, send_size=0, rcv_size=24, rcv_name=315, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11858, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x151df20, outheadp=0x151bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8079d88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 34 (Thread 177.34): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x152df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8082708) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 35 (Thread 177.35): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x153df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8082f60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 36 (Thread 177.36): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x154bdb8, option=2, send_size=0, rcv_size=24, rcv_name=324, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5360, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x154df20, outheadp=0x154bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80837b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 37 (Thread 177.37): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x155df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8084010) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 38 (Thread 177.38): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x156bdb8, option=2, send_size=0, rcv_size=24, rcv_name=330, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6765, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x156df20, outheadp=0x156bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8084868) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 39 (Thread 177.39): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x157df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80850c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 40 (Thread 177.40): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x158df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8085918) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 41 (Thread 177.41): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x159df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8086170) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 42 (Thread 177.42): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15abdb8, option=2, send_size=0, rcv_size=24, rcv_name=342, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=12846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x15adf20, outheadp=0x15abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80869c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 43 (Thread 177.43): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8087220) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 44 (Thread 177.44): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8087a78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 45 (Thread 177.45): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=351, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11872, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x15ddf20, outheadp=0x15dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80882d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 46 (Thread 177.46): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8088b28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 47 (Thread 177.47): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8089380) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 48 (Thread 177.48): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x160bdb8, option=2, send_size=0, rcv_size=24, rcv_name=360, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6518, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x160df20, outheadp=0x160bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8089bd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 49 (Thread 177.49): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x161bdb8, option=2, send_size=0, rcv_size=24, rcv_name=363, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5340, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x161df20, outheadp=0x161bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808a430) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 50 (Thread 177.50): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x162bdb8, option=2, send_size=0, rcv_size=24, rcv_name=366, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x162df20, outheadp=0x162bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808ac88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 51 (Thread 177.51): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x163df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808b4e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 52 (Thread 177.52): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x164df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808bd38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 53 (Thread 177.53): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x165df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808c590) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 54 (Thread 177.54): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x166df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808cde8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 55 (Thread 177.55): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x167bdb8, option=2, send_size=0, rcv_size=24, rcv_name=381, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4864, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x167df20, outheadp=0x167bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808d640) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 56 (Thread 177.56): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x168df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808de98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 57 (Thread 177.57): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x169df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808e6f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 58 (Thread 177.58): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808ef48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 59 (Thread 177.59): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=393, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5339, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16bdf20, outheadp=0x16bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808f7a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 60 (Thread 177.60): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=396, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6731, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16cdf20, outheadp=0x16cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808fff8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 61 (Thread 177.61): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=399, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4785, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16ddf20, outheadp=0x16dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8090850) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 62 (Thread 177.62): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=402, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11824, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16edf20, outheadp=0x16ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80910a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 63 (Thread 177.63): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=405, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11863, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16fdf20, outheadp=0x16fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8091900) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 64 (Thread 177.64): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x170df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8092158) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 65 (Thread 177.65): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x171df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80929b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 66 (Thread 177.66): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x172bdb8, option=2, send_size=0, rcv_size=24, rcv_name=414, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11855, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x172df20, outheadp=0x172bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8093208) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 67 (Thread 177.67): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x173bdb8, option=2, send_size=0, rcv_size=24, rcv_name=417, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6308, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x173df20, outheadp=0x173bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8093a60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 68 (Thread 177.68): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x174bdb8, option=2, send_size=0, rcv_size=24, rcv_name=420, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4830, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x174df20, outheadp=0x174bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80942b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 69 (Thread 177.69): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x175bdb8, option=2, send_size=0, rcv_size=24, rcv_name=423, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11875, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x175df20, outheadp=0x175bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8094b10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 70 (Thread 177.70): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x176bdb8, option=2, send_size=0, rcv_size=24, rcv_name=426, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6876, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x176df20, outheadp=0x176bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8095368) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 71 (Thread 177.71): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x177bdb8, option=2, send_size=0, rcv_size=24, rcv_name=429, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5321, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x177df20, outheadp=0x177bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8095bc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 72 (Thread 177.72): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x178df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8096418) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 73 (Thread 177.73): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x179df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8096c70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 74 (Thread 177.74): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80974c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 75 (Thread 177.75): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8097d20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 76 (Thread 177.76): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8098578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 77 (Thread 177.77): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8098dd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 78 (Thread 177.78): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=450, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4859, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x17edf20, outheadp=0x17ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8099628) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 79 (Thread 177.79): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8099e80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 80 (Thread 177.80): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x180bdb8, option=2, send_size=0, rcv_size=24, rcv_name=456, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6876, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x180df20, outheadp=0x180bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809a6d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 81 (Thread 177.81): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x181df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809af30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 82 (Thread 177.82): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x182df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809b788) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 83 (Thread 177.83): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x183df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809bfe0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 84 (Thread 177.84): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x184df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809c838) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 85 (Thread 177.85): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x185bdb8, option=2, send_size=0, rcv_size=24, rcv_name=471, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4834, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x185df20, outheadp=0x185bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809d090) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 86 (Thread 177.86): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x186bdb8, option=2, send_size=0, rcv_size=24, rcv_name=474, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4845, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x186df20, outheadp=0x186bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809d8e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 87 (Thread 177.87): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x187bbb8, option=2, send_size=0, rcv_size=24, rcv_name=477, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a450d8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11860, seqno=93, control=11864, offset=0, data=82976768, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11860, seqno=93, control=11864, offset=0, data=82976768, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x187df20, OutHeadP=0x187bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x187df20, outp=0x187bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x187df20, outheadp=0x187bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x809e140) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 88 (Thread 177.88): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x188bdb8, option=2, send_size=0, rcv_size=24, rcv_name=480, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6778, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x188df20, outheadp=0x188bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809e998) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 89 (Thread 177.89): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x189df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809f1f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 90 (Thread 177.90): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18abdb8, option=2, send_size=0, rcv_size=24, rcv_name=486, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4959, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x18adf20, outheadp=0x18abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809fa48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 91 (Thread 177.91): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a02a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 92 (Thread 177.92): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18cbc48, option=2, send_size=0, rcv_size=24, rcv_name=492, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473816, control=28, offset=2453504, data=14823424, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473816, control=28, offset=2453504, data=14823424, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x18cdf20, OutHeadP=0x18cbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x18cdf20, outp=0x18cbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x18cdf20, outheadp=0x18cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x80a0af8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 93 (Thread 177.93): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a1350) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 94 (Thread 177.94): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a1ba8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 95 (Thread 177.95): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a2400) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 96 (Thread 177.96): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x190bdb8, option=2, send_size=0, rcv_size=24, rcv_name=504, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4851, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x190df20, outheadp=0x190bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a2c58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 97 (Thread 177.97): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x191df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a34b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 98 (Thread 177.98): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x192df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a3d08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 99 (Thread 177.99): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x193df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a4560) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 100 (Thread 177.100): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x194bdb8, option=2, send_size=0, rcv_size=24, rcv_name=516, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11837, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x194df20, outheadp=0x194bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a4db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 101 (Thread 177.101): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x195df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a5610) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 102 (Thread 177.102): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x196df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a5e68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 103 (Thread 177.103): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x197df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a66c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 104 (Thread 177.104): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x198df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a6f18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 105 (Thread 177.105): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x199bdb8, option=2, send_size=0, rcv_size=24, rcv_name=531, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5402, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x199df20, outheadp=0x199bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a7770) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 106 (Thread 177.106): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19abdb8, option=2, send_size=0, rcv_size=24, rcv_name=534, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11872, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x19adf20, outheadp=0x19abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a7fc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 107 (Thread 177.107): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a8820) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 108 (Thread 177.108): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a9078) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 109 (Thread 177.109): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a98d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 110 (Thread 177.110): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80aa128) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 111 (Thread 177.111): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8075b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 112 (Thread 177.112): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ab848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 113 (Thread 177.113): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ae9a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 114 (Thread 177.114): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ac0f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 115 (Thread 177.115): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x807f030) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 116 (Thread 177.116): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b2ae0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 117 (Thread 177.117): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b2b28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 118 (Thread 177.118): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b5e78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 119 (Thread 177.119): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b66d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 120 (Thread 177.120): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b6f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 121 (Thread 177.121): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b7780) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 122 (Thread 177.122): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1aabdb8, option=2, send_size=0, rcv_size=24, rcv_name=692, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5327, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1aadf20, outheadp=0x1aabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b7fd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 123 (Thread 177.123): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1abbdb8, option=2, send_size=0, rcv_size=24, rcv_name=695, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1abdf20, outheadp=0x1abbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b8830) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 124 (Thread 177.124): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1acbdb8, option=2, send_size=0, rcv_size=24, rcv_name=698, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5595, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1acdf20, outheadp=0x1acbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b9088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 125 (Thread 177.125): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1addf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b98e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 126 (Thread 177.126): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1aebdb8, option=2, send_size=0, rcv_size=24, rcv_name=704, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6972, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1aedf20, outheadp=0x1aebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80ba138) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 127 (Thread 177.127): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1afdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ba990) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 128 (Thread 177.128): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=710, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11847, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1b0df20, outheadp=0x1b0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80bb1e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 129 (Thread 177.129): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bba40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 130 (Thread 177.130): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bc298) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 131 (Thread 177.131): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bcaf0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 132 (Thread 177.132): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bd348) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 133 (Thread 177.133): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bdba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 134 (Thread 177.134): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80be3f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 135 (Thread 177.135): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bec50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 136 (Thread 177.136): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b8bdb8, option=2, send_size=0, rcv_size=24, rcv_name=734, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4785, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1b8df20, outheadp=0x1b8bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80bf4a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 137 (Thread 177.137): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bfd00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 138 (Thread 177.138): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1badf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c0558) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 139 (Thread 177.139): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=743, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=13223, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1bbdf20, outheadp=0x1bbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80c0db0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 140 (Thread 177.140): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bcdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c1608) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 141 (Thread 177.141): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c1e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 142 (Thread 177.142): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c26b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 143 (Thread 177.143): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81198b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 144 (Thread 177.144): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81196f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 145 (Thread 177.145): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8119848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 146 (Thread 177.146): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8117318) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 147 (Thread 177.147): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8115880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 148 (Thread 177.148): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11826, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1c4df20, outheadp=0x1c4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81199c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 149 (Thread 177.149): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8115600) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 150 (Thread 177.150): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8118b18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 151 (Thread 177.151): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2168, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6298, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1c7df20, outheadp=0x1c7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81197b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 152 (Thread 177.152): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8119ba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 153 (Thread 177.153): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x811d050) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 154 (Thread 177.154): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2177, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6298, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cadf20, outheadp=0x1cabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811d8a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 155 (Thread 177.155): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2180, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5340, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cbdf20, outheadp=0x1cbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811e100) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 156 (Thread 177.156): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ccbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2183, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4830, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ccdf20, outheadp=0x1ccbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811e958) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 157 (Thread 177.157): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cdbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2186, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5321, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cddf20, outheadp=0x1cdbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811f1b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 158 (Thread 177.158): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x811fa08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 159 (Thread 177.159): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8120260) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 160 (Thread 177.160): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8120ab8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 161 (Thread 177.161): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d1bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2198, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d1df20, outheadp=0x1d1bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8121310) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 162 (Thread 177.162): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8121b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 163 (Thread 177.163): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2204, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5883, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d3df20, outheadp=0x1d3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81223c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 164 (Thread 177.164): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2207, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d4df20, outheadp=0x1d4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8122c18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 165 (Thread 177.165): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8123470) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 166 (Thread 177.166): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8123cc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 167 (Thread 177.167): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d7bbb8, option=2, send_size=0, rcv_size=24, rcv_name=2216, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8133588) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6841, seqno=93, control=11809, offset=0, data=66523136, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6841, seqno=93, control=11809, offset=0, data=66523136, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1d7df20, OutHeadP=0x1d7bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1d7df20, outp=0x1d7bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1d7df20, outheadp=0x1d7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8124520) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 168 (Thread 177.168): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8124d78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 169 (Thread 177.169): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81255d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 170 (Thread 177.170): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2225, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11849, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dadf20, outheadp=0x1dabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8125e28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 171 (Thread 177.171): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8126680) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 172 (Thread 177.172): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dcbc48, option=2, send_size=0, rcv_size=24, rcv_name=2231, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473817, control=28, offset=4096, data=14979072, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473817, control=28, offset=4096, data=14979072, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1dcdf20, OutHeadP=0x1dcbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1dcdf20, outp=0x1dcbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1dcdf20, outheadp=0x1dcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8126ed8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 173 (Thread 177.173): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8127730) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 174 (Thread 177.174): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1debdb8, option=2, send_size=0, rcv_size=24, rcv_name=2237, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11878, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dedf20, outheadp=0x1debf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8127f88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 175 (Thread 177.175): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dfbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2240, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11869, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dfdf20, outheadp=0x1dfbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81287e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 176 (Thread 177.176): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8129038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 177 (Thread 177.177): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8129890) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 178 (Thread 177.178): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e2bbd8, option=2, send_size=0, rcv_size=24, rcv_name=2249, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82c8510) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11826, seqno=66, control=4763, offset=32768, data=66375680, length=98304, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11826, seqno=66, control=4763, offset=32768, data=66375680, length=98304, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1e2df20, OutHeadP=0x1e2bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x17, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1e2df20, outp=0x1e2bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1e2df20, outheadp=0x1e2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x812a0e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 179 (Thread 177.179): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x812a940) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 180 (Thread 177.180): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159660) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 181 (Thread 177.181): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814c4c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 182 (Thread 177.182): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8137e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 183 (Thread 177.183): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x813f2a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 184 (Thread 177.184): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8154568) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 185 (Thread 177.185): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e9bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2967, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11843, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1e9df20, outheadp=0x1e9bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8151aa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 186 (Thread 177.186): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1eabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2970, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11816, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1eadf20, outheadp=0x1eabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814aaa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 187 (Thread 177.187): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ebbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2973, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11855, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ebdf20, outheadp=0x1ebbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80f1e70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 188 (Thread 177.188): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ecbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2976, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4939, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ecdf20, outheadp=0x1ecbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814ee10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 189 (Thread 177.189): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1edbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2979, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6526, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1eddf20, outheadp=0x1edbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8135588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 190 (Thread 177.190): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1eedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8140a08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 191 (Thread 177.191): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1efdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f27e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 192 (Thread 177.192): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x813db08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 193 (Thread 177.193): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f1bbb8, option=2, send_size=0, rcv_size=24, rcv_name=2991, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8306a00) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4845, seqno=93, control=5059, offset=0, data=82788352, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4845, seqno=93, control=5059, offset=0, data=82788352, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1f1df20, OutHeadP=0x1f1bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1f1df20, outp=0x1f1bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1f1df20, outheadp=0x1f1bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81555c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 194 (Thread 177.194): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f2bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2994, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6765, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f2df20, outheadp=0x1f2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80c99e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 195 (Thread 177.195): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 196 (Thread 177.196): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3000, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f4df20, outheadp=0x1f4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81548f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 197 (Thread 177.197): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3003, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11805, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f5df20, outheadp=0x1f5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8153f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 198 (Thread 177.198): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814ffd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 199 (Thread 177.199): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3009, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5144, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f7df20, outheadp=0x1f7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8151548) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 200 (Thread 177.200): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f8bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3012, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6308, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f8df20, outheadp=0x1f8bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8137480) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 201 (Thread 177.201): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81450d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 202 (Thread 177.202): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fadf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f2fc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 203 (Thread 177.203): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81565c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 204 (Thread 177.204): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fcdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8153f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 205 (Thread 177.205): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814b820) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 206 (Thread 177.206): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8145130) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 207 (Thread 177.207): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ffdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81133e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 208 (Thread 177.208): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x200df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159170) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 209 (Thread 177.209): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x201df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8153628) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 210 (Thread 177.210): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x202df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8133f08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 211 (Thread 177.211): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x203bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3045, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11831, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x203df20, outheadp=0x203bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814f088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 212 (Thread 177.212): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x204df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8151d20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 213 (Thread 177.213): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x205bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3051, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4782, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x205df20, outheadp=0x205bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8154e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 214 (Thread 177.214): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x206bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3054, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a1d690) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4830, seqno=93, control=11851, offset=0, data=84103168, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4830, seqno=93, control=11851, offset=0, data=84103168, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x206df20, OutHeadP=0x206bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x206df20, outp=0x206bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x206df20, outheadp=0x206bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81595f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 215 (Thread 177.215): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x207bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3057, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11866, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x207df20, outheadp=0x207bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8138498) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 216 (Thread 177.216): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x208df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f1bd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 217 (Thread 177.217): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x209df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816a648) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 218 (Thread 177.218): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816aea0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 219 (Thread 177.219): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3069, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4834, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x20bdf20, outheadp=0x20bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x816b6f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 220 (Thread 177.220): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816bf50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 221 (Thread 177.221): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816c7a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 222 (Thread 177.222): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20ebc48, option=2, send_size=0, rcv_size=24, rcv_name=3078, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473819, control=28, offset=0, data=15933440, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473819, control=28, offset=0, data=15933440, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x20edf20, OutHeadP=0x20ebf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x20edf20, outp=0x20ebf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x20edf20, outheadp=0x20ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x816d000) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 223 (Thread 177.223): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816d858) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 224 (Thread 177.224): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x210df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816e0b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 225 (Thread 177.225): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x211bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3087, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4853, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x211df20, outheadp=0x211bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x816e908) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 226 (Thread 177.226): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x212df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816f160) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 227 (Thread 177.227): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x213df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816f9b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 228 (Thread 177.228): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x214bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3096, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6841, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x214df20, outheadp=0x214bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8170210) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 229 (Thread 177.229): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x215bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3099, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6203, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x215df20, outheadp=0x215bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8170a68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 230 (Thread 177.230): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x216bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3102, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6314, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x216df20, outheadp=0x216bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81712c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 231 (Thread 177.231): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x217df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8171b18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 232 (Thread 177.232): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x218bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3108, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5402, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x218df20, outheadp=0x218bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8172370) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 233 (Thread 177.233): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x219df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8172bc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 234 (Thread 177.234): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3114, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5354, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21adf20, outheadp=0x21abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8173420) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 235 (Thread 177.235): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3117, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4787, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21bdf20, outheadp=0x21bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8173c78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 236 (Thread 177.236): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3120, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21cdf20, outheadp=0x21cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81744d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 237 (Thread 177.237): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8174d28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 238 (Thread 177.238): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8175580) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 239 (Thread 177.239): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3129, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11837, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21fdf20, outheadp=0x21fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8175dd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 240 (Thread 177.240): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x220bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3132, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=12846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x220df20, outheadp=0x220bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8176630) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 241 (Thread 177.241): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x221df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8176e88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 242 (Thread 177.242): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x222df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81776e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 243 (Thread 177.243): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x223df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8177f38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 244 (Thread 177.244): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x224bc48, option=2, send_size=0, rcv_size=24, rcv_name=3144, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473818, control=28, offset=2125824, data=15642624, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473818, control=28, offset=2125824, data=15642624, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x224df20, OutHeadP=0x224bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x224df20, outp=0x224bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x224df20, outheadp=0x224bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8178790) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 245 (Thread 177.245): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x225bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3147, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4782, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x225df20, outheadp=0x225bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8178fe8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 246 (Thread 177.246): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x226df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8179840) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 247 (Thread 177.247): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x227df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817a098) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 248 (Thread 177.248): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x228df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817a8f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 249 (Thread 177.249): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x229bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11805, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x229df20, outheadp=0x229bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817b148) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 250 (Thread 177.250): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3162, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11831, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x22adf20, outheadp=0x22abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 251 (Thread 177.251): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817c1f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 252 (Thread 177.252): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817ca50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 253 (Thread 177.253): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817d2a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 254 (Thread 177.254): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3174, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11875, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x22edf20, outheadp=0x22ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817db00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 255 (Thread 177.255): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817e358) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 256 (Thread 177.256): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x230df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817ebb0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 257 (Thread 177.257): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x231df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817f408) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 258 (Thread 177.258): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x232df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817fc60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 259 (Thread 177.259): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x233bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3189, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5963, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x233df20, outheadp=0x233bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81804b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 260 (Thread 177.260): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x234df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8180d10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 261 (Thread 177.261): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x235df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8181568) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 262 (Thread 177.262): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x236df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8181dc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 263 (Thread 177.263): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x237df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8182618) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 264 (Thread 177.264): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x238df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8182e70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 265 (Thread 177.265): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x239bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3207, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4859, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x239df20, outheadp=0x239bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81836c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 266 (Thread 177.266): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8183f20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 267 (Thread 177.267): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8184778) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 268 (Thread 177.268): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8184fd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 269 (Thread 177.269): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8185828) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 270 (Thread 177.270): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8186080) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 271 (Thread 177.271): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81868d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 272 (Thread 177.272): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x240df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8187130) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 273 (Thread 177.273): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x241bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3231, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4814, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x241df20, outheadp=0x241bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8187988) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 274 (Thread 177.274): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x242df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81881e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 275 (Thread 177.275): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x243df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8188a38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 276 (Thread 177.276): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x244df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8189290) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 277 (Thread 177.277): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x245bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3243, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11843, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x245df20, outheadp=0x245bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8189ae8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 278 (Thread 177.278): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x246bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3246, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6517, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x246df20, outheadp=0x246bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818a340) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 279 (Thread 177.279): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x247df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ab98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 280 (Thread 177.280): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x248df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818b3f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 281 (Thread 177.281): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x249bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3255, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5315, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x249df20, outheadp=0x249bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818bc48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 282 (Thread 177.282): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818c4a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 283 (Thread 177.283): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ccf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 284 (Thread 177.284): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818d550) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 285 (Thread 177.285): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818dda8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 286 (Thread 177.286): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818e600) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 287 (Thread 177.287): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3273, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x24fdf20, outheadp=0x24fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818ee58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 288 (Thread 177.288): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x250df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818f6b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 289 (Thread 177.289): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x251df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ff08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 290 (Thread 177.290): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x252df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8190760) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 291 (Thread 177.291): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x253df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8190fb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 292 (Thread 177.292): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x254bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3288, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11852, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x254df20, outheadp=0x254bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8191810) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 293 (Thread 177.293): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x255df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8192068) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 294 (Thread 177.294): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x256bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3294, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5144, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x256df20, outheadp=0x256bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81928c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 295 (Thread 177.295): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x257df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8193118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 296 (Thread 177.296): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x258df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8193970) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 297 (Thread 177.297): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x259df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81941c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 298 (Thread 177.298): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8194a20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 299 (Thread 177.299): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8195278) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 300 (Thread 177.300): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3312, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5339, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25cdf20, outheadp=0x25cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8195ad0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 301 (Thread 177.301): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3315, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=13223, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25ddf20, outheadp=0x25dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8196328) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 302 (Thread 177.302): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8196b80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 303 (Thread 177.303): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3321, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6517, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25fdf20, outheadp=0x25fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81973d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 304 (Thread 177.304): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x260df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8197c30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 305 (Thread 177.305): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x261bcc8, option=2, send_size=0, rcv_size=24, rcv_name=3327, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82c8510) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059a84 in _pager_seqnos_memory_object_data_unlock (object=11826, seqno=68, control=4763, offset=131072, length=4096, access=2) at /home/sthibaul-guest/hurd-debian/./libpager/data-unlock.c:87 +#6 0x0105c1b4 in _Xmemory_object_data_unlock (InHeadP=0x261df20, OutHeadP=0x261bf10) at memory_objectServer.c:467 +#7 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x20000, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#8 0x0105adac in pager_demuxer (inp=0x261df20, outp=0x261bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#9 0x010b5163 in internal_demuxer (inp=0x261df20, outheadp=0x261bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#10 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#11 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#12 0x010b0058 in cthread_body (self=0x8198488) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#13 0x00000000 in ?? () + +Thread 306 (Thread 177.306): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x262bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3330, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11829, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x262df20, outheadp=0x262bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8198ce0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 307 (Thread 177.307): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x263df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8199538) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 308 (Thread 177.308): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x264bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3336, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x264df20, outheadp=0x264bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8199d90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 309 (Thread 177.309): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x265bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3339, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4797, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x265df20, outheadp=0x265bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x819a5e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 310 (Thread 177.310): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x266bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3342, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5883, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x266df20, outheadp=0x266bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x819ae40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 311 (Thread 177.311): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x267df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819b698) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 312 (Thread 177.312): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x268df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819bef0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 313 (Thread 177.313): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x269df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819c748) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 314 (Thread 177.314): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819cfa0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 315 (Thread 177.315): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819d7f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 316 (Thread 177.316): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819e050) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 317 (Thread 177.317): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819e8a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 318 (Thread 177.318): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819f100) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 319 (Thread 177.319): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819f958) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 320 (Thread 177.320): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x270bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3372, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x270df20, outheadp=0x270bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a01b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 321 (Thread 177.321): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x271df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a0a08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 322 (Thread 177.322): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x272df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a1260) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 323 (Thread 177.323): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x273df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a1ab8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 324 (Thread 177.324): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x274bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3384, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11818, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x274df20, outheadp=0x274bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a2310) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 325 (Thread 177.325): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x275bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3387, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11818, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x275df20, outheadp=0x275bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a2b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 326 (Thread 177.326): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x276df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a33c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 327 (Thread 177.327): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x277df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a3c18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 328 (Thread 177.328): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x278df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a4470) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 329 (Thread 177.329): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x279bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3399, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11856, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x279df20, outheadp=0x279bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a4cc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 330 (Thread 177.330): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a5520) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 331 (Thread 177.331): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3405, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5049, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27bdf20, outheadp=0x27bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a5d78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 332 (Thread 177.332): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a65d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 333 (Thread 177.333): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3411, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5127, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27ddf20, outheadp=0x27dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a6e28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 334 (Thread 177.334): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3414, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6203, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27edf20, outheadp=0x27ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a7680) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 335 (Thread 177.335): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a7ed8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 336 (Thread 177.336): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x280bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3420, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11878, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x280df20, outheadp=0x280bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a8730) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 337 (Thread 177.337): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x281df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a8f88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 338 (Thread 177.338): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x282bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3426, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3aa2370) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=10039, seqno=93, control=9839, offset=0, data=85422080, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=10039, seqno=93, control=9839, offset=0, data=85422080, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x282df20, OutHeadP=0x282bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x282df20, outp=0x282bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x282df20, outheadp=0x282bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81a97e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 339 (Thread 177.339): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x283df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aa038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 340 (Thread 177.340): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x284df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aa890) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 341 (Thread 177.341): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x285bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3435, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5963, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x285df20, outheadp=0x285bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ab0e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 342 (Thread 177.342): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x286df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ab940) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 343 (Thread 177.343): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x287df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ac198) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 344 (Thread 177.344): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x288df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ac9f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 345 (Thread 177.345): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x289bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3447, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x289df20, outheadp=0x289bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ad248) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 346 (Thread 177.346): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81adaa0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 347 (Thread 177.347): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ae2f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 348 (Thread 177.348): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aeb50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 349 (Thread 177.349): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81af3a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 350 (Thread 177.350): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81afc00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 351 (Thread 177.351): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b0458) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 352 (Thread 177.352): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x290df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b0cb0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 353 (Thread 177.353): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x291df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b1508) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 354 (Thread 177.354): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x292df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b1d60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 355 (Thread 177.355): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x293df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b25b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 356 (Thread 177.356): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x294bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3480, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35f50) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4864, seqno=93, control=11880, offset=0, data=81281024, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4864, seqno=93, control=11880, offset=0, data=81281024, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x294df20, OutHeadP=0x294bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x294df20, outp=0x294bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x294df20, outheadp=0x294bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81b2e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 357 (Thread 177.357): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x295df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b3668) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 358 (Thread 177.358): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x296df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b3ec0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 359 (Thread 177.359): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x297df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b4718) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 360 (Thread 177.360): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x298bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3492, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82156d0) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11818, seqno=93, control=11814, offset=0, data=84856832, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11818, seqno=93, control=11814, offset=0, data=84856832, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x298df20, OutHeadP=0x298bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x298df20, outp=0x298bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x298df20, outheadp=0x298bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81b4f70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 361 (Thread 177.361): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x299bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3495, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11888, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x299df20, outheadp=0x299bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81b57c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 362 (Thread 177.362): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b6020) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 363 (Thread 177.363): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b6878) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 364 (Thread 177.364): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b70d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 365 (Thread 177.365): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b7928) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 366 (Thread 177.366): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b8180) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 367 (Thread 177.367): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b89d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 368 (Thread 177.368): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b9230) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 369 (Thread 177.369): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b9a88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 370 (Thread 177.370): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a2bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3522, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11829, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a2df20, outheadp=0x2a2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ba2e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 371 (Thread 177.371): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3525, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11856, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a3df20, outheadp=0x2a3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bab38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 372 (Thread 177.372): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bb390) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 373 (Thread 177.373): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3531, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4873, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a5df20, outheadp=0x2a5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bbbe8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 374 (Thread 177.374): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a6bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3534, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a6df20, outheadp=0x2a6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bc440) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 375 (Thread 177.375): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bcc98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 376 (Thread 177.376): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bd4f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 377 (Thread 177.377): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bdd48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 378 (Thread 177.378): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2aadf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81be5a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 379 (Thread 177.379): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2abdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bedf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 380 (Thread 177.380): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2acbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3552, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11819, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2acdf20, outheadp=0x2acbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bf650) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 381 (Thread 177.381): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2addf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bfea8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 382 (Thread 177.382): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2aedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c0700) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 383 (Thread 177.383): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2afbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3561, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4845, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2afdf20, outheadp=0x2afbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c0f58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 384 (Thread 177.384): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3564, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6972, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b0df20, outheadp=0x2b0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c17b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 385 (Thread 177.385): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c2008) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 386 (Thread 177.386): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c2860) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 387 (Thread 177.387): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3573, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4959, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b3df20, outheadp=0x2b3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c30b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 388 (Thread 177.388): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c3910) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 389 (Thread 177.389): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b5bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3579, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a1d730) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11847, seqno=93, control=6869, offset=0, data=84291584, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11847, seqno=93, control=6869, offset=0, data=84291584, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2b5df20, OutHeadP=0x2b5bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2b5df20, outp=0x2b5bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2b5df20, outheadp=0x2b5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81c4168) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 390 (Thread 177.390): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c49c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 391 (Thread 177.391): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3585, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11819, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b7df20, outheadp=0x2b7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c5218) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 392 (Thread 177.392): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c5a70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 393 (Thread 177.393): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b9bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3591, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11866, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b9df20, outheadp=0x2b9bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c62c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 394 (Thread 177.394): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2badf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c6b20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 395 (Thread 177.395): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c7378) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 396 (Thread 177.396): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3600, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11869, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2bcdf20, outheadp=0x2bcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c7bd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 397 (Thread 177.397): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c8428) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 398 (Thread 177.398): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c8c80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 399 (Thread 177.399): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c94d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 400 (Thread 177.400): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c9d30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 401 (Thread 177.401): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ca588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 402 (Thread 177.402): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cade0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 403 (Thread 177.403): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3621, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c3df20, outheadp=0x2c3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cb638) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 404 (Thread 177.404): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cbe90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 405 (Thread 177.405): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3627, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5360, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c5df20, outheadp=0x2c5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cc6e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 406 (Thread 177.406): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c6bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3630, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82b1050) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11824, seqno=93, control=5619, offset=0, data=84668416, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11824, seqno=93, control=5619, offset=0, data=84668416, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2c6df20, OutHeadP=0x2c6bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2c6df20, outp=0x2c6bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2c6df20, outheadp=0x2c6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81ccf40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 407 (Thread 177.407): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3633, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5288, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c7df20, outheadp=0x2c7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cd798) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 408 (Thread 177.408): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cdff0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 409 (Thread 177.409): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ce848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 410 (Thread 177.410): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3642, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4812, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cadf20, outheadp=0x2cabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cf0a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 411 (Thread 177.411): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3645, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5595, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cbdf20, outheadp=0x2cbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cf8f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 412 (Thread 177.412): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ccbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3648, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8318a20) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6778, seqno=93, control=4919, offset=0, data=67067904, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6778, seqno=93, control=4919, offset=0, data=67067904, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2ccdf20, OutHeadP=0x2ccbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2ccdf20, outp=0x2ccbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2ccdf20, outheadp=0x2ccbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81d0150) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 413 (Thread 177.413): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d09a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 414 (Thread 177.414): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d1200) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 415 (Thread 177.415): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cfbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3657, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4939, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cfdf20, outheadp=0x2cfbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d1a58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 416 (Thread 177.416): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d22b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 417 (Thread 177.417): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d2b08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 418 (Thread 177.418): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d3360) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 419 (Thread 177.419): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d3bb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 420 (Thread 177.420): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3672, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5354, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2d4df20, outheadp=0x2d4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d4410) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 421 (Thread 177.421): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d4c68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 422 (Thread 177.422): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d54c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 423 (Thread 177.423): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d5d18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 424 (Thread 177.424): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d6570) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 425 (Thread 177.425): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d6dc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 426 (Thread 177.426): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3690, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5288, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2dadf20, outheadp=0x2dabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d7620) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 427 (Thread 177.427): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d7e78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 428 (Thread 177.428): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3696, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5127, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2dcdf20, outheadp=0x2dcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d86d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 429 (Thread 177.429): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d8f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 430 (Thread 177.430): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d9780) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 431 (Thread 177.431): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d9fd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 432 (Thread 177.432): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3708, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4797, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2e0df20, outheadp=0x2e0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81da830) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 433 (Thread 177.433): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81db088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 434 (Thread 177.434): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81db8e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 435 (Thread 177.435): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81dc138) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 436 (Thread 177.436): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e4bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3720, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x835c670) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11829, seqno=93, control=11823, offset=0, data=84480000, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11829, seqno=93, control=11823, offset=0, data=84480000, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2e4df20, OutHeadP=0x2e4bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2e4df20, outp=0x2e4bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2e4df20, outheadp=0x2e4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81dc990) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 437 (Thread 177.437): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81dd1e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 438 (Thread 177.438): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e6bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3726, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4814, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2e6df20, outheadp=0x2e6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81dda40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 439 (Thread 177.439): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81de298) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 440 (Thread 177.440): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81deaf0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 441 (Thread 177.441): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81df348) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 442 (Thread 177.442): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2eabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3738, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6526, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2eadf20, outheadp=0x2eabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81dfba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 443 (Thread 177.443): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ebdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e03f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 444 (Thread 177.444): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ecdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e0c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 445 (Thread 177.445): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2edbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3747, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6518, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2eddf20, outheadp=0x2edbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e14a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 446 (Thread 177.446): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2eedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e1d00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 447 (Thread 177.447): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2efdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e2558) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 448 (Thread 177.448): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e2db0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 449 (Thread 177.449): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e3608) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 450 (Thread 177.450): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e3e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 451 (Thread 177.451): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e46b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 452 (Thread 177.452): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e4f10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 453 (Thread 177.453): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3771, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5327, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2f5df20, outheadp=0x2f5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e5768) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 454 (Thread 177.454): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e5fc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 455 (Thread 177.455): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e6818) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 456 (Thread 177.456): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e7070) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 457 (Thread 177.457): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e78c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 458 (Thread 177.458): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3786, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11824, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2fadf20, outheadp=0x2fabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e8120) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 459 (Thread 177.459): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e8978) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 460 (Thread 177.460): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3792, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5315, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2fcdf20, outheadp=0x2fcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e91d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 461 (Thread 177.461): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fdbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3795, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x824b9a8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4861, seqno=93, control=11977, offset=0, data=81657856, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4861, seqno=93, control=11977, offset=0, data=81657856, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2fddf20, OutHeadP=0x2fdbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2fddf20, outp=0x2fdbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2fddf20, outheadp=0x2fdbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81e9a28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 462 (Thread 177.462): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ea280) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 463 (Thread 177.463): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ffbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3801, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82a5fa8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11849, seqno=93, control=6975, offset=0, data=83914752, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11849, seqno=93, control=6975, offset=0, data=83914752, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2ffdf20, OutHeadP=0x2ffbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2ffdf20, outp=0x2ffbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2ffdf20, outheadp=0x2ffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81eaad8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 464 (Thread 177.464): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x300bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3804, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11860, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x300df20, outheadp=0x300bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81eb330) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 465 (Thread 177.465): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x301bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3807, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x301df20, outheadp=0x301bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ebb88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 466 (Thread 177.466): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x302df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ec3e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 467 (Thread 177.467): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x303df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ecc38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 468 (Thread 177.468): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x304df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ed490) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 469 (Thread 177.469): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x305bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3819, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11816, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x305df20, outheadp=0x305bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81edce8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 470 (Thread 177.470): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x306bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3822, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11847, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x306df20, outheadp=0x306bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ee540) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 471 (Thread 177.471): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x307bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3825, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5049, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x307df20, outheadp=0x307bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81eed98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 472 (Thread 177.472): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x308df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ef5f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 473 (Thread 177.473): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x309df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81efe48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 474 (Thread 177.474): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3834, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11852, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x30adf20, outheadp=0x30abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f06a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 475 (Thread 177.475): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f0ef8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 476 (Thread 177.476): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3840, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11827, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x30cdf20, outheadp=0x30cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f1750) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 477 (Thread 177.477): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f1fa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 478 (Thread 177.478): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f2800) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 479 (Thread 177.479): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30fbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3849, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x81432f0) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6765, seqno=93, control=11752, offset=0, data=67751936, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6765, seqno=93, control=11752, offset=0, data=67751936, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x30fdf20, OutHeadP=0x30fbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x30fdf20, outp=0x30fbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x30fdf20, outheadp=0x30fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81f3058) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 480 (Thread 177.480): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x310bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3852, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4853, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x310df20, outheadp=0x310bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f38b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 481 (Thread 177.481): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x311bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3855, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11888, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x311df20, outheadp=0x311bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f4108) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 482 (Thread 177.482): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x312df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f4960) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 483 (Thread 177.483): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x313df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f51b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 484 (Thread 177.484): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x314df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f5a10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 485 (Thread 177.485): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x315df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f6268) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 486 (Thread 177.486): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x316bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3870, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4873, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x316df20, outheadp=0x316bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f6ac0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 487 (Thread 177.487): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x317df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f7318) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 488 (Thread 177.488): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x318df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f7b70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 489 (Thread 177.489): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x319bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3879, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11827, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x319df20, outheadp=0x319bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f83c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 490 (Thread 177.490): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f8c20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 491 (Thread 177.491): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f9478) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 492 (Thread 177.492): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3888, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4851, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x31cdf20, outheadp=0x31cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f9cd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 493 (Thread 177.493): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fa528) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 494 (Thread 177.494): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fad80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 495 (Thread 177.495): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3897, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11849, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x31fdf20, outheadp=0x31fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81fb5d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 496 (Thread 177.496): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x320df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fbe30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 497 (Thread 177.497): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x321df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fc688) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 498 (Thread 177.498): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x322df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fcee0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 499 (Thread 177.499): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x323df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fd738) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 500 (Thread 177.500): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x324df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fdf90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 501 (Thread 177.501): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x325df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fe7e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 502 (Thread 177.502): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x326bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3918, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6841, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x326df20, outheadp=0x326bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ff040) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 503 (Thread 177.503): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x327df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ff898) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 504 (Thread 177.504): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x328bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3924, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4864, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x328df20, outheadp=0x328bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x82000f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 505 (Thread 177.505): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x329df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8200948) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 506 (Thread 177.506): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82011a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 507 (Thread 177.507): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82019f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 508 (Thread 177.508): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8202250) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 509 (Thread 177.509): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8202aa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 510 (Thread 177.510): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3942, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6778, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x32edf20, outheadp=0x32ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8203300) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 511 (Thread 177.511): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32fbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3945, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8133628) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4787, seqno=93, control=2767, offset=0, data=85045248, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4787, seqno=93, control=2767, offset=0, data=85045248, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x32fdf20, OutHeadP=0x32fbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x32fdf20, outp=0x32fbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x32fdf20, outheadp=0x32fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8203b58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 512 (Thread 177.512): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x330df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82043b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 513 (Thread 177.513): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x331bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3951, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260d48) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11856, seqno=91, control=5370, offset=0, data=83353600, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11856, seqno=91, control=5370, offset=0, data=83353600, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x331df20, OutHeadP=0x331bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x331df20, outp=0x331bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x331df20, outheadp=0x331bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8204c08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 514 (Thread 177.514): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x332df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8205460) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 515 (Thread 177.515): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x333df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8205cb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 516 (Thread 177.516): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x334df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8206510) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 517 (Thread 177.517): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x335df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8206d68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 518 (Thread 177.518): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x336df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82075c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 519 (Thread 177.519): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x337df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8207e18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 520 (Thread 177.520): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x338df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8208670) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 521 (Thread 177.521): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x339bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3975, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11863, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x339df20, outheadp=0x339bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8208ec8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 522 (Thread 177.522): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3978, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4787, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33adf20, outheadp=0x33abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8209720) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 523 (Thread 177.523): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33bbc48, option=2, send_size=0, rcv_size=24, rcv_name=3981, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473815, control=28, offset=14811136, data=12541952, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473815, control=28, offset=14811136, data=12541952, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x33bdf20, OutHeadP=0x33bbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x33bdf20, outp=0x33bbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x33bdf20, outheadp=0x33bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8209f78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 524 (Thread 177.524): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3984, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11860, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33cdf20, outheadp=0x33cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x820a7d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 525 (Thread 177.525): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x820b028) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 526 (Thread 177.526): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3990, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6731, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33edf20, outheadp=0x33ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x820b880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 527 (Thread 177.527): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x820c0d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 528 (Thread 177.528): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x395bdb8, option=2, send_size=0, rcv_size=24, rcv_name=8764, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=11800, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x395bf10, outheadp=0x395df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a006a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 529 (Thread 177.529): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x39bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=8881, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x39bbf10, outheadp=0x39bdf20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a016f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 530 (Thread 177.530): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x40ebf10, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x83a9420) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 531 (Thread 177.531): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x43adf20, option=2051, send_size=40, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x3a4efc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 532 (Thread 177.532): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x47abdb8, option=2, send_size=0, rcv_size=24, rcv_name=13165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=11806, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x47adf20, outheadp=0x47abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a31a48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 533 (Thread 177.533): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x48cdf20, option=2051, send_size=40, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8400f30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 534 (Thread 177.534): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x4bbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=4850, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=13460, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x4bbdf20, outheadp=0x4bbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x83bb9c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 535 (Thread 177.535): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x4bcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=5058, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x4bcbf10, outheadp=0x4bcdf20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x82b9038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn new file mode 100644 index 00000000..7c4cf52d --- /dev/null +++ b/open_issues/ext2fs_page_cache_swapping_leak.mdwn @@ -0,0 +1,364 @@ +[[!meta copyright="Copyright © 2011, 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_gnumach open_issue_hurd]] + +There is a [[!FF_project 272]][[!tag bounty]] on this task. + +[[!toc]] + + +# IRC, OFTC, #debian-hurd, 2011-03-24 + + <youpi> I still believe we have an ext2fs page cache swapping leak, however + <youpi> as the 1.8GiB swap was full, yet the ld process was only 1.5GiB big + <pinotree> a leak at swapping time, you mean? + <youpi> I mean the ext2fs page cache being swapped out instead of simply + dropped + <pinotree> ah + <pinotree> so the swap tends to accumulate unuseful stuff, i see + <youpi> yes + <youpi> the disk content, basicallyt :) + + +# IRC, freenode, #hurd, 2011-04-18 + + <antrik> damn, a cp -a simply gobbles down swap space... + <braunr> really ? + <braunr> that's weird + <braunr> why would a copy use so much anonymous memory ? + <braunr> unless the external pager is so busy that the kernel falls back to + its default pager + <youpi> that's what I suggested some time ago + <braunr> maybe this case should be traced in the kernel + <braunr> a simple message in the kernel buffer to warn that this condition + happened may help + <youpi> I'm seeing swap space being kept used on buildds for no real reason + except possibly backing ext2fs pages + <youpi> that could help, yes + <antrik> youpi: I think it was actually slpz who suggested that... + <youpi> I think we're generally missing feedback from memory behavior + <antrik> youpi: do you think andrei's kernel instrumentation work might be + helpful with analyzing such things? + <youpi> antrik: I think I suggested it too, but never mind + <youpi> antrik: no, because it's not a trace of events that you want + <youpi> some specific events would be useful + <youpi> but then we don't really need a whole framework for that + <antrik> apt-get upgrade eats swap too + <youpi> the upgrade itself, or the computation of the ugprade? + <youpi> apt is a memory eater nowadays + <antrik> installing the packages + <antrik> seems to have stabilized though after a while... + <antrik> so perhaps it's not a leak in this case + <youpi> ideally we should have a way to know what was put in the swap + <braunr> how would you represent what's in the swap ? + <antrik> the apt-get process has 46M of virtual memory above the 128 M + baseline + <braunr> mostly libraries i guess + <braunr> are trheads stacks 8 MiB like on Linux ? + <youpi> braunr: at least knowing how much of each process is in the swap + <youpi> braunr: 2MiB + <braunr> ok + <youpi> vminfo could also report which parts of the address space are in + the swap + <antrik> youpi: would be nice to have some simple utility reporting how + much of a process' address space is anonymous + <antrik> (in fact, I wonder why it's not reported by standard tools such as + ps or top... this shouldn't be too difficult I would think?) + <antrik> it would be much more useful information than the total virt size, + which includes rather meaningless disk and device mappings... + <youpi> agreed + <braunr> well + <braunr> there are tools like pmap for this + <braunr> unfortunately, it's difficult in mach to know what backs a + non-anonymous mapping + <braunr> pagers should be able to name their mappings + <youpi> that'd be helpful for debugging yes + <braunr> there is almost no overhead in doing that, and it would be very + useful + <youpi> and could lead to /proc/pid/maps + <braunr> yes + <braunr> isn't there a maps already ? + <youpi> nope + <braunr> ok + <youpi> (probably not very useful without the names) + <braunr> ithought i remembered maps without names, and guessed it might + have been on the hurd for that reason + <braunr> but i'm not sure + <youpi> there's the vminfo command, yes + <braunr> 14:06 < youpi> braunr: at least knowing how much of each process + is in the swap + <braunr> wouldn't it be clearer to do it the other way around ? + <braunr> like a swapinfo tool indicating what it contains ? + <youpi> sure, but it's a lot more difficult + <braunr> really ? + <braunr> why ? + <youpi> because you have to traverse all the mappings + <youpi> etc + <youpi> (in all processes, I mean) + <youpi> and you have to name what is waht + <braunr> there are other ways + <braunr> the swap is a central structure + <youpi> while simply introducing the swap % in vminfo + <youpi> for a given process you know what is what + <braunr> right + <youpi> and doing that introduction is probably very simple + <braunr> that's a good point + <braunr> top-down is effectively easier than bottom-up resolution in Mach + VM + <antrik> hm... the memory use caused by cp doesn't seem to be reflected in + the virtual size of any particular process + <antrik> ghost memory + <braunr> what's cp vmsize at the time of the problem ? + <antrik> it's at 134 M right now... so considering the 128 M baseline, + nothing worth speaking of + <braunr> right + <braunr> maybe a copy map during I/O + <braunr> but I don't know Mach copy maps in detail, as they have been + eliminated from UVM + <antrik> BTW, the memory eatup happens even before swap comes into + play... swapping seems to be a result of the problem, not the cause + <braunr> what do you mean ? + <braunr> I thought swapping was the issue + <braunr> you mean RAM is full before swapping ? + <antrik> well, I don't know what the actual problem is... I just don't + understand why the memory use increases without any particular process + seeing an increase in size + <antrik> the "free" size in vmstat decreses + <antrik> once it's eatun up, swap space use increases + <braunr> well it doesn't change much of it + <braunr> the anonymous memory pager will use RAM before resorting to the + external default-pager + <antrik> I would suspect normal block caching... but then, shouldn't this + show up in the memory info of the ext2 process? + <braunr> although, again, I'm not sure of the behaviour of the anonymous + memory pager + <braunr> antrik: I don't know how block caching behaves + <antrik> BTW, is it a know problem that doing ^C on a "cp -a" seems to hang + the whole system?... + <antrik> (the whole hurd instance that is... the other instance is not + affected) + <youpi> not that I know of + <braunr> seems like a deadlock in the anonymous memory handling + <youpi> (and I've never seen that) + <antrik> happens both in my main system (using ancient hurd/libc) and in my + subhurd (recently upgraded to current stuff) + <antrik> this make testing this stuff quite a lot harder... [sigh] + <antrik> any suggestions how to debug this hang? + <braunr> antrik: no :/ + +2011-04-28: [[!taglink open_issue_documentation]] + + <antrik> hm... is it normal that "swap free" doesn't increase as a process' + memory is paged back in? + <youpi> yes + <youpi> there's no real use cleaning swap + <youpi> on the contrary, it makes paging the process out again longer + <antrik> hm... so essentially, after swapping back and forth a bit, a part + of the swap equal to the size of physical RAM will be occupied with stuff + that is actually in RAM? + <youpi> yes + <youpi> so that that RAM can be freed immediately if needed + <antrik> hm... that means my effective swap size is only like 300 MB... no + wonder I see crashes under load + <antrik> err... make that 230 actually + <antrik> indeed, quitting the application freed both the physical RAM and + swap space + <braunr> 02:28 < antrik> hm... is it normal that "swap free" doesn't + increase as a process' memory is paged back in? + <braunr> swap is the backing store of anonymous memory, like ext2fs is the + backing store of memory objects created from its pager + <braunr> so you can view swap as the file system for everything that isn't + an external memory object + + +# IRC, freenode, #hurd, 2011-11-15 + + <braunr> hm, now my system got unstable + <braunr> swap is increasing, without any apparent reason + <antrik> you mean without any load? + <braunr> with load, yes + <braunr> :) + <antrik> well, with load is "normal"... + <antrik> at least for some loads + <braunr> i can't create memory pressure to stress reclaiming without any + load + <antrik> what load are you using? + <braunr> ftp mirrorring + <antrik> hm... never tried that; but I guess it's similar to apt-get + <antrik> so yes, that's "normal". I talked about it several times, and also + wrote to the ML + <braunr> antrik: ok + <antrik> if you find out how to fix this, you are my hero ;-) + <braunr> arg :) + <antrik> I suspect it's the infamous double swapping problem; but that's + just a guess + <braunr> looks like this + <antrik> BTW, if you give me the exact command, I could check if I see it + too + <braunr> i use lftp (mirror -Re) from a linux git repository + <braunr> through sftp + <braunr> (lots of small files, big content) + <antrik> can't you just give me the exact command? I don't feel like + figuring it out myself + <braunr> antrik: cd linux-stable; lftp sftp://hurd_addr/ + <braunr> inside lftp: mkdir linux-stable; cd linux-stable; mirror -Re + <braunr> hm, half of physical memory just got freed + <braunr> our page cache is really weird :/ + <braunr> (i didn't delete any file when that happened) + <antrik> hurd_addr? + <braunr> ssh server ip address + <braunr> or name + <braunr> of your hurd :) + <antrik> I'm confused. you are mirroring *from* the Hurd box? + <braunr> no, to it + <antrik> ah, so you login via sftp and then push to it? + <braunr> yes + <braunr> fragmentation looks very fine + <braunr> even for the huge pv_entry cache and its 60k+ entries + <braunr> (and i'm running a kernel with the cpu layer enabled) + <braunr> git reset/status/diff/log/grep all work correctly + <braunr> anyway, mcsim's branch looks quite stable to me + <antrik> braunr: I can't reproduce the swap leak with ftp. free memory + idles around 6.5 k (seems to be the threshold where paging starts), and + swap use is constant + <antrik> might be because everything swappable is already present in swap + from previous load I guess... + <antrik> err... scratch that. was connected to the wrong host, silly me + <antrik> indeed swap gets eaten away, as expected + <antrik> but only if free memory actually falls below the + threshold. otherwise it just oscillates around a constant value, and + never touches swap + <antrik> so this seems to confirm the double swapping theory + <youpi> antrik: is that "double swap" theory written somewhere? + <youpi> (no, a quick google didn't tell me) + + +## IRC, freenode, #hurd, 2011-11-16 + + <antrik> youpi: + http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html talks + about "double paging". probably it's also the term others used for it; + however, the term is generally used in a completely different meaning, so + I guess it's not really suitable for googling either ;-) + <antrik> IIRC slpz (or perhaps someone else?) proposed a solution to this, + but I don't remember any details + <youpi> ok so it's the same thing I was thinking about with swap getting + filled + <youpi> my question was: is there something to release the double swap, + once the ext2fs pager managed to recover? + <antrik> apparently not + <antrik> the only way to free the memory seems to be terminating the FS + server + <youpi> uh :/ + + +# IRC, freenode, #hurd, 2011-11-30 + + <antrik> slpz: basically, whenever free memory goes below the paging + threshold (which seems to be around 6 MiB) while there is other I/O + happening, swap usage begins to increase continuously; and only gets + freed again when the filesystem translator in question exits + <antrik> so it sounds *very* much like pages go to swap because the + filesystem isn't quick enough to properly page them out + <antrik> slpz: I think it was you who talked about double paging a while + back? + <slpz> antrik: probably, sounds like me :-) + <antrik> slpz: I have some indication that the degenerating performance and + ultimate hang issues I'm seeing are partially or entirely caused by + double paging... + <antrik> slpz: I don't remember, did you propose some possible fix? + <slpz> antrik: hmm... perhaps it wasn't me, because I don't remember trying + to fix that problem... + <slpz> antrik: at which point do you think pages get duplicated? + <antrik> slpz: it was a question. I don't remember whether you proposed + something or not :-) + <antrik> slpz: basically, whenever free memory goes below the paging + threshold (which seems to be around 6 MiB) while there is other I/O + happening, swap usage begins to increase continuously; and only gets + freed again when the filesystem translator in question exits + <antrik> so it sounds *very* much like pages go to swap because the + filesystem isn't quick enough to properly page them out + <tschwinge> + http://www.bddebian.com:8888/~hurd-web/open_issues/ext2fs_page_cache_swapping_leak/ + <slpz> tschwinge: thanks + <slpz> antrik: I see + <tschwinge> Always at your service. ;-) + <slpz> antrik: I didn't addressed this problem directly, but when I've + modified the pageout mechanism to provide a special treatment for + external pages, I also removed the possibility of sending them to the + default pager + <slpz> antrik: this was in my experimental environment, of course + <antrik> slpz: oh, nice... so it may fix the issues I'm seeing? :-) + <antrik> anything testable yet? + <slpz> antrik: yes, only anonymous memory could be swapped with that + <slpz> antrik: it works, but is ugly as hell + <antrik> tschwinge: these is also your observation about compilations + getting slower on further runs, and my followups... I *suspect* it's the + same issue + +[[performance/degradation]]. + + <slpz> antrik: I'm thinking about establishing a repository for these + experimental versions, so they don't get lost with the time + <antrik> slpz: please do :-) + <slpz> antrik: perhaps in savannah's HARD project + <antrik> even if it's not ready for upstream, it would be nice if I could + test it -- right now it's bothering me more than any other Hurd issues I + think... + <slpz> also, there's another problem which causes performance degradation + with the simple use of the system + <tschwinge> slpz: Please just push to Savannah Hurd. Under your + slpz/... or similar. + <tschwinge> antrik: Might very well be, yes. + <slpz> and I almost sure it is the fragmentation of the task map + <slpz> tschwinge: ok + <slpz> after playing a bit with a translator, it can easily get more than + 3000 entries in its map + <antrik> slpz: yeah, other issues might play a role here as well. I + observed that terminating the problematic FS servers does free most of + the memory and remove most of the performance degradation, but in some + cases it's still very slow + <slpz> that makes vm_map_lookup a lot slower + <antrik> on a related note: any idea what can cause paging errors and a + system hang even when there is plenty of free swap? + <antrik> (I'm not entirely sure, but my impression is that it *might* be + related to the swap usage and performance degradation problems) + <slpz> I think this degree of fragmentation has something to do with the + reiterative mapping of memory objects which is done in pager-memcpy.c + <slpz> antrik: which kind of paging errors? + <antrik> hm... I don't think I ever noted down the exact message; but I + think it's the same you get when actually running out of swap + <slpz> antrik: that could be the default pager dying for some internal bug + <antrik> well, but it *seems* to go along with the performance degradation + and/or swap usage + <slpz> I also have the impression that we're using memory objects the wrong + way + <antrik> basically, once I get to a certain level of swap use and slowness + (after about a month of use), the system eventually dies + <slpz> antrik: I never had a system running for that time, so it could be a + completely different problem from what I've seen before :-/ + <slpz> Anybody has experience with block-level caches on microkernel + environments? + <antrik> slpz: yeah, it typically happens after about a month of my normal + use... but I can significantly accellerate it by putting some problematic + load on it, such as large apt-get runs... + <slpz> I wonder if it would be better to put them in kernel or in user + space. And in the latter, if it would be better to have one per-device + shared for all accesing translators, or just each task should have its + own cache... + <antrik> slpz: + http://lists.gnu.org/archive/html/bug-hurd/2011-09/msg00041.html is where + I described the issue(s) + <antrik> (should send another update for the most recent findings I + guess...) + <antrik> slpz: well, if we move to userspace drivers, the kernel part of + the question is already answered ;-) + <antrik> but I'm not sure about per-device cache vs. caching in FS server diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn new file mode 100644 index 00000000..a3a22b16 --- /dev/null +++ b/open_issues/extern_inline.mdwn @@ -0,0 +1,109 @@ +[[!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_hurd]] + +[[!toc]] + + +# IRC, unknown channel, unknown date + + <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline? + <youpi> why static inlines instead of extern lines ? + <youpi> +in + <youpi> static inlines can lead to space waste where it isn't inlined + <tschwinge> Are you sure about that -- I don't think so. + <tschwinge> At least with 99 inlining. + <youpi> what can the compiler do where it isn't inlined ? + <youpi> include a copy + <youpi> thus space waste + <youpi> 00000000004004b1 t f + <youpi> 00000000004004d5 t f + <youpi> I've juste checked + <youpi> two copies of my inline function + <youpi> one per .o + <tschwinge> Yes, but isn't it expected tobe that way? ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch? + <tschwinge> It's been a long time that I had a look at this... + <tschwinge> The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore. + <youpi> ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance) + <youpi> but the duplication issue still holds + <youpi> the functions not ending up in the library is a concern indeed + <tschwinge> That's what my second patch fixes, I think. + <youpi> grah, callisto rebooted for no reason + <youpi> ah, indeed the second patch fixes things correctly + <youpi> uh, indeed it's --dbg-package=hurd in there + <youpi> how odd + <youpi> tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline + <tschwinge> Is this true: + <tschwinge> static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol. + <youpi> so as to not expose it + <youpi> for other cases we can keep an extern inline as they are just programs + <tschwinge> Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available. + <youpi> and that avoids duplicate code + <youpi> yes + <youpi> but as long as you provide the extern inlines by compiling an xinl.c there's no problem + <tschwinge> Sure, that'd be the alternative. + <youpi> for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines) + <tschwinge> So you say it'd be better to do that (xinl.c) instead of static inline? + <youpi> for programs, you can just keep them all extern inlines + <youpi> yes, it shares code + <youpi> it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines + <tschwinge> ANd in .c files that are part of programs I'd also use extern inline or static inline? + <youpi> for programs just always use extern lines + <youpi> +in + <youpi> as you don't care about symbol exposure + <youpi> unless the inline is defined in a .c file of course, in that case it's useless to make it extern + <tschwinge> But then I also always need xinl.c files for those, which we apparently don't have in a few places. + <youpi> yes + <tschwinge> But probably didn't notice so far, as the functions could always be inlined. + <youpi> probably because we used to have luck + <youpi> yes + <tschwinge> Yes, I was thinking about the term/munge.c thing. + <tschwinge> OK, I think I get it now. Then I'll try to fix this accordingly. + <tschwinge> But not now. Thanks for the help! + <youpi> ok, thanks + <tschwinge> It was quite a bit confusing to me. + <tschwinge> Due to the mostly reversed definition of extern inline in glibc (I think). + <youpi> inline definitely is confusing + <youpi> especially since the semantic has changed over time and according to standards :) + <tschwinge> And then GCC changing that according to C99. + <tschwinge> Yes. + + +# IRC, freenode, #hurd, 2012-03-14 + + <youpi> + http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=blob;f=debian/patches/extern_inline_fix.patch;h=b9eacbff97dc56e99a69ddb601a5fc948f6e44a7;hb=HEAD + <youpi> maybe review it, and then we apply it + <pinotree> + http://patch-tracker.debian.org/patch/series/view/hurd/20120222-1/extern_inline_fix.patch + ;) + <civodul> youpi: the #ifdef __USE_EXTERN_INLINES in there and the extra + "extern" decls look wrong to me + <youpi> iirc USE_EXTERN_INLINES is needed + <youpi> otherwise it's not compliant + <youpi> or maybe it's for -O0 + <youpi> anyway IIRC it's needed + <civodul> when !defined __USE_EXTERN_INLINES, you end up with extern decls + with no corresponding definition + <youpi> yes + <youpi> they are defined in the code + <civodul> where? + <youpi> there's a special .c file in each lib + <youpi> libdiskfs/extern-inline.c + <youpi> etc + <civodul> oooh, right + <youpi> extern inline means that anyway + <youpi> the compiler is allowed to not always inline + <civodul> yes + <civodul> that looks good to me, then + <civodul> youpi: can you apply it, with proper authorship & co.? + <civodul> (no rush, though) + <youpi> sure diff --git a/open_issues/faccessat.mdwn b/open_issues/faccessat.mdwn new file mode 100644 index 00000000..911acbb6 --- /dev/null +++ b/open_issues/faccessat.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 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 open_issue_hurd]] + +`faccessat()` fails on some cases; in particular when: + +* flags does not have `AT_EACCESS` +* dirfd is not `AT_FDCWD` +* pathname is not an absolute path + +In such case, it will return -1 setting `ENOTSUP` as errno. + +[[faccessat.c]] diff --git a/open_issues/faccessat/faccessat.c b/open_issues/faccessat/faccessat.c new file mode 100644 index 00000000..24b1233c --- /dev/null +++ b/open_issues/faccessat/faccessat.c @@ -0,0 +1,26 @@ +#include <fcntl.h> +#include <unistd.h> +#include <stdio.h> +#include <errno.h> +#include <string.h> +#include <stdlib.h> + +#define TESTFN "faccessat-test-file" + +int main() +{ + int fd; + int ret; + + system("touch " TESTFN ); + fd = open(".", O_RDONLY); + printf("> open: %d\n", fd); + + errno = 0; + ret = faccessat(fd, TESTFN, R_OK, 0); + printf("> faccessat: %d, %d (%s)\n", ret, errno, strerror(errno)); + + close(fd); + + return 0; +} diff --git a/open_issues/fakeroot_exit_0.mdwn b/open_issues/fakeroot_exit_0.mdwn new file mode 100644 index 00000000..c6075b17 --- /dev/null +++ b/open_issues/fakeroot_exit_0.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + + $ fakeroot ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include + [...] + + LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot + + LD_PRELOAD=libfakeroot-tcp.so + + ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include + libfakeroot: connect: Interrupted system call + + RESULT=0 + + exit $RESULT + + exit 0 + kill -s HUP 23612 + + kill -s HUP 23612 + +(The `EINTR` issue has been [[!debbug desc="fixed" 641200]].) + +`connect() < 0` invokes `fail()` which invokes `exit(1)`. Not yet figured out +why the process exits 0 dispite that. `LD_PRELOAD` issue? ([[!taglink +open_issue_glibc]].) + + +# Build + +`libacl1-dev` is missing. + + $ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -b -d diff --git a/open_issues/fcntl_locking_dev_null.mdwn b/open_issues/fcntl_locking_dev_null.mdwn new file mode 100644 index 00000000..4c65a5c4 --- /dev/null +++ b/open_issues/fcntl_locking_dev_null.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="fcntl locking /dev/null"]] + +[[!tag open_issue_hurd]] + + +# IRC, OFTC, #debian-hurd, 2012-07-06 + + <pinotree> regarding the libwibble failure (which holds libbuffy → + libbuffy-bindings), the failing test happens because it logs to /dev/null + as test file, + <pinotree> and while doing that, it wants to lock it first, having a + ENOTSUP in return + <youpi> oh + <youpi> locking null, how interesting + <youpi> what is that supposed to do ? :o) + <pinotree> from what i was reading posix, it would seem that such object is + considered a "File" + <youpi> is it our unimplemented record lock, or just the lock operation + that /dev/null doesn't support ? + <youpi> what size is null supposed to be? zero, right? + <pinotree> the latter + <youpi> ah + <youpi> so we can simply make lock return 0 + <youpi> since there's no byte to lock? + <youpi> I don't remember whether you can lock unexistant bytes + <pinotree> indeed, if i change the libwibble unit test to use eg /tmp/foo, + they pas + <pinotree> s diff --git a/open_issues/fdisk.mdwn b/open_issues/fdisk.mdwn new file mode 100644 index 00000000..ece8fc89 --- /dev/null +++ b/open_issues/fdisk.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + + Command (m for help): w + The partition table has been altered! + + Calling ioctl() to re-read partition table. + *Segmentation fault* + +Changes have been saved, though. + +Perhaps realted to the [[BLKRRPART_IOCTL]]? diff --git a/open_issues/fifo_O_RDWR.mdwn b/open_issues/fifo_O_RDWR.mdwn new file mode 100644 index 00000000..730e5c6f --- /dev/null +++ b/open_issues/fifo_O_RDWR.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="fifo O_RDWR"]] + +[[!tag open_issue_hurd]] + +[[!debbug 646016]] + +IRC, OFTC, #debian-hurd, 2011-10-19: + + <tschwinge> pinotree: Nice! And that open(FIFO, O_RDWR) hanging issue may + warrant investigation on the Hurd side, too -- if the other systems + behave differently, we should probably have convincing reasons for our + behavior. + <pinotree> i gue somebody working on hurd never cared about that case - i + guess it falls back to one of O_RDONLY or O_WRONLY + <pinotree> *guess diff --git a/open_issues/file_locking.mdwn b/open_issues/file_locking.mdwn new file mode 100644 index 00000000..563307a4 --- /dev/null +++ b/open_issues/file_locking.mdwn @@ -0,0 +1,74 @@ +[[!meta copyright="Copyright © 2010, 2011 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_hurd open_issue_glibc]] + +IRC, #hurd, 2010-12-31. + + <pinotree> youpi: i found the issue with python-apt + <pinotree> s/with/of/ + <youpi> good! + <pinotree> lock file issue, though :/ + <youpi> :/ + <pinotree> this is the sample test case, derived from apt's code: + http://paste.debian.net/103536/ + <pinotree> basically, it seems asking for a file lock in the same process + where there's already such lock on the file, fails + <pinotree> youpi: ↑ + <youpi> uh, posix doesn't even define some nesting + <pinotree> it seems it just talks about concurrency with other processes + <youpi> posix tells more about it later + <youpi> saying that if a lock already exists, then it is replaced by the + new + <youpi> (when inside the same process) + <pinotree> yay, found a bug in hurd :p + <youpi> well, actually it's known + <youpi> i.e. setlk is completely bogus, based on flock + <youpi> and flock doesn't have the same semantic in that regard + <youpi> so we can't fix it without really implementing setlk + <pinotree> the XXX comment in glibc/sysdeps/mach/hurd/fcntl.c, by chance? + :) + <youpi> of course :) + <pinotree> youpi: hm, flock's man page says: + <pinotree> "A process may only hold one type of lock (shared or exclusive) + on a file. Subsequent flock() calls on an already locked file will + convert an existing lock to the new lock mode." + <pinotree> so a new lock in the same process over the original lock should + replace the old one? + <youpi> uh, that's not what I had seen + <pinotree> http://linux.die.net/man/2/flock + <youpi> An attempt to lock the file using one of these file descrip- + <youpi> tors may be denied by a lock that the calling process + has already + <youpi> placed via another descriptor. + <youpi> so it's really not that easy + <pinotree> that's in case of trying to create a lock on a file with a + different fd than the existing lock + <youpi> that's what your testcase does + <pinotree> which, hm, is python-apt's case + <youpi> that being said, the sentence I pasted does not seem to appear in + posix + <pinotree> flock() does not seem posix + <youpi> it may have been the behavior of Linux at some point in the past + <youpi> it's not , but F_SETLK is + <youpi> and in linux world, flock <=> F_SETLK, iirc + <youpi> in glibc world, even + <youpi> (just checked it, see sysdeps/posix/flock.c + <youpi> pinotree: I guess your testcase works on Linux? + <pinotree> which means we should get a proper F_SETLK working, and then + just use this flock version (instead of the custom one), no? + <pinotree> yes, it works on linux (and on kfreebsd, see that python-apt + builds) + <youpi> no, I mean our flock() should probably be happy with locking part + of a file several times + <youpi> (that is, hurd's file_lock() RPC) + <youpi> ah, no, on Linux flock is its own system call + <youpi> (which is independant from lockf from the locking point of view, + iirc) diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn new file mode 100644 index 00000000..c51863b9 --- /dev/null +++ b/open_issues/file_system_exerciser.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2011, 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_hurd]] + +Test our file system implementations with the File System Exerciser. + + * <http://codemonkey.org.uk/projects/fsx/> + + +# Alternatives + + +## fs_mark + + +### IRC, freenode, #hurd, 2012-04-30 + + <pinotree> mcsim: http://sourceforge.net/projects/fsmark/ + <pinotree> mcsim: just saw it in debian's NEW queue and from the + description it seemed like something it could be helpful for you + <pinotree> (and in general to test fs'es) diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn new file mode 100644 index 00000000..6b90aa0a --- /dev/null +++ b/open_issues/fork_deadlock.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 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]] + +This started appearing when Jérémie's [[glibc]] signal patches were integrated: +very sporadically, but still now and then, `fork` will hang, as follows, and +typically in `/bin/sh`. + +From a `libtool` invocation: + + #0 0x0107b13c in swtch_pri () at /build/eglibc-Q9jlik/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0107c9c4 in __spin_lock_solid (lock=0x125080c) at spin-solid.c:27 + No locals. + #2 0x01091427 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1250008) at hurdsig.c:172 + No locals. + #4 0x011261ec in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235 + No locals. + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18784244, 19197896, 1, 16925832, 16925460, 17980399}, __mask_was_saved = 0, __saved_mask = 33}} + pid = 0 + err = <optimized out> + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1250008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] + + +Another one in `dash`: + + #0 0x0105927c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0105ac44 in __spin_lock_solid (lock=0x123580c) at spin-solid.c:27 + No locals. + #2 0x010701c7 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172 + No locals. + #4 0x011048f0 in _hurd_critical_section_unlock (our_lock=0x1235008) at ../hurd/hurd/signal.h:235 + ss = 0x1235008 + pending = <optimized out> + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18780148, 19087304, 134621988, 0, 16938700, 17842902}, __mask_was_saved = 0, __saved_mask = 4294967295}} + pid = 0 + err = 0 + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1235008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] diff --git a/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn b/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn new file mode 100644 index 00000000..39003ae4 --- /dev/null +++ b/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn @@ -0,0 +1,185 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +[[!meta title="fork: mach_port_mod_refs: EKERN_UREFS_OWERFLOW"]] + +[[!toc]] + + +# Original Report + +In the [[GCC testsuite|gcc]], at this point: + + Running /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp ... + +... `expect` had gone bonkers: + + $ ps --all --format=hurd-long -w + PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + [...] + 3567 1000 10295 3567 3567 2 137M 856K 98.2 5hrs 28 hours expect -- /usr/share/dejagnu/runtest.exp --tool gcc + [...] + +Last lines of `gcc/testsuite/gcc/gcc.sum`: + + PASS: gcc.c-torture/unsorted/q.c, -O2 -flto -flto-partition=none + PASS: gcc.c-torture/unsorted/q.c, -O2 -flto + PASS: gcc.c-torture/unsorted/r.c, -O0 + PASS: gcc.c-torture/unsorted/r.c, -O1 + PASS: gcc.c-torture/unsorted/r.c, -O2 + PASS: gcc.c-torture/unsorted/r.c, -O3 -fomit-frame-pointer + PASS: gcc.c-torture/unsorted/r.c, -O3 -g + PASS: gcc.c-torture/unsorted/r.c, -Os + PASS: gcc.c-torture/unsorted/r.c, -O2 -flto -flto-partition=none + +Last lines of `gcc/testsuite/gcc/gcc.log`: + + Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -flto-partition=none -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c (timeout = 300) + spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -flto-partition=none -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c + PASS: gcc.c-torture/unsorted/r.c, -O2 -flto -flto-partition=none + Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c (timeout = 300) + spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c + +The root filesystem is sort-of deadlocked: `syncfs -c /` doesn't finish +-- even without `-s`. But it is fine to spawn new processes, execute new +commands, etc. + +GDB on 3567: + + (gdb) info threads + 2 Thread 3567.2 0x011aaf4c in mach_msg_trap () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + * 1 Thread 3567.1 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + (gdb) bt + #0 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + #1 0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27 + #2 0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31 + #3 0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89 + #4 __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814 + #5 0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86 + #6 0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37 + #7 0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62 + #8 0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466 + #9 0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119 + #10 0x0105bea6 in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #11 0x0105bf6d in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #12 0x0105c229 in exp_getptyslave () from /usr/lib/libexpect.so.5.44.1.15 + #13 0x0103e4b2 in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #14 0x01087d79 in ?? () from /usr/lib/libtcl8.5.so.0 + #15 0x01088beb in ?? () from /usr/lib/libtcl8.5.so.0 + #16 0x0108826a in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0 + #17 0x0108985f in TclEvalObjEx () from /usr/lib/libtcl8.5.so.0 + [...] + (gdb) bt full + #0 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27 + No locals. + #2 0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31 + No locals. + #3 0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89 + No locals. + #4 __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814 + ar_ptr = <value optimized out> + nb = 104 + newp = 0x68 + oldp = 0x8076450 + oldsize = 104 + __func__ = "__libc_realloc" + #5 0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86 + sf = {_sbf = {_f = {_flags = -72515584, + _IO_read_ptr = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_read_end = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_read_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_write_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_write_ptr = 0x80764b5 "", _IO_write_end = 0x80764bc "\201\004", + _IO_buf_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_buf_end = 0x80764bc "\201\004", _IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0, _markers = 0x0, _chain = 0x0, _fileno = 20046008, + _flags2 = 0, _old_offset = 23018464, _cur_column = 0, _vtable_offset = 49 '1', _shortbuf = "\001", _lock = 0x0, _offset = 85643859813466072, + _codecvt = 0x1304583, _wide_data = 0x15f3bc0, _freeres_list = 0x0, _freeres_buf = 0x15f3c58, _freeres_size = 0, _mode = -1, + _unused2 = "\240;_\001\236D0\001\005\000\000\000\340;_\001(K3\001\000\000\000\000\005\000\000\000\000\000\000\000\250\230\060\001\260\303\031\001"}, + vtable = 0x131b9c0}, _s = {_allocate_buffer = 0x122cdf0 <__libc_malloc>, _free_buffer = 0x122cd20 <__libc_free>}} + ret = <value optimized out> + needed = 94 + #6 0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37 + done = 1 + #7 0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62 + errbuf = "\334\r", '\000' <repeats 14 times>, "\f\265\032\001\000\000\000\000x\262\004\b\000\000\000\000\000\000\000\000\377\377\377\377 \262\004\b\250\065\063\001\070A_\001k\000\000\000\000\000\000\000ı2\001\002", '\000' <repeats 11 times>"\366, \377\377\377\270\235\004\bk\000\000\000X=_\001\037\343\037\001\377\377\377\377\000\000\000\000s=_\001\361\t\006\001\070A_\001\362\t\006\001\350\t\006\001\000\000\000\000\304B_\001\350\t\006\001\330\377_\001\033\000\000\000)\036\024\001\364\267\025\001x=_\001Bq\022\001\000\000\000\000\350:\b\b\230=_\001\364\267\025\001X\313\031\b S\005\b\230=_\001\004\334\f\001X\313\031\b\000\022\030\b\300L\005\b\364\267\025\001\370\021\030\b S\005\b\bB_\001\a\365\f\001 S\005\b\320\021\030\b\001\000\000\000\274A_\001,\316\024\001\001\000\000\000\001\000\000\000\344"... + buf = <value optimized out> + #8 0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466 + newproc = 122 + sigthread_refs = 4 + portnames = 0x63000 + porttypes = 0x64000 + sigthread = 130 + state = {gs = 1, fs = 18236712, es = 20390776, ds = 17004532, edi = 1, esi = 143348, ebp = 23020160, esp = 0, ebx = 23020088, edx = 23020016, + ecx = 23020028, eax = 3966371413, eip = 23020088, cs = 18236712, efl = 0, uesp = 20138312, ss = 18488015} + newtask = 121 + thread = 139 + thread_refs = 65534 + statecount = <value optimized out> + nportnames = 142 + nporttypes = 142 + env = {{__jmpbuf = {20037620, 23068628, 23020252, 23020128, 23019736, 19231503}, __mask_was_saved = 0, __saved_mask = 4222451713}} + pid = <value optimized out> + err = EKERN_INVALID_ADDRESS + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1376808 + threads = 0x65000 + nthreads = 2 + stopped = 0 + i = 2 + #9 0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119 + status = <value optimized out> + save = <value optimized out> + pid = <value optimized out> + sa = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 524288, sa_flags = 0} + omask = 0 + [...] + +`fork` failed here: + + 458 /* We have one extra user reference created at the beginning of this + 459 function, accounted for by mach_port_names (and which will thus be + 460 accounted for in the child below). This extra right gets consumed + 461 in the child by the store into _hurd_sigthread in the child fork. */ + 462 if (thread_refs > 1 && + 463 (err = __mach_port_mod_refs (newtask, ss->thread, + 464 MACH_PORT_RIGHT_SEND, + 465 thread_refs))) + 466 LOSE; + +This is in the parent, before signal thread setup, registering with the +proc server, and starting the new process. + +The error is 19, `EKERN_UREFS_OVERFLOW`. + +(This is likely also the reason why the error path did not execute +successfully.) + +[[!tag open_issue_glibc]] + +On 2010-11-30 and 2010-12-04, when I had again started the GCC testsuite, it +failed again, but at another position (understandably), but with the same +symptoms as shown below. In particular, the `thread_refs` values were the same +ones. + + +# Discussion + + * <http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00028.html> + + * <http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00002.html> + +This is likely *simply* a programming error in glibc's fork implementation. + + +# Bounty + +There is a [[!FF_project 273]][[!tag bounty]] on this task. diff --git a/open_issues/formal_verification.mdwn b/open_issues/formal_verification.mdwn new file mode 100644 index 00000000..b7db76ee --- /dev/null +++ b/open_issues/formal_verification.mdwn @@ -0,0 +1,30 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +*Formal verification* ([[!wikipedia Formal_verification desc="Wikipedia +article"]]) deals with formally reasoning about a program's correctness. + +Especially in the field of [[DSL]]s, this is used for asserting program codes' +correctness, as explained in {{$microkernel/barrelfish#fof_plos09}}, for +example. + +[[!toc]] + + +# Issues + + * [[locking_issues]] + + * [[term_blocking]] + + +# Bounty + +There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks. diff --git a/open_issues/fsync.mdwn b/open_issues/fsync.mdwn new file mode 100644 index 00000000..d36a75ad --- /dev/null +++ b/open_issues/fsync.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, unknown channel, unknown date + + <youpi> azeem: I think I found why apt-get throws Hurd down sometimes + <youpi> the problem is that it basically write(file, 20MB); fsync(); + <youpi> i.e. it throws a storm of dirty-writeback to ext2fs + <youpi> which thus goes into throttling threads + <youpi> since posix explicitely says that fsync() can be void, I think I'll patch apt-get on the buildd + <youpi> (that bug has bitten me too many times in the past days to let it go further) + <youpi> for now it works + * youpi crosses fingers diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index 76832165..d9940716 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -1,20 +1,131 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!tag open_issue_porting open_issue_gcc fixed_in_debian]] +[[!tag open_issue_gcc]] -For GCC trunk: +Here's what's to be done for maintaining GCC. -Debian package has patches (for 4.3). Some have been forwarded upstream. (And -have been ignored.) [[Thomas_Schwinge|tschwinge]] is working on getting them -integrated. +Apart from the target-specific configuration machinery, there shouldn't be any +major differences within GCC between the GNU/Hurd and GNU/Linux ports, for +example. Especially all the compiler magic is all the same. + +[[!toc levels=2]] + + +# [[General information|/gcc]] + + +# [[Sources|source_repositories/gcc]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..upstream/trunk +-i +/^commit |^---$|hurd|linux|nptl|glibc + +--> + +Last reviewed up to the [[Git mirror's dfed30bca14de84e0446cc02f5a27407dbfdc3e1 +(2012-06-11) sources|source_repositories/gcc]]. + +<http://gcc.gnu.org/install/configure.html> has documentation for the +`configure` switches. + + * Configure fragments that have `*linux*` cases might/should often contain + those for us (and GNU/k*BSD) as well. + + * `configure.ac` + + * `libgomp/configure.tgt` + + * `libstdc++-v3/configure.host` + + `abi_baseline_pair` etc. setting. + + * `libstdc++-v3/config/os/gnu-linux/*` + + Is used for all GNU systems, as per `libstdc++-v3/configure.host`. + Should rename to `gnu-user` to reflect this? + + * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for + x86 Linux. (Why?) + + * `hurd/usr` + + `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`, + [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]]. + + Debian. + + * Eventually: get rid of this special-casing. [[!message-id + "gckk1s$e0b$1@ger.gmane.org"]]. + + * [[`libmudflap`|libmudflap]]. + + * Might [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) be + worthwhile w.r.t. our [[multithreaded|multithreading]] libraries? + + * Also see `libgcc/config/i386/morestack.S`: comments w.r.t + `TARGET_THREAD_SPLIT_STACK_OFFSET`; likely needs porting. + + As per `libgcc/config/i386/t-stack-i386`, the former file is only used for + `-fsplit-stack` support -- which is currently enabled for us in + `libgcc/config.host`, but not usable via GCC proper. + + * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't + valid for us (yet), I think. + + * `--enable-languages=[...]` + + * GNAT is not yet ported / bootstrapped? + + * The Google Go's libgo (introduced in + e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs + OS configuration / support. + + * `--enable-frame-pointer` + + `gcc/configure.ac`: `enable_frame_pointer=no` + + * `--with-dwarf2`? + + * `--enable-werror` + + * `--enable-checking` + + * `--enable-linker-build-id` + + * `--enable-gnu-unique-object` + + * `--enable-lto`, `--enable-gold` + + [[binutils_gold]] + + * `--enable-indirect-function` + + [[IFUNC]] + + * <http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html>, + <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00672.html> + + * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or + similar. Likewise for `gcc/config/i386/t-linux`. + + * Debian's GCC package has Hurd-specific patches. Some have been forwarded + upstream (and have been ignored). [[Thomas_Schwinge|tschwinge]] is working + on getting them integrated. * [\[meta-bug\] bootstrap bugs for \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824) @@ -25,26 +136,402 @@ integrated. * [-fstack-protector shouldn't use TLS in freestanding mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838) - * [Tool chain configuration: GNU/\* sharing stuff with - GNU/Linux](http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html) + * Check before/after Joseph changes. (Should be fine.) + * 34618b3190c110b8926cc2b1db4b4eac95451995 + What's this used for? (Check ML.) Ask to include i686-pc-gnu (once it is + buildable out of the box)? See also + 73905b5de0d9a086f22ded7638bb1c0ae1b91326. -Additionally: + * Various testsuite bits should include `*-*-gnu*`, too. - * Configure fragments that have `*linux*` cases might/should often contain - those for us (and GNU/k*BSD) as well. + * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's + libbid: - * `libgcc/configure.ac` [might - need](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) to be - aligned for us to the `*linux*` cases. As well as at the end of - `libgcc/config.host`. Check. + [...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c + [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory + compilation terminated. + make[1]: *** [bid_decimal_globals.o] Error 1 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc' + make: *** [all-target-libgcc] Error 2 - checking whether decimal floating point is supported... no - checking whether fixed-point is supported... no + See threads at [[!message-id + "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]], + [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id + "4D52D522.1040804@gmail.com"]]. Can simply configure the first GCC with + `--disable-decimal-float`. - * `libgomp/configure.tgt` + Alternatively, can we use `#ifndef inhibit_libc` for this (these?) file(s)? + See `generic-nonstrack.c`, for example. The latter (and also + `generic-morestack-thread.c`) also has a nice explanation of `inhibit_libc` + which could be centralized at one place, for example definition of + `inhibit_libc`. - * [[`libmudflap`|libmudflap]]. + * [low] [[toolchain/cross-gnu]] + + The directory that should contain system headers does not exist: + /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include + make[2]: *** [stmp-fixinc] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc' + make[1]: *** [all-gcc] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj' + + `mkdir` the directory for now, but what is really going on? GCC has *use + `/usr/include` patch*, but glibc still installs into `/include/`? + + * `__GLIBC__` + + IRC, freenode, #hurd, 2012-01-05: + + <civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny + <youpi> ?? + <youpi> not from features.h ? + <civodul> in gcc/config/kfreebsd-gnu.h + <civodul> :-) + <pinotree> correct, it's enabled in gcc's config + <pinotree> i discovered that after banging my head on the wall trying + to find out why some stuff wasn't compiling even after kfreebsd + porting patches adding preprocessors checks for __GLIBC__ + + IRC, freenode, #hurd, 2012-05-25: + + <gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU? + <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty + <braunr> gnu_srs: well, this only tells your the compiler defaults + <tschwinge> gnu_srs: See the email I just sent. + + [[!message-id "87396od3ej.fsf@schwinge.name"]] + + <braunr> __GLIBC__ would probably be introduced by a glibc header + <gnu_srs> tschwinge: I saw your email. I wonder if features.h is + included in the kFreeBSD build of webkit. + <gnu_srs> It is defined in their build, but not in the Hurd build. + <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__ + <pinotree> (a bit stupid choice imho, but hardly something that could + be changed now...) + <braunr> :/ + <braunr> personally i don't consider this only "a bit" stupid, as + kfreebsd is one of the various efforts pushing towards portability + <braunr> and using such hacks actually hinders portability ... + <pinotree> yeah don't tell me, i can remember at least half dozen of + occasions when a code wouldn't have been compiling at all on other + glibc platforms otherwise + <pinotree> sure, i have nothing against kfreebsd's efforts, but making + gcc define something which is proper of the libc used is stupid + <braunr> it is + <pinotree> i spotted changes like: + <pinotree> -#ifdef __linux + <pinotree> +#if defined(__linux__) || defined(__GLIBC__) + <pinotree> and wondered why they wouldn't work at all for us... and + then realized there were no #include in that file before that + preprocessor check + <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h: + <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS() \ + <tschwinge> do \ + <tschwinge> { \ + <tschwinge> builtin_define ("__FreeBSD_kernel__"); \ + <tschwinge> builtin_define ("__GLIBC__"); \ + <tschwinge> builtin_define_std ("unix"); \ + <tschwinge> builtin_assert ("system=unix"); \ + <tschwinge> builtin_assert ("system=posix"); \ + <tschwinge> } \ + <tschwinge> while (0) + <tschwinge> I might raise this upstream at some point. + <pinotree> tschwinge: i could guess the change was proposed by the + kfreebsd people, so asking them before at d-bsd@d.o would be a start + <tschwinge> pinotree: Ack. + <pinotree> especially that they would need to fix stuff afterwards + <pinotree> imho we could propose them the change, and if they agree put + that as local patch to debian's gcc4.6/.7 after wheezy, so there is + plenty of time for them to fix stuff + <pinotree> what should be done first is, however, find out why that + define has been added to gcc + + * [low] Does `-mcpu=native` etc. work? (For example, + 2ae1f0cc764e998bfc684d662aba0497e8723e52.) + + * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b + + * `config/mmap.m4` + + * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for + us? + + * f29a2041f32773464e226a83f41762c2e9cf658e + (e53a96c2136f7cdff4699475fea41afeed9dece3) + + Testresults same as for GNU/Linux. + + * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when + using __SIGRTMIN`. GCC PR52390. Fixed by + 8d2259c83f94c082ad8a00b5d00bb639ce24efce. + + * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for + i?86-linux`. + + * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined? Supposed + to come from `config/tls.m4:GCC_CHECK_TLS`? + + * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us? This + is used in libgcc for ObjC wrapper stuff and similar in libstdc++. + C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]], + [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as + [[!debbug 629866]]/[[!message-id + "20110609002620.GA16719@const.famille.thibault.fr"]]. + + +# Build + +Here's a log of a GCC build run; this is from our [[Git repository's +2e2db3f92b534460c68c2f9ae64455884424beb6 (2012-06-15; 2012-06-06) +sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ (cd ../master/ && contrib/gcc_update --touch) + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-build-with-cxx --enable-languages=all,ada 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +This takes up around 3.1 GiB, and needs roughly 3.0 h on kepler.SCHWINGE and +12.75 h on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check + +--> + + +## Analysis + + $ toolchain/logs/process gcc build + + * [[`checking if gcc static flag -static + works... no`|glibc_madvise_vs_static_linking]] + + Addressed in Debian glibc. + + * DFP + + Addressed in *hurd/decimal_floating_point* branch. + + +configure: WARNING: decimal float is not supported for this target, ignored + + ... and later on: + + -checking for decimal floating point... bid + +checking for decimal floating point... configure: WARNING: decimal float is not supported for this target, ignored + +dpd + + ... and later on: + + -checking whether decimal floating point is supported... yes + +checking whether decimal floating point is supported... no + +configure: WARNING: decimal float is not supported for this target, ignored + + * `libstdc++-v3/acinclude.m4`: ISO/IEC TR 24733 + + -checking for ISO/IEC TR 24733 ... yes + +checking for ISO/IEC TR 24733 ... no + + * `--enable-decimal-float`, `--enable-fixed-point`, `--with-long-double-128` + + `configure: WARNING: decimal float is not supported for this target, + ignored` + + * `libgcc/configure.ac` [might + need](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) to be + aligned for us to the `*linux*` cases. As well as at the end of + `libgcc/config.host`. Check. + + checking whether decimal floating point is supported... no + checking whether fixed-point is supported... no + + * `host-linux.c` vs. `host-default.c` + + * *fixincludes* stuff + + * malloc? + + -cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h + +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.h + + Comes from `gcc/config.gcc`: `i386/t-pmm_malloc` vs. `i386/t-gmm_malloc` + for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`. + + * *libgomp* + + * `libgomp/config/linux/`, `libgomp/config/linux/x86` + + `sed`ed away. + + * `-ftls-model=initial-exec -march=i486 -mtune=i686` + + `sed`ed away. + + * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`. What're they used for? + + * `RLIMIT_VMEM`. Usage kosher? + + * `libtool: link: ar rc .libs/libstdc++.a [...]` + + Just different order of object files, or another problem? TODO + + * `libobjc/encoding.c`: + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...] + +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function] + + * `libobjc/thr.c`: `gcc/gthr-posix.h` + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...] + +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0, + + from [...]/hurd/master/libobjc/thr.c:45: + +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority': + +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter] + + * `/proc/self/*` + + -checking for /proc/self/exe... yes + -checking for /proc/self/maps... yes + +checking for /proc/self/exe... no + +checking for /proc/self/maps... no + + * GCJ: `java-signal.h`, `java-signal-aux.h` + + -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h + -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h + +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h + +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.h + + * GCJ: `jni_md.h` + + -checking jni_md.h support... yes + +checking jni_md.h support... configure: WARNING: no + + * *default library search path* + + -checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib /lib64 /usr/lib64 + +checking for the default library search path... /lib /usr/lib + + * `./classpath/[...]/*.properties` + + Just different order of files, or another problem? + + * `libjava/gnu/gcj/util/natGCInfo.cc` + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter] + + * `libgcj.la` + + Just different order of object files, or another problem? + + Is there a pattern that GNU/Hurd hands out the files alphabetically sorted + where it wouldn't need to ([[!taglink open_issue_hurd]])? + + * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` + + `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` + + * `jar` + + make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava' + -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do + +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do + + Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and + coulomb.SCHWINGE a GCJ one. + + There are other instances of this in the following. + + * *default library search path* + + -checking for the default library search path... /lib /usr/lib /lib/[MULTIARCH] /usr/lib/[MULTIARCH] /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib /lib64 /usr/lib64 + +checking for the default library search path... /lib /usr/lib + + Should be aligned by Samuel's binutils patch. + + * `value-unwind.h` + + -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \ + +DEFINES='' HEADERS='' \ + ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h + + Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*` + vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway. + + * `soft-fp` prototypes + + ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes] + + * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd. Is + that correct? Probably futex support. + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 850 MiB, and needs roughly 4 min on kepler.SCHWINGE and 45 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc install + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + [[libtool]]. + + * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` + + `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above) + + * `jar`: as above. + + +# Testsuite + +<http://gcc.gnu.org/install/test.html> + +Testing on GNU/Hurd is blocked on +[[fork_mach_port_mod_refs_ekern_urefs_owerflow]]. + +TODO. Can use parallel testing, see [[!message-id +"20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]]. + + $ make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check + [...] + +This needs roughly 6.5 h on kepler.SCHWINGE and 50.25 h on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc test + +TODO. + + +# Specific Languages + + * [[GNAT]] - * [[C++]]. + * [[gccgo]] diff --git a/open_issues/gcc/c++.mdwn b/open_issues/gcc/c++.mdwn deleted file mode 100644 index cab4c1f1..00000000 --- a/open_issues/gcc/c++.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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_porting open_issue_gcc fixed_in_debian]] - -Modify the [[hurd/building/cross-compiling]] shell script to configure GCC for -building GCC with C++ support when building its second (i.e., final) version. - -Compiling a most-trivial C++ program used to work with GCC 4.2 and 4.3 (and the -resulting binaries would also work), but linking fails with GCC SVN trunk: - - $ $TARGET-g++ -Wall a.cc -lpthread - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__multf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fixunstfsi' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__subtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__divtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__copysigntf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__addtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__lttf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__netf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatunsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__eqtf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fabstf2' - collect2: ld returned 1 exit status - -Whether this defect report also applies to a natively-build GCC from SVN trunk -has not yet been checked. - -[[Thomas_Schwinge|tschwinge]] suspects the problem to be a configuration issue -of a GCC helper library, whose configuration setup has changed after GCC 4.3. - -The need for `-lpthread` is another story. See the Debian glibc patches -repository for details. diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn new file mode 100644 index 00000000..0ecc1228 --- /dev/null +++ b/open_issues/gccgo.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="Enable Google Go programming (GCC: gccgo)"]] + +[[!tag open_issue_gcc]] + +Make the [Google Go programming language](http://golang.org/) available on +GNU/Hurd in its [[GCC]] *gccgo* implementation, and enable Hurd-specific +features. + +There is a [[!FF_project 263]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/gccgo feeds=no]] + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in the Google Go programming language. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/gdb-heap.mdwn b/open_issues/gdb-heap.mdwn new file mode 100644 index 00000000..75c31bbe --- /dev/null +++ b/open_issues/gdb-heap.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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_gdb]] + +Might be interesting to have a look at +[*gdb-heap*](https://fedorahosted.org/gdb-heap/) with respect to our +long-lived [[hurd/translator]] processes. diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn new file mode 100644 index 00000000..1652031b --- /dev/null +++ b/open_issues/gdb.mdwn @@ -0,0 +1,127 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 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_gdb]] + +Here's what's to be done for maintaining GNU GDB. + +[[!toc levels=2]] + + +# [[General information|/gdb]] + + +# [[Sources|source_repositories/gdb]] + + +# Configuration + +Last reviewed up to the [[Git mirror's ea9812279fe436be9a010d07ef1dbe465199a3d7 +(2011-09-07) sources|source_repositories/gdb]]. + + * Globally + + * a.out, COFF, PE image support and 64 bit support are not interesting. + + * In the testsuites, `.exp` and `.d` files very likely should not only + care for `*-*-linux*`, but also `*-*-gnu*`. (If the need to be + conditionalized like this at all.) + + * `bfd/` + + See [[binutils]]. + + * `libdecnumber/` + + Should/can probably align to GNU/Linux. + + * Have a look at config/i386/i386gnu.mh. + + * configure.tgt + + * glibc-tdep et al. also for GNU/Hurd? + + * [[gdbserver]] + + +# Build + +Here's a log of a GDB build run; this is from our [[Git repository's +695f61ff0f378e1680964128585044799de27015 (2011-09-06) +sources|source_repositories/gdb]], run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --disable-werror 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +There are several occurences of *error: dereferencing type-punned pointer will +break strict-aliasing rules* in the MIG-generated stub files; thus no `-Werror` +until that is resolved ([[strict_aliasing]]). + +This takes up around 140 MiB and needs roughly 6 min on kepler.SCHWINGE and 30 +min on coulomb.SCHWINGE. + + +## Analysis + +x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask +out most of the differences that are due to GNU/Linux supporting more core file +formats and more emulation vectors. + + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/gdb/linux/log_build.sed < toolchain/logs/gdb/linux/log_build) <(sed -f toolchain/logs/gdb/hurd/log_build.sed < toolchain/logs/gdb/hurd/log_build) > toolchain/logs/gdb/log_build.diff + + * Why do we specify `-D_GNU_SOURCE`, and GNU/Linux doesn't? + + * Why does GNU/Linux have an additional `-ldl -rdynamic` when linking `gdb`? + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 50 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3 +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/hurd/log_install + $ diff -wu <(sed -f toolchain/logs/gdb/linux/log_install.sed < toolchain/logs/gdb/linux/log_install) <(sed -f toolchain/logs/gdb/hurd/log_install.sed < toolchain/logs/gdb/hurd/log_install) > toolchain/logs/gdb/log_install.diff + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + +# Testsuite + +On GNU/Hurd, hampered by the [[term_blocking]] issue. + + $ make -k check + [...] + +This needs roughly 45 min on kepler.SCHWINGE and TODO min on coulomb.SCHWINGE. + + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && sed -e "s%\(/media/data\)\?${PWD}%[...]%g" < hurd/master.build/gdb/testsuite/gdb.sum' > toolchain/logs/gdb/linux/sum + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && sed -e "s%\(/media/erich\)\?${PWD}%[...]%g" < hurd/master.build/gdb/testsuite/gdb.sum' > toolchain/logs/gdb/hurd/sum + $ diff -u -F ^Running toolchain/logs/gdb/linux/sum toolchain/logs/gdb/hurd/sum > toolchain/logs/gdb/sum.diff + + +## Analysis + +TODO. diff --git a/open_issues/gdb/gdbserver.mdwn b/open_issues/gdb/gdbserver.mdwn new file mode 100644 index 00000000..fe239bbc --- /dev/null +++ b/open_issues/gdb/gdbserver.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 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_gdb]] + +Needs porting. Can probably use/share most code from GDB proper. + +# Miscellaneous Issues + + * ``m addr,length'` + + What is `errno`? Is is *the* `errno`? If yes, of the system GDB is + running on, or the system gdbserver is running on? Clarify documentation. diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn new file mode 100644 index 00000000..4e4f2ea0 --- /dev/null +++ b/open_issues/gdb_attach.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="GDB: attach"]] + +[[!tag open_issue_gdb]] + + +# [[gdb_thread_ids]] + + +# IRC, freenode, #hurd, 2012-06-30 + + <braunr> hm, gdb isn't able to determine which thread is running when + attaching to a process + + +# IRC, freenode, #hurd, 2012-07-02 + + <braunr> woah, now that's a weird message ! + <braunr> when using gdb on a hanged ext2fs : + <braunr> Pid 938 has an additional task suspend count of 1; clear it? (y or + n) + <braunr> when hanged, gdb thinks the target task is already being debugged + :/ + <braunr> no wonder why it's completely stuck + <braunr> hm, the task_suspend might actually be the crash-dump-core server + attempting to create the core :/ + <braunr> hm interesting, looks like a problem with the + diskfs_catch_exception macro + <pinotree> braunr: what's up with it? + <braunr> pinotree: it uses setjmp + <braunr> hm random corruptions :/ + <braunr> definitely looks like a concurrency problem diff --git a/open_issues/gdb_catch_syscall.mdwn b/open_issues/gdb_catch_syscall.mdwn new file mode 100644 index 00000000..366c88f5 --- /dev/null +++ b/open_issues/gdb_catch_syscall.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[meta title="GDB: catch syscall"]] + + (gdb) catch syscall + The feature 'catch syscall' is not supported on this architeture yet. + +[[!tag open_issue_gdb]] + +Perhaps can ``marry'' that one with [[hurd/debugging/rpctrace]]? diff --git a/open_issues/gdb_gcore.mdwn b/open_issues/gdb_gcore.mdwn new file mode 100644 index 00000000..69211ac0 --- /dev/null +++ b/open_issues/gdb_gcore.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]] + +[[!meta title="GDB: gcore"]] + +[[!tag open_issue_gdb]] + +GDB's `gcore` command doesn't work / needs to be implemented / ported in GDB: + + tschwinge@flubber:~ $ gcore 8371 + [New Thread 8371.1] + [New Thread 8371.2] + [New Thread 8371.3] + /media/data/home/tschwinge/core.cA0ICY:2: Error in sourced command file: + Undefined command: "gcore". Try "help". + gcore: failed to create core.8371 + +If someone is working in this area, they may want to port +<http://code.google.com/p/google-coredumper/>, too. diff --git a/open_issues/gdb_noninvasive_mode_new_threads.mdwn b/open_issues/gdb_noninvasive_mode_new_threads.mdwn new file mode 100644 index 00000000..9b3992f4 --- /dev/null +++ b/open_issues/gdb_noninvasive_mode_new_threads.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 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_gdb]] + +Debugging a translator. `gdb binary`. `set noninvasive on`. `attach [PID]`. +Translator does some work. GDB doesn't notice new threads. `detach`. `attach +[PID]` -- now new threads are visible. diff --git a/open_issues/gdb_qemu_debugging_gnumach.mdwn b/open_issues/gdb_qemu_debugging_gnumach.mdwn new file mode 100644 index 00000000..d3105f50 --- /dev/null +++ b/open_issues/gdb_qemu_debugging_gnumach.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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_gdb open_issue_gnumach]] + +\#hurd, freenode, June (?) 2010 + + <jkoenig> is there a way to get gdb to map addresses as required when debugging mach with qemu ? + <jkoenig> I can examine the data if I manually map the addresses th 0xc0000000 but maybe there's an easier way... + <youpi> jkoenig: I haven't found a way + <youpi> I'm mostly using the internal kdb + diff --git a/open_issues/gdb_signal_thread_bt.mdwn b/open_issues/gdb_signal_thread_bt.mdwn new file mode 100644 index 00000000..74065922 --- /dev/null +++ b/open_issues/gdb_signal_thread_bt.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +[[!meta title="GDB: bt on the signal thread"]] + +[[!tag open_issue_gdb]] + + (gdb) r + Starting program: /media/data/home/tschwinge/tmp/h + [New Thread 26731.15] + + Breakpoint 1, 0x08048236 in main () + (gdb) info threads + 5 Thread 26731.15 0x080a97fc in mach_msg_trap () + * 4 Thread 26731.14 0x08048236 in main () + (gdb) thread 5 + [Switching to thread 5 (Thread 26731.15)]#0 0x080a97fc in mach_msg_trap () + (gdb) bt + #0 0x080a97fc in mach_msg_trap () + #1 0x080a272e in mach_msg () + #2 0x080a9934 in mach_msg_server_timeout () + #3 0x080a99ff in mach_msg_server () + #4 0x080a327e in _hurd_msgport_receive () + Cannot access memory at address 0x1012000 diff --git a/open_issues/gdb_thread_ids.mdwn b/open_issues/gdb_thread_ids.mdwn index eeb67f30..c04a10ee 100644 --- a/open_issues/gdb_thread_ids.mdwn +++ b/open_issues/gdb_thread_ids.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="GDB: thread ids"]] @@ -19,3 +20,12 @@ GNU GDB's Pedro Alves: > was, if gnu-nat.c couldn't be using the port's id as thread ids instead of a > locally auto-generated number. Maybe the thread id of the main thread would > be preserved across execs this way + + +Also see [[thread numbering of ps and GDB]]. + +--- + +`attach` to a multi-threaded process. See threads 1 to 5. `detach`. `attach` +again -- thread numbers continue where they stopped last time: now they're +threads 6 to 10. diff --git a/open_issues/git-core-2.mdwn b/open_issues/git-core-2.mdwn index 84e002b5..2d8ad96b 100644 --- a/open_issues/git-core-2.mdwn +++ b/open_issues/git-core-2.mdwn @@ -1,17 +1,25 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Hiccup of git clone when checking out files"]] +[[!meta title="Hiccups of Git"]] [[!tag open_issue_porting]] +[[!toc]] + + +# Log + +December, 2008. + On the otherwise-idle flubber: $ git clone git://sources.redhat.com/git/glibc.git @@ -40,7 +48,7 @@ On the otherwise-idle flubber: -rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 localedata/charmaps/IBM862 So these files are indeed of zero-length in the checked-out tree. Is this -git's fault or something else's? +Git's fault or something else's? Fixing this situation is easy enough: @@ -48,3 +56,135 @@ Fixing this situation is easy enough: $ git status # On branch master nothing to commit (working directory clean) + +Still seen on 2010-03-16. + +--- + +A very similar issue, seen on 2010-11-17. The working tree had a lot of +differences to HEAD. + + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/darwin.h' (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/iq2000/iq2000.md' (Interrupted system call) + error: git checkout-index: unable to create file gcc/config/lm32/lm32.c (File exists) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ ls -l gcc/config/iq2000/iq2000.md gcc/config/lm32/lm32.c + ls: cannot access gcc/config/iq2000/iq2000.md: No such file or directory + -rw-r--r-- 1 tschwinge tschwinge 32159 Nov 17 19:09 gcc/config/lm32/lm32.c + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: git checkout-index: unable to create file gcc/fortran/expr.c (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: git checkout-index: unable to create file gcc/config/sol2.h (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/i386/i386.c' (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + Checking out files: 100% (1149/1149), done. + HEAD is now at fe3e43c Merge commit 'refs/top-bases/hurd/master' into hurd/master + +--- + +2010-12-22, grubber: + + $ git remote update + Fetching savannah + remote: Counting objects: 582331, done. + remote: Compressing objects: 100% (124133/124133), done. + remote: Total 582331 (delta 460856), reused 578352 (delta 457598) + Receiving objects: 100% (582331/582331), 525.15 MiB | 204 KiB/s, done. + fatal: cannot pread pack file: Interrupted system call + fatal: index-pack failed + error: Could not fetch savannah + +--- + +2011-06-10, coulomb.SCHWINGE, checking out [[binutils]]' master branch, +starting from an empty working directory (after an external `git push`): + + $ git checkout -f + fatal: cannot create directory at 'gas/testsuite/gas/bfin': Interrupted system call + $ git checkout -f + error: unable to create file gas/testsuite/gas/i386/ilp32/x86-64-sse4_1-intel.d (File exists) + warning: unable to unlink gas/testsuite/gas/m68k-coff: Operation not permitted + fatal: cannot create directory at 'gas/testsuite/gas/m68k-coff': Operation not permitted + $ git checkout -f + error: unable to create file gas/testsuite/gas/h8300/h8300.exp (File exists) + error: unable to create file gas/testsuite/gas/i386/x86-64-addr32-intel.d (File exists) + error: unable to create file gas/testsuite/gas/ia64/secname.d (File exists) + error: unable to create file gas/testsuite/gas/m68k/pr11676.s (File exists) + Checking out files: 100% (12315/12315), done. + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: gas/testsuite/gas/h8300/h8300.exp + # modified: gas/testsuite/gas/i386/x86-64-addr32-intel.d + # modified: gas/testsuite/gas/ia64/secname.d + # modified: gas/testsuite/gas/m68k/pr11676.s + # + no changes added to commit (use "git add" and/or "git commit -a") + $ rm gas/testsuite/gas/h8300/h8300.exp gas/testsuite/gas/i386/x86-64-addr32-intel.d gas/testsuite/gas/ia64/secname.d gas/testsuite/gas/m68k/pr11676.s + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + + +# Analysis + +2011-06-13 + +Running `git checkout -f` under GDB: + + error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse-check.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse4_1.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/ppc/astest.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (File exists) + warning: unable to unlink include/cgen: Operation not permitted + fatal: cannot create directory at 'include/cgen': Operation not permitted + +Again: + + error: git checkout-index: unable to create file gas/config/te-vxworks.h (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/d10v/warning-019.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i860/dual03.s (File exists) + error: git checkout-index: unable to create file ld/testsuite/ld-mmix/sec-7a.s (File exists) + warning: unable to unlink ld/testsuite/ld-powerpc: Operation not permitted + fatal: cannot create directory at 'ld/testsuite/ld-powerpc': Operation not permitted + +And: [[git_duplicated_content]]. + +All these (very likely) have the same root cause: `SA_RESTART` restarting too +much. + +With `git checkout`, Git uses in progress.c a SIGALRM handler (`SA_RESTART`; +invoked every second via `setitimer(ITIMER_REAL)`) to display status messages: +*x % already checked out*. + +To avoid the status update signals every second, in +`[git]/progress.c:start_progress_delay` we can just return `NULL` (manually in +GDB, for example), then both the *error: git checkout-index* and the +[[duplicated content|git_duplicated_content]] issues go away. + +I'm guessing that when returning from a `SA_RESTART` signal handler, too much +of the \`\`syscall''s is being restarted. For example, if a file has already +been created, the restarted creation attempt would fail: *File exists*. If +data has been written, it might get written again (duplication issue). Then, +there are cases where `unlink` apparently returns EINTR, which is not kosher +either. Etc. + +Do we have problems with `SA_RESTART` vs. the atomicity of our syscall-alikes? diff --git a/open_issues/git_duplicated_content.mdwn b/open_issues/git_duplicated_content.mdwn new file mode 100644 index 00000000..cbc171a7 --- /dev/null +++ b/open_issues/git_duplicated_content.mdwn @@ -0,0 +1,131 @@ +[[!meta copyright="Copyright © 2011 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_porting]] + + $ git-new-workdir ~/tmp/binutils/git /media/hd1s1/tmp/master master + error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call) + Checking out files: 100% (12315/12315), done. + Already on 'master' + $ cd /media/hd1s1/tmp/master + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d + # + no changes added to commit (use "git add" and/or "git commit -a") + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + +([[Git issue|git-core-2]] is known.) + + $ git-new-workdir ~/tmp/binutils/git /media/hd1s2/tmp/master master + error: unable to create file bfd/elf32-dlx.c (Interrupted system call) + error: unable to create file bfd/sunos.c (Interrupted system call) + error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call) + error: unable to create file gas/testsuite/gas/mmix/regx-op.d (Interrupted system call) + error: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (Interrupted system call) + error: unable to create file gold/testsuite/script_test_2.t (Interrupted system call) + error: unable to create file ld/testsuite/ld-mmix/loc7m.d (Interrupted system call) + error: unable to create file ld/testsuite/ld-powerpc/tlsexe.g (Interrupted system call) + Checking out files: 100% (12315/12315), done. + Already on 'master' + $ cd /media/hd1s2/tmp/master + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: bfd/elf32-dlx.c + # modified: bfd/sunos.c + # modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d + # modified: gas/testsuite/gas/mmix/regx-op.d + # modified: gas/testsuite/gas/tic6x/reloc-bad-4.s + # modified: gold/testsuite/script_test_2.t + # modified: ld/testsuite/ld-mmix/loc7m.d + # modified: ld/testsuite/ld-powerpc/tlsexe.g + # + no changes added to commit (use "git add" and/or "git commit -a") + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + +Now you'd expect these directories to have identical content, but: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff + $ ls -l /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + $ grep '^[^ @+-]' < /tmp/diff + diff -x .git -ru /media/hd1s1/tmp/master//ld/configure /media/hd1s2/tmp/master//ld/configure + +(Note that this isn't a file that Git had issues with.) + +Try again: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff_ + $ ls -l /tmp/diff* + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_ + $ cmp /tmp/diff{,_}; echo $? + 0 + +At least it's consistent. Force a reload: + + # settrans -ag /media/hd1s1 + # settrans -ag /media/hd1s2 + +Try again: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff__ + $ ls -l /tmp/diff* + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_ + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:30 /tmp/diff__ + $ cmp /tmp/diff{,__}; echo $? + 0 + +Consistent; thus very likely corrupt on-disk. + +After a few tries, the pattern generally is that for the files where there are +differences, once the file regularely ends, its content appears once more. +That is, the files' content appears once (regularely), and then the same again. + +Some more copying: + + $ (cd /media/hd1s1/tmp/ && cp -a master master_) + $ (cd /media/hd1s2/tmp/ && cp -a master master_) + $ diff -x .git -ru /media/hd1s1/tmp/master{,_}/ > /tmp/diff1 + $ diff -x .git -ru /media/hd1s2/tmp/master{,_}/ > /tmp/diff2 + $ ls -l /tmp/diff{1,2} + -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff1 + -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff2 + +No further difference. + +--- + + $ git-new-workdir git master master + $ diff -x .git -ur tar_master/ master/ > master.diff + + $ rm -rf ar_master* && (cd git/ && git archive master) | (mkdir ar_master && cd ar_master/ && tar -x) && diff -x .git -ru tar_master/ ar_master/ > ar_master.diff; ls -l ar_master.diff + $ (cd git/ && git archive master) | md5sum + +--- + +2011-06-13 + +-> [[git-core-2]] diff --git a/open_issues/git_nfs_mmap.mdwn b/open_issues/git_nfs_mmap.mdwn new file mode 100644 index 00000000..21067022 --- /dev/null +++ b/open_issues/git_nfs_mmap.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2011, 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_porting]] + + $ git-new-workdir /media/kepler-data/home/thomas/tmp/source/binutils/git master master + fatal: Out of memory? mmap failed: No such device + $ echo $? + 128 + $ showtrans /media/kepler-data + /hurd/nfs kepler.schwinge.homeip.net:/media/data + +With `sh -x`: + + [...] + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/remotes master/.git/remotes + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/rr-cache master/.git/rr-cache + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/svn master/.git/svn + + cd master + + cp /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/HEAD .git/HEAD + + git checkout -f master + fatal: Out of memory? mmap failed: No such device + +As one can easily guess (and confirm with [[hurd/debugging/rpctrace]]), `git` +tries to [[glibc/mmap]] a file via the [[hurd/translator/nfs]] translator, this +fails, and it isn't prepared to cope with that: + + [...] + 88->dir_lookup (".git/objects/pack/pack-37ca560e7877fa0cc6e5ddcd556aa73e5a3e3f40.idx" 2049 0) = 0 3 "/media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37" (null) + 62->dir_lookup ("media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37c" 2049 0) = 0 1 "/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5" 61 + 61->dir_lookup ("home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5d" 2049 0) = 0 1 "" 84 + task3741-> 3206 (pn{ 33}) = 0 + 84->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) + 84->io_stat_request () = 0 {1 704 0 36308992 0 0 -1 33060 1 1000 1000 4712 0 1307711395 0 1307657003 0 1307657003 0 4096 16 0 1000 0 0 100663296 1836017780 29537 0 0 0 0} + 84->io_map_request () = 0x4000002d (Operation not supported) + 84->io_map_request () = 0x4000002d (Operation not supported) + 76->io_write_request ("fatal: Out of memory? mmap failed: No such device + " -1) = 0 50 + 64->proc_mark_exit_request (32768 0) = 0 + task3741-> 2008 () = 0 + Child 3741 exited with 128 + +This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue. + +There is a `NO_MMAP` conditional in Git's source code, but it is a compile-time +conditional. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn new file mode 100644 index 00000000..31cafbfe --- /dev/null +++ b/open_issues/glibc.mdwn @@ -0,0 +1,943 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 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]] + +Here's what's to be done for maintaining glibc. + +[[!toc levels=2]] + + +# [[General information|/glibc]] + + +# [[Sources|source_repositories/glibc]] + + +# [[Debian]] Cheat Sheet + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master +-i +/^commit |^Merge:|^---$|hurd|linux|gs:|__ASSUME + +--> + +Last reviewed up to the [[Git mirror's 56e49b714ecd32c72c334802b00e3d62008d98e3 +(2012-07-25) sources|source_repositories/glibc]]. + + * `t/hurdsig-fixes` + + hurdsig.c: In function '_hurd_internal_post_signal': + hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] + hurdsig.c:1168:12: note: 'pending' was declared here + + * `t/host-independency` + + [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id + "20120525202732.GA31088@intel.com"]], commit + 918b56067a444572f1c71b02f18255ae4540b043. [[!GCC_PR 53183]], GCC commit + c05436a7e361b8040ee899266e15bea817212c37. + + * `t/sysvshm` + + ../sysdeps/mach/hurd/shmat.c: In function '__shmat': + ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] + ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive': + ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable] + ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized] + ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized] + + * [[`t/tls`|t/tls]] + + * [[`t/tls-threadvar`|t/tls-threadvar]] + + * t/verify.h + + People didn't like this too much. + + Other examples: + + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert` + + * [[toolchain/cross-gnu]], without `--disable-multi-arch` + + i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...] + ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages: + ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string' + + Might simply be a missing patch(es) from master. + + * --build=X + + `long double` test: due to `cross_compiling = maybe` wants to execute a + file, which fails. Thus `--build=X` has to be set. + + * Check what all these are: + + running configure fragment for sysdeps/mach/hurd + checking Hurd header version... ok + running configure fragment for sysdeps/mach + checking for i586-pc-gnu-mig... i586-pc-gnu-mig + checking for mach/mach_types.h... yes + checking for mach/mach_types.defs... yes + checking for task_t in mach/mach_types.h... task_t + checking for thread_t in mach/mach_types.h... thread_t + checking for creation_time in task_basic_info... yes + checking for mach/mach.defs... yes + checking for mach/mach4.defs... yes + checking for mach/clock.defs... no + checking for mach/clock_priv.defs... no + checking for mach/host_priv.defs... no + checking for mach/host_security.defs... no + checking for mach/ledger.defs... no + checking for mach/lock_set.defs... no + checking for mach/processor.defs... no + checking for mach/processor_set.defs... no + checking for mach/task.defs... no + checking for mach/thread_act.defs... no + checking for mach/vm_map.defs... no + checking for mach/memory_object.defs... yes + checking for mach/memory_object_default.defs... yes + checking for mach/default_pager.defs... yes + checking for mach/i386/mach_i386.defs... yes + checking for egrep... grep -E + checking for host_page_size in mach_host.defs... no + checking for mach/machine/ndr_def.h... no + checking for machine/ndr_def.h... no + checking for i386_io_perm_modify in mach_i386.defs... yes + checking for i386_set_gdt in mach_i386.defs... yes + checking whether i586-pc-gnu-mig supports the retcode keyword... yes + + * `sysdeps/i386/stackguard-macros.h` + + See [[t/tls|t/tls]]. + + * Verify 77c84aeb81808c3109665949448dba59965c391e against + `~/shared/glibc/make_TAGS.patch`. + + * `HP_SMALL_TIMING_AVAIL` not defined anywhere. + + * Unify `CPUCLOCK_WHICH` stuff in `clock_*` files. + + * Not all tests are re-run in a `make -k tests; make tests-clean; make -k + tests` cycle. For example, after `make tests-clean`: + + $ find ./ -name \*.out + ./localedata/tst-locale.out + ./localedata/sort-test.out + ./localedata/de_DE.out + ./localedata/en_US.out + ./localedata/da_DK.out + ./localedata/hr_HR.out + ./localedata/sv_SE.out + ./localedata/tr_TR.out + ./localedata/fr_FR.out + ./localedata/si_LK.out + ./localedata/tst-mbswcs.out + ./iconvdata/iconv-test.out + ./iconvdata/tst-tables.out + ./stdlib/isomac.out + ./posix/wordexp-tst.out + ./posix/annexc.out + ./posix/tst-getconf.out + ./elf/check-textrel.out + ./elf/check-execstack.out + ./elf/check-localplt.out + ./c++-types-check.out + ./check-local-headers.out + ./begin-end-check.out + + * `CPUCLOCK_WHICH`, `t/cpuclock` + + /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime': + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH' + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH' + collect2: error: ld returned 1 exit status + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt' + make[1]: *** [rt/others] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' + make: *** [all] Error 2 + + * Missing interfaces, amongst many more. + + Many more are missing, some of which have been announced in `NEWS`, others + typically haven't (like new flags to existing functions). Typically, + porters will notice missing functionaly. But in case you're looking for + something to work on, here's a list. + + `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`, + `CLOCK_REALTIME_ALARM`, `O_PATH`, + `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27), + `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) + `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, + `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, + `setns`, `sync_file_range` + + * `chflags` + + IRC, OFTC, #debian-hurd, 2012-04-27: + + <Steap> Does anyone have any idea why int main(void) { return + chflags(); } will compile with gcc but not with g++ ? It says + that "chflags" was not declared in this scope. + <Steap> I get the same error on FreeBSD, but including sys/stat.h + makes it work + <Steap> Can't find a solution on Hurd though :/ + <youpi> the Hurd doesn't have chflags + <youpi> apparently linux neither + <youpi> what does it do? + <Steap> change flags :) + <Steap> Are you sure the Hurd does not have chflags ? Because gcc + does not complain + <youpi> there is no chflags function in /usr/include + <youpi> but what flags does it change? + <Steap> According to the FreeBSD manpage, it can set flags such as + UF_NODUMP, UF_IMMUTABLE etc. + <youpi> Hum, there is actually a chflags() definition + <youpi> but no declaration + <youpi> so actually chflags is supported, but the declaration was + forgotten + <youpi> probably because since linux doens't have it, it has never + been a problem up to now + <youpi> so I'd say ignore the error for now, we'll add the + declaration + + * `getcontext`/`setcontext` + + Needed for [[gccgo]]. + + IRC, freenode, #hurd, 2012-04-19: + + <gnu_srs> How much work/knowledge is needed to implement + getcontext/setcontext? + <gnu_srs> Any already implemented alternatives available? + <youpi> x86 registers knowledge, as well as unix signal masks + <youpi> there's the linux implementation that can be taken as an + exxample, but the signal part has to be rewritten + <gnu_srs> Well, it's a pity they are not implemented. That's the + remaining hurdle to get gccgo working :-( + <youpi> uh :/ + <gnu_srs> Everything builds, but the testsuite fails due to these + missing functions. + <gnu_srs> Regarding getcontext/setcontext they seem to be written + in assembly for linux but the code is not very long. + <gnu_srs> How much effort would it be to write something similar + for Hurd? Anybody fluent in asm? + <gnu_srs> And registers and signals. + <tschwinge> gnu_srs: Signals is the key thing -- everything else we + can probably just copy. I have never/not yet looked at it, + though. + <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in + one file: getcontext, setcontext, swapcontext, not makecontext. + <gnu_srs> Dunno how much assembly calls used though. + <gnu_srs> Hi, any preferences about implementing get/setcontext in + C or Asm? + <tschwinge> gnu_srs: I think these will have to be implemented in + assembly. Based on the Linux x86 variants. + + IRC, freenode, #hurd, 2012-04-20: + + <tschwinge> youpi: Your understanding of that is better than mine + -- the *context stuff can't be very useful at the moment, because + when the user changes uc_stack.ss_sp (which the glibc tests are + doing), we're losing access to the _hurd_threadvars. Correct? + <tschwinge> At least the getcontext test works, the other get a + SIGILL. + <tschwinge> others + <tschwinge> _hurd_threadvars issue is just guessing. + <youpi> tschwinge: yes, threadvars are on the stack + <youpi> threadvars is not much code, it should just work, but care + has to be taken on the libpthread/libthread side, which does some + initialization + <tschwinge> OK, that at least matches my understanding. + + * [[`mremap`|mremap]] + + * `syncfs` + + We should be easily able to implement that one. + + * `futimesat`, `readlinkat`, `renameat` + + If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`. + + * `bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT` + + * `io/fcntl.h [__USE_ATFILE]` + + Do we support `AT_FDCWD` et al.? + (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.) + + * `MAP_POPULATE` (`mmap`, `sys/mman.h`) -- *Populate (prefault) + pagetables.* + + Some Linux kernel version, `mm/mmap.c`: + + if (vm_flags & VM_LOCKED) { + if (!mlock_vma_pages_range(vma, addr, addr + len)) + mm->locked_vm += (len >> PAGE_SHIFT); + } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK)) + make_pages_present(addr, addr + len); + return addr; + + Is only advisory, so can worked around with `#define MAP_POPULATE 0`, + 8069478040336a7de3461be275432493cc7e4c91. + + * `t/opendirat`: `opendirat` (`scandirat`, `scandirat64`) + + Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 + + 14d96785125abee5e9a49a1c3037f35a581750bd. + + * `madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP` + + [[glibc_madvise_vs_static_linking]]. + + * `msync` + + Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`. + + * `sys/epoll.h` + + Used by [[wayland]], for example. + + * `sys/eventfd.h` + + * `sys/inotify.h` + + * `sys/signalfd.h` + + * `sys/timerfd.h` + + * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51) + + * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`) + + IRC, freenode, #hurd, 2012-04-20: + + <pinotree> in glibc, we use the generic waitflags.h which, unlike + linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, + WCONTINUED + <pinotree> should the generic bits/waitflags.h define them anyway, + since they are posix? + <youpi> well, we'd have to implement them anyway + <youpi> but otherwise, I'd say yes + <pinotree> sure, but since glibc headers should expose at least + everything declared by posix, i thought they should be defined + anyway + <youpi> that might bring bugs + <youpi> some applications might be #ifdefing them + <youpi> and break when they are defined but not working + <pinotree> i guess they would define them to 0, andd having them to + non-zero values shouldn't break them (since those values don't do + anything, so they would act as if they were 0.. or not?) + <youpi> no, I mean they would do something else, not define them to + 0 + <pinotree> like posix/tst-waitid.c, you mean? + <youpi> yes + + For specific packages: + + * [[octave]] + + * Create `t/cleanup_kernel-features.h`. + + * Add tests from Linux kernel commit messages for `t/dup3` et al. + + * In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of + `-DHAVE_SENDFILE` -- but we do have `sendfile`, too. + + * `/usr/include/pthread.h` overwrite issue + + `make`, after editing `nss/nss_db/db-initgroups.c`: + + [...] + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv' + make subdir=nss -C nss ..=../ others + make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + make[2]: *** [/usr/include/pthread.h] Error 1 + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + make[1]: *** [nss/others] Error 2 + make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker' + make: *** [all] Error 2 + + See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]]. Passing + `install_root=/INVALID` to `make`/`make check` is a cheap cure. For `make + install`, prepending an additional slash to `install_root` (that is, + `install_root=//[...]`) is enough to obfuscate the Makefile rules. + + * `sysdeps/unix/sysv/linux/syslog.c` + + * Verify baseline changes, if we need any follow-up changes: + + * a11ec63713ea3903c482dc907a108be404191a02 + * 7e2b0c8562b35155820f87b5ff02a8b6850344cc + * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9 + * 5a2a1d75043138e696222ced4560de2fb90b8024 + * 5ae958d74180e2572d198bd7872c86f391de6da7 + * 5b08ac571ff8e94fe96511a532f0d20997de5f52 + * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26 + * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf + * 63c4ed22b5048c8701d8806026c23cc95f0df756 + * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c + * e35fcef8b739ed24e083ff8a3078ac14e101cf67 + * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba + * 8a492a675e566dc1e666df0a86cbf541442cb179 + * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef + * c86434ccb576a3ce35b5a74f72b9f03bd45b522a + * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 + * 15bac72bac03faeb3b725b1d208c62160f0c3ad7 + * c08fb0d7bba4015078406b28d3906ccc5fda9d5a + * 10b3bedcb03386cc280113f552479793e4bac35f + * 754f7da38b0904b4b989d3500cc8dd5be625cf6a + * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d + * 962dba7828cf251a9025ccb43bc6effa30379b72 + * 3162f12e58c3a848db883916843b332b9f8c9d39 + * 1c06ba3100847da6bd1f2e011dc24fa8debd9615 + * 84b9230c404aed4fd3a7bb3d045ca367043dde8c + * 090555538d4347a52807ba9f08cf20ed13206afe + * 817328eea788c746131cf151b64fd250200da333 + * c3758feebf7c8786231465da664743c6f0ec79cc + * 1ac7a2c7b448c851eb8976fcc290a906a4075203 + * c21cc9bcb38a87ff638d1099ca871d94a2192b31 + * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde + * b8b4863d78bf26b39918fc753b03ed98ef262903 + * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1 + * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in + `sysdeps/mach/hurd/dl-sysdep.c` + * 0e516e0e14f2f9783a21cd1727bc53776341f857 + * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc + * cf7c9078a5acdbb435498ace92cd81009637a971 + * db753e2cfb2051ebf20dc089f87c5b1297cc2cff + * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good. + * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b + * 451f001b50870604e1f2daef12f04f9f460d3997 + + a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484. `nptl/Versions + [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`. We don't even + define it yet. Also see + [[glibc___libc_alloca_cutoff_should_be_lowered]]. + * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34 + * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca + * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f + * 68dc949774cb651d53541df4abdc60327f7e096b + * 70181fddf1467996bea393d13294ffe76b8a0853 + * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca + * 32465c3ea007065acd8ca8199f130cdf4068130d + * 18ba70a559c52719fd94a713cc380514d9d19125 + * 620a05296fe3380b7441ba7720e8b25c48a8c28c + * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in + TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c` + hunk? + * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 + + 1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix + pathconf(_PC_BUF_SIZE).` + * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.` + * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 + + 6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long + paths` + * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler + call in spawn implementation` + * 3b85df27870a47ed1db84e948e37a5a50a178a92 + + f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf + * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid + timeouts in emulated pselect` + * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`; + strndupa? + * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative + error numbers in strerror_r`. Change needed for + `sysdeps/mach/_strerror.c`? + * 7ea72f99966a65a56aedba817ee2413ff9b1f23c + + adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer + in XPG strerror function`. Change needed for + `sysdeps/mach/xpg-strerror.c`? + * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss. Does it work? + * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 + + 80e2212d8e59933a1641f029ebd360526ff0e074 + + 4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code + used for raise()`. Also for `bits/siginfo.h`? + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work? + Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`, + `/proc/[PID]/mem` ([[!tag open_issue_hurd]], + [[hurd/translator/procfs]]). + * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`. + Watch what happens. + * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`. Watch + what happens. Native build: apparently OK. + * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) + + 1b74661a6b93a892ecb1c717dedeedba5c2a976c + + fd5e21c75d8e9221d766f4bc922a237265514ec2. Watch what happens. Native + build: `use-default-link = no`. + * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`), + 4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in + {,f}pathconf`). What about stuff like that for us? + * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with + AC_CHECK_TOOL`). Aren't there more in other configure.in and Makefile + files? + * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in + cancellation initialization`). Is this needed in other places, too? + * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64 + bytes`). Probably we have hidden somewhere such a constant, too (in + libpthread). + * d96de9634a334af16c0ac711074c15ac1762b23c + + ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn* + only in compat mode`). Change looks good, but what about + `SPAWN_XFLAGS_TRY_SHELL` for us? + * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features + mandatory and simplify the code.`). Generally looks good. + * `locale/global-locale.c`: Apparently, no one is using + `_HURD_THREADVAR_LOCALE`. But it is exported via + `hurd/threadvar.h`. + * `mach/devstream.c`: reversed. Fixed in + `t/repair-mach_devstream.c`. + * `malloc/arena.c`: should be OK. + * `Remove support for !USE___THREAD`. + d063d164335938d557460bebaa7cfe388157b627 (generally looks good; + `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) + + (de82006d43e198fd162807c9adc720c7ebd728a3 + + 037e9fe21c92216ef7032ea2796781ec27ca182a) + + 995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) + + bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok). + * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all + kinds of unused configuration options and dead code.`). `NO_STARTER` + changes (should be OK). + * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify + malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237, `BZ + 11929`. Is this all kosher for us? See [[!message-id + "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. + * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls + option, TLS support is required`). + * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in + __cmsg_nxthdr`). Probably just a C++ thing and not relevant for us; + see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]]. + * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7. Kosher with + respect to our [[glibc/mmap]] peculiarities? + * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`, + aa78043a4aafe5db1a1a76d544a833b63b4c5f5c + + 49a43d80ec5c97cf6136b1ee2687414773b2d5aa + + 3871f58f065dac3917eb18220a479e9591769c8c + + 9beb2334930db81ceada5aa6051fe5ac0554db32 + + 0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 + + edc5984d4d18296d7aa3d8f4ed8f7336a743170e + + 57769839788e2c62b68d9dfbf4b35052321278ba. + <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. + * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 + + 4efeffc1d583597e4f52985b9747269e47b754e2 + + d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror + `bits/siginfo.h` changes. + * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe, + [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for + us? + * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 -- + probably should do similar changes, also to the generic file. + * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id + "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]] + 02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same + for the generic version as used by GNU Hurd. + * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4, + [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what + about other architectures? + * `sendmmsg` usage, c030f70c8796c7743c3aa97d6beff3bd5b8dcd5d -- need a + `ENOSYS` stub, [[!message-id "87a9zubdm9.fsf@schwinge.name"]], + `t/sendmmsg`. + * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to + adapt for (conditional?) Sun RPC reversion (if that was the original + cause for the patch)? + * [low] `Add __fsword_t and use it in bits/statfs.h`, + 3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id + "20120517134700.GA19046@intel.com"]] -- only updates one copy of + `bits/statfs.h`; update the others, too, for consistency. + * *baseline* + + +# Build + +Here's a log of a glibc build run; this is from our [[Git repository's +8958805c11c741d9211e20612c86271d906c9a0b (2012-07-28; 2012-06-30) +sources|source_repositories/glibc]], run on coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../Roger_Whittaker/configure AUTOCONF=: --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build + [...] + $ make install_root=/INVALID 2>&1 | tee log_build_ + [...] + +This takes up around 500 MiB and needs roughly X min on kepler.SCHWINGE and 100 +min on coulomb.SCHWINGE. + +<!-- + + $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test + +Mask out gcc-4.X (with possibly a backslash before the dot), GCC 4.5's column +output for (warning, error) messages, GCC 4.6's `[-Wsomething]` or `[enabled by +default]` identifiers which warning flag triggered. + + $ for f in log_*; do sed -e 's%gcc-4\\\?.[456]%[GCC]%g' -e 's%g++-4\\\?.[456]%[G++]%g' -e 's%\(:[0-9]\+:\)[0-9]\+:%\1%' -e 's% \[\(-W[a-z-]\+\|enabled by default\)\]$%%' < "$f" > "$f".nv; done + + $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do ~/tmp/gcc/git/contrib/compare-debug --preserve ../Roger_Whittaker.build-gcc-4.4-486.O/"$f" "$f"; done 2>&1 | less + $ while read f; do (readelf -a "$f" && objdump -xDrtw "$f") > N && (cd ../Roger_Whittaker.build-gcc-4.4-486.O/ && readelf -a "$f" && objdump -xDrtw "$f") > O && diff -u O N | less; done + $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do readelf -h "$f" | grep OS/ABI | (read a b && [ x"$b" != x'UNIX - System V' ] && echo "### $f: $b"); done + +--> + + +## Analysis + + $ toolchain/logs/process gcc build fetch coulomb.SCHWINGE + +TODO. + + * With GCC 4.5, there's a ton of these warnings: + + hurd/hurd.h: In function '__hurd_fail': + hurd/hurd.h:73: warning: case value '0' not in enumerated type 'error_t' + + ... as well as a few individual instances: + + hurdselect.c: In function '_hurd_select': + hurdselect.c:265: warning: case value '0' not in enumerated type 'error_t' + get-host.c: In function '_hurd_get_host_config': + get-host.c:38: warning: case value '0' not in enumerated type 'error_t' + hurdmsg.c: In function '_S_msg_get_init_ints': + hurdmsg.c:186: warning: case value '0' not in enumerated type 'error_t' + hurdmsg.c: In function '_S_msg_set_init_ints': + hurdmsg.c:273: warning: case value '0' not in enumerated type 'error_t' + intr-msg.c: In function '_hurd_intr_rpc_mach_msg': + intr-msg.c:363: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/setitimer.c: In function 'timer_thread': + sysdeps/mach/hurd/setitimer.c:117: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/wait4.c: In function '__wait4': + sysdeps/mach/hurd/wait4.c:40: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/fork.c: In function '__fork': + sysdeps/mach/hurd/fork.c:423: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/spawni.c: In function '__spawni': + sysdeps/mach/hurd/spawni.c:600: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/setpriority.c: In function 'setonepriority': + sysdeps/mach/hurd/setpriority.c:66: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/ioctl.c: In function 'send_rpc': + sysdeps/mach/hurd/ioctl.c:177: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/ioctl.c: In function '__ioctl': + sysdeps/mach/hurd/ioctl.c:306: warning: case value '0' not in enumerated type 'error_t' + + [[!message-id "20120723195143.7F8142C0B9@topped-with-meat.com"]]. + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + introduces: + + genops.c: In function '_IO_flush_all_lockp': + genops.c:869:3: warning: passing argument 1 of '__save_FCT' makes pointer from integer without a cast [enabled by default] + genops.c:869:3: note: expected 'void *' but argument is of type 'int' + + A similar warning has already been (and still is) seen here: + + dl-iteratephdr.c:83:3: warning: passing argument 1 of '__save_FCT' makes pointer from integer without a cast [enabled by default] + dl-iteratephdr.c:83:3: note: expected 'void *' but argument is of type 'int' + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + (or probably Samuel's mmap backport) introduces: + + ../sysdeps/mach/hurd/mmap.c: In function '__mmap': + ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default] + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + introduces: + + nscd_gethst_r.c: In function '__nscd_get_nl_timestamp': + nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] + + This was already present before: + + nscd_gethst_r.c: In function 'nscd_gethst_r': + nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] + + * baseline + 2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032 + introduces: + + In file included from regex.c:62:0: + regcomp.c: In function 'init_word_char': + regcomp.c:935:4: warning: large integer implicitly truncated to unsigned type [-Woverflow] + regcomp.c:936:4: warning: large integer implicitly truncated to unsigned type [-Woverflow] + + tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] + + +# Install + +TODO. + + $ make install_root="$PWD".install install 2>&1 | tee log_install + [...] + +This takes up around 100 MiB, and needs roughly X min on kepler.SCHWINGE and 16 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc install fetch coulomb.SCHWINGE + +TODO. + +<!-- + $ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-linux.sed) <(ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_install | sed "s%\(/media/erich\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-hurd.sed) > open_issues/gdb/log_install.diff + +[[log_install.diff]]. + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + +--> + + +# Testsuite + + $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test + [...] + +This needs roughly X min on kepler.SCHWINGE and 60 min on coulomb.SCHWINGE. + +Specifying `fast-check=yes` disables the `conformtest` which takes 1.75 h (out +of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't +our most critical issue to solve. + +<!-- + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/data\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_linux + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_hurd + +Comparing the results files, [[sum_linux]] to [[sum_hurd]]: + + $ diff -u -F ^Running open_issues/gdb/sum_linux open_issues/gdb/sum_hurd > open_issues/gdb/sum.diff + +[[open_issues/gdb/sum.diff]]. +--> + + +## Analysis + + $ toolchain/logs/process gcc test fetch coulomb.SCHWINGE + +There is quite a baseline of failures. + + +### Additional Failures Compared to Debian + + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test > log_test.filtered + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered + + * `bug-atexit3.out`, `debug/tst-chk4`, `debug/tst-chk5`, `debug/tst-chk6`, + `debug/tst-lfschk4`, `debug/tst-lfschk5`, `debug/tst-lfschk6` + + dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory + + See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]]. + Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6 + /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`. + This is a bug in the glibc test harness. Should probably use some + `configure` magic akin to the `fixincludes` stuff (`gcc-4.4 + -print-file-name=libstdc++.so.6`, etc.). + + * `debug/tst-chk4`, `debug/tst-chk5`, `debug/tst-chk6`, `debug/tst-lfschk4`, + `debug/tst-lfschk5`, `debug/tst-lfschk6` + + Fail in the same way as the C ones, `tst-chk1..3`. + + * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`, + `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`, + `grp/tst_fgetgrent`, `dlfcn/tststatic`, `dlfcn/tststatic2`, + `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory + + Looking into `localedata/bug-setlocale1.c`, it is clear what it going on: + only the root of the build directory is added for `--library-path`, but + none of the other directories that are additionally used. This is a bug in + the glibc test harness. Hacked around by `ln -s mach/libmachuser.so.1 + hurd/libhurduser.so.0.3 ./`. Hopefully the other instances are similar. + + * `posix/tst-getconf` + + Ends with: + + getconf POSIX_ALLOC_SIZE_MIN /: /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/posix/getconf: pathconf: /: Invalid argument + + * `dlfcn/tststatic`, `dlfcn/tststatic2` + + No output, SEGFAULT. + + * `math/test-idouble`, `math/test-ifloat`, `math/test-ildoubl`, + `math/test-ldouble` + + SIGSEGV. + + * `rt/tst-aio10`, `rt/tst-aio9` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `do_test': + tst-aio10.c:(.text+0x1b): undefined reference to `pthread_self' + tst-aio10.c:(.text+0x78): undefined reference to `pthread_barrier_init' + tst-aio10.c:(.text+0xf7): undefined reference to `pthread_create' + tst-aio10.c:(.text+0x10b): undefined reference to `pthread_barrier_wait' + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `tf': + tst-aio10.c:(.text+0x5ae): undefined reference to `pthread_barrier_wait' + tst-aio10.c:(.text+0x5ef): undefined reference to `pthread_kill' + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10] Error 1 + + * `rt-tst-aio2`, `rt-tst-aio3`, `rt/tst-mqueue3`, `rt/tst-mqueue6`, + `rt/tst-mqueue8`, `elf/tst-thrlock`, `rt/tst-timer3`, + `nss//libnss_test1.so` + + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + * `elf/tst-audit1`, `elf/tst-audit2` + + SIGKILL. + + * `inet/tst-ether_line` + + tst-ether_line.c:19: error: 'ETH_ALEN' undeclared (first use in this function) + + Will either need a `hurd/netinet/if_ether.h` that includes + `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`? + See also [[!sourceware_PR 11142]]. + + * `gmon/tst-sprofil` + + Floating point exception + + * `posix/bug-regex31-mem`, `posix/tst-fnmatch-mem` + + *output* files: some memory not freed. + + * `assert/test-assert.out` + + Fails sometimes... + + * `stdlib/bug-getcontext.out` + + getcontext failed, errno: 1073741902. + + Is not implemented; see above. In 8958805c11c741d9211e20612c86271d906c9a0b + testing, `stdlib/bug-getcontext.out` now says: *Skipping test; no support + for FP exceptions.* + + * `elf/tst-unique3lib.so`, `elf/tst-unique3lib2.so`, `elf/tst-unique4lib.so` + + Only with GCC 4.4; no longer with 4.5 or 4.6: + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/elf/tst-unique3lib.os:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0' + + * `math/test-fenv.out` + + Used to fail (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`), but something between + 22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and + 005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely + Jérémie's signaling work. + + * `posix/tst-waitid.out` + + Fails sometimes (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`). + + * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d, + [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]]) + + Unused direct dependencies: + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2 + + As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes -- + correct? + + +## OLD + +`configure --without-cvs --prefix= --disable-profile --build=i486-gnu +--host=i486-gnu` + +`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to +c9fd33ef070def49c078c94f8d9bc9f8a8e267f7. + +Configured with `--prefix=/usr` instead of `--prefix=`. + +Resolved failures: + + * localedata/tst_mblen.out + * localedata/tst_mbrlen.out + * localedata/tst_mbrtowc.out + * localedata/tst_mbsrtowcs.out + * localedata/tst_mbstowcs.out + * localedata/tst_mbtowc.out + * localedata/tst_swscanf.out + * localedata/tst_wcrtomb.out + * localedata/tst_wcsrtombs.out + * localedata/tst_wcstombs.out + * localedata/tst_wctob.out + * localedata/tst_wctomb.out + * localedata/bug-iconv-trans.out + * localedata/tst-wctype.out + * math/test-float.out + * math/test-double.out + * posix/tst-vfork3-mem + * io/tst-mkdirat.out + +New: + + * A lot of `error while loading shared libraries: libmachuser.so.1: cannot + open shared object file: No such file or directory`. Is it perhaps picking + that library up from `$prefix/lib/`? + + New failures; likely due to that: + + * iconvdata/iconv-test.out + * iconvdata/tst-tables.out + * malloc/tst-mtrace.out + * grp/tst_fgetgrent.out + * posix/globtest.out + * posix/wordexp-tst.out + * io/ftwtest.out + * elf/tst-pathopt.out + + Changed failures; likely due to that: + + * debug/tst-chk4.out / debug/tst-chk5.out + + -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory + +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory + +--- + +Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting. + +--- + +Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting. + +New failures: + + * posix/bug-glob3.out (SEGFAULT; but also on Linux) + * wctype/bug-wctypeh.o (compile error; but also on Linux) diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn new file mode 100644 index 00000000..331632f3 --- /dev/null +++ b/open_issues/glibc/debian.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + + +# Open Issues + +`threads = yes` is set in `debian/sysdeps/linux.mk` and +`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`. But this +is only read in `debian/rules` for deciding some `nscd` package issue? + +`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC +configuration. + +Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip +locale stuff. + +`--disable-compatible-utmp`? + + +# Building + +Run `debian/rules patch` to apply patches (instead of having it done during the +build). Then you can edit files manually. + +Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc. + +If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the +`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will +fail. (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for +example.) Why is this special handling only done for `xen`, but not for +`i686`? + +> Samuel: Historically because it's done that way in linux-i386. I don't know +> the real reason. + +Do `export LC_ALL=C` before building, otherwise the testsuite/make error +messages will be different from those stored in the +`debian/testsuite-checking/expected-results-*` files, resulting in a spurious +build failure. + +Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]` +to build (or `build` instead of `build-arch` to build the arch-independent +stuff, too). Can interrupt with `C-c` during locale stuff or testsuite if only +interested in the build tree. + +Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2 +[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the +architecture-dependent ones. + +The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules +EGLIBC_PASSES=libc' -nc -b -uc`. `-nc` will prevent the *clean step* which +would first try to un-patch, which may conflict if you have done any edits +apter applying patches. + +If the Debian symbol versioning file is not up to date and the build of Debian +packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the +environment \`\`helps''; see `man dpkg-gensymbols`. diff --git a/open_issues/glibc/getlogin_r.mdwn b/open_issues/glibc/getlogin_r.mdwn new file mode 100644 index 00000000..9980ea1f --- /dev/null +++ b/open_issues/glibc/getlogin_r.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="getlogin_r"]] + +[[!tag open_issue_glibc]] + + +# IRC, freenode, #hurd, 2012-04-23 + + * pinotree spots how our getlogin_r() implementation uses a static + buffer... + <braunr> oO + <pinotree> braunr: yeah, the _r means "reentrantbutnotreally" xD + <braunr> pinotree: that's amazing .. + <antrik> pinotree: without having checked the actual implementation, that + doesn't sound like a problem... + <antrik> caching doesn't break reentrancy. the problem with the plain + getlogin() is that a static buffer is *returned to the user* + <pinotree> antrik: http://paste.debian.net/164727/ + <braunr> ah, caching + <pinotree> i don't think this is caching at all + <antrik> pinotree: OK, not actually caching... but same effect as far as I + can tell + <antrik> pinotree: or is it the fixed size of the temporary variable you + are concerned about? + <pinotree> antrik: my concern was about the "static" of the buffer used for + the get_login rpc + <antrik> pinotree: I'm not sure that's a problem. can the login actually + ever change for a running process? + <pinotree> dunno + <pinotree> but if so, it would be pointless to do the rpc every time + instead of just once + <antrik> pinotree: true + * pinotree would just make it non-static and be safe + <antrik> pinotree: well, one might argue that allocating a KiB of stack + space is not very friendly, especially in a low-level library... + <antrik> not sure what the general policy is about such things in libc diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn new file mode 100644 index 00000000..a293eea0 --- /dev/null +++ b/open_issues/glibc/mremap.mdwn @@ -0,0 +1,221 @@ +[[!meta copyright="Copyright © 2011, 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]] + +[[!toc]] + + +# binutils gold + +## IRC, freenode, #hurd, 2011-01-12 + + <teythoon> I've been looking into building gold on hurd and it built fine + with one minor tweak + <teythoon> and it's working fine according to its test suite + <teythoon> the only problem is that the build system is failing to detect + the hurdish mremap which lives in libmemusage + <teythoon> on linux it is in the libc so the check succeeds + <teythoon> any hints on how to fix this properly? + <antrik> hm... it's strange that it's a different library on the Hurd + <antrik> are the implementations compatible? + <teythoon> antrik: it seems so, though the declarations differ slightly + <antrik> I guess the best thing is to ask on the appropriate list(s) why + they are different... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1 + mremap /usr/include/sys/mman.h + <teythoon> extern void *mremap (void *__addr, size_t __old_len, size_t + __new_len, int __flags, ...) __THROW; + <teythoon> vs + <antrik> of course it would be possible to modify the configure script to + check for the Hurd variant too; but first we should establish whether + here is actually any reason for being different, or it's just some + historical artefact that should be fixed... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern + void *mremap' mremap.c + <teythoon> extern void *mremap (void *, size_t, size_t, int, ...); + <teythoon> the problem is that the test fails to link due to the fact that + mremap isn't in the libc on hurd + <antrik> yeah, it would be possible for the configure script to check + whether it works when the hurdish extra library is added explicitely + <antrik> but again, I don't see any good reason for being different here in + the first place... + <teythoon> so should I create a patch to move mremap? + <antrik> if it's not too complicated, that would be nice... it's always + easier to discuss when you already have code :-) + <antrik> OTOH, asking first might spare you some useless work if it turns + out there *is* some reason for being different after all... + so where is the right place to discuss this? + <antrik> bug-hurd mailing list and/or glibc mailing list. not sure which + one is better -- I guess it doesn't hurt to crosspost... + +[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to +[[mailing_lists/bug-hurd]] would be fine, too. + + <teythoon> antrik: some further digging revealed that mremap belongs to + /lib/libmemusage.so on both hurd and linux + <teythoon> the only difference is that on linux there is a weak reference + to that function in /lib/libc-2.11.2.so + <teythoon> $ objdump -T /lib/libc-2.11.2.so | fgrep mremap + <teythoon> 00000000000cf7e0 w DF .text 0000000000000028 GLIBC_2.2.5 + mremap + <antrik> ah, it's probably simply a bug that we don't have this weak + reference too + <antrik> IIRC we had similar bugs before + <antrik> teythoon: can you provide a patch for that? + <teythoon> antrik: unfortunately I have no idea how that weak ref ended up + there + + <guillem> teythoon: also the libmemusage.s seems to be just a debugging + library to be used by LD_PRELOAD or similar + <guillem> which override those memory functions + <guillem> the libc should provide actual code for those functions, even if + the symbol is declared weak (so overridable) + <guillem> teythoon: are you sure that's the actual problem? can you paste + somewhere the build logs with the error? + <teythoon> guillem: sure + <teythoon> http://paste.debian.net/104437/ + <teythoon> that's the part of config.log that shows the detection (or the + failure to detect it) of mremap + <teythoon> this results in HAVE_MREMAP not being defined + <teythoon> as a consequence it is declared in gold.h and this declaration + conflicts with the one from sys/mman.h http://paste.debian.net/104438/ + <teythoon> on linux the test for mremap succeeds + <guillem> teythoon: hmm oh I guess it's just what that, mremap is linux + specific so it's not available on the hurd + <guillem> teythoon: I just checked glibc and seems to confirm that + <braunr> CONFORMING TO This call is Linux-specific, and should not be used + in programs intended to be portable. + <teythoon> ah okay + <teythoon> so I guess we shouldn't ship an header with that declaration... + <guillem> teythoon: yeah :/ good luck telling that to drepper :) + <guillem> teythoon: I guess he'll suggest that everyone else needs to get + our own copy of sys/mman.h + <guillem> s/our/their/ + <teythoon> hm, so how should I proceed? + <braunr> what's your goal ? + <braunr> detecting mremap ? + <teythoon> making binutils/gold compile ootb on hurd + <teythoon> I picked it from the open issues page ;) + <braunr> well, if there is no mremap, you need a replacement + <teythoon> gold has a replacement + <braunr> ok + <braunr> so your problem is fixing the detection of mremap right ? + <teythoon> yes + <braunr> ok, that's a build system question then :/ + <braunr> you need to ask an autotools guy + <teythoon> well, actually the build system correctly detects the absence of + mremap + <braunr> (gold does use the autotools right ?) + <teythoon> yes + <braunr> oh, i'm lost now (i admit i didn't read the whole issue :/) + <teythoon> it is just that the declaration in sys/mman.h conflicts with + their own declaration + <braunr> ah + <braunr> so in the absence of mremap, they use their own builtin function + <teythoon> yes + <teythoon> and according to the test suite it is working perfectly + <teythoon> gold that is + <teythoon> the declaration in mman.h has an extra __THROW + <guillem> a workaround would be to rename gold's mremap to something else, + gold_mremap for example + <braunr> that's really the kind of annoying issue + <braunr> you either have to change glibc, or gold + <guillem> yeah + <braunr> you'll face difficulty changing glibc, as guillem told you + <guillem> the correct solution though IMO is to fix glibc + <braunr> but this may be true for gold too + <braunr> guillem: i agree + <antrik> maybe it would be easiest actually to implement mremap()?... + <braunr> but as this is something quite linux specific, it makes sense to + use another internal name, and wrap that to the linux mremap if it's + detected + <braunr> antrik: i'm nto sure + <antrik> braunr: I don't think using such workarounds is a good + idea. clearly there would be no issue if the header file wouldn't be + incorrect on Hurd + <braunr> antrik: that's why i said i agree with guillem when he says "the + correct solution though IMO is to fix glibc" + <teythoon> what exactly is the problem with getting a patch into glibc? + <braunr> the people involved + <guillem> teythoon: and touching a generic header file + <braunr> but feel free to try, you could be lucky + <teythoon> but glibc is not an linux specific piece of software, right? + <braunr> teythoon: no, it's not + <guillem> erm... + <braunr> teythoon: but in practice, it is + <guillem> supposedly not :) + <antrik> braunr: BTW, by "easiest" I don't mean coding alone, but + coding+pushing upstream :-) + <guillem> so the problem is, misc/sys/mman.h should be a generic header and + as such not include linux specific parts, which are not present on hurd, + kfreebsd, etc etc + <braunr> antrik: yes, that's why guillem and i suggested the workaround + thing in gold + <antrik> that also requires pushing upstream. and quite frankly, if I were + the gold maintainer, I wouldn't accept it. + <guillem> but the easiest (and wrong) solution in glibc to avoid maintainer + conflict will probably be copying that file under hurd's glibc tree and + install that instead + <braunr> antrik: implementing mremap could be relatively easy to do + actually + <braunr> antrik: IIRC, vm_map() supports overlapping + <antrik> well, actually the easiest solution would be to create a patch + that never goes upstream but is included in Debian, like many + others... but that's obviously not a good long-term plan + <antrik> braunr: yes, I think so too + <antrik> braunr: haven't checked, but I have a vague recollection that the + fundamentals are pretty much there + <antrik> teythoon: so, apart from an ugly workaround in gold, there are + essentially three options: 1. implement mremap; 2. make parts of mman.h + conditional; 3. use our own copy of mman.h + <antrik> 1. would be ideal, but might be non-trivial; 2. would might be + tricky to get right, and even more tricky to get upstream; 3. would be + simple, but a maintenance burden in the long term + <teythoon> looking at golds replacement code (mmap & memcpy) 1 sounds like + the best option performance wise + +[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. +[[I|tschwinge]] remember some discussion about this, but have not yet worked on +locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. + + +# IRC, OFTC, #debian-hurd, 2012-06-19 + + <bdefreese> OK, how the heck do you get an undefined reference to mremap? + <youpi> simply because we don't have it + <pinotree> mremap exists only on linux + <bdefreese> It's in sys/mman.h + <pinotree> on linux? + <bdefreese> No, on GNU/Hurd + <bdefreese> /usr/include/i386-gnu/sys/mman.h + <youpi> that's just the common file with linux + <youpi> containing just the prototype + <youpi> that doesn't mean there's an implementation behind + <pinotree> youpi: hm no, linux has an own version + <youpi> uh + <bdefreese> Ah, aye, I didn't look at the implementation.. :( + <youpi> it's then odd that it was added to the generic sys/mman.h :) + <bdefreese> Just another stub? + <pinotree> ah, only few linux archs have own versions + <youpi> for the macro values I guess + <pinotree> http://paste.debian.net/175173/ on glibc/master + <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? + <youpi> rgrep on a linux box ;) + <youpi> <bits/mman.h> + <youpi> but that's again linuxish + <bdefreese> Aye but with us having that in the header it is causing some + code to be run which utilizes mremap. If that wasn't defined we wouldn't + be calling it. + <youpi> ah + <youpi> we could try to remove it indeed + <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined + __GNU__? + <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn new file mode 100644 index 00000000..b12b7558 --- /dev/null +++ b/open_issues/glibc/octave.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 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, OFTC, #debian-hurd, 2012-04-23 + + <pinotree> diffing the octave i386 vs hurd-i386 build logs gives + interesting surprises + <youpi> checking whether this system has an arbitrary file name length + limit... no | checking whether this system has an arbitrary + file name length limit... yes + <youpi> ? + <pinotree> not only that + <youpi> checking whether getcwd handles long file names properly... yes + | checking whether getcwd handles long file names properly... no, but it + is partly worki+ + <youpi> ? + <pinotree> -checking whether fdopendir works... yes + <pinotree> +checking whether fdopendir works... no + <pinotree> (- is i386, + is hurd-i386) + <pinotree> -checking whether getlogin_r works with small buffers... yes + <pinotree> +checking whether getlogin_r works with small buffers... no + <pinotree> -checking for working mkstemp... yes + <pinotree> +checking for working mkstemp... no + <pinotree> +checking for working nanosleep... no (mishandles large + arguments) diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn new file mode 100644 index 00000000..e72732ab --- /dev/null +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011, 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 open_issue_libpthread]] + +This basically means to get rid of `sysdeps/mach/hurd/bits/libc-tsd.h` (and +thus the `_HURD_THREADVAR_*`/`_hurd_threadvar_location` interface), and +directly use `__thread` instead. + +IRC, freenode, #hurd, 2011-10-23: + + <tschwinge> youpi: If we want to replace threadvars with TLS, there is one + problem: the threadvars interface is publically exported: + /usr/include/hurd/threadvar.h. + <tschwinge> youpi: But I am somewhat inclined to say that the only user of + this is libthreads/libpthread. Do you think differently? + <youpi> tschwinge: that's very probable + <youpi> so I think we can just drop it + <youpi> (people should use TLS anyway) + +[[libpthread_set_stack_size]]. + +After this has been done, probably the whole `__libc_tsd_*` stuff can be +dropped altogether, and `__thread` directly be used in glibc. diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn new file mode 100644 index 00000000..68db2cc1 --- /dev/null +++ b/open_issues/glibc/t/tls.mdwn @@ -0,0 +1,70 @@ +[[!meta copyright="Copyright © 2011, 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 open_issue_libpthread]] + +# To Do + + * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel. + + * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed. + + +# Documentation + +[[!taglink open_issue_documentation]] + + * IRC, freenode, #hurd, 2011-11-26 + + <tschwinge> In glibc multiarch support (strcasecmp for i686 SSE3, etc.) + there is access to memory via gs: -- this will need to be changed for + us, right? + <youpi> depends on the access + <tschwinge> * `optimized strcasecmp and strncasecmp for x86-32` + (multiarch), + <tschwinge> 76e3966e9efc3808a9e7ad09121c5dfc1211c20b + + <tschwinge> 6abf346582ba678f4850a88b4a5950593841df1d + + <tschwinge> 5583a0862cf94f71cbcde91c4043a20af65facca. `gs` + access. + <youpi> + movl __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax + <youpi> that's handled by the linker fine + <youpi> it's only the things held in the tcb_t structure which can pose + problem + <tschwinge> tcbhead_t? + <tschwinge> I'm looking at this. + <tschwinge> So, at gs:0, there is the TCB. + <tschwinge> And we have the same layout as NPTL/Linux, just that we + don't have as much data there as they have. + <tschwinge> We're missing multiple_threads, sysinfo, sttack_guard, + pointer_guard, gscope_flag, private_futex, __private_tm[5]. + <tschwinge> So, if one of these is referenced (be it my name or by + numeric offset), this is invalid for us. + <tschwinge> Anything else should work equivalently. + <youpi> yes + <youpi> usually the only numeric offset being used is 0 + <youpi> so it would simply not build + <tschwinge> And the other offsers are generated via tcb-offsets.sym. + <tschwinge> glibc's elf/stackguard-macros.h is wrong for us (but not + used anywhere apart from elf/tst-stackguard1.c, I think). + +After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's +`sysdeps/i386/stackguard-macros.h`; problem remains. + + <tschwinge> __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale; + -- this means that a __libc_tsd_LOCALE values will be in the TLS + segment, and this is what is being accessed from the assembler code + with %gs:__libc_tsd_LOCALE@NTPOFF, and the linker will resolve this. + <youpi> yes + <youpi> see in the nm output, the libc_tsd symbols + <youpi> these provide the offsets + <tschwinge> youpi: Thank you, I'm now understanding this part of TLS + much better. + <youpi> have you had a look at the tls.pdf from Uli ? + <youpi> all the gory details are there :) diff --git a/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn b/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn new file mode 100644 index 00000000..6d1b4bea --- /dev/null +++ b/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="glibc: __libc_alloca_cutoff should be lowered"]] + +[[!tag open_issue_hurd open_issue_glibc]] + +Ognyan Kulev, *[LIBC] \_\_libc\_alloca\_cutoff should be lowered*, bug-hurd, +2003-06-12, <http://lists.gnu.org/archive/html/bug-hurd/2003-06/msg00050.html> + +Replace second link (mail.gnu.org) with +<http://lists.gnu.org/archive/html/bug-hurd/2002-09/msg00143.html>. diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn new file mode 100644 index 00000000..14329d0f --- /dev/null +++ b/open_issues/glibc_ioctls.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010 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. + + <pinotree> d'oh, broken defines for ioctl()! + <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines + <pinotree> tschwinge: ↑ know anything about this? + <pinotree> #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h + <pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit + + <pinotree> youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header + <youpi> that's possible + <pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq' + <youpi> ah, that's not a bug then + <youpi> see the ioctl section of the porting page of the wiki + <pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq + <pinotree> +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough + * pinotree looks + <youpi> it's not to be done so simply + <youpi> see the page :) + <youpi> I'm afraid _IOT_arpreq can't be properly defined + * pinotree is not finding it... + <pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html + <youpi> that's it yes + <youpi> I mean, that's the kind of thing + <youpi> but not the wiki page, let me look + <youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html + <pinotree> i also saw a glib patch adding few types like that (char, short, int) + <youpi> yes that's the same kind of thing + <pinotree> i see + <youpi> setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such + <pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char[16] + <pinotree> so basically it would support at most 3 elements in a passed struct? + <pinotree> s/elements/fields/ + <youpi> 3 kinds of fields + <youpi> as you provide a count + <pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ? + <pinotree> ie the order of the fields in the struct does not matter, it seems? + <youpi> the order of the fields does matter + <youpi> as this encodes how mig will read the struct to send them + <pinotree> uhm + <youpi> also, _IOTS(struct sockaddr) won't work + <pinotree> yeah i should define it too + <youpi> no, it even needs to be replaced by its content + <pinotree> ah + <pinotree> it is possible to compose the _IOTS()? + <pinotree> (to build structs with more than 3 kind of fields) + <youpi> no + <pinotree> d'oh + <youpi> that's a hard shortcoming of the whole ioctl encoding + * pinotree scratches his head + <youpi> there's no way but redefining ioctl(), really + <youpi> it was a funny trick to encode it this way, but unrealistic + <pinotree> i see, yes + <youpi> not to mention ioctls which contain pointers, which just can not be passed to mig + <pinotree> indeed + <youpi> actually it's not mach's ioctl issue + <youpi> as mach doesn't know ioctl + <youpi> but the hurd ioctl interface + <pinotree> right + <youpi> which might end up in mach, other processes, other machines, etc. + * pinotree s/Mach/Hurd/ :) diff --git a/open_issues/glibc_libpthread_robust_mutexes.mdwn b/open_issues/glibc_libpthread_robust_mutexes.mdwn new file mode 100644 index 00000000..a92c984d --- /dev/null +++ b/open_issues/glibc_libpthread_robust_mutexes.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010 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 open_issue_libpthread]] + +libpthread: glibc 44e2ad5ab8c21dbfed3e384ba2ed31d7a8fc4744 +998e5fc14595229101561d76282036839e5b66ab -- The robust mutex functions are in +POSIX 2008. + +--- + +IRC, #hurd, unknown date. + + <youpi> neal: bad news: you remember the PTHREAD_RECURSIVE_MUTEX_INITIALIZER that points to a global __pthread_recursive_mutexattr? + <youpi> that doesn't work + <youpi> because some libraries like libstdc++ do not link against libpthread, while still using pthread_mutex_lock/unlock (counting on them being provided by either libc or libpthread-stubs) + <CIA-1> sthibaul-guest * r626 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): + <CIA-1> * debian/patches/libpthread_rwlock_initializer.patch: Disable patch for now: + <CIA-1> our initializer does not work when the application does not link against + <CIA-1> libpthread. + + <CIA-1> sthibaul-guest * r629 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): do not disable adding PTHREAD_RWLOCK_INITIALIZER, that's not the one that poses problems + <CIA-1> sthibaul-guest * r630 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_no_recursive_mutex_initializer.patch: New patch + <CIA-1> to drop undefined references to __pthread_recursive_mutexattr. + + <youpi> I'm thinking about how to fix the PTHREAD_RECURSIVE_MUTEX_INITIALIZER + <youpi> instead of a pointer to a static attribute variable, which posed problem + <youpi> could we perhaps consider that page 0 is never mapped + <youpi> and thus not only pointer 0 but also 1 2, etc. are invalid + <neal> I think that is a good solution + <youpi> and use them as special values + <neal> alternatively, we could assume that -PAGESIZE is never valid + <youpi> that makes us test it in all pthread_mutex_* functions, but it's not so bad + <neal> I'm not sure which is better + <youpi> why isn't it? + <neal> because the kernel is mapped there normally + <youpi> the kernel could be elsewhere + <neal> true + <youpi> in a 64bit adressing space for instance + <neal> I think your solution is a good one + <youpi> ok + + <CIA-1> sthibault * r633 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_recursive_mutex_initializer.patch: New patch + <CIA-1> to fix the recursive mutex initializers usage in libraries not linking + <CIA-1> against libpthread. diff --git a/open_issues/glibc_madvise_vs_static_linking.mdwn b/open_issues/glibc_madvise_vs_static_linking.mdwn new file mode 100644 index 00000000..ab633b0f --- /dev/null +++ b/open_issues/glibc_madvise_vs_static_linking.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2010, 2011, 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]] + +[[!sourceware_PR 4822]]. + + $ echo 'int main() {}' | gcc -o /dev/null -static -x c - + /usr/lib/gcc/i486-gnu/4.4.5/../../../libcrt.a(malloc.o): In function `_int_free': + (.text+0xdc3): warning: warning: madvise is not implemented and will always fail + +This is correct, but it does confuse GNU Autoconf, for example, which then +thinks that static linking is not supported and sets a flag accordingly, which +luckly no / not many packages use. + +*This call does not influence the semantics of the application (except in the +case of MADV_DONTNEED), but may influence its performance. The kernel is free +to ignore the advice.* (`man madvise`), so we may simply want to turn it into a +no-op in glibc, avoiding the link-time warning. + +GCC c5db973fdab3db3e13db575e5650c0bcfd3630f4 (2011-10-17) makes use of this. +As we now export the symbol (and `MADV_DONTNEED`, too), GCC will no longer +`munmap` pages, but will keep them mapped for later re-use. This may increase +memory usage. + +2011-07: This is what Samuel has [done for Debian +glibc](http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/local-madvise_warn.diff). + + +# IRC, freenode, #hurd, 2012-02-16 + + <tschwinge> youpi: With Roland's fix the situation will be that just using + gcc -static doesn't emit the stub warning, but still will do so in case + that the source code itself links in madvise. Is this acceptable for + you/Debian/...? + <youpi> packages with -Werror will still bug out + <youpi> not that I consider -Werror to be a good idea, though :) + <tschwinge> youpi: Indeed. Compiler warnings can be caused by all kinds of + things. -Werror is good for development, but not for releases. diff --git a/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn new file mode 100644 index 00000000..47f104c6 --- /dev/null +++ b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 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. + + <youpi> you can hardcode DTV_OFFSET as 4 for now + <youpi> it's the offset of the dtv field in the tcbhead_t structure from hurd/libpthread + <tschwinge> youpi: May very well be that I'm misunderstanding something, but wouldn't it rather be the offset of tcb in __pthread + the offset of dtv in tcbhead_t (which indeed is 4)? + <youpi> what you don't know is that DTV_OFFSET is not relative to __pthread, but to the tls segment + <tschwinge> Oh, aha. Thanks. + <youpi> and drepper abused the fact that in nptl __pthread appears at the start of the tls segment + +kFreeBSD, glibc: + + ++#if 0 + + DTV_OFFSET offsetof(struct pthread, header.dtv) + ++#else + ++DTV_OFFSET offsetof(struct _pthread_descr_struct, p_header.data.dtvp) + ++#endif diff --git a/open_issues/glusterfs.mdwn b/open_issues/glusterfs.mdwn new file mode 100644 index 00000000..68518938 --- /dev/null +++ b/open_issues/glusterfs.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +IRC, unknown channel, unknown date. + + <antrik> "GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It + <antrik> borrows a powerful concept called Translators from GNU Hurd kernel." + <antrik> seems to be more similar to libstore than actual translators, though diff --git a/open_issues/gnumach_console_timestamp.mdwn b/open_issues/gnumach_console_timestamp.mdwn new file mode 100644 index 00000000..52b574d5 --- /dev/null +++ b/open_issues/gnumach_console_timestamp.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +There is a [[!FF_project 267]][[!tag bounty]] on this task. + +IRC, freenode, #hurd, 2011-02-17 + + <azeem> task 39011c10 deallocating an invalid port 349, most probably a + bug. + <azeem> kernel: Page fault (14), code=6 + <azeem> Stopped at 0x28b9c7: orb %bh,0(%ecx,%edi,2) + <azeem> db> + [...] + <antrik> tschwinge: I doubt the deallocating warning is related to the + later fault + <tschwinge> antrik: YOu may be right. + <tschwinge> Perhaps it'd be a good idea to add some sort of timestamp to + Mach messages. + <tschwinge> Like in Linux' dmesg. + <tschwinge> Or just RDTSC (internal processor counter). diff --git a/open_issues/gnumach_constants.mdwn b/open_issues/gnumach_constants.mdwn new file mode 100644 index 00000000..16c8cf41 --- /dev/null +++ b/open_issues/gnumach_constants.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +At compile-time, GNU Mach is parameterized with several constants. These might +need some tuning. Debian has some patches. + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> youpi: in ipc/ipc_hash.c, there is code which computes the size of + the global (space, port)->entry hash table + <braunr> youpi: you may be interested in tuning this one too + <youpi> I know + <braunr> ok + <youpi> the current value is not so bad + <youpi> it's big enough for buildds to run fine + <braunr> 256 if i'm right + <braunr> well + <braunr> it won't fail + <youpi> we're limited by the 4000 object limitation anyway + <braunr> since it's a chained hash table + <braunr> but increasing it may help performances a bit + <braunr> and it certainly can't hurt much diff --git a/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn new file mode 100644 index 00000000..2df74301 --- /dev/null +++ b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn @@ -0,0 +1,142 @@ +[[!meta copyright="Copyright © 2010 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_gnumach]] + +IRC, unknown channel, unknown date. + + <antrik> youpi: I have found an interesting Mach problem, but I'm a bit scared of debugging it... + <antrik> (it is related to VM stuff) + <antrik> I have a memory region that is mapped by the iopl device (it's an mmio region -- graphics memory to be precise) + <antrik> when gdb tries to read that region with vm_read() (for a "print" command), it triggers a general protection trap... + <youpi> antrik: does the general protection trap kill the whole kernel or just gdb? + <antrik> kernel + <antrik> kernel: General protection trap (13), code=0 + <antrik> pmap_copy_page(41000000,49f2000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(209c1c54,41000000,1000,1,20994908) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(209c1c54,41000000,1000,20994908,2099490c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(209ba6e4,2c000,1000,0,25394ec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(209ba6e4,2c000,1000,208d303c,25394f00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(2095cfe4,208d3010,0,1fff3e48,2095cfd4) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(2095cfd4,2095cfe4,28,127ca0,0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(1024440,3,28,30,2c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x102441c + <antrik> BTW, is it useful at all to write down the paramenters as well?... + <antrik> argments I mean + <youpi> in the trace you mean? + <antrik> yes + <youpi> apparently the problem here is that the call to vm_fault_page() didn't perform its task + <youpi> which address is faulty? + <antrik> not sure what you mean + <youpi> ah shit the gpf wouldn't tell you + <youpi> does examine 49f2000 work? + <youpi> oh, wait, 4100000, that can't work + <youpi> +0 + <youpi> which physical address is your mmio at? + <antrik> haven't tried it... but I can provoke the fault again if it helps :-) + <youpi> we have the 1GB limitation issue + <antrik> oh... lemme check + <youpi> no need to, I think the problem is that + <youpi> the iopl driver should check that it's not above phys_last_addr + <antrik> it's only vm_read() that fails, though... + <antrik> the actual program I debugged in gdb works perfectly fine + <youpi> yes, but that's because it's accessing the memory in a different way + <youpi> in the case of direct reads it just uses the page table + <youpi> in the case of vm_read() it uses kernel's projection + <youpi> but in that case it's not in the kernel projection + <antrik> phys = 1090519040 + <youpi> that's it, it's beyond 1GB + <youpi> there's not much to do except changing mach's adressing organization + <antrik> yeah, that's the 0x41000000 + <antrik> hm... I guess we could make the vm_read() bail out instead of crashing?... + <youpi> yes + <youpi> but there are a lot of places like this + <antrik> still, it's not exactly fun when trying to debug a program and the kernel crashes :-) + <youpi> right :) + <antrik> I could try to add the check... if you tell me where it belongs ;-) + <youpi> antrik: it's not just one place, that's the problem + <youpi> it's all the places that call pmap_zero_page, pmap_copy_page, copy_to_phys or copy_from_phys + <youpi> and since we do want to let the iopl device create such kind of page, in principle we have to cope with them all + <youpi> pmap_zero_page should be ok, though + <youpi> the rest isn't + <antrik> is that tricky, or just a matter of doing it in all places? + + <antrik> hm... now it crashed in "normal" usage as well... + <antrik> hm... a page fault trap for a change... + <antrik> hm... now gdb tried to vm_read() something that is mapped to physical address 0x0... + <antrik> so I guess I fucked something up in the mapping code + <antrik> is it expected that such a vm_read() causes a kernel page fault, though?... + <antrik> youpi: ^ + <youpi> nope + <youpi> in principle the check for validity of the page is done earlier + <youpi> physical address 0x0 makes sense, though + <antrik> OK, here is the trace: + <antrik> Kernel page fault (14), code=0 at address 0x0 + <antrik> pmap_copy_page(0,6e54000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(20a067b0,0,1000,1,0acacec) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(20a067b0,0,1000,20acacec,20acacf0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(20a0f1c4,120d000,1000,0,253cdec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(20a0f1c4,120d000,1000,20a5703c,253cdf00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(20a52c80,20a57010,253cdf40,20ae33cc,20a52c70) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(20a52c70,20a52c80,28,20873074,20873070) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(10247d0,3,28,30,2f) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x10247ac + <antrik> seems to be exactly the same, except for the different arguments... + <antrik> hm... interesting... it *does* write something to the framebuffer, before it crashes... + <antrik> (which unfortunately makes it a bit hard to read the panic message... ;-) ) + <LarstiQ> heh :) + <antrik> wait, it must write to something else than the frame buffer as well, or else the debugger should just paint over the crap... + <antrik> or perhaps it crashes so hard that the debugger doesn't even work? ;-) + <antrik> hm... I guess the first thing I should actually do is finding out what's up with e2fsck... this make testing crashes kinda annoying :-( + <antrik> oh, "interesting"... I ran it on one of my other hurd partitions, and it complained about an endless number of files... (perhaps all) + <antrik> however, the value for the normal files was different than for the passive translator nodes + <antrik> it doesn't happen only on crashes; it seems that all passive translators that are still in use at time of shutdown (or crash) have the offending bit set in the inode + <antrik> ouch... seems it doesn't write into the framebuffer after all, but rather scribbles all over the first 4 MiB of memory -- which includes also the VGA window, before it goes on killing the kernel... + <youpi> which iopl driver are you using ? + <antrik> ? + <youpi> the one from the debian patch? + <youpi> upstream, gnumach doesn't have an iopl device any more + <antrik> I guess so... standard Debian stuff here + <antrik> oh. how does X map the memory, then? + <youpi> X does yes + <antrik> ? + <youpi> X uses the iopl() device to access the video memory, yes + <youpi> I don't know if that was what you were asking for, but that's what I meant by my answer :) + <antrik> yeah, I know how it does *currently* do it -- I stole the code from there :-) + <antrik> my question is, how is X supposed to get at the framebuffer, when there is no iopl device anymore? + <youpi> ah, I hadn't noticed the "how" word + <youpi> in Debian there is + <LarstiQ> !debian → !x? + <youpi> the clean "access device memory" interface is yet to be done + <antrik> err... that sounds like Xorg philosophy + <youpi> what, to wait for a nice interface ? + <antrik> "let's kill the old stuff, fuck regressions... maybe someone will figure out how to do it with the new stuff at some point. if not, not our problem" + <youpi> that's also a GNU philosophy + <youpi> ah, that one + <antrik> anyone know how device_map() is supposed to behave? the documentation isn't really clear... + <antrik> my understanding was then when an offset is specified, then the resulting object will be relative to that object; i.e. the offset of a later vm_map() on this object is applied on top of the object's internal offset... + <antrik> but that doesn't seem to be how it works for the iopl device, if I read the xf86 code correctly... + <antrik> yeah, the offset parameter seems a nop when doing device_map() on the iopl device diff --git a/open_issues/gnumach_i686.mdwn b/open_issues/gnumach_i686.mdwn new file mode 100644 index 00000000..b34df73b --- /dev/null +++ b/open_issues/gnumach_i686.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-05 + + <braunr> we could use a gnumach-i686 too + <pinotree> how would you compile gnumach as i686 variant btw? add + -march=.. or something like that in CFLAGS? + <braunr> yes + <braunr> at least we'll get some cmovs :) + + +## IRC, freenode, #hurd, 2012-07-07 + + <braunr> it was rejected in the past because we didn't think it would bring + real performance benefit, but it actually may diff --git a/open_issues/gnumach_integer_overflow.mdwn b/open_issues/gnumach_integer_overflow.mdwn new file mode 100644 index 00000000..2166e591 --- /dev/null +++ b/open_issues/gnumach_integer_overflow.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-04 + + <braunr> yes, we have integer overflows on resident_page_count, but + luckily, the member is rarely used diff --git a/open_issues/gnumach_kernel_threads.mdwn b/open_issues/gnumach_kernel_threads.mdwn new file mode 100644 index 00000000..9591986b --- /dev/null +++ b/open_issues/gnumach_kernel_threads.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +IRC, freenode, #hurd, 2011-07-13 + + <braunr> jkoenig: why does gnumach appear as "root=device:hd0s1" in ps ? + <jkoenig> braunr, it's the closest we can do to its command line + <braunr> doesn't it deserve something special like kernel threads in linux + ? + <braunr> so that it's actually clear that it's a special task/process + <jkoenig> you mean something like [mach root=device:hd0s1] ? + <braunr> something like that yes + <braunr> also, it would be nice if gnumach threads could actually be seen, + i don't remember if the mach interface allows it though diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn new file mode 100644 index 00000000..9feb30c8 --- /dev/null +++ b/open_issues/gnumach_memory_management.mdwn @@ -0,0 +1,2135 @@ +[[!meta copyright="Copyright © 2011, 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_gnumach]] + +There is a [[!FF_project 266]][[!tag bounty]] on this task. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-04-12 + + <antrik> braunr: do you think the allocator you wrote for x15 could be used + for gnumach? and would you be willing to mentor this? :-) + <braunr> antrik: to be willing to isn't my current problem + <braunr> antrik: and yes, I think my allocator can be used + <braunr> it's a slab allocator after all, it only requires reap() and + grow() + <braunr> or mmap()/munmap() whatever you want to call it + <braunr> a backend + <braunr> antrik: although i've been having other ideas recently + <braunr> that would have more impact on our usage patterns I think + <antrik> mcsim: have you investigated how the zone allocator works and how + it's hooked into the system yet? + <braunr> mcsim: now let me give you a link + <braunr> mcsim: + http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=330436e799f322949bfd9e2fedf0475660309946;hb=HEAD + <braunr> mcsim: this is an implementation of the slab allocator i've been + working on recently + <braunr> mcsim: i haven't made it public because i reworked the per + processor layer, and this part isn't complete yet + <braunr> mcsim: you could use it as a reference for your project + <mcsim> braunr: ok + <braunr> it used to be close to the 2001 vmem paper + <braunr> but after many tests, fragmentation and accounting issues have + been found + <braunr> so i rewrote it to be closer to the linux implementation (cache + filling/draining in bukl transfers) + <braunr> bulk* + <braunr> they actually use the word draining in linux too :) + <mcsim> antrik: not complete yet. + <antrik> braunr: oh, it's unfinished? that's unfortunate... + <braunr> antrik: only the per processor part + <braunr> antrik: so it doesn't matter much for gnumach + <braunr> and it's not difficult to set up + <antrik> mcsim: hm, OK... but do you think you will have a fairly good + understanding in the next couple of days?... + <antrik> I'm asking because I'd really like to see a proposal a bit more + specific than "I'll look into things..." + <antrik> i.e. you should have an idea which things you will actually have + to change to hook up a new allocator etc. + <antrik> braunr: OK. will the interface remain unchanged, so it could be + easily replaced with an improved implementation later? + <braunr> the zone allocator in gnumach is a badly written bare object + allocator actually, there aren't many things to understand about it + <braunr> antrik: yes + <antrik> great :-) + <braunr> and the per processor part should be very close to the phys + allocator sitting next to it + <braunr> (with the slight difference that, as per cpu caches have variable + sizes, they are allocated on the free path rather than on the allocation + path) + <braunr> this is a nice trick in the vmem paper i've kept in mind + <braunr> and the interface also allows to set a "source" for caches + <antrik> ah, good point... do you think we should replace the physmem + allocator too? and if so, do it in one step, or one piece at a time?... + <braunr> no + <braunr> too many drivers currently depend on the physical allocator and + the pmap module as they are + <braunr> remember linux 2.0 drivers need a direct virtual to physical + mapping + <braunr> (especially true for dma mappings) + <antrik> OK + <braunr> the nice thing about having a configurable memory source is that + <antrik> whot do you mean by "allocated on the free path"? + <braunr> even if most caches will use the standard vm_kmem module as their + backend + <braunr> there is one exception in the vm_map module, allowing us to get + rid of either a static limit, or specific allocation code + <braunr> antrik: well, when you allocate a page, the allocator will lookup + one in a per cpu cache + <braunr> if it's empty, it fills the cache + <braunr> (called pools in my implementations) + <braunr> it then retries + <braunr> the problem in the slab allocator is that per cpu caches have + variable sizes + <braunr> so per cpu pools are allocated from their own pools + <braunr> (remember the magazine_xx caches in the output i showed you, this + is the same thing) + <braunr> but if you allocate them at allocation time, you could end up in + an infinite loop + <braunr> so, in the slab allocator, when a per cpu cache is empty, you just + fall back to the slab layer + <braunr> on the free path, when a per cpu cache doesn't exist, you allocate + it from its own cache + <braunr> this way you can't have an infinite loop + <mcsim> antrik: I'll try, but I have exams now. + <mcsim> As I understand amount of elements which could be allocated we + determine by zone initialization. And at this time memory for zone is + reserved. I'm going to change this. And make something similar to kmalloc + and vmalloc (support for pages consecutive physically and virtually). And + pages in zones consecutive always physically. + <mcsim> Am I right? + <braunr> mcsim: don't try to do that + <mcsim> why? + <braunr> mcsim: we just need a slab allocator with an interface close to + the zone allocator + <antrik> mcsim: IIRC the size of the complete zalloc map is fixed; but not + the number of elements per zone + <braunr> we don't need two allocators like kmalloc and vmalloc + <braunr> actually we just need vmalloc + <braunr> IIRC the limits are only present because the original developers + wanted to track leaks + <braunr> they assumed zones would be large enough, which isn't true any + more today + <braunr> but i didn't see any true reservation + <braunr> antrik: i'm not sure i was clear enough about the "allocation of + cpu caches on the free path" + <braunr> antrik: for a better explanation, read the vmem paper ;) + <antrik> braunr: you mean there is no fundamental reason why the zone map + has a limited maximal size; and it was only put in to catch cases where + something eats up all memory with kernel object creation?... + <antrik> braunr: I think I got it now :-) + <braunr> antrik: i'm pretty certin of it yes + <antrik> I don't see though how it is related to what we were talking + about... + <braunr> 10:55 < braunr> and the per processor part should be very close to + the phys allocator sitting next to it + <braunr> the phys allocator doesn't have to use this trick + <braunr> because pages have a fixed size, so per cpu caches all have the + same size too + <braunr> and the number of "caches", that is, physical segments, is limited + and known at compile time + <braunr> so having them statically allocated is possible + <antrik> I see + <braunr> it would actually be very difficult to have a phys allocator + requiring dynamic allocation when the dynamic allocator isn't yet ready + <antrik> hehe :-) + <mcsim> total size of all zone allocations is limited to 12 MB. And is "was + only put in to catch cases where something eats up all memory with kernel + object creation?" + <braunr> mcsim: ah right, there could be a kernel submap backing all the + zones + <braunr> but this can be increased too + <braunr> submaps are kind of evil :/ + <antrik> mcsim: I think it's actually 32 MiB or something like that in the + Debian version... + <antrik> braunr: I'm not sure I ever fully understood what the zalloc map + is... I looked through the code once, and I think I got a rough + understading, but I was still pretty uncertain about some bits. and I + don't remember the details anyways :-) + <braunr> antrik: IIRC, it's a kernel submap + <braunr> it's named kmem_map in x15 + <antrik> don't know what a submap is + <braunr> submaps are vm_map objects + <braunr> in a top vm_map, there are vm_map_entries + <braunr> these entries usually point to vm_objects + <braunr> (for the page cache) + <braunr> but they can point to other maps too + <braunr> the goal is to reduce fragmentation by isolating allocations + <braunr> this also helps reducing contention + <braunr> for exemple, on BSD, there is a submap for mbufs, so that the + network code doesn't interfere too much with other kernel allocations + <braunr> antrik: they are similar to spans in vmem, but vmem has an elegant + importing mechanism which eliminates the static limit problem + <antrik> so memory is not directly allocated from the physical allocator, + but instead from another map which in turn contains physical memory, or + something like that?... + <braunr> no, this is entirely virtual + <braunr> submaps are almost exclusively used for the kernel_map + <antrik> you are using a lot of identifies here, but I don't remember (or + never knew) what most of them mean :-( + <braunr> sorry :) + <braunr> the kernel map is the vm_map used to represent the ~1 GiB of + virtual memory the kernel has (on i386) + <braunr> vm_map objects are simple virtual space maps + <braunr> they contain what you see in linux when doing /proc/self/maps + <braunr> cat /proc/self/maps + <braunr> (linux uses entirely different names but it's roughly the same + structure) + <braunr> each line is a vm_map_entry + <braunr> (well, there aren't submaps in linux though) + <braunr> the pmap tool on netbsd is able to show the kernel map with its + submaps, but i don't have any image around + <mcsim> braunr: is limit for zones is feature and shouldn't be changed? + <braunr> mcsim: i think we shouldn't have fixed limits for zones + <braunr> mcsim: this should be part of the debugging facilities in the slab + allocator + <braunr> is this fixed limit really a major problem ? + <braunr> i mean, don't focus on that too much, there are other issues + requiring more attention + <antrik> braunr: at 12 MiB, it used to be, causing a lot of zalloc + panics. after increasing, I don't think it's much of a problem anymore... + <antrik> but as memory sizes grow, it might become one again + <antrik> that's the problem with a fixed size... + <braunr> yes, that's the issue with submaps + <braunr> but gnumach is full of those, so let's fix them by order of + priority + <antrik> well, I'm still trying to digest what you wrote about submaps :-) + <braunr> i'm downloading netbsd, so you can have a good view of all this + <antrik> so, when the kernel allocates virtual address space regions + (mostly for itself), instead of grabbing chunks of the address space + directly, it takes parts out of a pre-reserved region? + <braunr> not exactly + <braunr> both statements are true + <mcsim> antrik: only virtual addresses are reserved + <braunr> it grabs chunks of the address space directly, but does so in a + reserved region of the address space + <braunr> a submap is like a normal map, it has a start address, a size, and + is empty, then it's populated with vm_map_entries + <braunr> so instead of allocating from 3-4 GiB, you allocate from, say, + 3.1-3.2 GiB + <antrik> yeah, that's more or less what I meant... + <mcsim> braunr: I see two problems: limited zones and absence of caching. + <mcsim> with caching absence of readahead paging will be not so significant + <braunr> please avoid readahead + <mcsim> ok + <braunr> and it's not about paging, it's about kernel memory, which is + wired + <braunr> (well most of it) + <braunr> what about limited zones ? + <braunr> the whole kernel space is limited, there has to be limits + <braunr> the problem is how to handle them + <antrik> braunr: almost all. I looked through all zones once, and IIRC I + found exactly one that actually allows paging... + <braunr> currently, when you reach the limit, you have an OOM error + <braunr> antrik: yes, there are + <braunr> i don't remember which implementation does that but, when + processes haven't been active for a minute or so, they are "swapedout" + <braunr> completely + <braunr> even the kernel stack + <braunr> and the page tables + <braunr> (most of the pmap structures are destroyed, some are retained) + <antrik> that might very well be true... at least inactive processes often + show up with 0 memory use in top on Hurd + <braunr> this is done by having a pageable kernel map, with wired entries + <braunr> when the swapper thread swaps tasks out, it unwires them + <braunr> but i think modern implementations don't do that any more + <antrik> well, I was talking about zalloc only :-) + <braunr> oh + <braunr> so the zalloc_map must be pageable + <braunr> or there are two submaps ? + <antrik> not sure whether "morden implementations" includes Linux ;-) + <braunr> no, i'm talking about the bsd family only + <antrik> but it's certainly true that on Linux even inactive processes + retain some memory + <braunr> linux doesn't make any difference between processor-bound and + I/O-bound processes + <antrik> braunr: I have no idea how it works. I just remember that when + creating zones, one of the optional flags decides whether the zone is + pagable. but as I said, IIRC there is exactly one that actually is... + <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max, + zone_map_size, FALSE); + <braunr> kmem_suballoc(parent, min, max, size, pageable) + <braunr> so the zone_map isn't + <antrik> IIRC my conclusion was that pagable zones do not count in the + fixed zone map limit... but I'm not sure anymore + <braunr> zinit() has a memtype parameter + <braunr> with ZONE_PAGEABLE as a possible flag + <braunr> this is wierd :) + <mcsim> There is no any zones which use ZONE_PAGEABLE flag + <antrik> mcsim: are you sure? I think I found one... + <braunr> if (zone->type & ZONE_PAGEABLE) { + <antrik> admittedly, it is several years ago that I looked into this, so my + memory is rather dim... + <braunr> if (kmem_alloc_pageable(zone_map, &addr, ... + <braunr> calling kmem_alloc_pageable() on an unpageable submap seems wrong + <mcsim> I've greped gnumach code and there is no any zinit procedure call + with ZONE_PAGEABLE flag + <braunr> good + <antrik> hm... perhaps it was in some code that has been removed + alltogether since ;-) + <antrik> actually I think it would be pretty neat to have pageable kernel + objects... but I guess it would require considerable effort to implement + this right + <braunr> mcsim: you also mentioned absence of caching + <braunr> mcsim: the zone allocator actually is a bare caching object + allocator + <braunr> antrik: no, it's easy + <braunr> antrik: i already had that in x15 0.1 + <braunr> antrik: the problem is being sure the objects you allocate from a + pageable backing store are never used when resolving a page fault + <braunr> that's all + <antrik> I wouldn't expect that to be easy... but surely you know better + :-) + <mcsim> braunr: indeed. I was wrong. + <antrik> braunr: what is a caching object allocator?... + <braunr> antrik: ok, it's not easy + <braunr> antrik: but once you have vm_objects implemented, having pageable + kernel object is just a matter of using the right options, really + <braunr> antrik: an allocator that caches its buffers + <braunr> some years ago, the term "object" would also apply to + preconstructed buffers + <antrik> I have no idea what you mean by "caches its buffers" here :-) + <braunr> well, a memory allocator which doesn't immediately free its + buffers caches them + <mcsim> braunr: but can it return objects to system? + <braunr> mcsim: which one ? + <antrik> yeah, obviously the *implementation* of pageable kernel objects is + not hard. the tricky part is deciding which objects can be pageable, and + which need to be wired... + <mcsim> Can zone allocator return cached objects to system as in slab? + <mcsim> I mean reap() + <braunr> well yes, it does so, and it does that too often + <braunr> the caching in the zone allocator is actually limited to the + pagesize + <braunr> once page is completely free, it is returned to the vm + <mcsim> this is bad caching + <braunr> yes + <mcsim> if object takes all page than there is now caching at all + <braunr> caching by side effect + <braunr> true + <braunr> but the linux slab allocator does the same thing :p + <braunr> hm + <braunr> no, the solaris slab allocator does so + <mcsim> linux's slab returns objects only when system ask + <antrik> without preconstructed objects, is there actually any point in + caching empty slabs?... + <mcsim> Once I've changed my allocator to slab and it cached more than 1GB + of my memory) + <braunr> ok wait, need to fix a few mistakes first + <mcsim> s/ask/asks + <braunr> the zone allocator (in gnumach) actually has a garbage collector + <antrik> braunr: well, the Solaris allocator follows the slab/magazine + paper, right? so there is caching at the magazine layer... in that case + caching empty slabs too would be rather redundant I'd say... + <braunr> which is called when running low on memory, similar to the slab + allocaotr + <braunr> antrik: yes + <antrik> (or rather the paper follows the Solaris allocator ;-) ) + <braunr> mcsim: the zone allocator reap() is zone_gc() + <antrik> braunr: hm, right, there is a "collectable" flag for zones... but + I never understood what it means + <antrik> braunr: BTW, I heard Linux has yet another allocator now called + "slob"... do you happen to know what that is? + <braunr> slob is a very simple allocator for embedded devices + <mcsim> AFAIR this is just heap allocator + <braunr> useful when you have a very low amount of memory + <braunr> like 1 MiB + <braunr> yes + <antrik> just googled it :-) + <braunr> zone and slab are very similar + <antrik> sounds like a simple heap allocator + <mcsim> there is another allocator that calls slub, and it better than slab + in many cases + <braunr> the main difference is the data structures used to store slabs + <braunr> mcsim: i disagree + <antrik> mcsim: ah, you already said that :-) + <braunr> mcsim: slub is better for systems with very large amounts of + memory and processors + <braunr> otherwise, slab is better + <braunr> in addition, there are accounting issues with slub + <braunr> because of cache merging + <mcsim> ok. This strange that slub is default allocator + <braunr> well both are very good + <braunr> iirc, linus stated that he really doesn't care as long as its + works fine + <braunr> he refused slqb because of that + <braunr> slub is nice because it requires less memory than slab, while + still being as fast for most cases + <braunr> it gets slower on the free path, when the cpu performing the free + is different from the one which allocated the object + <braunr> that's a reasonable cost + <mcsim> slub uses heap for large object. Are there any tests that compare + what is better for large objects? + <antrik> well, if slub requires less memory, why do you think slab is + better for smaller systems? :-) + <braunr> antrik: smaller is relative + <antrik> mcsim: for large objects slab allocation is rather pointless, as + you don't have multiple objects in a page anyways... + <braunr> antrik: when lameter wrote slub, it was intended for systems with + several hundreds processors + <antrik> BTW, was slqb really refused only because the other ones are "good + enough"?... + <braunr> yes + <antrik> wow, that's a strange argument... + <braunr> linus is already unhappy of having "so many" allocators + <antrik> well, if the new one is better, it could replace one of the others + :-) + <antrik> or is it useful only in certain cases? + <braunr> that's the problem + <braunr> nobody really knows + <antrik> hm, OK... I guess that should be tested *before* merging ;-) + <antrik> is anyone still working on it, or was it abandonned? + <antrik> mcsim: back to caching... + <antrik> what does caching in the kernel object allocator got to do with + readahead (i.e. clustered paging)?... + <mcsim> if we cached some physical pages we don't need to find new ones for + allocating new object. And that's why there will not be a page fault. + <mcsim> antrik: Regarding kam. Hasn't he finished his project? + <antrik> err... what? + <antrik> one of us must be seriously confused + <antrik> I totally fail to see what caching of physical pages (which isn't + even really a correct description of what slab does) has to do with page + faults + <antrik> right, KAM didn't finish his project + <mcsim> If we free the physical page and return it to system we need + another one for next allocation. But if we keep it, we don't need to find + new physical page. + <mcsim> And physical page is allocated only then when page fault + occurs. Probably, I'm wrong + <antrik> what does "return to system" mean? we are talking about the + kernel... + <antrik> zalloc/slab are about allocating kernel objects. this doesn't have + *anything* to do with paging of userspace processes + <antrik> only thing the have in common is that they need to get pages from + the physical page allocator. but that's yet another topic + <mcsim> Under "return to system" I mean ability to use this page for other + needs. + <braunr> mcsim: consider kernel memory to be wired + <braunr> here, return to system means releasing a page back to the vm + system + <braunr> the vm_kmem module then unmaps the physical page and free its + virtual address in the kernel map + <mcsim> ok + <braunr> antrik: the problem with new allocators like slqb is that it's + very difficult to really know if they're better, even with extensive + testing + <braunr> antrik: there are papers (like wilson95) about the difficulties in + making valuable results in this field + <braunr> see + http://www.sceen.net/~rbraun/dynamic_storage_allocation_a_survey_and_critical_review.pdf + <mcsim> how can be allocated physically continuous object now? + <braunr> mcsim: rephrase please + <mcsim> what is similar to kmalloc in Linux to gnumach? + <braunr> i know memory is reserved for dma in a direct virtual to physical + mapping + <braunr> so even if the allocation is done similarly to vmalloc() + <braunr> the selected region of virtual space maps physical memory, so + memory is physically contiguous too + <braunr> for other allocation types, a block large enough is allocated, so + it's contiguous too + <mcsim> I don't clearly understand. If we have fragmentation in physical + ram, so there aren't 2 free pages in a row, but there are able apart, we + can't to allocate these 2 pages along? + <braunr> no + <braunr> but every system has this problem + <mcsim> But since we have only 12 or 32 MB of memory the problem becomes + more significant + <braunr> you're confusing virtual and physical memory + <braunr> those 32 MiB are virtual + <braunr> the physical pages backing them don't have to be contiguous + <mcsim> Oh, indeed + <mcsim> So the only problem are limits? + <braunr> and performance + <braunr> and correctness + <braunr> i find the zone allocator badly written + <braunr> antrik: mcsim: here is the content of the kernel pmap on NetBSD + (which uses a virtual memory system close to the Mach VM) + <braunr> antrik: mcsim: http://www.sceen.net/~rbraun/pmap.out + +[[pmap.out]] + + <braunr> you can see the kmem_map (which is used for most general kernel + allocations) is 128 MiB large + <braunr> actually it's not the kernel pmap, it's the kernel_map + <antrik> braunr: why is it called pmap.out then? ;-) + <braunr> antrik: because the tool is named pmap + <braunr> for process map + <braunr> it also exists under Linux, although direct access to + /proc/xx/maps gives more info + <mcsim> braunr: I've said that this is kernel_map. Can I see kernel_map for + Linux? + <braunr> mcsim: I don't know how to do that + <mcsim> s/I've/You've + <braunr> but Linux doesn't have submaps, and uses a direct virtual to + physical mapping, so it's used differently + <antrik> how are things (such as zalloc zones) entered into kernel_map? + <braunr> in zone_init() you have + <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max, + zone_map_size, FALSE); + <braunr> so here, kmem_map is named zone_map + <braunr> then, in zalloc() + <braunr> kmem_alloc_wired(zone_map, &addr, zone->alloc_size) + <antrik> so, kmem_alloc just deals out chunks of memory referenced directly + by the address, and without knowing anything about the use? + <braunr> kmem_alloc() gives virtual pages + <braunr> zalloc() carves them into buffers, as in the slab allocator + <braunr> the difference is essentially the lack of formal "slab" object + <braunr> which makes the zone code look like a mess + <antrik> so kmem_suballoc() essentially just takes a bunch of pages from + the main kernel_map, and uses these to back another map which then in + turn deals out pages just like the main kernel_map? + <braunr> no + <braunr> kmem_suballoc creates a vm_map_entry object, and sets its start + and end address + <braunr> and creates a vm_map object, which is then inserted in the new + entry + <braunr> maybe that's what you meant with "essentially just takes a bunch + of pages from the main kernel_map" + <braunr> but there really is no allocation at this point + <braunr> except the map entry and the new map objects + <antrik> well, I'm trying to understand how kmem_alloc() manages things. so + it has map_entry structures like the maps of userspace processes? do + these also reference actual memory objects? + <braunr> kmem_alloc just allocates virtual pages from a vm_map, and backs + those with physical pages (unless the user requested pageable memory) + <braunr> it's not "like the maps of userspace processes" + <braunr> these are actually the same structures + <braunr> a vm_map_entry can reference a memory object or a kernel submap + <braunr> in netbsd, it can also referernce nothing (for pure wired kernel + memory like the vm_page array) + <braunr> maybe it's the same in mach, i don't remember exactly + <braunr> antrik: this is actually very clear in vm/vm_kern.c + <braunr> kmem_alloc() creates a new kernel object for the allocation + <braunr> allocates a new entry (or uses a previous existing one if it can + be extended) through vm_map_find_entry() + <braunr> then calls kmem_alloc_pages() to back it with wired memory + <antrik> "creates a new kernel object" -- what kind of kernel object? + <braunr> kmem_alloc_wired() does roughly the same thing, except it doesn't + need a new kernel object because it knows the new area won't be pageable + <braunr> a simple vm_object + <braunr> used as a container for anonymous memory in case the pages are + swapped out + <antrik> vm_object is the same as memory object/pager? or yet something + different? + <braunr> antrik: almost + <braunr> antrik: a memory_object is the user view of a vm_object + <braunr> as in the kernel/user interfaces used by external pagers + <braunr> vm_object is a more internal name + <mcsim> Is fragmentation a big problem in slab allocator? + <mcsim> I've tested it on my computer in Linux and for some caches it + reached 30-40% + <antrik> well, fragmentation is a major problem for any allocator... + <antrik> the original slab allocator was design specifically with the goal + of reducing fragmentation + <antrik> the revised version with the addition of magazines takes a step + back on this though + <antrik> have you compared it to slub? would be pretty interesting... + <mcsim> I have an idea how can it be decreased, but it will hurt by + performance... + <mcsim> antrik: no I haven't, but there will be might the same, I think + <mcsim> if each cache will handle two types of object: with sizes that will + fit cache sizes (or I bit smaller) and with sizes which are much smaller + than maximal cache size. For first type of object will be used standard + slab allocator and for latter type will be used (within page) heap + allocator. + <mcsim> I think that than fragmentation will be decreased + <antrik> not at all. heap allocator has much worse fragmentation. that's + why slab allocator was invented + <antrik> the problem is that in a long-running program (such an the + kernel), objects tend to have vastly varying lifespans + <mcsim> but we use heap only for objects of specified sizes + <antrik> so often a few old objects will keep a whole page hostage + <mcsim> for example for 32 byte cache it could be 20-28 byte objects + <antrik> that's particularily visible in programs such as firefox, which + will grow the heap during use even though actual needs don't change + <antrik> the slab allocator groups objects in a fashion that makes it more + likely adjacent objects will be freed at similar times + <antrik> well, that's pretty oversimplyfied, but I hope you get the + idea... it's about locality + <mcsim> I agree, but I speak not about general heap allocation. We have + many heaps for objects with different sizes. + <mcsim> Could it be better? + <antrik> note that this has been a topic of considerable research. you + shouldn't seek to improve the actual algorithms -- you would have to read + up on the existing research at least before you can contribute anything + to the field :-) + <antrik> how would that be different from the slab allocator? + <mcsim> slab will allocate 32 byte for both 20 and 32 byte requests + <mcsim> And if there was request for 20 bytes we get 12 unused + <antrik> oh, you mean the implementation of the generic allocator on top of + slabs? well, that might not be optimal... but it's not an often used case + anyways. mostly the kernel uses constant-sized objects, which get their + own caches with custom tailored size + <antrik> I don't think the waste here matters at all + <mcsim> affirmative. So my idea is useless. + <antrik> does the statistic you refer to show the fragmentation in absolute + sizes too? + <mcsim> Can you explain what is absolute size? + <mcsim> I've counted what were requested (as parameter of kmalloc) and what + was really allocated (according to best fit cache size). + <antrik> how did you get that information? + <mcsim> I simply wrote a hook + <antrik> I mean total. i.e. how many KiB or MiB are wasted due to + fragmentation alltogether + <antrik> ah, interesting. how does it work? + <antrik> BTW, did you read the slab papers? + <mcsim> Do you mean articles from lwn.net? + <antrik> no + <antrik> I mean the papers from the Sun hackers who invented the slab + allocator(s) + <antrik> Bonwick mostly IIRC + <mcsim> Yes + <antrik> hm... then you really should know the rationale behind it... + <mcsim> There he says about 11% percent of memory waste + <antrik> you didn't answer my other questions BTW :-) + <mcsim> I've corrupted kernel tree with patch, and tomorrow I'm going to + read myself up for exam (I have it on Thursday). But than I'll send you a + module which I've used for testing. + <antrik> OK + <mcsim> I can send you module now, but it will not work without patch. + <mcsim> It would be better to rewrite it using debugfs, but when I was + writing this test I didn't know about trace_* macros + + +# IRC, freenode, #hurd, 2011-04-15 + + <mcsim> There is a hack in zone_gc when it allocates and frees two + vm_map_kentry_zone elements to make sure the gc will be able to allocate + two in vm_map_delete. Isn't it better to allocate memory for these + entries statically? + <youpi> mcsim: that's not the point of the hack + <youpi> mcsim: the point of the hack is to make sure vm_map_delete will be + able to allocate stuff + <youpi> allocating them statically will just work once + <youpi> it may happen several times that vm_map_delete needs to allocate it + while it's empty (and thus zget_space has to get called, leading to a + hang) + <youpi> funnily enough, the bug is also in macos X + <youpi> it's still in my TODO list to manage to find how to submit the + issue to them + <braunr> really ? + <braunr> eh + <braunr> is that because of map entry splitting ? + <youpi> it's git commit efc3d9c47cd744c316a8521c9a29fa274b507d26 + <youpi> braunr: iirc something like this, yes + <braunr> netbsd has this issue too + <youpi> possibly + <braunr> i think it's a fundamental problem with the design + <braunr> people think of munmap() as something similar to free() + <braunr> whereas it's really unmap + <braunr> with a BSD-like VM, unmap can easily end up splitting one entry in + two + <braunr> but your issue is more about harmful recursion right ? + <youpi> I don't remember actually + <youpi> it's quite some time ago :) + <braunr> ok + <braunr> i think that's why i have "sources" in my slab allocator, the + default source (vm_kern) and a custom one for kernel map entries + + +# IRC, freenode, #hurd, 2011-04-18 + + <mcsim> braunr: you've said that once page is completely free, it is + returned to the vm. + <mcsim> who else, besides zone_gc, can return free pages to the vm? + <braunr> mcsim: i also said i was wrong about that + <braunr> zone_gc is the only one + + +# IRC, freenode, #hurd, 2011-04-19 + + <braunr> antrik: mcsim: i added back a new per-cpu layer as planned + <braunr> + http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=c629b2b9b149f118a30f0129bd8b7526b0302c22;hb=HEAD + <braunr> mcsim: btw, in mem_cache_reap(), you can clearly see there are two + loops, just as in zone_gc, to reduce contention and avoid deadlocks + <braunr> this is really common in memory allocators + + +# IRC, freenode, #hurd, 2011-04-23 + + <mcsim> I've looked through some allocators and all of them use different + per cpu cache policy. AFAIK gnuhurd doesn't support multiprocessing, but + still multiprocessing must be kept in mind. So, what do you think what + kind of cpu caches is better? As for me I like variant with only per-cpu + caches (like in slqb). + <antrik> mcsim: well, have you looked at the allocator braunr wrote + himself? :-) + <antrik> I'm not sure I suggested that explicitly to you; but probably it + makes most sense to use that in gnumach + + +# IRC, freenode, #hurd, 2011-04-24 + + <mcsim> antrik: Yes, I have. He uses both global and per cpu caches. But he + also suggested to look through slqb, where there are only per cpu + caches.\ + <braunr> i don't remember slqb in detail + <braunr> what do you mean by "only per-cpu caches" ? + <braunr> a whole slab sytem for each cpu ? + <mcsim> I mean that there are no global queues in caches, but there are + special queues for each cpu. + <mcsim> I've just started investigating slqb's code, but I've read an + article on lwn about it. And I've read that it is used for zen kernel. + <braunr> zen ? + <mcsim> Here is this article http://lwn.net/Articles/311502/ + <mcsim> Yes, this is linux kernel with some patches which haven't been + approved to torvald's tree + <mcsim> http://zen-kernel.org/ + <braunr> i see + <braunr> well it looks nice + <braunr> but as for slub, the problem i can see is cross-CPU freeing + <braunr> and I think nick piggins mentions it + <braunr> piggin* + <braunr> this means that sometimes, objects are "burst-free" from one cpu + cache to another + <braunr> which has the same bad effects as in most other allocators, mainly + fragmentation + <mcsim> There is a special list for freeing object allocated for another + CPU + <mcsim> And garbage collector frees such object on his own + <braunr> so what's your question ? + <mcsim> It is described in the end of article. + <mcsim> What cpu-cache policy do you think is better to implement? + <braunr> at this point, any + <braunr> and even if we had a kernel that perfectly supports + multiprocessor, I wouldn't care much now + <braunr> it's very hard to evaluate such allocators + <braunr> slqb looks nice, but if you have the same amount of fragmentation + per slab as other allocators do (which is likely), you have tat amount of + fragmentation multiplied by the number of processors + <braunr> whereas having shared queues limit the problem somehow + <braunr> having shared queues mean you have a bit more contention + <braunr> so, as is the case most of the time, it's a tradeoff + <braunr> by the way, does pigging say why he "doesn't like" slub ? :) + <braunr> piggin* + <mcsim> http://lwn.net/Articles/311093/ + <mcsim> here he describes what slqb is better. + <braunr> well it doesn't describe why slub is worse + <mcsim> but not very particularly + <braunr> except for order-0 allocations + <braunr> and that's a form of fragmentation like i mentioned above + <braunr> in mach those problems have very different impacts + <braunr> the backend memory isn't physical, it's the kernel virtual space + <braunr> so the kernel allocator can request chunks of higher than order-0 + pages + <braunr> physical pages are allocated one at a time, then mapped in the + kernel space + <mcsim> Doesn't order of page depend on buffer size? + <braunr> it does + <mcsim> And why does gnumach allocates higher than order-0 pages more? + <braunr> why more ? + <braunr> i didn't say more + <mcsim> And why in mach those problems have very different impact? + <braunr> ? + <braunr> i've just explained why :) + <braunr> 09:37 < braunr> physical pages are allocated one at a time, then + mapped in the kernel space + <braunr> "one at a time" means order-0 pages, even if you allocate higher + than order-0 chunks + <mcsim> And in Linux they allocated more than one at time because of + prefetching page reading? + <braunr> do you understand what virtual memory is ? + <braunr> linux allocators allocate "physical memory" + <braunr> mach kernel allocator allocates "virtual memory" + <braunr> so even if you allocate a big chunk of virtual memory, it's backed + by order-0 physical pages + <mcsim> yes, I understand this + <braunr> you don't seem to :/ + <braunr> the problem of higher than order-0 page allocations is + fragmentation + <braunr> do you see why ? + <mcsim> yes + <braunr> so + <braunr> fragmentation in the kernel space is less likely to create issues + than it does in physical memory + <braunr> keep in mind physical memory is almost always full because of the + page cache + <braunr> and constantly under some pressure + <braunr> whereas the kernel space is mostly empty + <braunr> so allocating higher then order-0 pages in linux is more dangerous + than it is in Mach or BSD + <mcsim> ok + <braunr> on the other hand, linux focuses pure performance, and not having + to map memory means less operations, less tlb misses, quicker allocations + <braunr> the Mach VM must map pages "one at a time", which can be expensive + <braunr> it should be adapted to handle multiple page sizes (e.g. 2 MiB) so + that many allocations can be made with few mappings + <braunr> but that's not easy + <braunr> as always: tradeoffs + <mcsim> There are other benefits of physical allocating. In big DMA + transfers can be needed few continuous physical pages. How does mach + handles such cases? + <braunr> gnumach does that awfully + <braunr> it just reserves the whole DMA-able memory and uses special + allocation functions on it, IIRC + <braunr> but kernels which have a MAch VM like memory sytem such as BSDs + have cleaner methods + <braunr> NetBSD provides a function to allocate contiguous physical memory + <braunr> with many constraints + <braunr> FreeBSD uses a binary buddy system like Linux + <braunr> the fact that the kernel allocator uses virtual memory doesn't + mean the kernel has no mean to allocate contiguous physical memory ... + + +# IRC, freenode, #hurd, 2011-05-02 + + <braunr> hm nice, my allocator uses less memory than glibc (squeeze + version) on both 32 and 64 bits systems + <braunr> the new per-cpu layer is proving effective + <neal> braunr: Are you reimplementation malloc? + <braunr> no + <braunr> it's still the slab allocator for mach, but tested in userspace + <braunr> so i wrote malloc wrappers + <neal> Oh. + <braunr> i try to heavily test most of my code in userspace now + <neal> it's easier :-) + <neal> I agree + <braunr> even the physical memory allocator has been implemented this way + <neal> is this your mach version? + <braunr> virtual memory allocation will follow + <neal> or are you working on gnu mach? + <braunr> for now it's my version + <braunr> but i intend to spend the summer working on ipc port names + management + +[[rework_gnumach_IPC_spaces]]. + + <braunr> and integrate the result in gnu mach + <neal> are you keeping the same user-space API? + <neal> Or are you experimenting with something new? + <antrik> braunr: to be fair, it's not terribly hard to use less memory than + glibc :-) + <braunr> yes + <braunr> antrik: well ptmalloc3 received some nice improvements + <braunr> neal: the goal is to rework some of the internals only + <braunr> neal: namely, i simply intend to replace the splay tree with a + radix tree + <antrik> braunr: the glibc allocator is emphasising performace, unlike some + other allocators that trade some performance for much better memory + utilisation... + <antrik> ptmalloc3? + <braunr> that's the allocator used in glibc + <braunr> http://www.malloc.de/en/ + <antrik> OK. haven't seen any recent numbers... the comparision I have in + mind is many years old... + <braunr> i also made some additions to my avl and red-black trees this week + end, which finally make them suitable for almost all generic uses + <braunr> the red-black tree could be used in e.g. gnu mach to augment the + linked list used in vm maps + <braunr> which is what's done in most modern systems + <braunr> it could also be used to drop the overloaded (and probably over + imbalanced) page cache hash table + + +# IRC, freenode, #hurd, 2011-05-03 + + <mcsim> antrik: How should I start porting? Have I just include rbraun's + allocator to gnumach and make it compile? + <antrik> mcsim: well, basically yes I guess... but you will have to look at + the code in question first before we know anything more specific :-) + <antrik> I guess braunr might know better how to start, but he doesn't + appear to be here :-( + <braunr> mcsim: you can't juste put my code into gnu mach and make it run, + it really requires a few careful changes + <braunr> mcsim: you will have to analyse how the current zone allocator + interacts with regard to locking + <braunr> if it is used in interrupt handlers + <braunr> what kind of locks it should use instead of the pthread stuff + available in userspace + <braunr> you will have to change the reclamiing policy, so that caches are + reaped on demand + <braunr> (this basically boils down to calling the new reclaiming function + instead of zone_gc()) + <braunr> you must be careful about types too + <braunr> there is work to be done ;) + <braunr> (not to mention the obvious about replacing all the calls to the + zone allocator, and testing/debugging afterwards) + + +# IRC, freenode, #hurd, 2011-07-14 + + <braunr> can you make your patch available ? + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <braunr> mcsim: i'll test your branch + <mcsim> ok. I'll give you a link in a minute + <braunr> hm why balloc ? + <mcsim> Braun's allocator + <braunr> err + <braunr> + http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD + <braunr> mcsim: this is the interface i had in mind for a kernel version :) + <braunr> very similar to the original slab allocator interface actually + <braunr> well, you've been working + <mcsim> But I have a problem with this patch. When I apply it to gnumach + code from debian repository. I have to make a change in file ramdisk.c + with sed -i 's/kernel_map/\&kernel_map/' device/ramdisk.c + <mcsim> because in git repository there is no such file + <braunr> mcsim: how do you configure the kernel before building ? + <braunr> mcsim: you should keep in touch more often i think, so that you + get feedback from us and don't spend too much time "off course" + <mcsim> I didn't configure it. I just run dpkg-buildsource -b. + <braunr> oh you build the debian package + <braunr> well my version was by configure --enable-kdb --enable-rtl8139 + <braunr> and it seems stuck in an infinite loop during bootstrap + <mcsim> and printf doesn't work. The first function called by c_boot_entry + is printf(version). + <braunr> mcsim: also, you're invited to get the x15mach version of my + files, which are gplv2+ licensed + <braunr> be careful of my macros.h file, it can conflict with the + macros_help.h file from gnumach iirc + <mcsim> There were conflicts with MACRO_BEGIN and MACRO_END. But I solved + it + <braunr> ok + <braunr> it's tricky + <braunr> mcsim: try to find where the first use of the allocator is made + + +# IRC, freenode, #hurd, 2011-07-22 + + <mcsim> braunr, hello. Kernel with your allocator already compiles and + runs. There still some problems, but, certainly, I'm on the final stage + already. I hope I'll finish in a few days. + <tschwinge> mcsim: Oh, cool! Have you done some measurements already? + <mcsim> Not yet + <tschwinge> OK. + <tschwinge> But if it able to run a GNU/Hurd system, then that already is + something, a big milestone! + <braunr> nice + <braunr> although you'll probably need to tweak the garbage collecting + process + <mcsim> tschwinge: thanks + <mcsim> braunr: As back-end for allocating memory I use + kmem_alloc_wired. But in zalloc was an opportunity to use as back-end + kmem_alloc_pageable. Although there was no any zone that used + kmem_alloc_pageable. Do I need to implement this functionality? + <braunr> mcsim: do *not* use kmem_alloc_pageable() + <mcsim> braunr: Ok. This is even better) + <braunr> mcsim: in x15, i've taken this even further: there is *no* kernel + vm object, which means all kernel memory is wired and unmanaged + <braunr> making it fast and safe + <braunr> pageable kernel memory was useful back when RAM was really scarce + <braunr> 20 years ago + <braunr> but it's a source of deadlock + <mcsim> Indeed. I'll won't use kmem_alloc_pageable. + + +# IRC, freenode, #hurd, 2011-08-09 + + < braunr> mcsim: what's the "bug related to MEM_CF_VERIFY" you refer to in + one of your commits ? + < braunr> mcsim: don't use spin_lock_t as a member of another structure + < mcsim> braunr: I confused with types in *_verify functions, so they + didn't work. Than I fixed it in the commit you mentioned. + < braunr> in gnumach, most types are actually structure pointers + < braunr> use simple_lock_data_t + < braunr> mcsim: ok + < mcsim> > use simple_lock_data_t + < mcsim> braunr: ok + < braunr> mcsim: don't make too many changes to the code base, and if + you're unsure, don't hesitate to ask + < braunr> also, i really insist you rename the allocator, as done in x15 + for example + (http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=vm/kmem.c), instead of + a name based on mine :/ + < mcsim> braunr: Ok. It was just work name. When I finish I'll rename the + allocator. + < braunr> other than that, it's nice to see progress + < braunr> although again, it would be better with some reports along + < braunr> i won't be present at the meeting tomorrow unfortunately, but you + should use those to report the status of your work + < mcsim> braunr: You've said that I have to tweak gc process. Did you mean + to call mem_gc() when physical memory ends instead of calling it every x + seconds? Or something else? + < braunr> there are multiple topics, alhtough only one that really matters + < braunr> study how zone_gc was called + < braunr> reclaiming memory should happen when there is pressure on the VM + subsystem + < braunr> but it shouldn't happen too ofte, otherwise there is trashing + < braunr> and your caches become mostly useless + < braunr> the original slab allocator uses a 15-second period after a + reclaim during which reclaiming has no effect + < braunr> this allows having a somehow stable working set for this duration + < braunr> the linux slab allocator uses 5 seconds, but has a more + complicated reclaiming mechanism + < braunr> it releases memory gradually, and from reclaimable caches only + (dentry for example) + < braunr> for x15 i intend to implement the original 15 second interval and + then perform full reclaims + < mcsim> In zalloc mem_gc is called by vm_pageout_scan, but not often than + once a second. + < mcsim> In balloc I've changed interval to once in 15 seconds. + < braunr> don't use the code as it is + < braunr> the version you've based your work on was meant for userspace + < braunr> where there isn't memory pressure + < braunr> so a timer is used to trigger reclaims at regular intervals + < braunr> it's different in a kernel + < braunr> mcsim: where did you see vm_pageout_scan call the zone gc once a + second ? + < mcsim> vm_pageout_scan calls consider_zone_gc and consider_zone_gc checks + if second is passed. + < braunr> where ? + < mcsim> Than zone_gc can be called. + < braunr> ah ok, it's in zaclloc.c then + < braunr> zalloc.c + < braunr> yes this function is fine + < mcsim> so old gc didn't consider vm pressure. Or I missed something. + < braunr> it did + < mcsim> how? + < braunr> well, it's called by the pageout daemon + < braunr> under memory pressure + < braunr> so it's fine + < mcsim> so if mem_gc is called by pageout daemon is it fine? + < braunr> it must be changed to do something similar to what + consider_zone_gc does + < mcsim> It does. mem_gc does the same work as consider_zone_gc and + zone_gc. + < braunr> good + < mcsim> so gc process is fine? + < braunr> should be + < braunr> i see mem.c only includes mem.h, which then includes other + headers + < braunr> don't do that + < braunr> always include all the headers you need where you need them + < braunr> if you need avltree.h in both mem.c and mem.h, include it in both + files + < braunr> and by the way, i recommend you use the red black tree instead of + the avl type + < braunr> (it's the same interface so it shouldn't take long) + < mcsim> As to report. If you won't be present at the meeting, I can tell + you what I have to do now. + < braunr> sure + < braunr> in addition, use GPLv2 as the license, teh BSD one is meant for + the userspace version only + < braunr> GPLv2+ actually + < braunr> hm you don't need list.c + < braunr> it would only add dead code + < braunr> "Zone for dynamical allocator", don't mix terms + < braunr> this comment refers to a vm_map, so call it a map + < mcsim> 1. Change constructor for kentry_alloc_cache. + < mcsim> 2. Make measurements. + < mcsim> + + < mcsim> 3. Use simple_lock_data_t + < mcsim> 4. Replace license + < braunr> kentry_alloc_cache <= what is that ? + < braunr> cache for kernel map entries in vm_map ? + < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as + there is no kernel preemption + < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL + times a second. + < braunr> " + < mcsim> sorry. I meant vm_map_kentry_cache + < braunr> hm nothing actually about this comment + < braunr> mcsim: ok + < braunr> yes kernel map entries need special handling + < braunr> i don't know how it's done in gnumach though + < braunr> static preallocation ? + < mcsim> yes + < braunr> that's ugly :p + < mcsim> but it uses dynamic allocation further even for vm_map kernel + entries + < braunr> although such bootstrapping issues are generally difficult to + solve elegantly + < braunr> ah + < mcsim> now I use only static allocation, but I'll add dynamic allocation + too + < braunr> when you have time, mind the coding style (convert everything to + gnumach style, which mostly implies using tabs instead of 4-spaces + indentation) + < braunr> when you'll work on dynamic allocation for the kernel map + entries, you may want to review how it's done in x15 + < braunr> the mem_source type was originally intended for that purpose, but + has slightly changed once the allocator was adapted to work in my kernel + < mcsim> ok + < braunr> vm_map_kentry_zone is the only zone created with ZONE_FIXED + < braunr> and it is zcram()'ed immediately after + < braunr> so you can consider it a statically allocated zone + < braunr> in x15 i use another strategy: there is a special kernel submap + named kentry_map which contains only one map entry (statically allocated) + < braunr> this map is the backend (mem_source) for the kentry_cache + < braunr> the kentry_cache is created with a special flag that tells it + memory can't be reclaimed + < braunr> when the cache needs to grow, the single map entry is extended to + cover the allocated memory + < braunr> it's similar to the way pmap_growkernel() works for kernel page + table pages + < braunr> (and is actually based on that idea) + < braunr> it's a compromise between full static and dynamic allocation + types + < braunr> the advantage is that the allocator code can be used (so there is + no need for a special allocator like in netbsd) + < braunr> the drawback is that some resources can never be returned to + their source (and under peaks, the amount of unfreeable resources could + become large, but this is unexpected) + < braunr> mcsim: for now you shouldn't waste your time with this + < braunr> i see the number of kernel map entries is fixed at 256 + < braunr> and i've never seen the kernel use more than around 30 entries + < mcsim> Do you think that I have to left this problem to the end? + < braunr> yes + + +# IRC, freenode, #hurd, 2011-08-11 + + < mcsim> braunr: Hello. Can you give me an advice how can I make + measurements better? + < braunr> mcsim: what kind of measurements + < mcsim> braunr: How much is your allocator better than zalloc. + < braunr> slightly :p + < braunr> that's why i never took the time to put it in gnumach + < mcsim> braunr: Just I thought that there are some rules or + recommendations of such measurements. Or I can do them any way I want? + < braunr> mcsim: i don't know + < braunr> mcsim: benchmarking is an art of its own, and i don't even know + how to use the bits of profiling code available in gnumach (if it still + works) + < antrik> mcsim: hm... are you saying you already have a running system + with slab allocator?... :-) + < braunr> mcsim: the main advantage i can see is the removal of many + arbitrary hard limits + < mcsim> antrik: yes + < antrik> \o/ + < antrik> nice work! + < braunr> :) + < braunr> the cpu layer should also help a bit, but it's hard to measure + < braunr> i guess it could be seen on the ipc path for very small buffers + < mcsim> antrik: Thanks. But I still have to 1. Change constructor for + kentry_alloc_cache. and 2. Make measurements. + < braunr> and polish the whole thing :p + < antrik> mcsim: I'm not sure this can be measured... the performance + differente in any real live usage is probably just a few percent at most + -- it's hard to construct a benchmark giving enough precision so it's not + drowned in noise... + < antrik> perhaps it conserves some memory -- but that too would be hard to + measure I fear + < braunr> yes + < braunr> there *should* be better allocation times, less fragmentation, + better accounting ... :) + < braunr> and no arbitrary limits ! + < antrik> :-) + < braunr> oh, and the self debugging features can be nice too + < mcsim> But I need to prove that my work wasn't useless + < braunr> well it wasn't, but that's hard to measure + < braunr> it's easy to prove though, since there are additional features + that weren't present in the zone allocator + < mcsim> Ok. If there are some profiling features in gnumach can you give + me a link with their description? + < braunr> mcsim: sorry, no + < braunr> mcsim: you could still write the basic loop test, which counts + the number of allocations performed in a fixed time interval + < braunr> but as it doesn't match many real life patterns, it won't be very + useful + < braunr> and i'm afraid that if you consider real life patterns, you'll + see how negligeable the improvement can be compared to other operations + such as memory copies or I/O (ouch) + < mcsim> Do network drivers use this allocator? + < mcsim> ok. I'll scrape up some test and than I'll report results. + + +# IRC, freenode, #hurd, 2011-08-26 + + < mcsim> hello. Are there any analogs of copy_to_user and copy_from_user in + linux for gnumach? + < mcsim> Or how can I determine memory map if I know address? I need this + for vm_map_copyin + < guillem> mcsim: vm_map_lookup_entry? + < mcsim> guillem: but I need to transmit map to this function and it will + return an entry which contains specified address. + < mcsim> And I don't know what map have I transmit. + < mcsim> I need to transfer static array from kernel to user. What map + contains static data? + < antrik> mcsim: Mach doesn't have copy_{from,to}_user -- instead, large + chunks of data are transferred as out-of-line data in IPC messages + (i.e. using VM magic) + < mcsim> antrik: can you give me an example? I just found using + vm_map_copyin in host_zone_info. + < antrik> no idea what vm_map_copyin is to be honest... + + +# IRC, freenode, #hurd, 2011-08-27 + + < braunr> mcsim: the primitives are named copyin/copyout, and they are used + for messages with inline data + < braunr> or copyinmsg/copyoutmsg + < braunr> vm_map_copyin/out should be used for chunks larger than a page + (or roughly a page) + < braunr> also, when writing to a task space, see which is better suited: + vm_map_copyout or vm_map_copy_overwrite + < mcsim> braunr: and what will be src_map for vm_map_copyin/out? + < braunr> the caller map + < braunr> which you can get with current_map() iirc + < mcsim> braunr: thank you + < braunr> be careful not to leak anything in the transferred buffers + < braunr> memset() to 0 if in doubt + < mcsim> braunr:ok + < braunr> antrik: vm_map_copyin() is roughly vm_read() + < antrik> braunr: what is it used for? + < braunr> antrik: 01:11 < antrik> mcsim: Mach doesn't have + copy_{from,to}_user -- instead, large chunks of data are transferred as + out-of-line data in IPC messages (i.e. using VM magic) + < braunr> antrik: that "VM magic" is partly implemented using vm_map_copy* + functions + < antrik> braunr: oh, you mean it doesn't actually copy data, but only page + table entries? if so, that's *not* really comparable to + copy_{from,to}_user()... + + +# IRC, freenode, #hurd, 2011-08-28 + + < braunr> antrik: the equivalent of copy_{from,to}_user are + copy{in,out}{,msg} + < braunr> antrik: but when the data size is about a page or more, it's + better not to copy, of course + < antrik> braunr: it's actually not clear at all that it's really better to + do VM magic than to copy... + + +# IRC, freenode, #hurd, 2011-08-29 + + < braunr> antrik: at least, that used to be the general idea, and with a + simpler VM i suspect it's still true + < braunr> mcsim: did you progress on your host_zone_info replacement ? + < braunr> mcsim: i think you should stick to what the original + implementation did + < braunr> which is making an inline copy if caller provided enough space, + using kmem_alloc_pageable otherwise + < braunr> specify ipc_kernel_map if using kmem_alloc_pageable + < mcsim> braunr: yes. And it works. But I use kmem_alloc, not pageable. Is + it worse? + < mcsim> braunr: host_zone_info replacement is pushed to savannah + repository. + < braunr> mcsim: i'll have a look + < mcsim> braunr: I've pushed one more commit just now, which has attitude + to host_zone_info. + < braunr> mem_alloc_early_init should be renamed mem_bootstrap + < mcsim> ok + < braunr> mcsim: i don't understand your call to kmem_free + < mcsim> braunr: It shouldn't be there? + < braunr> why should it be there ? + < braunr> you're freeing what the copy object references + < braunr> it's strange that it even works + < braunr> also, you shouldn't pass infop directly as the copy object + < braunr> i guess you get a warning for that + < braunr> do what the original code does: use an intermediate copy object + and a cast + < mcsim> ok + < braunr> another error (without consequence but still, you should mind it) + < braunr> simple_lock(&mem_cache_list_lock); + < braunr> [...] + < braunr> kr = kmem_alloc(ipc_kernel_map, &info, info_size); + < braunr> you can't hold simple locks while allocating memory + < braunr> read how the original implementation works around this + < mcsim> ok + < braunr> i guess host_zone_info assumes the zone list doesn't change much + while unlocked + < braunr> or that's it's rather unimportant since it's for debugging + < braunr> a strict snapshot isn't required + < braunr> list_for_each_entry(&mem_cache_list, cache, node) max_caches++; + < braunr> you should really use two separate lines for readability + < braunr> also, instead of counting each time, you could just maintain a + global counter + < braunr> mcsim: use strncpy instead of strcpy for the cache names + < braunr> not to avoid overflow but rather to clear the unused bytes at the + end of the buffer + < braunr> mcsim: about kmem_alloc vs kmem_alloc_pageable, it's a minor + issue + < braunr> you're handing off debugging data to a userspace application + < braunr> a rather dull reporting tool in most cases, which doesn't require + wired down memory + < braunr> so in order to better use available memory, pageable memory + should be used + < braunr> in the future i guess it could become a not-so-minor issue though + < mcsim> ok. I'll fix it + < braunr> mcsim: have you tried to run the kernel with MC_VERIFY always on + ? + < braunr> MEM_CF_VERIFY actually + < mcsim1> yes. + < braunr> oh + < braunr> nothing wrong + < braunr> ? + < mcsim1> it is always set + < braunr> ok + < braunr> ah, you set it in macros.h .. + < braunr> don't + < braunr> put it in mem.c if you want, or better, make it a compile-time + option + < braunr> macros.h is a tiny macro library, it shouldn't define such + unrelated options + < mcsim1> ok. + < braunr> mcsim1: did you try fault injection to make sure the checking + code actually works and how it behaves when an error occurs ? + < mcsim1> I think that when I finish I'll merge files cpu.h and macros.h + with mem.c + < braunr> yes that would simplify things + < mcsim1> Yes. When I confused with types mem_buf_fill worked wrong and + panic occurred. + < braunr> very good + < braunr> have you progressed concerning the measurements you wanted to do + ? + < mcsim1> not much. + < braunr> ok + < mcsim1> I think they will be ready in a few days. + < antrik> what measurements are these? + < mcsim1> braunr: What maximal size for static data and stack in kernel? + < braunr> what do you mean ? + < braunr> kernel stacks are one page if i'm right + < braunr> static data (rodata+data+bss) are limited by grub bugs only :) + < mcsim1> braunr: probably they are present, because when I created too big + array I couldn't boot kernel + < braunr> local variable or static ? + < mcsim1> static + < braunr> how large ? + < mcsim1> 4Mb + < braunr> hm + < braunr> it's not a grub bug then + < braunr> i was able to embed as much as 32 MiB in x15 while doing this + kind of tests + < braunr> I guess it's the gnu mach boot code which only preallocates one + page for the initial kernel mapping + < braunr> one PTP (page table page) maps 4 MiB + < braunr> (x15 does this completely dynamically, unlike mach or even + current BSDs) + < mcsim1> antrik: First I want to measure time of each cache + creation/allocation/deallocation and then compile kernel. + < braunr> cache creation is irrelevant + < braunr> because of the cpu pools in the new allocator, you should test at + least two different allocation patterns + < braunr> one with quick allocs/frees + < braunr> the other with large numbers of allocs then their matching frees + < braunr> (larger being at least 100) + < braunr> i'd say the cpu pool layer is the real advantage over the + previous zone allocator + < braunr> (from a performance perspective) + < mcsim1> But there is only one cpu + < braunr> it doesn't matter + < braunr> it's stil a very effective cache + < braunr> in addition to reducing contention + < braunr> compare mem_cpu_pool_pop() against mem_cache_alloc_from_slab() + < braunr> mcsim1: work is needed to polish the whole thing, but getting it + actually working is a nice achievement for someone new on the project + < braunr> i hope it helped you learn about memory allocation, virtual + memory, gnu mach and the hurd in general :) + < antrik> indeed :-) + + +# IRC, freenode, #hurd, 2011-09-06 + + [some performance testing] + <braunr> i'm not sure such long tests are relevant but let's assume balloc + is slower + <braunr> some tuning is needed here + <braunr> first, we can see that slab allocation occurs more often in balloc + than page allocation does in zalloc + <braunr> so yes, as slab allocation is slower (have you measured which part + actually is slow ? i guess it's the kmem_alloc call) + <braunr> the whole process gets a bit slower too + <mcsim> I used alloc_size = 4096 for zalloc + <braunr> i don't know what that is exactly + <braunr> but you can't hold 500 16 bytes buffers in a page so zalloc must + have had free pages around for that + <mcsim> I use kmem_alloc_wired + <braunr> if you have time, measure it, so that we know how much it accounts + for + <braunr> where are the results for dealloc ? + <mcsim> I can't give you result right now because internet works very + bad. But for first DEALLOC result are the same, exept some cases when it + takes balloc for more than 1000 ticks + <braunr> must be the transfer from the cpu layer to the slab layer + <mcsim> as to kmem_alloc_wired. I think zalloc uses this function too for + allocating objects in zone I test. + <braunr> mcsim: yes, but less frequently, which is why it's faster + <braunr> mcsim: another very important aspect that should be measured is + memory consumption, have you looked into that ? + <mcsim> I think that I made too little iterations in test SMALL + <mcsim> If I increase constant SMALL_TESTS will it be good enough? + <braunr> mcsim: i don't know, try both :) + <braunr> if you increase the number of iterations, balloc average time will + be lower than zalloc, but this doesn't remove the first long + initialization step on the allocated slab + <mcsim> SMALL_TESTS to 500, I mean + <braunr> i wonder if maintaining the slabs sorted through insertion sort is + what makes it slow + <mcsim> braunr: where do you sort slabs? I don't see this. + <braunr> mcsim: mem_cache_alloc_from_slab and its free counterpart + <braunr> mcsim: the mem_source stuff is useless in gnumach, you can remove + it and directly call the kmem_alloc/free functions + <mcsim> But I have to make special allocator for kernel map entries. + <braunr> ah right + <mcsim> btw. It turned out that 256 entries are not enough. + <braunr> that's weird + <braunr> i'll make a patch so that the mem_source code looks more like what + i have in x15 then + <braunr> about the results, i don't think the slab layer is that slow + <braunr> it's the cpu_pool_fill/drain functions that take time + <braunr> they preallocate many objects (64 for your objects size if i'm + right) at once + <braunr> mcsim: look at the first result page: some times, a number around + 8000 is printed + <braunr> the common time (ticks, whatever) for a single object is 120 + <braunr> 8132/120 is 67, close enough to the 64 value + <mcsim> I forgot about SMALL tests here are they: + http://paste.debian.net/128533/ (balloc) http://paste.debian.net/128534/ + (zalloc) + <mcsim> braunr: why do you divide 8132 by 120? + <braunr> mcsim: to see if it matches my assumption that the ~8000 number + matches the cpu_pool_fill call + <mcsim> braunr: I've got it + <braunr> mcsim: i'd be much interested in the dealloc results if you can + paste them too + <mcsim> dealloc: http://paste.debian.net/128589/ + http://paste.debian.net/128590/ + <braunr> mcsim: thanks + <mcsim> second dealloc: http://paste.debian.net/128591/ + http://paste.debian.net/128592/ + <braunr> mcsim: so the main conclusion i retain from your tests is that the + transfers from the cpu and the slab layers are what makes the new + allocator a bit slower + <mcsim> OPERATION_SMALL dealloc: http://paste.debian.net/128593/ + http://paste.debian.net/128594/ + <braunr> mcsim: what needs to be measured now is global memory usage + <mcsim> braunr: data from /proc/vmstat after kernel compilation will be + enough? + <braunr> mcsim: let me check + <braunr> mcsim: no it won't do, you need to measure kernel memory usage + <braunr> the best moment to measure it is right after zone_gc is called + <mcsim> Are there any facilities in gnumach for memory measurement? + <braunr> it's specific to the allocators + <braunr> just count the number of used pages + <braunr> after garbage collection, there should be no free page, so this + should be rather simple + <mcsim> ok + <mcsim> braunr: When I measure memory usage in balloc, what formula is + better cache->nr_slabs * cache->bufs_per_slab * cache->buf_size or + cache->nr_slabs * cache->slab_size? + <braunr> the latter + + +# IRC, freenode, #hurd, 2011-09-07 + + <mcsim> braunr: I've disabled calling of mem_cpu_pool_fill and allocator + became faster + <braunr> mcsim: sounds nice + <braunr> mcsim: i suspect the free path might not be as fast though + <mcsim> results for first calling: http://paste.debian.net/128639/ second: + http://paste.debian.net/128640/ and with many alloc/free: + http://paste.debian.net/128641/ + <braunr> mcsim: thanks + <mcsim> best result are for second call: average time decreased from 159.56 + to 118.756 + <mcsim> First call slightly worse, but this is because I've added some + profiling code + <braunr> i still see some ~8k lines in 128639 + <braunr> even some around ~12k + <mcsim> I think this is because of mem_cache_grow I'm investigating it now + <braunr> i guess so too + <mcsim> I've measured time for first call in cache and from about 22000 + mem_cache_grow takes 20000 + <braunr> how did you change the code so that it doesn't call + mem_cpu_pool_fill ? + <braunr> is the cpu layer still used ? + <mcsim> http://paste.debian.net/128644/ + <braunr> don't forget the free path + <braunr> mcsim: anyway, even with the previous slightly slower behaviour we + could observe, the performance hit is negligible + <mcsim> Is free path a compilation? (I'm sorry for my english) + <braunr> mcsim: mem_cache_free + <braunr> mcsim: the last two measurements i'd advise are with big (>4k) + object sizes and, really, kernel allocator consumption + <mcsim> http://paste.debian.net/128648/ http://paste.debian.net/128646/ + http://paste.debian.net/128649/ (first, second, small) + <braunr> mcsim: these numbers are closer to the zalloc ones, aren't they ? + <mcsim> deallocating slighty faster too + <braunr> it may not be the case with larger objects, because of the use of + a tree + <mcsim> yes, they are closer + <braunr> but then, i expect some space gains + <braunr> the whole thing is about compromise + <mcsim> ok. I'll try to measure them today. Anyway I'll post result and you + could read them in the morning + <braunr> at least, it shows that the zone allocator was actually quite good + <braunr> i don't like how the code looks, there are various hacks here and + there, it lacks self inspection features, but it's quite good + <braunr> and there was little room for true improvement in this area, like + i told you :) + <braunr> (my allocator, like the current x15 dev branch, focuses on mp + machines) + <braunr> mcsim: thanks again for these numbers + <braunr> i wouldn't have had the courage to make the tests myself before + some time eh + <mcsim> braunr: hello. Look at the small_4096 results + http://paste.debian.net/128692/ (balloc) http://paste.debian.net/128693/ + (zalloc) + <braunr> mcsim: wow, what's that ? :) + <braunr> mcsim: you should really really include your test parameters in + the report + <braunr> like object size, purpose, and other similar details + <mcsim> for balloc I specified only object_size = 4096 + <mcsim> for zalloc object_size = 4096, alloc_size = 4096, memtype = 0; + <braunr> the results are weird + <braunr> apart from the very strange numbers (e.g. 0 or 4429543648), none + is around 3k, which is the value matching a kmem_alloc call + <braunr> happy to see balloc behaves quite good for this size too + <braunr> s/good/well/ + <mcsim> Oh + <mcsim> here is significant only first 101 lines + <mcsim> I'm sorry + <braunr> ok + <braunr> what does the test do again ? 10 loops of 10 allocs/frees ? + <mcsim> yes + <braunr> ok, so the only slowdown is at the beginning, when the slabs are + created + <braunr> the two big numbers (31844 and 19548) are strange + <mcsim> on the other hand time of compilation is + <mcsim> balloc zalloc + <mcsim> 38m28.290s 38m58.400s + <mcsim> 38m38.240s 38m42.140s + <mcsim> 38m30.410s 38m52.920s + <braunr> what are you compiling ? + <mcsim> gnumach kernel + <braunr> in 40 mins ? + <mcsim> yes + <braunr> you lack hvm i guess + <mcsim> is it long? + <mcsim> I use real PC + <braunr> very + <braunr> ok + <braunr> so it's normal + <mcsim> in vm it was about 2 hours) + <braunr> the difference really is negligible + <braunr> ok i can explain the big numbers + <braunr> the slab size depends on the object size, and for 4k, it is 32k + <braunr> you can store 8 4k buffers in a slab (lines 2 to 9) + <mcsim> so we need use kmem_alloc_* 8 times? + <braunr> on line 10, the ninth object is allocated, which adds another slab + to the cache, hence the big number + <braunr> no, once for a size of 32k + <braunr> and then the free list is initialized, which means accessing those + pages, which means tlb misses + <braunr> i guess the zone allocator already has free pages available + <mcsim> I see + <braunr> i think you can stop performance measurements, they show the + allocator is slightly slower, but so slightly we don't care about that + <braunr> we need numbers on memory usage now (at the page level) + <braunr> and this isn't easy + <mcsim> For balloc I can get numbers if I summarize nr_slabs*slab_size for + each cache, isn't it? + <braunr> yes + <braunr> you can have a look at the original implementation, function + mem_info + <mcsim> And for zalloc I have to summarize of cur_size and then add + zalloc_wasted_space? + <braunr> i don't know :/ + <braunr> i think the best moment to obtain accurate values is after zone_gc + removes the collected pages + <braunr> for both allocators, you could fill a stats structure at that + moment, and have an rpc copy that structure when a client tool requests + it + <braunr> concerning your tests, there is another point to have in mind + <braunr> the very first loop in your code shows a result of 31844 + <braunr> although you disabled the call to cpu_pool_fill + <braunr> but the reason why it's so long is that the cpu layer still exists + <braunr> and if you look carefully, the cpu pools are created as needed on + the free path + <mcsim> I removed cpu_pool_drain + <braunr> but not cpu_pool_push/pop i guess + <mcsim> http://paste.debian.net/128698/ + <braunr> see, you still allocate the cpu pool array on the free path + <mcsim> but I don't fill it + <braunr> that's not the point + <braunr> it uses mem_cache_alloc + <braunr> so in a call to free, you can also have an allocation, that can + potentially create a new slab + <mcsim> I see, so I have to create cpu_pool at the initialization stage? + <braunr> no, you can't + <braunr> there is a reason why they're allocated on the free path + <braunr> but since you don't have the fill/drain functions, i wonder if you + should just comment out the whole cpu layer code + <braunr> but hmm + <braunr> no really, it's not worth the effort + <braunr> even with drains/fills, the results are really good enough + <braunr> it makes the allocator smp ready + <braunr> we should just keep it that way + <braunr> mcsim: fyi, the reason why cpu pool arrays are allocated on the + free path is to avoid recursion + <braunr> because cpu pool arrays are allocated from caches just as almost + everything else + <mcsim> ok + <mcsim> summ of cur_size and then adding zalloc_wasted_space gives 0x4e1954 + <mcsim> but this value isn't even page aligned + <mcsim> For balloc I've got 0x4c6000 0x4aa000 0x48d000 + <braunr> hm can you report them in decimal, >> 10 so that values are in KiB + ? + <mcsim> 4888 4776 4660 for balloc + <mcsim> 4998 for zalloc + <braunr> when ? + <braunr> after boot ? + <mcsim> boot, compile, zone_gc + <mcsim> and then measure + <braunr> ? + <mcsim> I call garbage collector before measuring + <mcsim> and I measure after kernel compilation + <braunr> i thought it took you 40 minutes + <mcsim> for balloc I got results at night + <braunr> oh so you already got them + <braunr> i can't beleive the kernel only consumes 5 MiB + <mcsim> before gc it takes about 9052 Kib + <braunr> can i see the measurement code ? + <braunr> oh, and how much ram does your machine have ? + <mcsim> 758 mb + <mcsim> 768 + <braunr> that's really weird + <braunr> i'd expect the kernel to consume much more space + <mcsim> http://paste.debian.net/128703/ + <mcsim> it's only dynamically allocated data + <braunr> yes + <braunr> ipc ports, rights, vm map entries, vm objects, and lots of other + hanging buffers + <braunr> about how much is zalloc_wasted_space ? + <braunr> if it's small or constant, i guess you could ignore it + <mcsim> about 492 + <mcsim> KiB + <braunr> well it's another good point, mach internal structures don't imply + much overhead + <braunr> or, the zone allocator is underused + + <tschwinge> mcsim, braunr: The memory allocator project is coming along + good, as I get from your IRC messages? + <braunr> tschwinge: yes, but as expected, improvements are minor + <tschwinge> But at the very least it's now well-known, maintainable code. + <braunr> yes, it's readable, easier to understand, provides self inspection + and is smp ready + <braunr> there also are less hacks, but a few less features (there are no + way to avoid sleeping so it's unusable - and unused - in interrupt + handlers) + <braunr> is* no way + <braunr> tschwinge: mcsim did a good job porting and measuring it + + +# IRC, freenode, #hurd, 2011-09-08 + + <antrik> braunr: note that the zalloc map used to be limited to 8 MiB or + something like that a couple of years ago... so it doesn't seems + surprising that the kernel uses "only" 5 MiB :-) + <antrik> (yes, we had a *lot* of zalloc panics back then...) + + +# IRC, freenode, #hurd, 2011-09-14 + + <mcsim> braunr: hello. I've written a constructor for kernel map entries + and it can return resources to their source. Can you have a look at it? + http://paste.debian.net/130037/ If all be OK I'll push it tomorrow. + <braunr> mcsim: send the patch through mail please, i'll apply it on my + copy + <braunr> are you sure the cache is reapable ? + <mcsim> All slabs, except first I allocate with kmem_alloc_wired. + <braunr> how can you be sure ? + <mcsim> First slab I allocate during bootstrap and use pmap_steal_memory + and further I use only kmem_alloc_wired + <braunr> no, you use kmem_free + <braunr> in kentry_dealloc_cache() + <braunr> which probably creates a recursion + <braunr> using the constructor this way isn't a good idea + <braunr> constructors are good for preconstructed state (set counters to 0, + init lists and locks, that kind of things, not allocating memory) + <braunr> i don't think you should try to make this special cache reapable + <braunr> mcsim: keep in mind constructors are applied on buffers at *slab* + creation, not at object allocation + <braunr> so if you allocate a single slab with, say, 50 or 100 objects per + slab, kmem_alloc_wired would be called that number of times + <mcsim> why kentry_dealloc_cache can create recursion? kentry_dealloc_cache + is called only by mem_cache_reap. + <braunr> right + <braunr> but are you totally sure mem_cache_reap() can't be called by + kmem_free() ? + <braunr> i think you're right, it probably can't + + +# IRC, freenode, #hurd, 2011-09-25 + + <mcsim> braunr: hello. I rewrote constructor for kernel entries and seems + that it works fine. I think that this was last milestone. Only moving of + memory allocator sources to more appropriate place and merge with main + branch left. + <braunr> mcsim: it needs renaming and reindenting too + <mcsim> for reindenting C-x h Tab in emacs will be enough? + <braunr> mcsim: make sure which style must be used first + <mcsim> and what should I rename and where better to place allocator? For + example, there is no lib directory, like in x15. Should I create it and + move list.* and rbtree.* to lib/ or move these files to util/ or + something else? + <braunr> mcsim: i told you balloc isn't a good name before, use something + more meaningful (kmem is already used in gnumach unfortunately if i'm + right) + <braunr> you can put the support files in kern/ + <mcsim> what about vm_alloc? + <braunr> you should prefix it with vm_ + <braunr> shouldn't + <braunr> it's a top level allocator + <braunr> on top of the vm system + <braunr> maybe mcache + <braunr> hm no + <braunr> maybe just km_ + <mcsim> kern/km_alloc.*? + <braunr> no + <braunr> just km + <mcsim> ok. + + +# IRC, freenode, #hurd, 2011-09-27 + + <mcsim> braunr: hello. When I've tried to speed of new allocator and bad + I've removed function mem_cpu_pool_fill. But you've said to undo this. I + don't understand why this function is necessary. Can you explain it, + please? + <mcsim> When I've tried to compare speed of new allocator and old* + <braunr> i'm not sure i said that + <braunr> i said the performance overhead is negligible + <braunr> so it's better to leave the cpu pool layer in place, as it almost + doesn't hurt + <braunr> you can implement the KMEM_CF_NO_CPU_POOL I added in the x15 mach + version + <braunr> so that cpu pools aren't used by default, but the code is present + in case smp is implemented + <mcsim> I didn't remove cpu pool layer. I've just removed filling of cpu + pool during creation of slab. + <braunr> how do you fill the cpu pools then ? + <mcsim> If object is freed than it is added to cpu poll + <braunr> so you don't fill/drain the pools ? + <braunr> you try to get/put an object and if it fails you directly fall + back to the slab layer ? + <mcsim> I drain them during garbage collection + <braunr> oh + <mcsim> yes + <braunr> you shouldn't touch the cpu layer during gc + <braunr> the number of objects should be small enough so that we don't care + much + <mcsim> ok. I can drain cpu pool at any other time if it is prohibited to + in mem_gc. + <mcsim> But why do we need to fill cpu poll during slab creation? + <mcsim> In this case allocation consist of: get object from slab -> put it + to cpu pool -> get it from cpu pool + <mcsim> I've just remove last to stages + <braunr> hm cpu pools aren't filled at slab creation + <braunr> they're filled when they're empty, and drained when they're full + <braunr> so that the number of objects they contain is increased/reduced to + a value suitable for the next allocations/frees + <braunr> the idea is to fall back as little as possible to the slab layer + because it requires the acquisition of the cache lock + <mcsim> oh. You're right. I'm really sorry. The point is that if cpu pool + is empty we don't need to fill it first + <braunr> uh, yes we do :) + <mcsim> Why cache locking is so undesirable? If we have free objects in + slabs locking will not take a lot if time. + <braunr> mcsim: it's undesirable on a smp system + <mcsim> ok. + <braunr> mcsim: and spin locks are normally noops on a up system + <braunr> which is the case in gnumach, hence the slightly better + performances without the cpu layer + <braunr> but i designed this allocator for x15, which only supports mp + systems :) + <braunr> mcsim: sorry i couldn't look at your code, sick first, busy with + server migration now (new server almost ready for xen hurds :)) + <mcsim> ok. + <mcsim> I ended with allocator if didn't miss anything important:) + <braunr> i'll have a look soon i hope :) + + +# IRC, freenode, #hurd, 2011-09-27 + + <antrik> braunr: would it be realistic/useful to check during GC whether + all "used" objects are actually in a CPU pool, and if so, destroy them so + the slab can be freed?... + <antrik> mcsim: BTW, did you ever do any measurements of memory + use/fragmentation? + <mcsim> antrik: I couldn't do this for zalloc + <antrik> oh... why not? + <antrik> (BTW, I would be interested in a comparision between using the CPU + layer, and bare slab allocation without CPU layer) + <mcsim> Result I've got were strange. It wasn't even aligned to page size. + <mcsim> Probably is it better to look into /proc/vmstat? + <mcsim> Because I put hooks in the code and probably I missed something + <antrik> mcsim: I doubt vmstat would give enough information to make any + useful comparision... + <braunr> antrik: isn't this draining cpu pools at gc time ? + <braunr> antrik: the cpu layer was found to add a slight overhead compared + to always falling back to the slab layer + <antrik> braunr: my idea is only to drop entries from the CPU cache if they + actually prevent slabs from being freed... if other objects in the slab + are really in use, there is no point in flushing them from the CPU cache + <antrik> braunr: I meant comparing the fragmentation with/without CPU + layer. the difference in CPU usage is probably negligable anyways... + <antrik> you might remember that I was (and still am) sceptical about CPU + layer, as I suspect it worsens the good fragmentation properties of the + pure slab allocator -- but it would be nice to actually check this :-) + <braunr> antrik: right + <braunr> antrik: the more i think about it, the more i consider slqb to be + a better solution ...... :> + <braunr> an idea for when there's time + <braunr> eh + <antrik> hehe :-) + + +# IRC, freenode, #hurd, 2011-10-13 + + <braunr> mcsim: what's the current state of your gnumach branch ? + <mcsim> I've merged it with master in September + <braunr> yes i've seen that, but does it build and run fine ? + <mcsim> I've tested it on gnumach from debian repository, but for building + I had to make additional change in device/ramdisk.c, as I mentioned. + <braunr> mcsim: why ? + <mcsim> And it runs fine for me. + <braunr> mcsim: why did you need to make other changes ? + <mcsim> because there is a patch which comes with from-debian-repository + kernel and it addes some code, where I have to make changes. Earlier + kernel_map was a pointer to structure, but I change that and now + kernel_map is structure. So handling to it should be by taking the + address (&kernel_map) + <braunr> why did you do that ? + <braunr> or put it another way: what made you do that type change on + kernel_map ? + <mcsim> Earlier memory for kernel_map was allocating with zalloc. But now + salloc can't allocate memory before it's initialisation + <braunr> that's not a good reason + <braunr> a simple workaround for your problem is this : + <braunr> static struct vm_map kernel_map_store; + <braunr> vm_map_t kernel_map = &kernel_map_store; + <mcsim> braunr: Ok. I'll correct this. + + +# IRC, freenode, #hurd, 2011-11-01 + + <braunr> etenil: but mcsim's work is, for one, useful because the allocator + code is much clearer, adds some debugging support, and is smp-ready + + +# IRC, freenode, #hurd, 2011-11-14 + + <braunr> i've just realized that replacing the zone allocator removes most + (if not all) static limit on allocated objects + <braunr> as we have nothing similar to rlimits, this means kernel resources + are actually exhaustible + <braunr> and i'm not sure every allocation is cleanly handled in case of + memory shortage + <braunr> youpi: antrik: tschwinge: is this acceptable anyway ? + <braunr> (although IMO, it's also a good thing to get rid of those limits + that made the kernel panic for no valid reason) + <youpi> there are actually not many static limits on allocated objects + <youpi> only a few have one + <braunr> those defined in kern/mach_param.h + <youpi> most of them are not actually enforced + <braunr> ah ? + <braunr> they are used at zinit() time + <braunr> i thought they were + <youpi> yes, but most zones are actually fine with overcoming the max + <braunr> ok + <youpi> see zone->max_size += (zone->max_size >> 1); + <youpi> you need both !EXHAUSTIBLE and FIXED + <braunr> ok + <pinotree> making having rlimits enforced would be nice... + <pinotree> s/making// + <braunr> pinotree: the kernel wouldn't handle many standard rlimits anyway + + <braunr> i've just committed my final patch on mcsim's branch, which will + serve as the starting point for integration + <braunr> which means code in this branch won't change (or only last minute + changes) + <braunr> you're invited to test it + <braunr> there shouldn't be any noticeable difference with the master + branch + <braunr> a bit less fragmentation + <braunr> more memory can be reclaimed by the VM system + <braunr> there are debugging features + <braunr> it's SMP ready + <braunr> and overall cleaner than the zone allocator + <braunr> although a bit slower on the free path (because of what's + performed to reduce fragmentation) + <braunr> but even "slower" here is completely negligible + + +# IRC, freenode, #hurd, 2011-11-15 + + <mcsim> I enabled cpu_pool layer and kentry cache exhausted at "apt-get + source gnumach && (cd gnumach-* && dpkg-buildpackage)" + <mcsim> I mean kernel with your last commit + <mcsim> braunr: I'll make patch how I've done it in a few minutes, ok? It + will be more specific. + <braunr> mcsim: did you just remove the #if NCPUS > 1 directives ? + <mcsim> no. I replaced macro NCPUS > 1 with SLAB_LAYER, which equals NCPUS + > 1, than I redefined macro SLAB_LAYER + <braunr> ah, you want to make the layer optional, even on UP machines + <braunr> mcsim: can you give me the commands you used to trigger the + problem ? + <mcsim> apt-get source gnumach && (cd gnumach-* && dpkg-buildpackage) + <braunr> mcsim: how much ram & swap ? + <braunr> let's see if it can handle a quite large aptitude upgrade + <mcsim> how can I check swap size? + <braunr> free + <braunr> cat /proc/meminfo + <braunr> top + <braunr> whatever + <mcsim> total used free shared buffers + cached + <mcsim> Mem: 786368 332296 454072 0 0 + 0 + <mcsim> -/+ buffers/cache: 332296 454072 + <mcsim> Swap: 1533948 0 1533948 + <braunr> ok, i got the problem too + <mcsim> braunr: do you run hurd in qemu? + <braunr> yes + <braunr> i guess the cpu layer increases fragmentation a bit + <braunr> which means more map entries are needed + <braunr> hm, something's not right + <braunr> there are only 26 kernel map entries when i get the panic + <braunr> i wonder why the cache gets that stressed + <braunr> hm, reproducing the kentry exhaustion problem takes quite some + time + <mcsim> braunr: what do you mean? + <braunr> sometimes, dpkg-buildpackage finishes without triggering the + problem + <mcsim> the problem is in apt-get source gnumach + <braunr> i guess the problem happens because of drains/fills, which + allocate/free much more object than actually preallocated at boot time + <braunr> ah ? + <braunr> ok + <braunr> i've never had it at that point, only later + <braunr> i'm unable to trigger it currently, eh + <mcsim> do you use *-dbg kernel? + <braunr> yes + <braunr> well, i use the compiled kernel, with the slab allocator, built + with the in kernel debugger + <mcsim> when you run apt-get source gnumach, you run it in clean directory? + Or there are already present downloaded archives? + <braunr> completely empty + <braunr> ah just got it + <braunr> ok the limit is reached, as expected + <braunr> i'll just bump it + <braunr> the cpu layer drains/fills allocate several objects at once (64 if + the size is small enough) + <braunr> the limit of 256 (actually 252 since the slab descriptor is + embedded in its slab) is then easily reached + <antrik> mcsim: most direct way to check swap usage is vmstat + <braunr> damn, i can't live without slabtop and the amount of + active/inactive cache memory any more + <braunr> hm, weird, we have active/inactive memory in procfs, but not + buffers/cached memory + <braunr> we could set buffers to 0 and everything as cached memory, since + we're currently unable to communicate the purpose of cached memory + (whether it's used by disk servers or file system servers) + <braunr> mcsim: looks like there are about 240 kernel map entries (i forgot + about the ones used in kernel submaps) + <braunr> so yes, addin the cpu layer is what makes the kernel reach the + limit more easily + <mcsim> braunr: so just increasing limit will solve the problem? + <braunr> mcsim: yes + <braunr> slab reclaiming looks very stable + <braunr> and unfrequent + <braunr> (which is surprising) + <pinotree> braunr: "unfrequent"? + <braunr> pinotree: there isn't much memory pressure + <braunr> slab_collect() gets called once a minute on my hurd + <braunr> or is it infrequent ? + <braunr> :) + <pinotree> i have no idea :) + <braunr> infrequent, yes + + +# IRC, freenode, #hurd, 2011-11-16 + + <braunr> for those who want to play with the slab branch of gnumach, the + slabinfo tool is available at http://git.sceen.net/rbraun/slabinfo.git/ + <braunr> for those merely interested in numbers, here is the output of + slabinfo, for a hurd running in kvm with 512 MiB of RAM, an unused swap, + and a short usage history (gnumach debian packages built, aptitude + upgrade for a dozen of packages, a few git commands) + <braunr> http://www.sceen.net/~rbraun/slabinfo.out + <antrik> braunr: numbers for a long usage history would be much more + interesting :-) + + +## IRC, freenode, #hurd, 2011-11-17 + + <braunr> antrik: they'll come :) + <etenil> is something going on on darnassus? it's mighty slow + <braunr> yes + <braunr> i've rebooted it to run a modified kernel (with the slab + allocator) and i'm building stuff on it to stress it + <braunr> (i don't have any other available machine with that amount of + available physical memory) + <etenil> ok + <antrik> braunr: probably would be actually more interesting to test under + memory pressure... + <antrik> guess that doesn't make much of a difference for the kernel object + allocator though + <braunr> antrik: if ram is larger, there can be more objects stored in + kernel space, then, by building something large such as eglibc, memory + pressure is created, causing caches to be reaped + <braunr> our page cache is useless because of vm_object_cached_max + <braunr> it's a stupid arbitrary limit masking the inability of the vm to + handle pressure correctly + <braunr> if removing it, the kernel freezes soon after ram is filled + <braunr> antrik: it may help trigger the "double swap" issue you mentioned + <antrik> what may help trigger it? + <braunr> not checking this limit + <antrik> hm... indeed I wonder whether the freezes I see might have the + same cause + + +## IRC, freenode, #hurd, 2011-11-19 + + <braunr> http://www.sceen.net/~rbraun/slabinfo.out <= state of the slab + allocator after building the debian libc packages and removing all files + once done + <braunr> it's mostly the same as on any other machine, because of the + various arbitrary limits in mach (most importantly, the max number of + objects in the page cache) + <braunr> fragmentation is still quite low + <antrik> braunr: actually fragmentation seems to be lower than on the other + run... + <braunr> antrik: what makes you think that ? + <antrik> the numbers of currently unused objects seem to be in a similar + range IIRC, but more of them are reclaimable I think + <antrik> maybe I'm misremembering the other numbers + <braunr> there had been more reclaims on the other run + + +# IRC, freenode, #hurd, 2011-11-25 + + <braunr> mcsim: i've just updated the slab branch, please review my last + commit when you have time + <mcsim> braunr: Do you mean compilation/tests? + <braunr> no, just a quick glance at the code, see if it matches what you + intended with your original patch + <mcsim> braunr: everything is ok + <braunr> good + <braunr> i think the branch is ready for integration + + +# IRC, freenode, #hurd, 2011-12-17 + + <braunr> in the slab branch, there now is no use for the defines in + kern/mach_param.h + <braunr> should the file be removed or left empty as a placeholder for + future arbitrary limits ? + <braunr> (i'd tend ro remove it as a way of indicating we don't want + arbitrary limits but there may be a good reason to keep it around .. :)) + <youpi> I'd just drop it + <braunr> ok + <braunr> hmm maybe we do want to keep that one : + <braunr> #define IMAR_MAX (1 << 10) /* Max number of + msg-accepted reqs */ + <antrik> whatever that is... + <braunr> it gets returned in ipc_marequest_info + <braunr> but the mach_debug interface has never been used on the hurd + <braunr> there now is a master-slab branch in the gnumach repo, feel free + to test it + + +# IRC, freenode, #hurd, 2011-12-22 + + <youpi> braunr: does the new gnumach allocator has profiling features? + <youpi> e.g. to easily know where memory leaks reside + <braunr> youpi: you mean tracking call traces to allocated blocks ? + <youpi> not necessarily traces + <youpi> but at least means to know what kind of objects is filling memory + <braunr> it's very close to the zone allocator + <braunr> but instead of zones, there are caches + <braunr> each named after the type they store + <braunr> see http://www.sceen.net/~rbraun/slabinfo.out + <youpi> ok, so we can know, per-type, how much memory is used + <braunr> yes + <youpi> good + <braunr> if backtraces can easily be forged, it wouldn't be hard to add + that feature too + <youpi> does it dump such info when memory goes short? + <braunr> no but it can + <braunr> i've done this during tests + <youpi> it'd be good + <youpi> because I don't know in advance when a buildd will crash due to + that :) + <braunr> each time slab_collect() is called for example + <youpi> I mean not on collect, but when it's too late + <youpi> and thus always enabled + <braunr> ok + <youpi> (because there's nothing better to do than at least give infos) + <braunr> you just have to define "when it's too late", and i can add that + <youpi> when there is no memory left + <braunr> you mean when the number of free pages strictly reaches 0 ? + <youpi> yes + <braunr> ok + <youpi> i.e. just before crashing the kernel + <braunr> i see + + +# IRC, freenode, #hurdfr, 2012-01-02 + + <youpi> braunr: le code du slab allocator, il est écrit from scratch ? + <youpi> il y a encore du copyright carnegie mellon + <youpi> (dans slab_info.h du moins) + <youpi> ipc_hash_global_size = 256; + <youpi> il faudrait mettre 256 comme constante dans un header + <youpi> sinon c'est encore une valeur arbitraire cachée dans du code + <youpi> de même pour ipc_marequest_size etc. + <braunr> youpi: oui, from scratch + <braunr> slab_info.h est à l'origine zone_info.h + <braunr> pour les valeurs fixes, elles étaient déjà présentes de cette + façon, j'ai pensé qu'il valait mieux laisser comme ça pour faciliter la + lecture des diffs + <braunr> je ferai des macros à la place + <braunr> du coup il faudra peut-être remettre mach_param.h + <braunr> ou alors dans les .h ipc + + +# IRC, freenode, #hurd, 2012-01-18 + + <braunr> does the slab branch need other reviews/reports before being + integrated ? + + +# IRC, freenode, #hurd, 2012-01-30 + + <braunr> youpi: do you have some idea about when you want to get the slab + branch in master ? + <youpi> I was considering as soon as mcsim gets his paper + <braunr> right + + +# IRC, freenode, #hurd, 2012-02-22 + + <mcsim> Do I understand correct, that real memory page should be + necessarily in one of following lists: vm_page_queue_active, + vm_page_queue_inactive, vm_page_queue_free? + <braunr> cached pages are + <braunr> some special pages used only by the kernel aren't + <braunr> pages can be both wired and cached (i.e. managed by the page + cache), so that they can be passed to external applications and then + unwired (as is the case with your host_slab_info() function if you + remember) + <braunr> use "physical" instead of "real memory" + <mcsim> braunr: thank you. + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> youpi: tschwinge: when the slab code was added, a few new files + made into gnumach that come from my git repo and are used in other + projects as well + <braunr> they're licensed under BSD upstream and GPL in gnumach, and though + it initially didn't disturb me, now it does + <braunr> i think i should fix this by leaving the original copyright and + adding the GPL on top + <youpi> sure, submit a patch + <braunr> hm i have direct commit acces if im right + <youpi> then fix it :) + <braunr> do you want to review ? + <youpi> I don't think there is any need to + <braunr> ok diff --git a/open_issues/gnumach_memory_management/pmap.out b/open_issues/gnumach_memory_management/pmap.out new file mode 100644 index 00000000..b1af1e66 --- /dev/null +++ b/open_issues/gnumach_memory_management/pmap.out @@ -0,0 +1,85 @@ +Start End Size Offset rwxpc RWX I/W/A Dev Inode - File +c0000000-c16c1fff 23304k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16c2000-c16c2fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16c3000-c16e2fff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16e3000-c999cfff 133864k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ kmem_map ] + c16e3000-c16e3fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c16e4000-c1736fff 332k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1737000-c1737fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1738000-c1766fff 188k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1767000-c1767fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1768000-c182dfff 792k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c182e000-c182efff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c182f000-c187bfff 308k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c187c000-c187cfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c187d000-c187dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1880000-c189ffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c999d000-ca99cfff 16384k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ pager_map ] +ca99d000-ca9b7fff 108k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9b8000-ca9b9fff 8k 0a9b8000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +ca9ba000-ca9bbfff 8k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9bc000-ca9bffff 16k 0a9bc000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +ca9c0000-ca9dffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9e0000-cab0bfff 1200k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ phys_map ] +cab0c000-cad16fff 2092k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ mb_map ] + cab0c000-cab0cfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + cab0d000-cab3afff 184k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad17000-cad26fff 64k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad27000-cad2cfff 24k 0ad27000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cad2d000-cad2dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad2e000-cad2ffff 8k 0ad2e000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cad30000-cae0ffff 896k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cae10000-cae11fff 8k 0ae10000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cae12000-cae81fff 448k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cae82000-cae83fff 8k 0ae82000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cae84000-caecbfff 288k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caecc000-caecdfff 8k 0aecc000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caece000-caecefff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caecf000-caecffff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caed0000-caed1fff 8k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caed2000-caed3fff 8k 0aed2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caed4000-caee5fff 72k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caee6000-caee9fff 16k 0aee6000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caeea000-caeeefff 20k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caeef000-caef4fff 24k 0aeef000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caef5000-cb00cfff 1120k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb00d000-cb01cfff 64k 0b00d000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb01d000-cb02afff 56k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb02b000-cb82afff 8192k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ ubc_pager ] +cb82b000-cb838fff 56k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb839000-cb839fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb83a000-cb83bfff 8k 0b83a000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb83c000-cb855fff 104k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb856000-cb857fff 8k 0b856000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb858000-cb858fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb859000-cb85cfff 16k 0b859000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb85d000-cb85dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb85e000-cb85ffff 8k 0b85e000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb860000-cb88ffff 192k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb890000-cb8cffff 256k 0b890000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb8d0000-cb8f0fff 132k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb8f1000-cb8f4fff 16k 0b8f1000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb8f5000-cba03fff 1084k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cba04000-cba04fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cba05000-cbaf1fff 948k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbaf2000-cbaf3fff 8k 0baf2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbaf4000-cbaf7fff 16k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbaf8000-cbafffff 32k 0baf8000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb00000-cbb70fff 452k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbb71000-cbb76fff 24k 0bb71000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb77000-cbb7bfff 20k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbb7c000-cbb7ffff 16k 0bb7c000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb80000-cbbc1fff 264k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc2000-cbbc2fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc3000-cbbc3fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc4000-cbbc5fff 8k 0bbc4000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbc6000-cbbc8fff 12k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc9000-cbbcafff 8k 0bbc9000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbcb000-cbbcdfff 12k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbce000-cbbcffff 8k 0bbce000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbd0000-cbca1fff 840k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbca2000-cbcadfff 48k 0bca2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbcae000-cbcaefff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbcaf000-cbcb2fff 16k 0bcaf000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbcc0000-cbcdffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + total 193356k diff --git a/open_issues/gnumach_memory_management_2.mdwn b/open_issues/gnumach_memory_management_2.mdwn new file mode 100644 index 00000000..64aae2a4 --- /dev/null +++ b/open_issues/gnumach_memory_management_2.mdwn @@ -0,0 +1,246 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +IRC, freenode, #hurd, 2011-10-16: + + <youpi> braunr: I realize that kmem_alloc_wired maps the allocated pages in + the kernel map + <youpi> it's a bit of a waste when my allocation is exactly a page size + <youpi> is there a proper page allocation which would simply return its + physical address? + <youpi> pages returned by vm_page_grab may get swapped out, right? + <youpi> so could it be a matter of calling vm_page_alloc then vm_page_wire + (with lock_queues held) ? + <youpi> s/alloc/grab/ + <braunr> vm_page_grab() is only used at boot iirc + <braunr> youpi: mapping allocated memory in the kernel map is normal, even + if it's only a page + <braunr> the allocated area usually gets merged with an existing + vm_map_entry + <braunr> youpi: also, i'm not sure about what you're trying to do here, so + my answers may be out of scope :p + <youpi> saving addressing space + <youpi> with that scheme we're using twice as much addressing space for + kernel buffers + <braunr> kernel or user task ? + <youpi> kernl + <braunr> hm are there so many wired areas ? + <youpi> several MiBs, yes + <youpi> there are also the zalloc areas + <braunr> that's pretty normal + <youpi> which I've recently incrased + <braunr> hm forget what i've just said about vm_page_grab() + <braunr> youpi: is there a particular problem caused by kernel memory + exhaustion ? + <youpi> I currently can't pass the dh_strip stage of iceweasel due to this + <youpi> it can not allocate a stack + <braunr> a kernel thread stack ? + <youpi> yes + <braunr> that's surprising + <youpi> it'd be good to have a kernel memory profile + <braunr> vminfo is able to return the kernel map + <youpi> well, it's not suprising if the kernel map is full + <youpi> but it doesn't tell what allocates which p ieces + <braunr> that's what i mean, it's surprising to have a full kernel map + <youpi> (that's what profiling is about) + <braunr> right + <youpi> well, it's not really surprising, considering that the krenel map + size is arbitrarily chosen + <braunr> youpi: 2 GiB is really high enough + <youpi> it's not 2GiB, precisely + <youpi> there is much of the 2GiB addr space which is spent on physical + memory mapping + <youpi> then there is the virtual mapping + <braunr> are you sure we're talking about the kernel map, or e.g. the kmem + map + <youpi> which is currently only 192MiB + <youpi> the kmem_map part of kernel_map + <braunr> ok, the kmem_map submap then + <braunr> netbsd has used 128 MiB for yeas with almost no issue + <braunr> mach uses more kernel objects so it's reasonable to have a bigger + map + <braunr> but that big .. + <youpi> I've made the zalloc areas quite big + <youpi> err, not only zalloc area + <braunr> kernel stacks are allocated directly from the kernel map + <youpi> kalloc to 64MiB, zalloc to 64MiB + <youpi> ipc map size to 8MiB + <braunr> youpi: it could be the lack of kernel map entries + <youpi> and the device io map to 16MiB + <braunr> do you have the exact error message ? + <youpi> no more room for vm_map_find_entry in 71403294 + <youpi> no more rooom for kmem_alloc_aligned in 71403294 + <braunr> ah, aligned + <youpi> for a stack + <youpi> which is 4 pages only + <braunr> memory returned by kmem functions always return pages + <braunr> hum + <braunr> kmem functions always return memory in page units + <youpi> and my xen driver is allocating 1MiB memory for the network buffer + <braunr> 4 pages for kernel stacks ? + <youpi> through kmem_alloc_wire + <braunr> that seems a lot + <youpi> that's needed for xen page updates + <youpi> without having to split the update in several parts + <braunr> ok + <braunr> but are there any alignment requirements ? + <youpi> I guess mach uses the alignment trick to find "self" + <youpi> anyway, an alignment on 4pages shouldn't be a problem + <braunr> i think kmem_alloc_aligned() is the generic function used both for + requests with and without alignment constraints + <youpi> so I was thinking about at least moving my xen net driver to + vm_grab_page instead of kmem_alloc + <youpi> and along this, maybe others + <braunr> but you only get a vm_page, you can't access the memory it + describes + <youpi> non, a lloc_aligned always aligns + <youpi> why? + <braunr> because it's not mapped + <youpi> there's even vm_grab_page_physical_addr + <youpi> it is, in the physical memory map + <braunr> ah, you mean using the direct mapped area + <youpi> yes + <braunr> then yes + <braunr> i don't know that part much + <youpi> what I'm afraid of is the wiring + <braunr> why ? + <youpi> because I don't want to see my page swapped out :) + <youpi> or whatever might happen if I don't wire it + <braunr> oh i'm almost sure you won't + <youpi> why? + <youpi> why some people need to wire it, and I won't? + <braunr> because in most mach vm derived code i've seen, you have to + explicitely tell the vm your area is pageable + <youpi> ah, mach does such thing indeed + <braunr> wiring can be annoying when you're passing kernel data to external + tasks + <braunr> you have to make sure the memory isn't wired once passed + <braunr> but that's rather a security/resource management problem + <youpi> in the net driver case, it's not passed to anything else + <youpi> I'm seeing 19MiB kmem_alloc_wired atm + <braunr> looks ok to me + <braunr> be aware that the vm_resident code was meant for single page + allocations + <youpi> what does this mean? + <braunr> there is no buddy algorithm or anything else decent enough wrt + performance + <braunr> vm_page_grab_contiguous_pages() can be quite slow + <youpi> err, ok, but what is the relation with the question at stake ? + <braunr> you need 4 pages of direct mapped memory for stacks + <braunr> those pages need to be physically contiguous if you want to avoid + the mapping + <braunr> allocating physically contiguous pages in mach is slow + <braunr> :) + <youpi> I didn't mean I wanted to avoid the mapping for stacks + <youpi> for anything more than a page, kmem mapping should be fine + <youpi> I'm concerned with code which allocates only page per page + <youpi> which thus really doesn't need any mapping + <braunr> i don't know the mach details but in derived implementations, + there is almost no overhead when allocating single pages + <braunr> except for the tlb programming + <youpi> well, there is: twice as much addressing space + <braunr> well + <braunr> netbsd doesn't directly map physical memory + <braunr> and for others, like freebsd + <braunr> the area is just one vm_map_entry + <braunr> and on modern mmus, 4 MiBs physical mappings are used in pmap + <youpi> again, I don't care about tlb & performance + <youpi> just about the addressing space + <braunr> hm + <braunr> you say "twice" + <youpi> which is short when you're trying to link crazy stuff like + iceweasel & co + <youpi> yes + <braunr> ok, the virtual space is doubled + <youpi> yes + <braunr> but the resources consume to describe them aren't + <braunr> even on mach + <youpi> since you have both the physical mapping and the kmem mapping + <youpi> I don't care much about the resources + <youpi> but about addressing space + <braunr> well there are a limited numbers of solutions + <youpi> the space it takes and has to be taken from something else, that + is, here physical memory available to Mach + <braunr> reduce the physical mapping + <braunr> increase the kmem mapping + <braunr> or reduce kernel memory consumption + <youpi> and instead of taking the space from physical mapping, we can as + well avoid doubling the space consumption when it's trivial lto + <youpi> yes, the hird + <youpi> +t + <youpi> that's what I'm asking from the beginning :) + <braunr> 18:21 < youpi> I don't care much about the resources + <braunr> actually, you care :) + <youpi> yes and no + <braunr> i understand what you mean + <youpi> not in the sense "it takes a page_t to allocate a page" + <braunr> you want more virtual space, and aren't that much concerned about + the number of objects used + <youpi> yes + <braunr> then it makes sense + <braunr> but in this case, it could be a good idea to generalize it + <braunr> have our own kmalloc/vmalloc interfaces + <braunr> maybe a gsoc project :) + <youpi> err, don't we have them already? + <youpi> I mean, what exactly do you want to generalize? + <braunr> mach only ever had vmalloc + <youpi> we already have a hell lot of allocators :) + <youpi> and it's a pain to distribute the available space to them + <braunr> yes + <braunr> but what you basically want is to introduce something similar to + kmalloc for single pages + <youpi> or just patch the few cases that need it into just grabbing a page + <youpi> there are probably not so many + <braunr> ok + <braunr> i've just read vm_page_grab() + <braunr> it only removes a page from the free list + <braunr> other functions such as vm_page_alloc insert them afterwards + <braunr> if a page is in no list, it can't be paged out + <braunr> so i think it's probably safe to assume it's naturally wired + <braunr> you don't even need a call to vm_page_wire or a flag of some sort + <youpi> ok + <braunr> although considering the low amount of work done by + vm_page_wire(), you could, for clarity + <youpi> braunr: I was also wondering about the VM_PAGE_FREE_RESERVED & such + constants + <youpi> they're like 50 pages + <youpi> is this still reasonable nowadays? + <braunr> that's a question i'm still asking myself quite often :) + <youpi> also, the BURST_{MAX,MIN} & such in vm_pageout.c are probably out + of date? + <braunr> i didn't study the pageout code much + <youpi> k + <braunr> but correct handling of low memory thresholds is a good point to + keep in mind + <braunr> youpi: i often wonder how linux can sometimes have so few free + pages left and still be able to work without any visible failure + <youpi> well, as long as you have enough pages to be able to make progress, + you're fine + <youpi> that' the point of the RESERVED pages in mach I guess + <braunr> youpi: yes but, obviously, hard values are *bad* + <braunr> linux must adjust it, depending on the number of processors, the + number of pdflush threads, probably other things i don't have in mind + <braunr> i don't know what should make us adjust that value in mach + <youpi> which value? + <braunr> the size of the reserved pool + <youpi> I don't think it's adjusted + <braunr> that's what i'm saying + <braunr> i guess there is an #ifndef line for arch specific definitions + <youpi> err, you just said linux must adjust it : + <youpi> )) + <youpi> there is none + <braunr> linux adjusts it dynamically + <braunr> well ok + <braunr> that's another way to say it + <braunr> we don't have code to get rid of this macro + <braunr> but i don't even know how we, as maintainers, are supposed to + guess it diff --git a/open_issues/gnumach_memory_management_physical_memory.mdwn b/open_issues/gnumach_memory_management_physical_memory.mdwn new file mode 100644 index 00000000..58fefe1f --- /dev/null +++ b/open_issues/gnumach_memory_management_physical_memory.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +IRC, freenode, #hurd, 2011-10: + + <braunr> antrik: about our physical memory limitations, i told you some + time ago that part of it was due to the linux drivers + <braunr> and i mentioned the paper concerning the integration of the linux + drivers written at the time + <braunr> it does indeed tell that mach, which used the common 3G->4G area + for the kernel space had to be adapted + <braunr> because linux used segmentation so that kernel addresses matched + physical addresses + <braunr> and it looks like some (many) drivers require that + <braunr> our current gnumach actually does this (which i found surprising + when i first found it) + <braunr> and i believe the easy solution to exceed this limitation is to + use a strategy similar to what linux still does on i386 + <braunr> some highmem support + <braunr> we could alter the vm_resident module so that, by default, it + still looks for pages in the low 0-800 (or 0-1800 on debian patched + kernels) area + <braunr> but for everything else than the kernel, e.g. all user processes + <braunr> we could use a flag or a specialized function that would first + look in the highmem pool for available physical pages to map + <braunr> the only thing i'm not yet sure of is about user/kernel transfers + <braunr> if virtual addresses and copies are always cleanly done, then it's + ok + <braunr> and i really hope our linux drivers do so :) + <braunr> (i mean ,the glue code ofc) + +2011-10-23: + + <youpi> braunr: I believe, like Linus, that highmem support is a nightmare + <antrik> braunr: uhm... the drivers want virtual addressses to match + physical ones? I guess that means switching address spaces before any + driver code is executed?... diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn new file mode 100644 index 00000000..03cb3725 --- /dev/null +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -0,0 +1,627 @@ +[[!meta copyright="Copyright © 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_gnumach]] + +[[!toc]] + + +# [[page_cache]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <braunr> another not-too-long improvement would be changing the page cache + policy + <youpi> to drop the 4000 objects limit, you mean ? + <braunr> yes + <youpi> do you still have my patch attempt ? + <braunr> no + <youpi> let me grab that + <braunr> oh i won't start it right away you know + <braunr> i'll ask for it when i do + <youpi> k + <braunr> (otherwise i fell i'll just loose it again eh) + <youpi> :) + <braunr> but i imagine it's not too hard to achieve + <youpi> yes + <braunr> i also imagine to set a large threshold of free pages to avoid + deadlocks + <braunr> which will still be better than the current situation where we + have either lots of free pages because tha max limit is reached, or lots + of pressure and system freezes :/ + <youpi> yes + + +## IRC, freenode, #hurd, 2012-06-17 + + <braunr> youpi: i don't understand your patch :/ + <youpi> arf + <youpi> which part don't you understand? + <braunr> the global idea :/ + <youpi> first, drop the limit on number of objects + <braunr> you added a new collect call at pageout time + <youpi> (i.e. here, hack overflow into 0) + <braunr> yes + <braunr> obviously + <youpi> but then the cache keeps filling up with objects + <youpi> which sooner or later become empty + <youpi> thus the collect, which is supposed to look for empty objects, and + just drop them + <braunr> but not at the right time + <braunr> objects should be collected as soon as their ref count drops to 0 + <braunr> err + <youpi> now, the code of the collect is just a crude attempt without + knowing much about the vm + <braunr> when their resident page count drops to 0 + <youpi> so don't necessarily read it :) + <braunr> ok + <braunr> i've begin playing with the vm recently + <braunr> the limits (arbitrary, and very old obviously) seem far too low + for current resources + <braunr> (e.g. the threshold on free pages is 50 iirc ...) + <youpi> yes + <braunr> i'll probably use a different approach + <braunr> the one i mentioned (collecting one object at a time - or pushing + them on a list for bursts - when they become empty) + <braunr> this should relax the kernel allocator more + <braunr> (since there will be less empty vm_objects remaining until the + next global collecttion) + + +## IRC, freenode, #hurd, 2012-06-30 + + <braunr> the threshold values of the page cache seem quite enough actually + <youpi> braunr: ah + <braunr> youpi: yes, it seems the problems are in ext2, not in the VM + <youpi> k + <youpi> the page cache limitation still doesn't help :) + <braunr> the problem in the VM is the recycling of vm_objects, which aren't + freed once empty + <braunr> but it only wastes some of the slab memory, it doesn't prevent + correct processing + <youpi> braunr: thus the limitation, right? + <braunr> no + <braunr> well + <braunr> that's the policy they chose at the time + <braunr> for what reason .. i can't tell + <youpi> ok, but I mean + <youpi> we can't remove the policy because of the non-free of empty objects + <braunr> we must remove vm_objects at some point + <braunr> but even without it, it makes no sense to disable the limit while + ext2 is still unstable + <braunr> also, i noticed that the page count in vm_objects never actually + drop to 0 ... + <youpi> you mean the limit permits to avoid going into the buggy scenarii + too often? + <braunr> yes + <youpi> k + <braunr> at least, that's my impression + <braunr> my test case is tar xf files.tar.gz, which contains 50000 files of + 12k random data + <braunr> i'll try with other values + <braunr> i get crashes, deadlocks, livelocks, and it's not pretty :) + <braunr> and always in ext2, mach doesn't seem affected by the issue, other + than the obvious + <braunr> (well i get the usual "deallocating an invalid port", but as + mentioned, it's "most probably a bug", which is the case here :) + <youpi> braunr: looks coherent with the hangs I get on the buildds + <braunr> youpi: so that's the nasty bug i have to track now + <youpi> though I'm also still getting some out of memory from gnumach + sometimes + <braunr> the good thing is i can reproduce it very quickly + <youpi> a dump from the allocator to know which zone took all the room + might help + <braunr> youpi: yes i promised that too + <youpi> although that's probably related with ext2 issues :) + <braunr> youpi: can you send me the panic message so i can point the code + which must output the allocator state please ? + <youpi> next time I get it, sure :) + <pinotree> braunr: you could implement a /proc/slabinfo :) + <braunr> pinotree: yes but when a panic happens, it's too late + <braunr> http://git.sceen.net/rbraun/slabinfo.git/ btw + <braunr> although it's not part of procfs + <braunr> and the mach_debug interface isn't provided :( + + +## IRC, freenode, #hurd, 2012-07-03 + + <braunr> it looks like pagers create a thread per memory object ... + <antrik> braunr: oh. so if I open a lot of files, ext2fs will *inevitably* + have lots of threads?... + <braunr> antrik: i'm not sure + <braunr> it may only be required to flush them + <braunr> but when there are lots of them, the threads could run slowly, + giving the impression there is one per object + <braunr> in sync mode i don't see many threads + <braunr> and i don't get the bug either for now + <braunr> while i can see physical memory actually being used + <braunr> (and the bug happens before there is any memory pressure in the + kernel) + <braunr> so it definitely looks like a corruption in ext2fs + <braunr> and i have an idea .... :> + <braunr> hm no, i thought an alloca with a big size parameter could erase + memory outside the stack, but it's something else + <braunr> (although alloca should really be avoided) + <braunr> arg, the problem seems to be in diskfs_sync_everything -> + ports_bucket_iterate (pager_bucket, sync_one); :/ + <braunr> :( + <braunr> looks like the ext2 problem is triggered by calling pager_sync + from diskfs_sync_everything + <braunr> and is possibly related to + http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00127.html + <braunr> (and for reference, the rest of the discussion + http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00012.html) + <braunr> multithreading in libpager is scary :/ + <antrik> braunr: s/in libpager/ ;-) + <braunr> antrik: right + <braunr> omg the ugliness :/ + <braunr> ok i found a bug + <braunr> a real one :) + <braunr> (but not sure it's the only one since i tried that before) + <braunr> 01:38 < braunr> hm no, i thought an alloca with a big size + parameter could erase memory outside the stack, but it's something else + <braunr> turns out alloca is sometimes used for 64k+ allocations + <braunr> which explains the stack corruptions + <pinotree> ouch + <braunr> as it's used to duplicate the node table before traversing it, it + also explains why the cache limit affects the frequency of the bug + <braunr> now the fun part, write the patch following GNU protocol .. :) + +[[!message-id "1341350006-2499-1-git-send-email-rbraun@sceen.net"]] + + <braunr> if someone feels like it, there are a bunch of alloca calls in the + hurd (like around 30 if i'm right) + <braunr> most of them look safe, but some could trigger that same problem + in other servers + <braunr> ok so far, no problem with the upstream ext2fs code :) + <braunr> 20 loops of tar xf / rm -rf consuming all free memory as cache :) + <braunr> the hurd uses far too much cpu time for no valid reason in many + places :/ + * braunr happy + <braunr> my hurd is completely using its ram :) + <gnu_srs> Meaning, the bug is solved? Congrats if so :) + <braunr> well, ext2fs looks way more stable now + <braunr> i haven't had a single issue since the change, so i guess i messed + something with my previous test + <braunr> and the Mach VM cache implementation looks good enough + <braunr> now the only thing left is to detect unused objects and release + them + <braunr> which is actually the core of my work :) + <braunr> but i'm glad i could polish ext2fs + <braunr> with luck, this is the issue that was striking during "thread + storms" in the past + * pinotree hugs braunr + <braunr> i'm also very happy to see the slab allocator reacting well upon + memory pressure :> + <mcsim> braunr: Why alloca corrupted memory diskfs_node_iterate? Was + temporary node to big to keep it in stack? + <braunr> mcsim: yes + <braunr> 17:54 < braunr> turns out alloca is sometimes used for 64k+ + allocations + <braunr> and i wouldn't be surprised if our thread stacks are + simplecontiguous 64k mappings of zero-filled memory + <braunr> (as Mach only provides bottom-up allocation) + <braunr> our thread implementation should leave unmapped areas between + thread stacks, to easily catch such overflows + <pinotree> braunr: wouldn't also fatfs/inode.c and tmpfs/node.c need the + same fix? + <braunr> pinotree: possibly + <braunr> i haven't looked + <braunr> more than 300 loops of tar xf / rm -rf on an archive of 20000 + files of 12 KiB each, without any issue, still going on :) + <youpi> braunr: yay + + +## [[!message-id "20120703121820.GA30902@mail.sceen.net"]], 2012-07-03 + + +## IRC, freenode, #hurd, 2012-07-04 + + <braunr> mach is so good it caches objects which *no* page in physical + memory + <braunr> hm i think i have a working and not too dirty vm cache :> + <kilobug> braunr: congrats :) + <braunr> kilobug: hey :) + <braunr> the dangerous side effect is the increased swappiness + <braunr> we'll have to monitor that on the buildds + <braunr> otherwise the cache is effectively used, and the slab allocator + reports reasonable amounts of objects, not increasing once the ram is + full + <braunr> let's see what happens with 1.8 GiB of RAM now + <braunr> damn glibc is really long to build :) + <braunr> and i fear my vm cache patch makes non scalable algorithms negate + some of its benefits :/ + <braunr> 72 tasks, 2090 threads + <braunr> we need the ability to monitor threads somewhere + + +## IRC, freenode, #hurd, 2012-07-05 + + <braunr> hm i get kernel panics when not using the host cache :/ + <braunr> no virtual memory for stack allocations + <braunr> that's scary + <antrik> ? + <braunr> i guess the lack of host cache makes I/O slow enough to create a + big thread storm + <braunr> that completely exhausts the kernel space + <braunr> my patch challenges scalability :) + <antrik> and not having a zalloc zone anymore, instead of getting a nice + panic when trying to allocate yet another thread, you get an address + space exhaustion on an unrelated event instead. I see ;-) + <braunr> thread stacks are not allocated from a zone/cache + <braunr> also, the panic concerned aligned memory, but i don't think that + matters + <braunr> the kernel panic clearly mentions it's about thread stack + allocation + <antrik> oh, by "stack allocations" you actually mean allocating a stack + for a new thread... + <braunr> yes + <antrik> that's not what I normally understand when reading "stack + allocations" :-) + <braunr> user stacks are simple zero filled memory objects + <braunr> so we usually get a deadlock on them :> + <braunr> i wonder if making ports_manage_port_operations_multithread limit + the number of threads would be a good thing to do + <antrik> braunr: last time slpz did that, it turned out that it causes + deadlocks in at least one (very specific) situation + <braunr> ok + <antrik> I think you were actually active at the time slpz proposed the + patch (and it was added to Debian) -- though probably not at the time + where youpi tracked it down as the cause of certain lockups, so it was + dropped again... + <braunr> what seems very weird though is that we're normally using + continuations + <antrik> braunr: you mean in the kernel? how is that relevant to the topic + at hand?... + <braunr> antrik: continuations have been designed to reduce the number of + stacks to one per cpu :/ + <braunr> but they're not used everywhere + <antrik> they are not used *anywhere* in the Hurd... + <braunr> antrik: continuations are supposed to be used by kernel code + <antrik> braunr: not sure what you are getting at. of course we should use + some kind of continuations in the Hurd instead of having an active thread + for every single request in flight -- but that's not something that could + be done easily... + <braunr> antrik: oh no, i don't want to use continuations at all + <braunr> i just want to use less threads :) + <braunr> my panic definitely looks like a thread storm + <braunr> i guess increasing the kmem_map will help for the time bein + <braunr> g + <braunr> (it's not the whole kernel space that gets filled up actually) + <braunr> also, stacks are kept on a local cache until there is memory + pressure oO + <braunr> their slab cache can fill the backing map before there is any + pressure + <braunr> and it makes a two level cache, i'll have to remove that + <antrik> well, how do you reduce the number of threads? apart from + optimising scheduling (so requests are more likely to be completed before + new ones are handled), the only way to reduce the number of threads is to + avoid having a thread per request + <braunr> exactly + <antrik> so instead the state of each request being handled has to be + explicitly stored... + <antrik> i.e. continuations + <braunr> hm actually, no + <braunr> you use thread migration :) + <braunr> i don't want to artificially use the number of kernel threads + <braunr> the hurd should be revamped not to use that many threads + <braunr> but it looks like a hard task + <antrik> well, thread migration would reduce the global number of threads + in the system... it wouldn't prevent a server from having thousands of + threads + <braunr> threads would allready be allocated before getting in the server + <antrik> again, the only way not to use a thread for each outstanding + request is having some explicit request state management, + i.e. continuations + <braunr> hm right + <braunr> but we can nonetheless reduce the number of threads + <braunr> i wonder if the sync threads are created on behalf of the pagers + or the kernel + <braunr> one good thing is that i can already feel better performance + without using the host cache until the panic happens + <antrik> the tricky bit about that is that I/O can basically happen at any + point during handling a request, by hitting a page fault. so we need to + be able to continue with some other request at any point... + <braunr> yes + <antrik> actually, readahead should help a lot in reducing the number of + request and thus threads... still will be quite a lot though + <braunr> we should have a bunch of pageout threads handling requests + asynchronously + <braunr> it depends on the implementation + <braunr> consider readahead detects that, in the next 10 pages, 3 are not + resident, then 1 is, then 3 aren't, then 1 is again, and the last two + aren't + <braunr> how is this solved ? :) + <braunr> about the stack allocation issue, i actually think it's very + simple to solv + <braunr> the code is a remnant of the old BSD days, when processes were + heavily swapped + <braunr> so when a thread is created, its stack isn't allocated + <braunr> the allocation happens when the thread is dispatched, and the + scheduler finds it's swapped (which is the initial state) + <braunr> the stack is allocated, and the operation is assumed to succeed, + which is why failure produces a panic + <antrik> well, actually, not just readahead... clustered paging in + general. the thread storms happen mostly on write not read AIUI + <braunr> changing that to allocate at thread creation time will allow a + cleaner error handling + <braunr> antrik: yes, at writeback + <braunr> antrik: so i guess even when some physical pages are already + present, we should aim at larger sizes for fewer I/O requests + <antrik> not sure that would be worthwhile... probably doesn't happen all + that often. and if some of the pages are dirty, we would have to make + sure that they are ignored although they were part of the request... + <braunr> yes + <braunr> so one request per missing area ? + <antrik> the opposite might be a good idea though -- if every other page is + dirty, it *might* indeed be preferable to do a single request rewriting + even the clean ones in between... + <braunr> yes + <braunr> i personally think one request, then replace only what was + missing, is simpler and preferable + <antrik> OTOH, rewriting clean pages might considerably increase write time + (and wear) on SSDs + <braunr> why ? + <antrik> I doubt the controller is smart enough to recognies if a page + doesn't really need rewriting + <antrik> so it will actually allocate and write a new cluster + <braunr> no but it won't spread writes on different internal sectors, will + it ? + <braunr> sectors are usually really big + <antrik> "sectors" is not a term used in SSDs :-) + <braunr> they'll be erased completely whatever the amount of data at some + point if i'm right + <braunr> ah + <braunr> need to learn more about that + <braunr> i thought their internal hardware was much like nand flash + <antrik> admittedly I don't remember the correct terminology either... + <antrik> they *are* NAND flash + <antrik> writing is actually not the problem -- it can happen in small + chunks. the problem is erasing, which is only possible in large blocks + <braunr> yes + <braunr> so having larger requests doesn't seem like a problem to me + <braunr> because of that + <antrik> thus smart controllers (which pretty much all SSD nowadays have, + and apparently even SD cards) do not actually overwrite. instead, writes + always happen to clean portions, and erasing only happens when a block is + mostly clean + <antrik> (after relocating the remaining used parts to other clean areas) + <antrik> braunr: the problem is not having larger requests. the problem is + rewriting clusters that don't really need rewriting. it means the dist + performs unnecessary writing actions. + <antrik> it doesn't hurt for magnetic disks, as the head has to pass over + the unchanged sectors anyways; and rewriting the unnecessarily doesn't + increase wear + <antrik> but it's different for SSDs + <antrik> each write has a penalty there + <braunr> i thought only erases were the real penalty + <antrik> well, erase happens in the background with modern controllers; so + it has no direct penalty. the write has a direct performance penalty when + saturating the bandwith, and always has a direct wear penalty + <braunr> can't controllers handle 32k requests ? like everything does ? :/ + <antrik> sure they can. but that's beside the point... + <braunr> if they do, they won't mind the clean data inside such large + blocks + <antrik> apparently we are talking past each other + <braunr> i must be missing something important about SSD + <antrik> braunr: the point is, the controller doesn't *know* it's clean + data; so it will actually write it just like the really unclean data + <braunr> yes + <braunr> and it will choose an already clean sector for that (previously + erased), so writing larger blocks shouldn't hurt + <braunr> there will be a slight increase in bandwidth usage, but that's + pretty much all of it + <braunr> isn't it ? + <antrik> well, writing always happens to clean blocks. but writing more + blocks obviously needs more time, and causes more wear... + <braunr> aiui, blocks are always far larger than the amount of pages we + want to writeback in one request + <braunr> the only way to use more than one is crossing a boundary + <antrik> no. again, the blocks that can be *written* are actually quite + small. IIRC most SSDs use 4k nowadays + <braunr> ok + <antrik> only erasing operates on much larger blocks + <braunr> so writing is a problem too + <braunr> i didn't think it would cause wear leveling to happen + <antrik> well, I'm not sure whether the wear actually happens on write or + on erase... but that doesn't matter, as the number of blocks that need to + be erased is equivalent to the number of blocks written... + <braunr> sorry, i'm really not sure + <braunr> if you erase one sector, then write the first and third block, + it's clearly not equivalent + <braunr> i mean + <braunr> let's consider two kinds of pageout requests + <braunr> 1/ a big one including clean pages + <braunr> 2/ several ones for dirty pages only + <braunr> let's assume they both need an erase when they happen + <braunr> what's the actual difference between them ? + <braunr> wear will increase only if the controller handle it on writes, if + i'm right + <braunr> but other than that, it's just bandwidth + <antrik> strictly speaking erase is only *necessary* when there are no + clean blocks anymore. but modern controllers will try to perform erase of + unused blocks in the background, so it doesn't delay actual writes + <braunr> i agree on that + <antrik> but the point is that for each 16 pages (or so) written, we need + to erase one block so we get 16 clean pages to write... + <braunr> yes + <braunr> which is about the size of a request for the sequential policy + <braunr> so it fits + <antrik> just to be clear: it doesn't matter at all how the pages + "fit". the controller will reallocate them anyways + <antrik> what matters is how many pages you write + <braunr> ah + <braunr> i thought it would just put the whole request in a single sector + (or two) + <antrik> I'm not sure what you mean by "sector". as I said, it's not a term + used in SSD technology + <braunr> so do you imply that writes can actually get spread over different + sectors ? + <braunr> the sector is the unit at the nand flash level, its size is the + erase size + <antrik> actually, I used the right terminology... the erase unit is the + block; the write unit is the page + <braunr> sector is a synonym of block + <antrik> never seen it. and it's very confusing, as it isn't in any way + similar to sectors in magnetic disks... + <braunr> http://en.wikipedia.org/wiki/Flash_memory#NAND_flash + <braunr> it's actually in the NOR part right before, paragraph "Erasing" + <braunr> "Modern NOR flash memory chips are divided into erase segments + (often called blocks or sectors)." + <antrik> ah. I skipped the NOR part :-) + <braunr> i've only heard sector where i worked, but i don't consider french + computer engineers to be authorities on the matter :) + <antrik> hehe + <braunr> let's call them block + <braunr> so, thread stacks are allocated out of the kernel map + <braunr> this is already a bad thing (which is probably why there is a + local cache btw) + <antrik> anyways, yes. modern controllers might split a contiguous write + request onto several blocks, as well as put writes to completely + different logical pages into one block. the association between addresses + and actual blocks is completely free + <braunr> now i wonder why the kernel map is so slow, as the panic happens + at about 3k threads, so about 11M of thread stacks + <braunr> antrik: ok + <braunr> antrik: well then it makes sense to send only dirty pages + <braunr> s/slow/low/ + <antrik> it's different for raw flash (using MTD subsystem in Linux) -- but + I don't think this is something we should consider any time soon :-) + <antrik> (also, raw flash is only really usable with specialised + filesystems anyways) + <braunr> yes + <antrik> are the thread stacks really only 4k? I would expect them to be + larger in many cases... + <braunr> youpi reduced them some time ago, yes + <braunr> they're 4k on xen + <braunr> uh, 16k + <braunr> damn, i'm wondering why i created separate submaps for the slab + allocator :/ + <braunr> probably because that's how it was done by the zone allocator + before + <braunr> but that's stupid :/ + <braunr> hm the stack issue is actually more complicated than i thought + because of interrupt priority levels + <braunr> i increased the kernel map size to avoid the panic instead + <braunr> now libc0.3 seems to build fine + <braunr> and there seems to be a clear decrease of I/O :) + + +### IRC, freenode, #hurd, 2012-07-06 + + <antrik> braunr: there is a submap for the slab allocator? that's strange + indeed. I know we talked about this; and I am pretty sure we agreed + removing the submap would actually be among the major benefits of a new + allocator... + <braunr> antrik: a submap is a good idea anyway + <braunr> antrik: it avoids fragmenting the kernel space too much + <braunr> it also breaks down locking + <braunr> but we could consider it + <braunr> as a first step, i'll merge the kmem and kalloc submaps (the ones + used for the slab caches and the malloc-like allocations respectively) + <braunr> then i'll change the allocation of thread stacks to use a slab + cache + <braunr> and i'll also remove the thread swapping stuff + <braunr> it will take some time, but by the end we should be able to + allocate tens of thousands of threads, and suffer no panic when the limit + is reached + <antrik> braunr: I'm not sure "no panic" is really a worthwhile goal in + such a situation... + <braunr> antrik: uh ?N + <braunr> antrik: it only means the system won't allow the creation of + threads until there is memory available + <braunr> from my pov, the microkernel should never fail up to a point it + can't continue its job + <antrik> braunr: the system won't be able to recover from such a situation + anyways. without actual resource management/priorisation, not having a + panic is not really helpful. it only makes it harder to guess what + happened I fear... + <braunr> i don't see why it couldn't recover :/ + + +## IRC, freenode, #hurd, 2012-07-07 + + <braunr> grmbl, there are a lot of issues with making the page cache larger + :( + <braunr> it actually makes the system slower in half of my tests + <braunr> we have to test that on real hardware + <braunr> unfortunately my current results seem to indicate there is no + clear benefit from my patch + <braunr> the current limit of 4000 objects creates a good balance between + I/O and cpu time + <braunr> with the previous limit of 200, I/O is often extreme + <braunr> with my patch, either the working set is less than 4k objects, so + nothing is gained, or the lack of scalability of various parts of the + system add overhead that affect processing speed + <braunr> also, our file systems are cached, but our block layer isn't + <braunr> which means even when accessing data from the cache, accesses + still cause some I/O for metadata + + +## IRC, freenode, #hurd, 2012-07-08 + + <braunr> youpi: basically, it works fine, but exposes scalability issues, + and increases swapiness + <youpi> so it doens't help with stability? + <braunr> hum, that was never the goal :) + <braunr> the goal was to reduce I/O, and increase performance + <youpi> sure + <youpi> but does it at least not lower stability too much? + <braunr> not too much, no + <youpi> k + <braunr> most of the issues i found could be reproduced without the patch + <youpi> ah + <youpi> then fine :) + <braunr> random deadlocks on heavy loads + <braunr> youpi: but i'm not sure it helps with performance + <braunr> youpi: at least not when emulated, and the host cache is used + <youpi> that's not very surprising + <braunr> it does help a lot when there is no host cache and the working set + is greater (or far less) than 4k objects + <youpi> ok + <braunr> the amount of vm_object and ipc_port is gracefully adjusted + <youpi> that'd help us with not having to tell people to use the complex + -drive option :) + +([[hurd/running/qemu/writeback_caching]].) + + <braunr> so you can easily run a hurd with 128 MiB with decent performance + and no leak in ext2fs + <braunr> yes + <braunr> for example + <youpi> braunr: I'd say we should just try it on buildds + <braunr> (it's not finished yet, i'd like to work more on reducing + swapping) + <youpi> (though they're really not busy atm, so the stability change can't + really be measured) + <braunr> when building the hurd, which takes about 10 minutes in my kvm + instances, there is only a 30 seconds difference between using the host + cache and not using it + <braunr> this is already the case with the current kernel, since the + working set is less than 4k objects + <braunr> while with the previous limit of 200 objects, it took 50 minutes + without host cache, and 15 with it + <braunr> so it's a clear benefit for most uses, except my virtual machines + :) + <youpi> heh + <braunr> because there, the amount of ram means a lot of objects can be + cached, and i can measure an increase in cpu usage + <braunr> slight, but present + <braunr> youpi: isn't it a good thing that buildds are resting a bit ? :) + <youpi> on one hand, yes + <youpi> but on the other hand, that doesn't permit to continue + stress-testing the Hurd :) + <braunr> we're not in a hurry for this patch + <braunr> because using it really means you're tickling the pageout daemon a + lot :) + + +## [[metadata_caching]] diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn new file mode 100644 index 00000000..68cfcb5a --- /dev/null +++ b/open_issues/gnumach_rpc_timeouts.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-28 + + <pinotree> uhm, apparently mach cannot handle timeouts for rpc's of more + than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ + <pinotree> it seems that how ticks are calculated in mach, it becomes 0 + <pinotree> +because of diff --git a/open_issues/gnumach_tick.mdwn b/open_issues/gnumach_tick.mdwn new file mode 100644 index 00000000..eed447f6 --- /dev/null +++ b/open_issues/gnumach_tick.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-05 + + <pinotree> braunr: wrt to mach: it seems to me it ticks every 10ms or so, + it is true? + <braunr> yes + <braunr> and it's not preemptible + <pinotree> braunr: that means a gnumach kernel currently has a maximum + uptime of almost 500 days + <braunr> pinotree: what do you mean ? + <pinotree> there's an int (or uint, i don't remember) variable that keeps + the tick count + <braunr> yes the tick variable should probably be a 64-bits type + <braunr> or a struct + <braunr> but the tick count should only be used for computation on "short" + delays + <braunr> and it should be safe to use it even when it overflows + <braunr> it's not the wall clock + <pinotree> i found that when investigating why the maximum timeout for a + mach_msg is like INT_MAX >> 2 (or 4) or something like that, also due to + the tick count + <braunr> iirc, in linux, they mostly use the lower 32-bits on 32-bits + architecture, updating the 32 upper only when necessary diff --git a/open_issues/gnumach_tlb_flushing.mdwn b/open_issues/gnumach_tlb_flushing.mdwn new file mode 100644 index 00000000..45d0730d --- /dev/null +++ b/open_issues/gnumach_tlb_flushing.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 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_gnumach]] + +IRC, unknown channel, unknown date. + + <tschwinge> gianluca, youpi: Why the value 32 for the TLB flushing decision, by the way? + <youpi> completely arbitrary + <tschwinge> I thought whether that might perhaps be worth a macro definition with a comment? + <verte> what's the typical TLB size these days? + <youpi> tschwinge: right + <youpi> note that the 32 value would be probably different between native and xen + <gianluca> tschwinge: just arbitrary diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn new file mode 100644 index 00000000..90137766 --- /dev/null +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -0,0 +1,200 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + + +# IRC, freenode, #hurd, 2011-07-20 + + <braunr> could we add gnumach forward map entry merging as an open issue ? + <braunr> probably hurting anything using bash extensively, like build most + build systems + <braunr> mcsim: this map entry merging problem might interest you + <braunr> tschwinge: see vm/vm_map.c, line ~905 + <braunr> "See whether we can avoid creating a new entry (and object) by + extending one of our neighbors. [So far, we only attempt to extend from + below.]" + <braunr> and also vm_object_coalesce + <braunr> "NOTE: Only works at the moment if the second object is NULL - + if it's not, which object do we lock first?" + <braunr> although map entry merging should be enough + <braunr> this seems to be the cause for bash having between 400 and 1000+ + map entries + <braunr> thi makes allocations and faults slow, and forks even more + <braunr> but again, this should be checked before attempting anything + <braunr> (for example, this comment still exists in freebsd, although they + solved the problem, so who knows) + <antrik> braunr: what exactly would you want to check? + <antrik> braunr: this rather sounds like something you would just have to + try... + <braunr> antrik: that map merging is actually incomplete + <braunr> and that entries can actually be merged + <antrik> hm, I see... + <braunr> (i.e. they are adjacent and have compatible properties + <braunr> ) + <braunr> antrik: i just want to avoid the "hey, splay trees mak fork slow, + let's work on it for a month to see it wasn't the problem" + <antrik> so basically you need a dump of a task's map to check whether + there are indeed entries that could/should be merged? + <antrik> hehe :-) + <braunr> well, vminfo should give that easily, i just didn't take the time + to check it + <jkoenig> braunr, as you pointed out, "vminfo $$" seems to indicate that + merging _is_ incomplete. + <braunr> this could actually have a noticeable impact on package builds + <braunr> hm + <braunr> the number of entries for instances of bash running scripts don't + exceed 50-55 :/ + <braunr> the issue seems to affect only certain instances (login shells, + and su -) + <braunr> jkoenig: i guess dash is just much lighter than bash in many ways + :) + <jkoenig> braunr, the number seems to increase with usage (100 here for a + newly started interactive shell, vs. 150 in an old one) + <braunr> yes, merging is far from complete in the vm_map code + <braunr> it only handles null objects (private zeroed memory), and only + tries to extend a previous entry (this isn't even a true merge) + <braunr> this works well for the kernel however, which is why there are so + few as 25 entries + <braunr> but any request, be it e.g. mmap(), or mprotect(), can easily + split entries + <braunr> making their number larger + <jkoenig> my ext2fs has ~6500 entries, but I guess this is related to + mapping blocks from the filesystem, right? + <braunr> i think so + <braunr> hm not sure actually + <braunr> i'd say it's fragmentation due to copy on writes when client have + mapped memory from it + <braunr> there aren't that many file mappings though :( + <braunr> jkoenig: this might just be the same problem as in bash + <braunr> 0x1308000[0x3000] (prot=RW, max_prot=RWX, mem_obj=584) + <braunr> 0x130b000[0x6000] (prot=RW, max_prot=RWX, mem_obj=585) + <braunr> 0x1311000[0x3000] (prot=RX, max_prot=RWX, mem_obj=586) + <braunr> 0x1314000[0x1000] (prot=RW, max_prot=RWX, mem_obj=586) + <braunr> 0x1315000[0x2000] (prot=RX, max_prot=RWX, mem_obj=587) + <braunr> the first two could be merged but not the others + <jkoenig> theoritically, those may correspond to memory objects backed by + different portions of the disk, right? + <braunr> jkoenig: this looks very much like the same issue (many private + mappings not merged) + <braunr> jkoenig: i'm not sure + <braunr> jkoenig: normally there is an offset when the object is valid + <braunr> but vminfo may simply not display it if 0 + * jkoenig goes read about memory object + <braunr> ok, vminfo can't actually tell if the object is anonymous or + file-backed memory + <jkoenig> (I'm perplexed about how the kernel can merge two memory objects + if disctinct port names exist in the tasks' name space -- that's what + mem_obj is, right?) + <braunr> i don't see why + <braunr> jkoenig: can you be more specific ? + <jkoenig> braunr, if, say, 584 and 585 above are port names which the task + expects to be able to access and do stuff with, what will happen to them + when the memory objects are merged? + <braunr> good question + <braunr> but hm + <braunr> no it's not really a problem + <braunr> memory objects aren't directly handled by the vm system + <braunr> vm_object and memory_object are different things + <braunr> vm_objects can be split and merged + <braunr> and shadow objects form chains ending on a final vm_object + <braunr> which references a memory object + <braunr> hm + <braunr> jkoenig: ok no solution, they can't be merged :) + <jkoenig> braunr, I'm confused :-) + <braunr> jkoenig: but at least, if two vm_objects are created but reference + the same externel memory object, the vm should be able to merge them back + <braunr> external* + <braunr> are created as a result of a split + <braunr> say, you map a memory object, mprotect part of it (=split), then + mprotect the reste of it (=merge), it should work + <braunr> jkoenig: does that clarify things a bit ? + <jkoenig> ok so if I get it right, the entries shown by vmstat are the + vm_object, and the mem_obj listed is a send right to the memory object + they're referencing ? + <braunr> yes + <braunr> i'm not sure about the type of the integer showed (port name or + simply an index) + <braunr> jkoenig: another possibility explaining the high number of entries + is how anonymous memory is implemented + <braunr> if every vm_allocate request implies the creation of a memory + object from the default pager + <braunr> the vm has no way to merge them + <jkoenig> and a vm_object is not a capability, but just an internal kernel + structure used to record the composition of the address space + <braunr> jkoenig: not exactly the address space, but close enough + <braunr> jkoenig: it's a container used to know what's in physical memory + and what isn't + <jkoenig> braunr, ok I think I'm starting to get it, thanks. + <braunr> glad i could help + <braunr> i wonder when vm_map_enter() gets null objects though :/ + <braunr> "If this port is MEMORY_OBJECT_NULL, then zero-filled memory is + allocated instead" + <braunr> which means vm_allocate() + <jkoenig> braunr, when the task uses vm_allocate(), or maybe vm_map_enter() + with MEMORY_OBJECT_NULL, there's an opportunity to extend an existing + object though, is that what you referred to earlier ? + <braunr> jkoenig: yes, and that's what is done + <jkoenig> but how does that play out with the default pager? (I'm thinking + aloud, as always feel free to ignore ;-) + <braunr> the default pager backs vm_objects providing zero filled memory + <braunr> hm, guess it wasn't your question + <braunr> well, swap isn't like a file, pages can be placed dynamically, + which is why the offset is always 0 for this type of memory + <jkoenig> hmm I see, apparently a memory object does not have a size + <braunr> are you sure ? + <jkoenig> from what I can gather from + http://www.gnu.org/software/hurd/gnumach-doc/External-Memory-Management.html, + but I looked very quickly + <braunr> vm_objects have a size + <braunr> and each map entry recors the offset within the object where the + mapping begins + <braunr> offset and sizes are used by the kernel when querying the memory + object pager + <braunr> see memory_object_data_request for example + <jkoenig> right. + <braunr> but the default pager has another interface + <braunr> jkoenig: after some simple tests, i haven't seen a simple case + where forward merging could be applied :( + <braunr> which means it's a lot harder than it first looked + <braunr> hm + <braunr> actually, there seems to be cases where this can be done + <braunr> all of them occurring after a first merge was done + <braunr> (which means a mapping request perfectly fits between two map + entries) + + +# IRC, freenode, #hurd, 2011-07-21 + + <braunr> tschwinge: you may remove the forward map entry merging issue :/ + <pinotree> what did you discover? + <braunr> tschwinge: it's actually much more complicated than i thought, and + needs major changes in the vm, and about the way anonymous memory is + handled + <braunr> from what i could see, part of the problem still exists in freebsd + <braunr> for the same reasons (shadow objects being one of them) + + +# GCC build time using bash vs. dash + +<http://gcc.gnu.org/ml/gcc/2011-07/msg00444.html> + + +# Procedure + + * Analyze. + + * Measure. + + * Fix. + + * Measure again. + + * Have Samuel measure on the buildd. diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn new file mode 100644 index 00000000..d7407bfe --- /dev/null +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -0,0 +1,174 @@ +[[!meta copyright="Copyright © 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-23 + + <braunr> btw, i'm running a gnumach version using red-black trees for vm + map entries + <antrik> braunr: sounds fashionable ;-) + <youpi> braunr: with some perf improvement? + <braunr> looks promising for our ext2fs instances showing several thousands + of map entries + <braunr> youpi: i'm not using it for lookups yet + <braunr> but the tree is there, maintained, used for both regular and copy + maps, and it doesn't crash + <youpi> good :) + <braunr> antrik: isn't it ? :) + <braunr> youpi: and the diff stat is like 50/15 + <antrik> braunr: what's the goal of using the fashionable trees? + <braunr> antrik: speeding up lookups in address spaces + <antrik> braunr: so the idea is that if we have a heavily fragmented + address space, the performance penalty is smaller? + <braunr> yes + <antrik> OK + <antrik> I take it you gave up on attempts to actually decrease + fragmentation?... + <braunr> it's not as good as reducing fragmentation, which requires + implementing a powerful merge, but it's still better + <braunr> yes + <braunr> it's too messy for my brain :/ + <antrik> I see + <antrik> oh + <braunr> it will add some overhead though + <youpi> I guess log(n) ? + <braunr> but if there is a significant performance gain, it'll be worth it + <braunr> yes + <braunr> i was more thinking about the memory overhead + <antrik> right now it's a linear list? + <youpi> I don't think we care nowadays :) + <braunr> antrik: yes + <antrik> ouch + <braunr> antrik: yes ... :> + <braunr> the original authors expected vm maps to have like 30 entries + <braunr> so they used a list for the maps, and a hash table for the + object/offset to physical page lookups + <braunr> there is a small lookup cache though, which is a nice optimization + <braunr> my code now uses it first, and falls back to the RB tree if the + hint didn't help + <antrik> braunr: well, don't forget to check whether it actually *is* still + an optimisation, when using fashionable trees ;-) + <braunr> antrik: i checked that already :) + <braunr> i did the same in x15 + <antrik> I see + <braunr> both bsd and linux uses a similar technique + <braunr> use* + <braunr> (well, bsd actually use what is done in mach :) + <antrik> (or perhaps the other way around... ;-) ) + <braunr> i don't think so, as the bsd vm is really the mach vm + <braunr> but we don't care much + <antrik> oh, right... that part actually went full circle + <braunr> youpi: i have a patch ready for test on machines with significant + amounts of map entries (e.g. the buildds ..) + <braunr> youpi: i won't have time for tests tonight, are you interested ? + <braunr> (i've been running it for 15 minutes without any issue for now) + <youpi> I'd say post to the list + <braunr> ok + <youpi> braunr: your patch uses the rb tree for lookups, right? + <youpi> braunr: the buildd using rbtree seems swift + <youpi> but maybe it's just a psychologic effect :) + <youpi> the chroot ext2fs already has 1392 lines in vminfo + <youpi> an rbtree can't hurt there :) + <youpi> braunr: it really seems faster + <youpi> the reboot might have helped too + <youpi> benchmarks shall say + <youpi> for now, I'll just let ironforge use it + <antrik> youpi: it's always fast after a reboot ;-) + <youpi> sure + <youpi> but still + <youpi> I mean + <youpi> *obviously* the reboot has helped + <youpi> but it might not be all + <youpi> at least it feels so + <youpi> and obviously only benchmarks can say + <antrik> the major benefit AIUI is rather that the slowdown happening over + time will be less noticable + +[[performance/degradation]]. + + <youpi> "over time" is actually quite fast + <youpi> ext2 fills up very quickly when you build a package + <youpi> it went up to 1700 lines very quickly + <youpi> and stabilized around there + <antrik> yeah, it can be very fast under heavy load + <youpi> that's why I say reboot seems not all + <youpi> it's already not so fresh + <youpi> with 1700 lines in vminfo + <antrik> well, I don't know how much of the slowdown I'm experiencing + (after doing stuff under memory pressure) is actually related to VM map + fragmentation... + <antrik> might be all, might be none, might be something in between + <youpi> then try his patch + <antrik> guess I should play a bit with vminfo... + <antrik> well, currently I actually experience pretty little slowdown, as + for certain reasons (only indirectly related to the Hurd) I'm not running + mutt on this machine, so I don't really have memory pressure... + + +## IRC, freenode, #hurd, 2012-04-24 + + <braunr> youpi: yes, it uses bst lookups + <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+ + map entries, and another around 7.5k + <braunr> (on ironforge) + + +## IRC, freenode, #hurd, 2012-04-24 + + <youpi> braunr: $ sudo vminfo 624 | wc -l + <youpi> 22957 + <youpi> there's no way it can not help :) + <braunr> youpi: 23k, that's really huge + + +## IRC, freenode, #hurd, 2012-04-26 + + <braunr> youpi: any new numbers wrt the rbtree patch ? + <youpi> well, buildd times are not really accurate :) + <youpi> but what I can tell is that it managed to build qtwebkit fine + <braunr> ok + <youpi> so the patch is probably safe :) + <braunr> i'll commit it soon then + <youpi> I'd say feel free to, yes + <braunr> thanks + + +## IRC, freenode, #hurd, 2012-04-27 + + <braunr> elmig: don't expect anything grand though, this patch is mostly + useful when address spaces get really fragmented, which mainly happens on + buildds + <braunr> (and it only speeds lookups, which isn't as good as reducing + fragmentation; things like fork still have to copy thousands of map + entries) + +[[glibc/fork]]. + + +## IRC, freenode, #hurdfr, 2012-06-02 + + <youpi> braunr: oh, un bug de rbtree + <youpi> Assertion `diff != 0' failed in file "vm/vm_map.c", line 1002 + <youpi> c'est dans rbtree_insert() + <youpi> vm_map_enter (vm/vm_map.c:1002). + <youpi> vm_map (vm/vm_user.c:373). + <youpi> syscall_vm_map (kern/ipc_mig.c:657). + <youpi> erf j'ai tué mon débuggueur, je ne peux pas inspecter plus + <youpi> le peu qui me reste c'est qu'apparemment target_map == 1, size == + 0, mask == 0 + <youpi> anywhere = 1 + <braunr> youpi: ça signifie sûrement que des adresses overlappent + <braunr> je rejetterai un coup d'oeil sur le code demain + <braunr> (si ça se trouve c'est un bug rare de la vm, le genre qui fait + crasher le noyau) + <braunr> (enfin jveux dire, qui faisait crasher le noyau de façon très + obscure avant le patch rbtree) diff --git a/open_issues/gnumach_vm_object_resident_page_count.mdwn b/open_issues/gnumach_vm_object_resident_page_count.mdwn new file mode 100644 index 00000000..cc1b8897 --- /dev/null +++ b/open_issues/gnumach_vm_object_resident_page_count.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-03 + + <braunr> omg the ugliness + <braunr> the number of pages in physical memory for on object is a short + ... which limits the amount to .. 128 MiB + * braunr cries + <braunr> luckily, this should be easy to solve + +`vm/vm_object.h:vm_object:resident_page_count`. diff --git a/open_issues/grub_legacy.mdwn b/open_issues/grub_legacy.mdwn deleted file mode 100644 index cb69d10b..00000000 --- a/open_issues/grub_legacy.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -[[!meta copyright="Copyright © 2005, 2009 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]]."]]"""]] - -[[!meta title="GRUB (legacy)"]] - -[[!tag open_issue_porting]] - -Even though it is customarily used *for* booting GNU/Hurd systems, [[GRUB]], -specifically GRUB legacy (which is still in wide-spread use, despite that -rather depricative nickname), has never been ported to be installable when -attempted to be installed *from* GNU/Hurd systems: - - # grub-install \(hd0\) - df: Warning: cannot read table of mounted filesystems - df: Warning: cannot read table of mounted filesystems - Could not find device for /boot: Not found or not a block device. - -There is a patch, [[grub-install.patch]], to fix that. - - -`grub-install`, however, still fails while invoking `grub`: - - # grub-install \(hd0\) - The file /boot/grub/stage1 not read correctly. - - # grub - [...] - grub> dump (hd0,0)/boot/grub/stage1 /tmp/grub_stage1 - - Error 18: Selected cylinder exceeds maximum supported by BIOS - - -The successor, [[GRUB2]], also needs to be ported. diff --git a/open_issues/grub_legacy/grub-install.patch b/open_issues/grub_legacy/grub-install.patch deleted file mode 100644 index 3f6341b4..00000000 --- a/open_issues/grub_legacy/grub-install.patch +++ /dev/null @@ -1,23 +0,0 @@ -2005-08-23 Thomas Schwinge <tschwinge@gnu.org> - - * grub-install (find_device): Rough port for GNU/Hurd. - - ---- grub-install.orig 2005-08-23 16:56:02.000000000 +0200 -+++ grub-install 2005-08-23 17:01:55.000000000 +0200 -@@ -263,7 +263,14 @@ - find_device () { - # For now, this uses the program `df' to get the device name, but is - # this really portable? -- tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'` -+ # No. (Not even on GNU/Linux.) - Thomas Schwinge -+ -+ case $host_os in -+ gnu*) # TODO: What about using multiple devices? -+ tmp_fname=`fsysopts $1/ | sed -n 's%.*device:\([^ ]*\).*%/dev/\1%p'`;; -+ *) -+ tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'`;; -+ esac - - if test -z "$tmp_fname"; then - echo "Could not find device for $1" 2>&1 diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn new file mode 100644 index 00000000..6146885d --- /dev/null +++ b/open_issues/hurd_101.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].) + +Not the first time that something like this is proposed... + +IRC, freenode, #hurd, 2011-07-25 + + [failed GNU/Hurd project] + < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many + many people who insist on picking a hard task; realizing that indeed it's + hard; and going into hiding + < antrik> we see that happen every couple of months + < cluck> maybe we need a "hurd 101" + < cluck> getting a teacher and setting up a regularly held "class" for hurd + noobs + < Tekk_> cluck: what would that include? + < cluck> explaining core concepts, giving out "homework" (small tasks), etc + +[[Anatomy_of_a_Hurd_system]]. + + < cluck> that way "the big guys" could focus on the hard stuff and have an + army of code monkeys at their disposal to write speced stuff + < cluck> (then again this idea would heavily depend on available "teachers" + and "students", which, going by gsoc numbers, may not be all that + helpful) + < Tekk_> cluck: gsoc isn't an accurate indicator + < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P + < antrik> cluck: we don't need code monkeys... we need hackers + < Tekk_`> antrik: code monkeys involve into hackers + < Tekk_`> under the right conditions + < cluck> antrik: jokes aside some sort of triage system/training ground for + newcomers could be helpful diff --git a/open_issues/hurd_build_without_parted.mdwn b/open_issues/hurd_build_without_parted.mdwn new file mode 100644 index 00000000..06ecf56d --- /dev/null +++ b/open_issues/hurd_build_without_parted.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +Seen with `cross-gnu`. + +If the *parted* libraries aren't available, we explicitly have to set +`--without-parted` or the build will fail. diff --git a/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn new file mode 100644 index 00000000..b1eaf9a5 --- /dev/null +++ b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009, 2010 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]]."]]"""]] + +IRC, #hurd, 2009-08-25 + + <cfhammar> also I fixed (what I think is) a bug in hurd_file_name_lookup_retry when opening FDs with FS_RETRY_MAGIC + <cfhammar> it didn't actually reopen the FD, rather it just (effectively) duped it + <scolobb> cfhammar: That's great! I think I had some problems because of not being able to truly reopen a port to a file. + <antrik> cfhammar: what is the difference, and why do you consider it a bug?... + <cfhammar> antrik: for one thing you can't change open modes, and it doesn't reset the file cursor + <cfhammar> (which I actually needed, though I could have done it manually) + <cfhammar> antrik: and also it isn't consistant with linux + <cfhammar> you can trigger the bug from the shell: cat /dev/fd/3 3>> /tmp/foo + <antrik> cfhammar: I can't say that I understand the test case... but I can at least confirm that it behaves differently on Hurd and on Linux :-) diff --git a/open_issues/hurdextras.mdwn b/open_issues/hurdextras.mdwn new file mode 100644 index 00000000..f31802da --- /dev/null +++ b/open_issues/hurdextras.mdwn @@ -0,0 +1,87 @@ +[[!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]]."]]"""]] + +This is about merging some hurdextras stuff into Hurd proper repostitories. + +[[!toc levels=2]] + + +# OK + +## mboxfs + +Tarball-import, plus trivial changes. + + * Ludovic Courtes -- OK + * mmenal -- OK + +## notice + +Tarball-import. + + * Wolfgang Jährling <wolfgang@pro-linux.de> -- OK + +## run + +Tarball-import. + + * Marcus Brinkmann <marcus@gnu.org> -- OK + * Manuel Menal <mmenal@hurdfr.org> -- OK + + +# Not Interesting + +## procfs + +Not interesting anymore, but perhaps import for posterity? Likewise for Neal's +tarball(s). + + +# Not OK + +## httpfs + + * Arun V. <arunsark@yahoo.com> -- NOK + * Gopika U. K. <gopika78@yahoo.com> -- NOK + * mrphython / James A. Morrison <ja2morri@uwaterloo.ca> -- OK + +## jfs + + * Sajith T S <sajith@symonds.net> -- NOK + * mmenal / Manuel Menal <mmenal@hurdfr.org> -- OK + +## memfs + + * Farid Hajji <farid.hajji@ob.kamp.net> -- NOK + * Ludovic Courtes <ludo@chbouib.org> -- OK + * mmenal -- OK + +## pith + +[[tschwinge]] has some tarballs, too. + + * John Tobey <jtobey@john-edwin-tobey.org> -- NOK + * Manuel Menal <mmenal@hurdfr.org> -- OK + +## pptop + + * Miles Bader -- OK + * Paul Emsley <paule@chem.gla.ac.uk> -- NOK + * James Morrison -- OK + * Neal Walfield -- OK + * Jon Arney <jarney1@cox.net> -- OK + * Alfredo Beaumont Sainz <alfredo.beaumont@gmail.com> -- NOK (but trivial) -- OK + +## xmlfs + +Tarball-import. + + * Marc de Saint Sauveur <marc@hurdfr.org> -- NOK + * mmenal -- OK diff --git a/open_issues/ifunc.mdwn b/open_issues/ifunc.mdwn new file mode 100644 index 00000000..c357c99c --- /dev/null +++ b/open_issues/ifunc.mdwn @@ -0,0 +1,49 @@ +[[!meta copyright="Copyright © 2010, 2011 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_binutils open_issue_gcc open_issue_glibc]] + +Needs porting / support in [[/binutils]] and [[/glibc]], and then some target +configure magic for [[/GCC]]. + +<http://nickclifton.livejournal.com/6612.html> has a short summary about how to +use it from GCC. + + * binutils + + Already passes the ifunc testsuite bits for GAS, but notably for LD + (`ld/testsuite/ld-ifunc/ifunc.exp`), too, but that one contains a bunch of + stuff explicitly tailored towards Linux. For example, we get *OS/ABI: UNIX + - Linux*. (This should be fixed through using [[toolchain/ELFOSABI_GNU]].) + + Most of the executables that the testsuite generates don't actually + execute. (Though, this is partly due to the [[static + issue|binutils#static]].) + + $ tmpdir/local_prog + ifunc working correctly + $ tmpdir/static_prog + Killed + $ tmpdir/dynamic_prog + tmpdir/dynamic_prog: error while loading shared libraries: ./tmpdir/libshared_ifunc.so: ELF file OS ABI invalid + $ tmpdir/static_nonifunc_prog + Killed + $ tmpdir/test-1 + tmpdir/test-1: error while loading shared libraries: tmpdir/libshared_ifunc.so: ELF file OS ABI invalid + + * [[glibc]] + + * [[libc_variant_selection]] + + * [[GCC]] + + In `gcc/config.gcc`, set `default_gnu_indirect_function=yes` for us, like + done for GNU/Linux. See thread starting at [[!message-id + "CAFULd4YZsAQ6ckFjXtU5-yyv=3tYQwTJOPhU9zmJxFOrnotj8g@mail.gmail.com"]]. diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn new file mode 100644 index 00000000..95b71ebb --- /dev/null +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -0,0 +1,117 @@ +[[!meta copyright="Copyright © 2010, 2011 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_documentation]] + +It is possible to run Hurd stuff on top of another system instead of on Mach. +One obvious variant is [[emulation]] (using [[hurd/running/QEMU]], for +example), but +doing that does not really integratable the Hurd guest into the host system. +There is also a more direct way, more powerful, but it also has certain +requirements to do it effectively: + +IRC, #hurd, August / September 2010 + + <marcusb> silver_hook: the Hurd can also refer to the interfaces of the + filesystems etc, and a lot of that is really just server/client APIs that + could be implemented on any system that has transferable rights to + message capabilities. + <marcusb> silver_hook: it's surprising how few systems *have* transferable + rights, though! + <marcusb> silver_hook: usually it is added as an afterthought + <marcusb> and comes with restriction + <youpi> marcusb: there's SCM_RIGHTS to transfer fds, which is quite often + available + <marcusb> youpi: yes, I know this as "fdpassing" + <marcusb> youpi: it's described in the Stevens series even + [...] + <marcusb> ArneBab: well, let me put it this way. the Linux kernel has no + interface to manipulate another tasks's virtual address space, ie you + can't map/unmap stuff in another process + <marcusb> ArneBab: you would have to use ptrace and load some stub code in + that process to make that happen. + <marcusb> ArneBab: so for complete transparent manipulation, you need a + kernel module + <marcusb> that is what the User Mode Linux kernel module does + <marcusb> ArneBab: so say you use the User Mode Linux kernel module for + that one feature. Then you can do everything that User Mode Linux can + do, which, I assure you, includes running subhurds :) + <marcusb> it can be a bit tricky to implement those features, but it is not + harder than writing a kernel in the first place + <ArneBab> So, if I got an admin to install User Mode Linux and Mach + emulation, I’d get the flexibility (and independence from admin + decisions) I have in the Hurd? + <marcusb> ArneBab: one problem is that you still use Linux. For those who + want to get rid of Linux for political reasons, that would mean complete + failure + <marcusb> ArneBab: if you have UML kernel module, you can implement Mach in + user space + <marcusb> ArneBab: in fact, John Tobey did this a couple of years ago, or + started it + +([[tschwinge]] has tarballs of John's work.) + + <marcusb> ArneBab: or you can just implement parts of it and relay to Linux + for the rest + <marcusb> the point is, that if you don't care for kernel improvements, and + are sufficiently happy with the translator stuff, it's not hard to bring + the Hurd to Linux or BSD + +Continue reading about the [[benefits of a native Hurd implementation]]. + +--- + +IRC, #hurd, 2010-12-28 + + <antrik> kilobug: there is no real requirement for the Hurd to run on a + microkernel... as long as the important mechanisms are provided (most + notably external pagers and Mach IPC), the Hurd could run an top of + pretty much any kernel... + <antrik> whether it makes sense is another question of course :-) + <antrik> though I must say that I'm more and more convinced running the + Hurd on top of a monolithic kernel would actually be a useful approach + for the time being... + +--- + +IRC, #hurd, 2011-02-11 + + <neal> marcus and I were discussing how to add Mach to Linux + <neal> one could write a module to implement Mach IPC + <neal> and another to implement Mach VM + <neal> the big thing missing with Mach VM is the ability for a tracing + process to easily map or unmap an inferior process's memory + <antrik> neal: why would a tracing process need to map the inferior's + memory? + <neal> the simple answer is that is how it is done on Mach + <antrik> neal: is it? not sure we are talking about the same thing + here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK + <neal> on linux? + <neal> I think it use /proc/pid/mem + <antrik> on Hurd + <neal> I'm talking about adding Mach to Linux + <neal> by adding some functionality to Linux + <neal> and then implementing a bunch in user space + <antrik> yeah, but I don't understand the point about mapping inferior's + memory :-( + <antrik> what would be in user space? + <neal> there are a number of different cut points + <neal> one could imagine just using Linux's device drivers, CPU scheduler, + memory management, etc. + <neal> another possibility would be something higher where Hurd processes + just use some Hurdish servers + <antrik> neal: yeah, these are all options I have been considering... too + bad I wasn't able to come to FOSDEM -- I'd love to have participated in + this discussion :-( + <antrik> neal: BTW, were you just discussing this as a hypothetical idea, + or something you are seriously considering? + <neal> I'm unlikely to work on it, sorry + <antrik> didn't really expect that :-) + <antrik> would be nice though if you could write up your conclusions... diff --git a/open_issues/inotify_file_notice_changes.mdwn b/open_issues/inotify_file_notice_changes.mdwn new file mode 100644 index 00000000..6d644788 --- /dev/null +++ b/open_issues/inotify_file_notice_changes.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <barrucadu> I've been going through the xmlfs code, and plan to have it + monitor the backing store (xml file) for changes and update the presented + directory hierarchy when something is changed; is there a better way to + check a file for changes beyond checking its modification time every few + minutes? + <tschwinge> barrucadu: In the Hurd spirit, you'd use file_notice_changes + (fs.defs). + <barrucadu> thanks + <youpi> we should manage to work out an inotify interface around it, btw + <pochu> like gamin? + <pinotree> imho making gamin work should gain all the fam-using + applications + <pochu> (which, looking at the sources, seems to support hurd already, not + sure why it's not built) + <pinotree> pochu: the hurd_notify of gamin does not build OOTB + <pochu> > /build/buildd/gamin-0.1.10/./libgamin/gam_data.c:476: error: + 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function) + <pinotree> there are few patches in bugzilla to make it compile + <pochu> if they work, and you point me to them, I can upload a new gamin + with them included + <pinotree> #315644, #588337. #605246 + <pinotree> and iirc there's something else i have locally but not send yet + <pochu> please check and submit :) + <pinotree> ah no, those three contains all the build issues + <pinotree> .. plus relative proposed fixes + <pochu> ok, I'll try to get to it soonish + <pinotree> and you should know about two of them already ;D + <pochu> please remind me if I don't :) + +--- + +Apparently fanotify is cosidered inotify's successor, so we might directly go +supporting that one instead, or both. --[[tschwinge]], 2011-05-10 diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn new file mode 100644 index 00000000..72bb3b77 --- /dev/null +++ b/open_issues/issue_tracking.mdwn @@ -0,0 +1,196 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!toc]] + + +# Savannah Trackers, Open Issues, debbugs + +There are the Savannah trackers. Nobody really likes them. + +There is a proposal to add/move to <http://debbugs.gnu.org/>. It can be +operated by email, Debian people (developers and users) already know how to use +it. + +There are the [[Open_Issues]] pages. This is basically just free-form text +enriched by some tags for grouping, editable via the web and through Git +commit. [[tschwinge]] added this to the set, and/but mostly is the sole user +of it, even though casually there are a few other people contributing, and +surely these pages do show up in web searches. A more traditional system (like +the Savannah trackers or the new debbugs) do have their advantages, too, so +perhaps there's a niche for both these and the [[Open_Issues]]. + +IRC, freenode, #hurd, 2011-08-31: + + <tschwinge> So. Savannah trackers vs. Open Issues vs. debbugs. Any input? + <youpi> I like *both* open issues and debbugs + <youpi> open issues is good for exposing things that people may encounter + in other situations + <youpi> while debbugs is useful to actually work on a bug + <tschwinge> youpi: The advantage of debbugs being the email interface and + the well-known procedure, or something else? + <youpi> email interface, which nicely flows into a mailing list + <youpi> the savannah bug updates suffer from the additional layout + <tschwinge> How does one decide what to put in a debbug and what in an Open + Issue page? + <youpi> I'd say it's not exclusive at all + <youpi> like, a bug on a specific case can start as debbug, and as we + discover it's more general and will not be fixed immediately, get an open + issue page + <youpi> and conversely, when we know some shortcoming, start with an open + issue, and if some bugs are submitted which are actually due to it, + cross-link + <tschwinge> OK. + <youpi> (some general short coming I mean, like SIGINFO) + <tschwinge> And we would keep the current stuff in the trackers, and let + these ``get empty'' gradually (it'll be years...) ;-) or migrate the + remaining issues? + <tschwinge> What we can do is inhibiting the creation of new issues in the + trackers. + <youpi> I'd say move + <youpi> else they will be forgotten + <tschwinge> Hrm. + <antrik> actually, I considered creating a track-like plugin for ikiwiki, + as both the popularity of trac and the usefulness of open_issues show + that something wiki-like is actually more useful than a rigid traditional + bugtracker. but I'm not really willing to do the work, which is why I + didn't propose it before :-) + <antrik> err... trac-like + <youpi> yes, the wiki part is really useful to keep a good summary of the + issue + <tschwinge> antrik: Same for me. I always hoped that someone would do + it... :-) + <antrik> hehe + <tschwinge> antrik: But, as you surely know, this email parsing business is + just too ugly to do realiable, etc. + <antrik> youpi: my point is that adding a few additional bits (like a + comfortable tagging functionality, and some mail interface) could turn + into a full-blown tracker unifying the advantages of both... but as I + said, I'm not really willing to do the work :-) + <youpi> additional to open_issue you mean? + <youpi> yes, but like you say :) + <antrik> tschwinge: hm... seems to work well enough it debbugs + <youpi> debbugs just piles things + <youpi> and has a few commands + <youpi> you'd still need the web interface to edit the wiki part for + instance + <antrik> of course. that wouldn't change at all + <antrik> (except for adding a tagging GUI perhaps) + <antrik> (debbugs of course is not the only mail-operable bugtracking + system... there are a number of others -- and I heard rumors even + bugzilla grew a mail interface now...) + <youpi> antrik: a .mdwn diff should however be sent to the bug for + information + <youpi> atm, what happens sometimes is somebody saying something here on + #hurd, tschwinge turning that into an open_issue, and it does not show up + on the mailing list + <tschwinge> debbugs surely has the advantage that it is available (nearly) + right now. + <mattl> RT (request tracker) and ikiwiki play quite nicely together. + <tschwinge> mattl: You'Re using that at GNU/FSF/somewhere, right? + <mattl> you can close tickets from the wiki, and RT has a good command line + interface, email interface and web interface. + <mattl> tschwinge: yeah, we use RT and ikiwiki. + <mattl> RT for all FSF communications, and ikiwiki for internal organising. + <mattl> RT is not the easiest thing to set up, but works pretty well once + it's running. + +IRC, freenode, #hurd, 2011-10-19: + + <antrik> tschwinge: BTW, what happened to the plan of killing help-hurd? + <antrik> (and possibly some other lists) + <tschwinge> antrik: That plan got stalled, obviously. ;-) + <tschwinge> antrik: Now, I had proposed to use hurd-dev for development, + and turn bug-hurd into a debbugs bug reportling list. That proposal has + not heard any supportive/unsupportive votes yet. + <tschwinge> hurd-devel. That's the name. + <tschwinge> And turn off hurd-devel-readers. And turn off help-hurd. + <tschwinge> And web-hurd. + <tschwinge> Keep l4-hurd. + <antrik> yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm + not quite sure myself + <antrik> on one hand, a dedicated bug list can be convenient; on the other + hand, this kind of splits always causes unnecessary overhead IMHO + <antrik> also, hurd-devel would obviously be *only* for development, so in + this scenario we actually would *need* to keep something like help-hurd + as well... + <antrik> I think I'd prefer the non-exclusive mode for debbugs... would + have to check again how it works exactly though :-) + <tschwinge> antrik: I quite liked that exclusive mode for it automatically + archives discussions grouped by threads for easy reference. + <tschwinge> antrik: And, the very most of bug-hurd emails are ``issues'' of + some sort: bug report, patch (that needs to be tracked until it is + applied, etc. + <antrik> tschwinge: exclusive mode would just mean that people would take + most of these discussion elsewhere, and the bug list would only be used + when someone explicitly wants something tracked as a bug... + <antrik> ideally, the bug tracker should only track things if explicitly + CCed. ideally, it should be possible to forward mails that have been + posted without CC, so they can be tracked retroactively... + <tschwinge> antrik: Why do you think that people would take discussions + elsewhere? + <antrik> because most people don't consider it useful to put every random + question or remark in an issue tracker + <antrik> IMHO it should be easy to turn messages into tickets/followups; + but it should not happen automatically + <tschwinge> What if people wouldn't even notice that their issues is kept + in a tracker, too? + <draculus> It might send a notification of some sort? + <antrik> I once posted to a list with RT in exclusive mode, and quite + frankly, I considered it rather strange to get a ticket created for my + message :-) + <antrik> tschwinge: that would only be useful if you always close tickets + for irrelevant or finished discussions, mark duplicates etc. -- and this + would have to happen silently, without noise for most other people + following the list... + <antrik> tschwinge: are you sure you want to do that?... :-) + <tschwinge> Yes. + <tschwinge> Because that way we don't lose so much stuff as we currently + do. + <antrik> well, the decision is up to you in that case... + <tschwinge> In fact, probably less than manually archiving the content, as + I'm doing now, partially. + <tschwinge> antrik: Well, I'm just out for getting some comments. + <antrik> it would further reduce our bus factor though :-( + <tschwinge> That already is low enough that it doesn't matter anymore... + <tschwinge> antrik: So, to sum up, you'd use non-exclusive mode, but are + not actively opposed to exclusive mode as long as it doesn't too much + disturbe any procedures you're currently using? + <antrik> well, if it happens mostly in the background, I don't see why + anyone should be opposed... + <antrik> just make sure people posting to the list don't get a "ticket + created" message in response :-) + <antrik> it would make it harder though for people to explicitly track + issue they are interested in I fear + <antrik> when using non-exclusive mode, and people explicitly CC things to + the tracker, which sends a notice about a ticket being created, everyone + sees that and can act accordingly. if everything happens in the + background, few people would even think about it... + <antrik> so non-exclusive mode probably needs more effort to keep in order; + but it would be more useful too... + <tschwinge> Well, but with exclusive mode, people don't lose anything + compared to the current state, do they? + <antrik> tschwinge: probably not compared to the current state... but + possibly compared to a well-used non-exclusive mode :-) + + +# Further Systems + + * ikiwiki + + * <http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/> + + * <http://ikiwiki.info/todo/Better_bug_tracking_support/> + + * <http://ikiwiki.info/todo/tracking_bugs_with_dependencies/> + + * <http://ikiwiki.info/todo/Updated_bug_tracking_example/> + + * <http://bugseverywhere.org/> diff --git a/open_issues/keymap_mach_console.mdwn b/open_issues/keymap_mach_console.mdwn new file mode 100644 index 00000000..3063dd00 --- /dev/null +++ b/open_issues/keymap_mach_console.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-04-26 + + <guillem> pavkac: btw are you aware there's already some code to change the + keymap for the mach console (I think originally from the hurdfr guys, but + I cannot remember exactly from where I got it from :/) + <guillem> pavkac: http://www.hadrons.org/~guillem/tmp/hurd-keymap.tgz + <pavkac> guillem: No, I didn't know. I'll diff it and try to follow. + <guillem> pavkac: it would be nice to maybe integrate it properly into the + hurd + <guillem> you'll see the code is pretty basic, so extending it would be + nice too I guess :) + <pavkac> guillem: OK, I'll see to it. Unfortunately I'm quite busy this + week. Have a lot of homeworks to school. :/ + <pavkac> guillem: But, I'll find some time during weekend. + <youpi> maybe it'd be simpler to add it to the hurd package and use that + from the console-setup package indeed + <youpi> but copyright issues should be solved + <youpi> unless we simply put this into hurdextras + <guillem> ok found this: + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg02456.html + <guillem> and + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg01173.html + <guillem> which seems to be the original Mark's code + <guillem> AFAIR I contributed the the spanish keymap and some additional + key definitions for loadkeys + <guillem> and http://lists.debian.org/debian-hurd/2000/10/msg00130.html + <pavkac> I've fetched all. :) But I must leave, good night if you're in + Europe. :) + <guillem> pavkac: the tarball I provided should be the latest, the others + are mostly to track the provenance of the source diff --git a/open_issues/kvm.mdwn b/open_issues/kvm.mdwn new file mode 100644 index 00000000..6dfffc9a --- /dev/null +++ b/open_issues/kvm.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +Issues when running Hurd under KVM: un-synced filesystems, etc. No problems +with Virtualbox. + +2010-07-28, #hurd + + <youpi> pochu: you were the one reporting issues with qemu/kvm and hurd, right? + <youpi> is your machine somehow smp (like multicore for instance) + <youpi> ? + <pochu> youpi: yes, it's a Core 2 Duo + <pochu> so 2 cores + <youpi> ok, you might want to try to bind qemu/kvm + <youpi> e.g. install hwloc, and prepend "hwloc-bind 1 --" before the qemu/kvm command line + <pochu> ok, ty + +2010-07-31, GNU Mach commit 039176372b4271f370ef38eb2ee5d43923a5b28b. diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn new file mode 100644 index 00000000..a6f76a0e --- /dev/null +++ b/open_issues/largefile.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 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_hurd]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <pinotree> i kind of understood why (at least in some parts) largefile doesn't seem to work properly + <pinotree> libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset; + <pinotree> offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int + <pinotree> at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t) + <pinotree> diskfs.h is a public header though :/ + <youpi> well, we can change the soname to mark ABI change diff --git a/open_issues/latrace.mdwn b/open_issues/latrace.mdwn new file mode 100644 index 00000000..b5a2928c --- /dev/null +++ b/open_issues/latrace.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +Check whether <http://people.redhat.com/jolsa/latrace/> works. diff --git a/open_issues/lexical_dot-dot.mdwn b/open_issues/lexical_dot-dot.mdwn new file mode 100644 index 00000000..3299dfa0 --- /dev/null +++ b/open_issues/lexical_dot-dot.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="Lexical .. Resolution"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +There is a [[!FF_project 279]][[!tag bounty]] on this task. + + +# Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/lexical_dot-dot feeds=no]] diff --git a/open_issues/libasyncns.mdwn b/open_issues/libasyncns.mdwn new file mode 100644 index 00000000..bbd34bff --- /dev/null +++ b/open_issues/libasyncns.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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_porting]] + +IRC, unknown channel, unknown date. + + <pinotree> tschwinge: btw, would you be able to tell if and what's wrong with a socket-related problem? + <pinotree> it is reproducible with a very small self-contained C library + <pinotree> http://0pointer.de/lennart/projects/libasyncns/ + <pinotree> it has a test case with it, which fails + <pinotree> tschwinge: if that can ring some bell, imho the problem is related to SOCK_STREAM sockets created with socketpair and used with send/recv diff --git a/open_issues/libc_variant_selection.mdwn b/open_issues/libc_variant_selection.mdwn new file mode 100644 index 00000000..afcd9ae0 --- /dev/null +++ b/open_issues/libc_variant_selection.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2010, 2011 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 open_issue_porting]] + +There is a [[!FF_project 274]][[!tag bounty]] on this task. + +There are now specialized variants of Debian's libc package, libc0.3-i686 and +libc0.3-xen. + + +On Thu, Oct 07, 2010 at 11:22:46AM +0200, Samuel Thibault wrote: +> Thomas Schwinge, le Thu 07 Oct 2010 10:11:07 +0200, a écrit : +> > Also, this text says ``will be selected instead when running under Xen'' +> > -- is this meant to be automatically done? +> +> It's supposed to be, we need to add support for it. +> +> > If so, then it didn't work. +> +> Yes, you need to copy it by hand. Same for libc0.3-i686, we just need to +> steal the cpuid code from the kfreebsd port of glibc. + +--- + +Having working CPUID code inside [[glibc]] is also a prerequisite for proper +[[IFUNC]] support. diff --git a/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn new file mode 100644 index 00000000..1e4a6acb --- /dev/null +++ b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, unknown channel, unknown date. + + <tschwinge> By the way: your libdiskfs ., .. fix -- is that relevant for libnetfs as well? (Didn't look it up so far.) + <youpi> it could be a good idea to protect netfs users directly from there yes + <tschwinge> But probably the backend (e.g., NFS server) would protect us in the netfs case, right? + <youpi> possibly, but we could have locking issues in between like in libdiskfs + <youpi> and POSIX says it's invalid anyway + <youpi> so we'd probably better just forbid it diff --git a/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn new file mode 100644 index 00000000..817dac76 --- /dev/null +++ b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 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_libpthread]] + +IRC, unknown channel, unknown date: + + <azeem> neal: libgomp (GNU's implementation of OpenMP) uses PTHREAD_STACK_MIN, which we do not define apparently + <neal> azeem: We have fixed sized stacks. + <neal> so the pthread_attr_setstacksize will fail once you define PTHREAD_STACK_MIN) diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn new file mode 100644 index 00000000..80fc9fcd --- /dev/null +++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn @@ -0,0 +1,106 @@ +[[!meta copyright="Copyright © 2010, 2011 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 open_issue_hurd]] + +[[!toc]] + + +# bug-hurd discussion. + + +# IRC, freenode, #hurd, 2010-08-12 + + <jkoenig> Looking at hurd.git, shouldn't {hurd,include}/Makefile's "all" + target do something, and shouldn't pretty much everything depend on them? + As it stands it seems that the system headers are used and the + potentially newer ones never get built, except maybe on "install" (which + is seemingly never called from the top-level Makefile) + <jkoenig> I would fix it, but something tells me that maybe it's a feature + :-) + <antrik> jkoenig: the headers are provided by glibc, along with the stubs + <jkoenig> antrik, you mean, even those built from the .defs files in hurd/ + ? + <antrik> yes + <jkoenig> oh, ok then. + <antrik> as glibc provides the stubs (in libhurduser), the headers also + have to come from there, or they would get out of sync + <jkoenig> hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids, + then? + <antrik> jkoenig: not necessarily. the msgids describe what the servers + actually understand. if the stubs are missing from libhurduser, that's no + reason to leave out the msgids... + <jkoenig> ok this makes sense + + +# IRC, OFTC, #debian-hurd, 2011-09-29 + + <tschwinge> pinotree: I don't like their existence. IMO (but I haven't + researched this in very much detail), every user of RPC stubs should + generated them for themselves (and glibc should directly include the + stubs it uses internally). + <pinotree> sounds fair + <pinotree> maybe they could be moved from glibc to hurd? + <tschwinge> pinotree: Yeah; someone needs to research why we have them (or + if it's only convenience), and whether we want to keep them. + <pinotree> you could move them to hurd, leaving them unaltered, so binary + compatibility with eventual 3rd party users is not broken + <pinotree> but those using them, other than hurd itself, won't compile + anymore, so you fix them progressively + + +# IRC, freenode, #hurd, 2011-11-16 + + <braunr> is the mach_debug interface packaged in debian ? + <antrik> what mach_debug interface? + <braunr> include/include/mach_debug/mach_debug.defs in gnumach + <braunr> include/mach_debug/mach_debug.defs in gnumach + <antrik> what exactly is supposed to be packaged there? + <braunr> i'm talking about the host_*_info client code + <antrik> braunr: you mean MIG-generated stubs? + <braunr> antrik: yes + <braunr> i wrote a tiny slabinfo tool, and rpctrace doesn't show the + host_slab_info call + <braunr> do you happen to know why ? + <antrik> braunr: doesn't show it at all, or just doesn't translate? + <braunr> antrik: doesn't at all, the msgids file contains what's needed to + translate + <braunr> btw, i was able to build the libc0.3 packages with a kernel using + the slab allocator today, while monitoring it with the aforementioned + slabinfo tool, everything went smoothly + <antrik> great :-) + <braunr> i'll probably add a /proc/slabinfo entry some day + <braunr> and considering the current state of our beloved kernel, i'm + wondering why host_*_info rpcs are considered debugging calls + <braunr> imo, they should always be included by default + <braunr> and part of the standard mach interface + <braunr> (if the rpc is missing, an error is simply returned) + <antrik> I guess that's been inherited from original Mach + <antrik> so you think the stubs should be provided by libmachuser? + <braunr> i'm not sure + <antrik> actually, it's a bit arguable. if interfaces are not needed by + libc itself, it isn't really necessary to build them as part of the libc + build... + <braunr> i don't know the complete list of potential places for such calls + <antrik> OTOH, as any updates will happen in sync with other Mach updates, + it makes sense to keep them in one place, to reduce transition pain + <braunr> and i didn't want to imply they should be part of libc + <braunr> on the contrary, libmachuser seems right + <antrik> libmachuser is part of libc + <braunr> ah + <braunr> :) + <braunr> why so ? + <antrik> well, for one, libc needs the Mach (and Hurd) stubs itself + <antrik> also, it's traditionally the role of libc to provide the call + wrappers for syscalls... so it makes some sense + <braunr> sure, but why doesn't it depend on an external libmachuser instead + of embedding it ? + <braunr> right + <antrik> now that's a good question... no idea TBH :-) diff --git a/open_issues/libnetfs_io_map.mdwn b/open_issues/libnetfs_io_map.mdwn new file mode 100644 index 00000000..dc6da202 --- /dev/null +++ b/open_issues/libnetfs_io_map.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="libnetfs: io_map"]] + +[[!tag open_issue_hurd]] + +This hampers [[hurd/translator/nfs]] usability, for example: + + $ fsysopts ./ + /hurd/nfs [...] + $ cp -a /bin/true ./ + cp: failed to preserve authorship for `./true': Operation not supported + $ ./true + $ /lib/ld.so /bin/true + $ /lib/ld.so $PWD/true + [...]/true: error while loading shared libraries: [...]/true: failed to map segment from shared object: Error 1073741869 + +IRC, freenode, #hurd, 2012-03-14: + + <civodul> i just realized that ld.so uses mmap unconditionally + <civodul> so executables or shared libs can't be used off a netfs-based + file system + <civodul> that's annoying + <tschwinge> civodul: Do you know what it takes to fix libnetfs? I have no + idea. + <tschwinge> Never looked at it. + <civodul> tschwinge: implementing io_map + <civodul> but i think the idea is that io_map typically isn't convenient + for network file systems + <civodul> which is why it doesn't have it + <civodul> the GCS says "thou shall not require mmap" ;-) + +<http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html>. Analysis +to be found on [[glibc/mmap]] page. diff --git a/open_issues/libnfs.mdwn b/open_issues/libnfs.mdwn new file mode 100644 index 00000000..8cadefa4 --- /dev/null +++ b/open_issues/libnfs.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 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_hurd]] + +IRC, freenode, #hurd, 2012-01-09: + + <pinotree> https://github.com/sahlberg/libnfs ← maybe it could be used for + nfs support, instead of the rpc stuff "removed" in newer glibc versions + <antrik> pinotree: sounds like it could do much more than just the RPC + stuff -- definitely interesting :-) + <pinotree> hm but it seems to be an abstraction over either classic rpc or + tirpc + <pinotree> (anyway, it is packaged already in debian) + <antrik> good licensing too + <antrik> I guess I'll modify the GSoC task to "rework the Hurd NFS client + to use libnfs" :-) + <pinotree> the nfs translator? + <antrik> yes + +[[hurd/translator/nfs]] diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn new file mode 100644 index 00000000..c5054b7f --- /dev/null +++ b/open_issues/libpthread.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2010, 2011, 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 open_issue_libpthread]] + +[[!toc]] + + +# cthreads -> pthreads + +Get rid of cthreads; switch to pthreads. + +There is a [[!FF_project 275]][[!tag bounty]] on this task. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] + + +## IRC, freenode, #hurd, 2012-04-26 + + <pinotree> youpi: just to be sure: even if libpthread is compiled inside + glibc (with proper symbols forwarding etc), it doesn't change that you + cannot use both cthreads and pthreads in the same app, right? + +[[Packaging_libpthread]]. + + <youpi> it's the same libpthread + <youpi> symbol forwarding does not magically resolve that libpthread lacks + some libthread features :) + <pinotree> i know, i was referring about the clash between actively using + both + <youpi> there'll still be the issue that only one will be initialized + <youpi> and one that provides libc thread safety functions, etc. + <pinotree> that's what i wanted to knew, thanks :) diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn new file mode 100644 index 00000000..2c8f10f8 --- /dev/null +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -0,0 +1,78 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="libpthread: CLOCK_MONOTONIC"]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]] + + +# IRC, freenode, #hurd, 2012-04-22 + + <pinotree> youpi: what i thought would be creating a + glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and + _hurd_clock_{gettime,settime,getres} to it and making the current .c in + sysdeps call those + <youpi> yep + <youpi> that's unfortunate, but that's what nptl actually does + <pinotree> this way we could add inside hurdtime.c the mapped time stuff + too + <pinotree> most probably a noobish question, but why does rt link to + pthread? + <youpi> no idea :) + <youpi> possibly due to aio implementation + <youpi> ./sysdeps/pthread/aio_cancel.c + <youpi> probably due to that + <youpi> (and others) + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> pinotree: about librt vs libpthread, don't worry too much for now + <youpi> libpthread can lib against the already-installed librt + <youpi> it does work + <pinotree> youpi: wouldn't that cause a dependency loop? + <youpi> pinotree: what dependency loop? + <pinotree> youpi: librt wouldd link to pthread, no? + <youpi> and ? + <youpi> I don't think it's an issue that .so link with each other + <pinotree> it isn't? + <youpi> well, try + * pinotree never did that + <youpi> but I don't think it will pose problem + <youpi> well, perhaps initialization order + <youpi> anyway, I now have packages built, I'll test that + <youpi> pinotree: ok, it seems it doesn't work indeed :) + <youpi> early in initialization + <youpi> pinotree: the initialization bug might actually not be due to librt + at all + <youpi> pinotree: yes, things work even with -lrt + <pinotree> wow + + +## IRC, OFTC, #debian-hurd, 2012-06-04 + + <youpi> pinotree: -lrt in libpthread is what is breaking glib2.0 + <youpi> during ./configure it makes clock_gettime linked in, while at + library link it doesn't + <youpi> probably for obscure reasons + <youpi> I'll have to disable it in debian + + +### IRC, OFTC, #debian-hurd, 2012-06-05 + + <pinotree> youpi: i saw your message about the linking issues with + pthread/rt; do you want me to provide a patch to switch clock_gettime → + gettimeofday in libpthread? + <youpi> you mean switch it back as it was previously? + <pinotree> kind of, yes + <youpi> I have reverted the change in libc for now + <pinotree> ok diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn new file mode 100644 index 00000000..1418bea1 --- /dev/null +++ b/open_issues/libpthread_assertion_thread_prevp.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="libpthread: __pthread_enqueue: Assertion `thread->prevp == 0' +failed"]] + +[[!tag open_issue_libpthread]] + +IRC, OFTC, #debian-hurd, 2011-10-21: + + [Python testsuite] + <pinotree> [169/340/1] test_logging + <pinotree> python: + /home/pino/sources/hurd/hurd-20110519/./libpthread/pthread/pt-internal.h:109: + __pthread_enqueue: Assertion `thread->prevp == 0' failed. + <pinotree> sigh + +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? + <pinotree> ... thus potentially causing + "./libpthread/pthread/pt-internal.h:109: __pthread_enqueue: Assertion + `thread->prevp == 0' failed." because threads can be appended on + __pthread_dealloc() to the __pthread_free_threads list as well? + <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: + + <youpi> pinotree: I don't understand the relation between thread->prevp != + 0 and the __pthread_threads list + <youpi> the list never has elements removed indeed, since libpthread never + frees __pthread structures apparently + <pinotree> youpi: ye sorry, that relation is indeed nonsense + <youpi> in which condition did you get prevp != 0 + <pinotree> i wa trying to find some explaination for the "thread->prevp == + 0" assertion in the _queue function + <youpi> ? + <pinotree> *was + <youpi> it's not obvious to me how libpthread makes sure the various + cond/mutex/rwlock make sure that it's not queued several times + <pinotree> yeah + <pinotree> apparently prevp/next are used for lists of held + waitcond/mutex/rwlock and free threads diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn new file mode 100644 index 00000000..05a07ef2 --- /dev/null +++ b/open_issues/libpthread_dlopen.mdwn @@ -0,0 +1,129 @@ +[[!meta copyright="Copyright © 2011, 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_libpthread]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2010-01-24 + + <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed + libraries + <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, + we're the only one with such configuration + <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it + be it does not set THREADLIBS in the configure.ac switch case? + <youpi> that's expected + <youpi> on linux the libc provides hooks itself, on hurd-i386 it's + pthread-stubs + <pinotree> why not explicitly link to pthread though? + <youpi> because there is no strict need to, for applications that don't + need libpthread + <youpi> the dlopen case is a tricky case that pthread-stubs had not thought + about + <pinotree> hm + <pinotree> what if the pthread stubs would be moved in our glibc? + <youpi> that's what we should do yes + <youpi> (ideally) + <youpi> but for this we need to build libpthread along glibc, to get it + really working + +[[Packaging_libpthread]]. + + <youpi> and that's the tricky part (Makefile & such) which hasn't been done + yet + <pinotree> why both (stubs + actual libpthread)? + <youpi> because you need the stubs to be able to call the actual libpthread + <youpi> as soon libpthread gets dlopened for instance + <youpi> +as + <pinotree> i see + <youpi> (remember that nptl does this if you want to see how) + <youpi> (it's the libc files in nptl/) + <youpi> (and forward.c) + <guillem> also if libpthreads gets integrated with glibc don't we need to + switch the hurd from cthreads then? Which has been the blocker all this + time AFAIR? + <youpi> we don't _need_ to + <guillem> ok + + +# IRC, OFTC, #debian-hurd, 2011-07-21 + + <youpi> there's one known issue with pthreads + <youpi> you can't dlopen() it + +... if the main application is not already linked against it. + + <youpi> which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + <youpi> (so as to get libpthread initialized early, not at the dlopen() + call) + <lucas> I get this while building simgrid: + <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + /usr/bin/cmake -E create_symlink + /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so + /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so + <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua + <lucas> lua: + /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: + __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. + <lucas> Aborted (core dumped) + <youpi> that's it, yes + <youpi> (or at least it has the same symptoms) + <lucas> it would need fixing in lua, not in SG, then, right? + <youpi> yes + <lucas> ok, thanks + +The fix thus being: link the main application with -lpthread. + +IRC, freenode, #hurd, 2011-08-17 + + < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but + openjade itself is not liked against libpthread + < youpi> which means unexpectedly loading pthreads on the fly, which is + not implemented + < youpi> (and hard to implement of course) + < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread + < gnu_srs> Shuoldn't missing linking with pthread create an error when + building openjade then? + < youpi> no + < youpi> because it's just a module which needs pthread + < youpi> and that module _is_ linked with -lpthread + < youpi> and dlopen() loads libpthreads too due to that + < youpi> but that's unexpected, for the libpthread initialization stuff + < youpi> (and too late to fix initlaization) + < gnu_srs> How come that other OSes build opensp w/o problems? + < youpi> because there are stubs in the libc + < gnu_srs> Sorry for the delay: What hinders stubs to be present also in + the Hurd libc parts too, to cope with this problem? + < youpi> doing it + < youpi> which is hard because you need libpthread bits inside the libc + < youpi> making it simpler would need building libpthread at the same time + as libc + +[[packaging_libpthread]] + +--- + +The same symptom appears in an odd case, for instance: + + buildd@hurd:~$ ldd /usr/bin/openjade + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) + libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) + libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) + libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) + [...] + +openjade links against *both* libthreads and libpthread. The result is that libc +early-initializes libthreads only, and thus libpthread is not early-initialized, +and later on raises assertions. The solution is to just get rid of libthreads, +to have only one threading library. diff --git a/open_issues/libpthread_glibc_nptl_testsuite.mdwn b/open_issues/libpthread_glibc_nptl_testsuite.mdwn new file mode 100644 index 00000000..687f8eea --- /dev/null +++ b/open_issues/libpthread_glibc_nptl_testsuite.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 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 open_issue_libpthread]] + +For fun and profit we should run [[glibc]]'s [[NPTL]] testsuite against +[[libpthread]]. + +Also, there are sometimes issues fixed in NPTL that libpthread should also be +checked against. Totally incomplete list: + + * Return `EAGAIN` instead of `ENOMEM`, glibc + 5bdcc10322c488f53557440acf71623d8b313ab5. + * `pthread_cancel` when single-threaded, glibc + 439bf404b8fa125cf950dc1aa37838702c5353ea, [[!sourceware_PR 13613]], + [[!message-id "20120509202437.268a72b9@spoyarek"]]. + * `__libc_stack_end`, glibc 9c6ea9facbba4d430807bd21fa82892d713b1ecd, + 18b5e737de22462ab6b3fc89f26c9ad480ebb843, [[!sourceware_PR 12416]], + [[!message-id "20120419120021.4780e8c8@spoyarek"]], [[!message-id + "20120615005913.4f517e02@spoyarek"]], [[!message-id + "4FE378DE.8050906@mentor.com"]]. diff --git a/open_issues/libpthread_set_stack_size.mdwn b/open_issues/libpthread_set_stack_size.mdwn new file mode 100644 index 00000000..68f81752 --- /dev/null +++ b/open_issues/libpthread_set_stack_size.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 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 open_issue_libpthread]] + +IRC, freenode, #hurd, 2011-10-21: + + <pinotree> maybe i'm missing something... what's the reason for not + allowing setting a different stack size in libpthread? + +2011-10-23: + + <youpi> pinotree: the threadvars implementations + <youpi> which needs to find the variables according to sp value + <youpi> of course, since we now have TLS, threadvards can go away + <youpi> it's simply on the so-long TODO list + +[[glibc/t/tls-threadvar]]. diff --git a/open_issues/libpthread_weak_symbols.mdwn b/open_issues/libpthread_weak_symbols.mdwn new file mode 100644 index 00000000..6f135979 --- /dev/null +++ b/open_issues/libpthread_weak_symbols.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2010 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 open_issue_libpthread]] + +IRC, unknown channel, unknown date. + + <youpi> btw, the issue with pthread_cancel is tricky + <youpi> I'm afraid there might be no fix + <youpi> clean fix, I mean + <pinotree> oh, hm + <pinotree> where it the problem located, actually? + <youpi> it's a lot more than just one place + <youpi> in some c++ header there is a weak reference to pthread_cancel + <youpi> libpthreadstubs0 provides a weak definition of pthread_cancel, which can suit well + <youpi> problem comes when also linking with a library which pulls libpthread + <youpi> oops no libpthreadstubs0 doesn't provide a weak definition of pthread_cancel + <youpi> it couldn't implement it anyway + <youpi> and the problem here is that the linker seems to be looking for pthread_cancel in the libpthreadstubs0 library, not libpthread + <youpi> and can't find it + <youpi> I don't know how this translate to english, but we're “walking on eggs + <youpi> ” on this issue + <pinotree> i see + <youpi> i.e. we already know we're not respecting the ELF standard + <youpi> we need a feature that is not in the standard to make pthread symbols working + <youpi> the solution would be to integrate libpthread into the glibc + <pinotree> you mean in the sources, but still providing separate libc.so and libpthread.so? + <youpi> yes + <pinotree> would that be difficult/tricky? + <youpi> because that permits to put pthread_* functions forwarding directly in the glibc, as is done on linux + <youpi> problem is upstream, you know... + <youpi> if we put libpthread there, it'll be difficult for us to maintain it + <pinotree> ah, the friendly ulrich mate? + <youpi> we already have difficults to get almost trivial patches commited + <youpi> and the "yes I'll handle it someday" Roland mate + <youpi> Roland is supposed to be the GNU part maintainer, but he doesn't have a box running at the moment + <youpi> what we could do is to do it in Debian for the moment + <pinotree> yeah + <pinotree> iirc eglibc is maintained within git, isn't it? + <pinotree> maybe you could do a hurd branch, putting all the hurd patches and the pthread sources, and then releasing from that + <youpi> we're already moving to something like that, yes + <youpi> at least for all the other glibc patches we have + <youpi> maybe we'll just do that on sourceware actually diff --git a/open_issues/librpci.mdwn b/open_issues/librpci.mdwn new file mode 100644 index 00000000..a3af16b1 --- /dev/null +++ b/open_issues/librpci.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011 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_gnumach open_issue_hurd]] + +2004 to 2007, Anand Babu has been working some on this project. It is still in +rather early stages. It's meant to become an extension/complement to +[[hurd/debugging/rpctrace]]. + + * <https://savannah.nongnu.org/projects/rpci> + + > A C language library for interposing ports of a Hurd task running on top + > of GNU Mach micro-kernel. Using this library, it would be possible to + > implement a trace/replay system, RPC debugger, sandbox, etc. + + On top of that, a debugger was planned: + + > A RPC level debugger with useful command set to analyze/manipulate a task + > at run time. For example, the user will be able to set RPC break points, + > manipulate port rights and data, trace and replay a task. + +If there is interest, the existing source code could be moved from the CVS +repository into the [[source_repositories/incubator]] ([[tschwinge]] already +locally converted it to Git.) diff --git a/open_issues/libstore_parted.mdwn b/open_issues/libstore_parted.mdwn new file mode 100644 index 00000000..852c8fa8 --- /dev/null +++ b/open_issues/libstore_parted.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta redir=hurd/libstore/part]] diff --git a/open_issues/libtool.mdwn b/open_issues/libtool.mdwn new file mode 100644 index 00000000..7b2e0fe0 --- /dev/null +++ b/open_issues/libtool.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 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_porting]] + +# [[GCC]]: `libtool: finish`: `ldconfig` is not run for the Hurd. + +This probably comes from libtool's `libltdl/m4/libtool.m4` (or similar): +`finish_cmds`. + +There are a few other differences between `gnu` and `linux* | k*bsd*-gnu | +kopensolaris*-gnu`. diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn new file mode 100644 index 00000000..1d84d777 --- /dev/null +++ b/open_issues/linux_as_the_kernel.mdwn @@ -0,0 +1,237 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +Instead of attempting a [[history/port_to_another_microkernel]], or writing an +own one, an implementation of a Hurd system could use another existing +operating system/kernel, like [[UNIX]], for example, the Linux kernel. This is +not a [[microkernel]], but that is not an inherent hindrance; depending on what +the goals are. + +There has been an attempt for building a [[Mach_on_top_of_POSIX]]. + + +# IRC, freenode, #hurd, 2012-02-08 + +Richard's X-15 Mach re-implementation: + + <braunr> and in case you didn't notice, it's stalled + <braunr> actually i don't intend to work on it for the time being + <braunr> i'd rather do as neal suggested: take linux, strip it, and give it + a mach interface + <braunr> (if your goal really is to get something usable for real world + tasks) + <antrik> braunr: why would you want to strip down Linux? I think one of the + major benefits of building a Linux-Frankenmach would be the ability to + use standard Linux functionality alongside Hurd... + <braunr> we could have a linux x86_64 based mach replacement in "little" + time, with a compatible i386 interface for the hurd + <braunr> antrik: well, many of the vfs and network subsystems would be hard + to use + <antrik> BTW, one of the talks at FOSDEM was about the possibility of using + different kernels for Genode, and pariticularily focused on the + possibilities with using Linux... unfortunately, I wasn't able to follow + the whole talk; but they mentioned similar possibilities to what I'm + envisioning here :-) + + +## IRC, freenode, #hurd, 2012-03-28 + + <mel__> is there currently any work going on with respect to + Mach-alternatives? + <antrik> mel__: no + <antrik> we have other priorities to take care of :-) + <braunr> antrik: i still intend to try giving linux a "mach personality" :) + <braunr> antrik: but i don't have much time for development currently :( + <mel__> antrik: which means that the hope is that Mach can be turned into + something really well working (i.e. secure/scalable/etc.)? + <antrik> mel__: yes, that's the venue we are pursuing + <antrik> (and IMHO the right one... though the Linux layer mentioned by + braunr is also one of my favourite projects, that we should pursue *in + parallel* to the existing Mach-based implementation) + <mel__> what is this Linux Layer exactly? + <mel__> a Linux instance running on top of Mach in parallel to Hurd + serverS? + <braunr> mel__: not exactly + <braunr> mel__: it would involve adding a mach layer on top of linux + actually + <braunr> mel__: so that linux can be used as a mach kernel + <mel__> Ah! + <mel__> Running Hurd on top of Linux + <mel__> :-D + <mel__> Funny + <braunr> ironic, yes + <braunr> but very pragmatic + <mel__> and THEN + <antrik> yeah. I most like the name: Hurd Emulation Layer on + Linux... i.e. HELL :-) + <mel__> we use a device driver framework something so that we can use Linux + device drivers in Hurd! + <mel__> on top of Linux.... + <braunr> yes + <braunr> i guess a transition phase would include using in kernel drivers + directly for a while + <mel__> and somebody is working on that? + <antrik> mel__: well, for using Linux drivers we are persuing DDE, which + allows us doing that with Mach as well + <braunr> then grabbing them out of the kernel and into dde + <braunr> not yet + <antrik> (in fact we have been using Linux drivers since forever... they + just haven't been updated for ages) + <mel__> I would _guess_ that it is not that hard. + <braunr> it's not + <mel__> Basically one would need to implement the message passing interface + thing in linux I guess. + <braunr> and many exported kernel objects like tasks, threads, etc.. + <braunr> and implement all the RPCs normally implemented by the kernel + <braunr> but it's doable + <antrik> mel__: the IPC aspect is one part, but probably the less tricky + one. the external pager interface is really the crucial element + <mel__> uh + <mel__> yeah + <mel__> hooking into linux virtual memory stuff + <mel__> sounds delicate + <braunr> it's true that some interactions between the linux VM and file + systems (the linux equivalent of our pagers) is synchronous + <braunr> but i don't think it would be that hard considering the amount of + facilities available in linux + <braunr> it's just work, takes time, needs debugging, reviewing, testing, + etc.. + <lcc> hurd on top of linux. how would that work? + <braunr> 15:30 < braunr> antrik: i still intend to try giving linux a "mach + personality" :) + <braunr> lcc: 7 system calls and a few hundreds of RPCs on top, the + internal magic of course, and voila .. + <antrik> of course porting Mach still requires work + <mel__> that would then be GNU/Hurd/Linux + <mel__> :-) + <antrik> hehe + <braunr> eh + <antrik> braunr: BTW, are you more thinking of a userspace solution on top + of standard Linux mechanisms, or additions to Linux itself?... + <antrik> (we probably talked about it already, but I don't remember all the + details...) + <braunr> antrik: adding to linux + <antrik> do you think a pure userspace solution would be realistic at all? + (at the expense of some performance of course) + <mel__> it's probably comparable to the qemu vs. qemu/kvm thing + <antrik> yeah, I guess that pretty much sums it up... + <braunr> antrik: i don't know :/ + <antrik> OK + <lcc> how challenging is it to port mach? + <antrik> lcc: it requires good low-level knowledge of the platform in + question. having that, I guess it shouldn't be too hard to add the + necessary code in Mach... + <antrik> TBH I'm not sure how much knowledge of Mach internals is required + <braunr> the pmap module is the main thing to port + <antrik> braunr: well, sartakov seemed to have most trouble with the + scheduler when he attempted the ARM port... + <braunr> that's strange + <antrik> at least there was quite a long thread where he asked about how + task switching works in Mach + <braunr> ok + <braunr> that would be interesting + <braunr> i thought intereacting with the hardclock was enough + + +## IRC, freenode, #hurd, 2012-04-05 + + <braunr> antrik: don't you think HELL is worth a try for the GSoC btw ? + <antrik> braunr: definitely. I haven't managed to rework the project ideas + list at all this year... but it's something I wanted there for a long + time + + <youngrw> just out of curiousity, what is HELL ? + <antrik> Hurd Emulation Layer on Linux + <braunr> youngrw: it can be described in several ways + <braunr> youngrw: basically, it's a mach interface on top of linux + <youngrw> implementing I suppose both the IPC mechanism and memory + management interface? + <mel__> youngrw: basically that. more generally: implement everything in + order to let Hurd run on that layer. + <antrik> well, it's slightly more complicated in my view... it's basically + anything that allows running a Hurdish environment on top of + GNU/Linux. it might be simply an implementation/emulation of Mach + mechanisms; but it also *might* work on a slightly higher level... + <youngrw> antrik: how might HELL operate at the slighty higher level like + you describe? + <antrik> let's call it low-level HELL and high-level HELL ;-) + <antrik> (a more descriptive name would be hurdenv... but HELL is so much + more catchy :-) ) + <antrik> so, high-level HELL... basically, the idea would be not to emulate + the kernel facilities and run all the real Hurd servers; but instead to + use special servers implementing the Hurd interfaces, but on top of + standard Linux facilities + <antrik> hurdish programs could run in such an environment, as long as they + aren't too low-level + <antrik> I wonder whether generic RPC interfaces could be implemented with + some side channel tunneled though the ordinary Linux FS interfaces... + <antrik> so translators would be loaded as FUSE modules for example, but + could still present generic interfaces + <youngrw> That's actually pretty different from what I was expecting + <antrik> what were you expecting? + <youngrw> maybe something where the entire kernel interface is emulated by + a running user process, like a kind of virtual machine + <youngrw> I hope that makes sense--I may be using my words incorrectly. + <antrik> youngrw: that would be in the low-level HELL category + <youngrw> antrik: right; I had the misconception that the level was defined + by how it made use of the underlying linux system + <youngrw> and that different HELL designs would always implement the mach + interface + + +## IRC, freenode, #hurd, 2012-04-06 + + <braunr> antrik: i think we have diverging ideas about how to use linux for + the hurd + <braunr> antrik: what you seem to want are really emulation componants, + like e.g. ext2fs and pfinet actually using the linux implementation + <braunr> (correct me if i'm mistaken) + <braunr> whereas my project is to make linux behave as a mach clone + <antrik> braunr: as I said, I consider both variants -- either a high-level + HELL or a low-level HELL + <braunr> ok + <antrik> (or perhaps a mix of both) + <braunr> a mix would be best imho + <antrik> yeah, probably + <braunr> so we have the real hurd, the real mach interface, and a set of + native translators (e.g. ext2fs) along some emulating their functionality + using linux code (e.g. a hypothetical ext4fs) + <antrik> I don't think we would have emulation servers for individual Linux + filesystems. rather, a generic server interfacing with the Linux VFS + tree... + <braunr> ok + + <antrik> braunr: BTW, I think I mentioned a couple of years ago that the + most realistic route towards a modern Mach in my opinion would be taking + a modern BSD (or Linux), and redo what the original Mach developers did + -- i.e. add the Mach-specific features, and drop the unnecessary UNIX + stuff + <braunr> antrik: :) + <braunr> we had discussions about it some time ago yes + <antrik> later I realised that it's better *not* to drop the UNIX + interfaces, but rather to keep them in parallel :-) + <braunr> antrik: for what purpose ? + <braunr> (i can imagine a few, but i'd like to know your idea) + <antrik> for the purpose of HELL :-) + <braunr> well hell would be the implementation, but what do you keep these + unix interfaces for ? + <antrik> i.e. people being able to play around with a Hurd environment + while staying with their existing system + <braunr> yes, i see + <braunr> i was considering doing that for development, yes + <braunr> uml first, and then i realized i wouldn't need it :) + <braunr> then i remembed netbsd and its syscall emulation layer + <antrik> also we might leverage some "foreign" userspace infrastructure + that way, such as udev + <antrik> (in the case of Linux that is... not sure whether NetBSD has + something similar at all ;-) ) + <braunr> i'll have to check, it's been a long time since i've really used + it + <braunr> they must use a pure devfs instance now diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn new file mode 100644 index 00000000..a4311d3e --- /dev/null +++ b/open_issues/linux_vmsig.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="Linux: vmsig"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + + * *cooperating with the VM when memory pressure increases* + + * *notify user applications of virtual memory events via real-time signals* + +<http://www.cs.umass.edu/~emery/pubs/bookmarking-collector/>, and discussion at +<http://lambda-the-ultimate.org/node/2391> and +<http://marc.info/?t=113269321800003&r=1&w=2>. + +Found this via <http://lambda-the-ultimate.org/node/4094#comment-62100>, which +was linked from [LWN](http://lwn.net/Articles/409416/). + +From a quick glance, this sounds to [[me|tschwinge]] quite a bit like +mechanisms also found in (originating in?) Mach's +[[microkernel/mach/external_pager_mechanism]]. May be worth having a look at +it. diff --git a/open_issues/lisp_cross-compile.mdwn b/open_issues/lisp_cross-compile.mdwn new file mode 100644 index 00000000..c9100aec --- /dev/null +++ b/open_issues/lisp_cross-compile.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +flaviocruz-soc2008-lisp-branch: lisp stuff can't be cross-compiled. diff --git a/open_issues/llvm.mdwn b/open_issues/llvm.mdwn new file mode 100644 index 00000000..d0b7b91d --- /dev/null +++ b/open_issues/llvm.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2011 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_llvm open_issue_porting]] + +[LLVM](http://www.llvm.org/) needs a little bit of porting for being usable on +GNU/Hurd. + +Apparently this has already been done within Debian; +<http://anonscm.debian.org/viewvc/pkg-llvm/llvm/trunk/debian/patches/>. diff --git a/open_issues/locking_issues.mdwn b/open_issues/locking_issues.mdwn new file mode 100644 index 00000000..e15562bc --- /dev/null +++ b/open_issues/locking_issues.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +There are locking issues in the Hurd's libraries. + +[[!toc]] + + +# Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/libdiskfs_locking feeds=no]] + + +# ext2fs Deadlock + +[[ext2fs_deadlock]]. + + +# Formal Verification + +Methods of [[formal_verification]] should be applied to get an understanding of +the behavior of the locking logic. There are tools for formal +verification/[[code_analysis]] that can likely help here. + +There is a [[!FF_project 278]][[!tag bounty]] on this task. diff --git a/open_issues/low_memory.mdwn b/open_issues/low_memory.mdwn new file mode 100644 index 00000000..22470c65 --- /dev/null +++ b/open_issues/low_memory.mdwn @@ -0,0 +1,113 @@ +[[!meta copyright="Copyright © 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_gnumach open_issue_glibc open_issue_hurd]] + +Issues relating to system behavior under memory pressure. + +[[!toc]] + + +# [[gnumach_page_cache_policy]] + + +# IRC, freenode, #hurd, 2012-07-08 + + <braunr> am i mistaken or is the default pager simply not vm privileged ? + <braunr> (which would explain the hangs when memory is very low) + <youpi> no idea + <youpi> but that's very possible + <youpi> we start it by hand from the init scripts + <braunr> actually, i see no way provided by mach to set that + <braunr> i'd assume it would set the property when a thread would register + itself as the default pager, but it doesn't + <braunr> i'll check at runtime and see if fixing helps + <youpi> thread_wire(host, thread, 1) ? + <youpi> ./hurd/mach-defpager/wiring.c: kr = + thread_wire(priv_host_port, + <braunr> no + <braunr> look in cprocs.c + <braunr> iir + <braunr> iirc + <braunr> iiuc, it sets a 1:1 kernel/user mapping + <youpi> ?? + <youpi> thread_wire, not cthread_wire + <braunr> ah + <braunr> right, i'm getting tired + <braunr> youpi: do you understand the comment in default_pager_thread() ? + <youpi> well, I'm not sure to know what external vs internal is + <braunr> i'm almost sure the default pager is blocked because of a relation + with an unprivlege thread + <braunr> +d + <braunr> when hangs happen, the pageout daemon is still running, waiting + for an event so he can continue + <braunr> it* + + <braunr> all right, our pageout stuff completely sucks + <braunr> when you think the system is hanged, it's actually not + <pinotree> and what's happening instead? + <braunr> instead, it seems it's in a very complex resursive state which + ends in the slab allocator not being able to allocate kernel map entries + <braunr> recursive* + <braunr> the pageout daemon, unable to continue, progressively slows + <braunr> in hope the default pager is able to service the pageout requests, + but it's not + <braunr> probably the most complicated deadlock i've seen :) + <braunr> luckily ! + <braunr> i've been playing with some tunables involved in waking up the + pageout daemon + <braunr> and got good results so far + <braunr> (although it's clearly not a proper solution) + <braunr> one thing the kernel lacks is a way to separate clean from dirty + pages + <braunr> this stupid kernel doesn't try to free clean pages first .. :) + <braunr> hm + <braunr> now i can see the system recover, but some applications are still + stuck :( + <braunr> (but don't worry, my tests are rather aggressive) + <braunr> what i mean by aggressive is several builds and various dd of a + few hundred MiB in parallel, on various file systems + <braunr> so far the file systems have been very resilient + <braunr> ok, let's try running the hurd with 64 MiB of RAM + <braunr> after some initial swapping, it runs smoothly :) + <braunr> uh ? + <braunr> ah no, i'm still doing my parallel builds + <braunr> although less + <braunr> gcc: internal compiler error: Resource lost (program as) + <braunr> arg + <braunr> lol + <braunr> the file system crashed under the compiler + <pinotree> too much memory required during linking? or ram+swap should have + been enough? + <braunr> there is a lot of swap, i doubt it + <braunr> the hurd is such a dumb and impressive system at the same time + <braunr> pinotree: what does this tell you ? + <braunr> git: hurdsig.c:948: post_signal: Unexpected error: (os/kern) + failure. + <pinotree> something samuel spots often during the builds of haskell + packages + +Probably also the *sigpost* case mentioned in [[!message-id +"87bol6aixd.fsf@schwinge.name"]]. + + <braunr> actually i should be asking jkoenig + <braunr> it seems the lack of memory has a strong impact on signal delivery + <braunr> which is bad + <antrik> braunr: I have a vague recollection of slpz also saying something + about missing dirty page tracking a while back... I might be confusing + stuff though + <braunr> pinotree: yes it happens often during links + <braunr> which makes sense + <pinotree> braunr: "happens often" == "hurdsig.c:948: post_signal: ..."? + <braunr> yes + <pinotree> if you can reproduce it often, what about debugging it? :P + <braunr> i mean, the few times i got it, it was often during a link :p + <braunr> i'd rather debug the pageout deadlock :( + <braunr> but it's hard diff --git a/open_issues/lsof.mdwn b/open_issues/lsof.mdwn new file mode 100644 index 00000000..2cbf2302 --- /dev/null +++ b/open_issues/lsof.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +We don't have a `lsof` tool. Perhaps we could cook something with having a +look at which ports are open at the moment (as [[`portinfo`|hurd/portinfo]] +does, for example)? diff --git a/open_issues/ltrace.mdwn b/open_issues/ltrace.mdwn new file mode 100644 index 00000000..cf0df759 --- /dev/null +++ b/open_issues/ltrace.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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. + + <youpi> it'd be good to have ltrace eventually + <youpi> rpctrace has too many issues to be usable + <youpi> (and a lot of them are hard to fix iirc) + <youpi> ltrace traces library calls + <youpi> in principle it should just work at the dynamic linker stage, so should be portable diff --git a/open_issues/m4_vs_stack.mdwn b/open_issues/m4_vs_stack.mdwn new file mode 100644 index 00000000..c92cfb00 --- /dev/null +++ b/open_issues/m4_vs_stack.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009 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_porting]] + + m4 (1.4.13-1+hurd.2) unreleased; urgency=low + + * Drop stack overflow (checks/stackovf) check, test-c-stack and + test-c-stack2 checks, and /dev/null/ (test-open and test-fopen) checks. + + -- Samuel Thibault <samuel.thibault@ens-lyon.org> Tue, 18 Aug 2009 20:54:30 +0000 + + <youpi> that was a quick fix (as not having m4 makes autoconf uninstallable, which is quite a problem) + <youpi> there's probably something wrong in the stack management of the Hurd, I haven't investigated diff --git a/open_issues/mach-defpager_debugging.mdwn b/open_issues/mach-defpager_debugging.mdwn new file mode 100644 index 00000000..33e717d9 --- /dev/null +++ b/open_issues/mach-defpager_debugging.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2011, 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_gdb]] + +IRC, freenode, #hurd, 2011-11-10: + + <mcsim> hello. Is there any way to debug mach-defpager? When I set + breakpoint to any function in it, pager never breaks. + +IRC, freenode, #hurd, 2011-11-11: + + <mcsim> hello. I've read that hde tried to debug defpager and wrote some + patches for debugging defpager, but I couldn't find them. Does anybody + know are these patches in public? diff --git a/open_issues/mach-defpager_malloc_hook.mdwn b/open_issues/mach-defpager_malloc_hook.mdwn new file mode 100644 index 00000000..2bbff75a --- /dev/null +++ b/open_issues/mach-defpager_malloc_hook.mdwn @@ -0,0 +1,14 @@ +[[!meta copyright="Copyright © 2011 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 open_issue_hurd]] + +*malloc hooks* are used in `[hurd]/mach-defpager/kalloc.c`. But their use is +deprecated (glibc 7d17596c198f11fa85cbcf9587443f262e63b616). diff --git a/open_issues/mach-defpager_swap.mdwn b/open_issues/mach-defpager_swap.mdwn new file mode 100644 index 00000000..7d3b001c --- /dev/null +++ b/open_issues/mach-defpager_swap.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 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_gnumach]] + +[[!toc]] + + +# IRC, OFTC, #debian-hurd, 2012-06-16 + + <lifeng> I allocated a 5GB partition as swap, but hurd only found 1GB + <youpi> use 2GiB swaps only, >2Gib are not supported + <youpi> (and apparently it just truncates the size, to be investigated) diff --git a/open_issues/mach-defpager_vs_defpager.mdwn b/open_issues/mach-defpager_vs_defpager.mdwn new file mode 100644 index 00000000..f03bc67f --- /dev/null +++ b/open_issues/mach-defpager_vs_defpager.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2010, 2011 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_gnumach open_issue_hurd]] + +IRC, freenode, #hurd, end of May/beginning of June 2010 + + <cfhammar> whats the difference between mach-defpager and defpager? + <cfhammar> i'm guessing defpager is a hurdish version that uses libstore + but was never finished or something + <cfhammar> found an interesting thread about it: + http://mirror.libre.fm/hurd/list/msg01232.html + <slpz> antrik: an interesting thread, indeed :-) + <pochu> slpz: btw is mach-defpager linked statically but not called + mach-defpager.static on purpose? + <slpz> antrik: also, I can confirm that mach-defpager needs a complete + rewrite ;-) + <slpz> pochu: I think the original defpager was launched by serverboot + <slpz> pochu: that could be the reason to have it static, like ext2fs + <slpz> and since there's no need to execute it again during the normal + operation of the system, they probably decided to not create a + dynamically linked version + <slpz> (but I'm just guessing) + <slpz> of perhaps they wanted to prevent mach-defpager from the need of + reading libraries, since it's used when memory is really scarce (guessing + again) diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn new file mode 100644 index 00000000..c14ce95a --- /dev/null +++ b/open_issues/mach_migrating_threads.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +<http://www.brynosaurus.com/pub/os/thread-migrate.pdf> + + * [[microkernel/mach/memory_object/discussion]] + + * [[resource_management_problems]] diff --git a/open_issues/mach_on_top_of_posix.mdwn b/open_issues/mach_on_top_of_posix.mdwn new file mode 100644 index 00000000..7574feb0 --- /dev/null +++ b/open_issues/mach_on_top_of_posix.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="Mach on Top of POSIX"]] + +[[!tag open_issue_gnumach]] + +At the beginning of the 2000s, there was a *Mach on Top of POSIX* port started +by John Edwin Tobey. Status unknown. Ask [[tschwinge]] for the source code. diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn new file mode 100644 index 00000000..9abb7639 --- /dev/null +++ b/open_issues/mach_tasks_memory_usage.mdwn @@ -0,0 +1,147 @@ +[[!meta copyright="Copyright © 2011 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_documentation]] + +IRC, freenode, #hurd, 2011-01-06 + + <antrik> hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but + the sum of all RSS is <300 MiB... what's the rest? + <braunr> kernel memory ? + <braunr> the zone allocator maybe + <braunr> or the page cache simply + <antrik> braunr: which page cache? AIUI, caches are implemented by the + individual filesystem servers -- in which case any memory used by them + should show up in RSS + <antrik> also, gnumach is listed among other tasks, so I'd assume the + kernel memery also to be accounted for + <braunr> antrik: no, the kernel maintains a page cache, very similar to + what is done in Linux, and almost the same as in FreeBSD + <braunr> the file system servers are just backing stores + <braunr> the RSS for the gnumach tasks only includes kernel memory + <braunr> I don't think the page cache is accounted for + <braunr> because it's not really kernel memory, it's a cache of user space + memory + <antrik> apparently my understanding of Mach paging is still (or again?) + rather incomplete :-( + <antrik> BTW, is there any way to find out how much anonymous memory a + process is using? the "virtual" includes discardable mappings, and is + thus not very helpful... + <antrik> (that applies to Linux as well though) + <braunr> can you provide an example of the output of vmstat please ? + <braunr> I don't have a Hurd VM near me + <antrik> olaf@alien:~$ vmstat + <antrik> pagesize: 4K + <antrik> size: 501M + <antrik> free: 6.39M + <antrik> active: 155M + <antrik> inactive: 310M + <antrik> wired: 29.4M + <antrik> zero filled: 15.3G + <antrik> reactivated: 708M + <antrik> pageins: 3.43G + <antrik> pageouts: 1.55G + <antrik> page faults: 26844574 + <antrik> cow faults: 3736174 + <antrik> memobj hit ratio: 92% + <antrik> swap size: 733M + <antrik> swap free: 432M + <antrik> interesting... closing a single screen window temporarily raises + the "free" value by almost 10 MB + <antrik> I guess bash is rather hungry nowadays ;-) + <braunr> antrik: I guess the only way is using pmap or looking into + /proc/<pid>/maps + <braunr> but it won't give you the amount of physical memory used by + anonymous mappings + <antrik> nah, I don't even want that... just like to know how much memory + (RAM+swap) a process is really using + <braunr> antrik: then the RSS field is what you want + <antrik> OTOH, anonymous doesn't include program code or other actively + used mappings... so not very useful either + <antrik> nah, RSS doesn't count anything that is in swap + <braunr> well + <braunr> don't you have a SWAP column ? + <braunr> hm + <braunr> i guess not + <braunr> antrik: why do you say it doesn't include other actively used + mappings ? + <braunr> antrik: and the inclusion of program code also depends on the + implementation of the ELF handler + <braunr> I don't know how the hurd does that, but some ELF loaders use + anonymous memory for the execution view + <antrik> well, if a program maps a data file, and regularily accesses parts + of the file, they won't occupy physical RAM all the time (and show up in + RSS), but they are not anonymous mappings. similar to program code + <braunr> then this anonymous memory is shared by all processes using that + code + <antrik> oh, interesting + <antrik> is it really a completely distinct mapping, rather than just COW? + <braunr> the first is + <braunr> others are COW + <antrik> so if a program loads 200 MB of libraries, they are all read in on + startup, and occupy RAM or swap subsequently, even if most of the code is + never actually run?... + <kilobug> library code should be backed by the library file on disk, not be + swap + <braunr> depends on the implementation + <braunr> I guess most use the file system backend + <braunr> but in the Hurd, ext2fs.static and ld.so.1 use anonymous memory + <braunr> (that's the case for another reason, still, I don't think the + report in top/ps clearly indicates that fact) + <kilobug> braunr: yeah for bootstrapping issues, makes sense + <braunr> it may also depends on the pic/pie options used when building + libraries + + +IRC, freenode, #hurd, 2011-07-24 + + < braunr> the panic is probably due to memory shortage + < braunr> so as antrik suggested, use more swap + < antrik> gg0: you could run "vmstat 1" in another terminal to watch memory + usage + < antrik> that way we will know for sure whether it's related + < braunr> antrik: it's trickier than that + < braunr> it depends if the zones used are pageable + < antrik> braunr: well, if it's a zone map exhaustion, then the swap size + won't change anything?... + < braunr> antrik: in this case no, but if the zone is pageable and the + pager (backing anonymous memory) refuses to create memory because it + estimates it's full (all swap space is reserved), it will fail to + < braunr> too + < braunr> but i don't think there are much pageable zones in the kernel + < antrik> yes, but in that case we can see the exhaustion in vmstat :-) + < braunr> many* + < braunr> i'm not sure + < braunr> reserved swap space doesn't mean it's used + < braunr> that's one of the major changes in freebsd 4 or 5 i was + mentioning + < antrik> if it's reserved, it wouldn't show up as "free", would it?... + < braunr> (btw, it's also what makes anonymous memory merging so hard) + < braunr> yes it would + < braunr> well, it could, i'm not sure + < braunr> anonymous memory is considered as a file + < braunr> one big file filled with zeroes, which is the swap partition + < braunr> when you allocate pageable anonymous memory, a part of this + "file" is reserved + < braunr> but i don't know if the reported number if the reserved + (allocated) space, or used (actually containing data) + < braunr> is* + < braunr> i also suspect wired allocations can fail because of a full swap + (because the kernel is unable to make free pages) + < braunr> in this case vmstat will show it + < antrik> what does it matter whether there is data there or not? if it's + reserved, it's not free. if it behaves differently, I'd consider that a + serious bug + < braunr> maybe the original developers intended to monitor its actual + usage + < braunr> antrik: i've just checked how the free count gets updated, and it + looks like it is on both seqnos_memory_object_data_initialize and + seqnos_memory_object_data_write + < braunr> antrik: so i guess reserved memory is accounted for diff --git a/open_issues/mach_vm_pageout.mdwn b/open_issues/mach_vm_pageout.mdwn new file mode 100644 index 00000000..dac7fe28 --- /dev/null +++ b/open_issues/mach_vm_pageout.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +IRC, freenode, #hurd, 2011-09-09 + + <slpz> It's amazing how broken some parts of Mach's VM are + <slpz> currently, it doesn't even keep track of the number of external + pages in the lists + <slpz> and vm_pageout_scan produces a hang if want_pages == FALSE (which + never is, because vm_page_external_count is always 0) diff --git a/open_issues/magic_translator_machtype.mdwn b/open_issues/magic_translator_machtype.mdwn new file mode 100644 index 00000000..1c62b762 --- /dev/null +++ b/open_issues/magic_translator_machtype.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2008, 2010 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]]."]]"""]] + +[[!meta title="/hurd/magic machtype"]] + +[[!tag open_issue_hurd open_issue_glibc]] + + tschwinge@clubber:~ $ settrans -ca machtype /hurd/magic machtype + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. + thomas@dirichlet:~ $ ssh clubber + Warning: Permanently added '[clubber.bddebian.com]:2251' (RSA) to the list of known hosts. + Last login: Tue Dec 30 08:52:58 2008 from dslb-084-057-196-016.pools.arcor-ip.net + tschwinge@clubber:~ $ cat machtype + Segmentation fault + tschwinge@clubber:~ $ l machtype + Segmentation fault + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. diff --git a/open_issues/memory_object_model_vs_block-level_cache.mdwn b/open_issues/memory_object_model_vs_block-level_cache.mdwn new file mode 100644 index 00000000..7da5dea4 --- /dev/null +++ b/open_issues/memory_object_model_vs_block-level_cache.mdwn @@ -0,0 +1,273 @@ +[[!meta copyright="Copyright © 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_documentation open_issue_hurd open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-02-14 + + <slpz> Open question: what do you think about dropping the memory object + model and implementing a simple block-level cache? + +[[microkernel/mach/memory_object]]. + + <kilobug> slpz: AFAIK the memory object has more purpose than just cache, + it's allow used for passing chunk of data between processes, handling + swap (which similar to cache, but still slightly different), ... + <slpz> kilobug: user processes usually make their way to data with POSIX + operations, so memory objects are only needed for mmap'ed files + <slpz> kilobug: and swap can be replaced for an in-kernel system or even + could still use the memory object + <braunr> slpz: memory objects are used for the page cache + <kilobug> slpz: translators (especially diskfs based) make heavy use of + memory objects, and if "user processes" use POSIX semantics, Hurd process + (translators, pagers, ...) shouldn't be bound to POSIX + <slpz> braunr: and page cache could be moved to a lower level, near to the + devices + <braunr> not likely + <braunr> well, it could, but then you'd still have the file system overhead + <slpz> kilobug: but the use of memory objects it's not compulsory, you can + easily write a fs translator without implementing memory objects at all + (except to mmap) + <braunr> a unified buffer/VM cache as all modern systems have is probably + the most efficient approach + <slpz> braunr: I agree. I want to look at *BSD/Linux vfs systems to seem + how much cache policy depends on the filesystem + <slpz> braunr: Are you aware of any good papers on this matter? + <braunr> netbsd UVM, the linux virtual memory system + <braunr> both a bit old bit still relevant + <slpz> braunr: Thanks. + <slpz> the problem in our case is that having FS and cache information at + different contexts (kernel vs. translator), I find hard to coordinate + them. + <slpz> that's why I though about a block-level cache that GNU Mach could + manage by itself + <slpz> I wonder how QNX deals with this + <braunr> the point of having a simple page cache is explicitely about not + caring if those pages are blocks or files or whatever + <braunr> the kernel (at least, mach) normally has all the accounting + information it needs to implement its cache policy + <braunr> file system translators shouldn't cache much + <braunr> the pager interface could be refined, but it looks ok to me as it + is + <slpz> Mach has the accounting info, but it's not able to purge the cache + without coordination with translators + <braunr> which is normal + <slpz> And this is a big problem when memory pressure increases, as it + doesn't know for sure when memory is going to be freed + <braunr> Mach flushes its cache when it decides to, and sends back dirty + pages if needed by the pager + <braunr> that's the case with every paging implementation + <braunr> the main difference is security with untrusted pagers + <braunr> but that's another issue + <slpz> but in a monolithic implementation, the kernel is able for force a + chunk of cache memory to be freed without hoping for other process to do + the job + <braunr> that's not true + <braunr> they're not process, they're threads, but the timing issue is the + same + <braunr> see pdflush on linux + <slpz> no, it isn't. + <braunr> when memory is scarce, threads that request memory can either wait + or immediately fail, and if they wait, they're usually woken by one of + the vm threads once flushing is done + <slpz> a kernel thread can access all the information in the kernel, and + synchronization is pretty easy. + <braunr> on mach, synchronization is done with messages, that's even easier + than shared kernel locks + <slpz> with processes in different spaces, resource coordination becomes + really difficult + <braunr> and what kind of info would an external pager need when simply + asked to take back its dirty pages + <braunr> what resources ? + <slpz> just take a look at the thread storm problem when GNU Mach needs to + clean a bunch of pages + <braunr> Mach is big enough to correctly account memory + <braunr> there can be thread storms on monolithic systems + <braunr> that's a Mach issue, not a microkernel issue + <braunr> that's why linux limits the number of pdflush thread instances + <slpz> Mach can account memory, but can't assure when be freed by any + means, in a lesser degree than a monolithic system + <braunr> again i disagree + <braunr> no system can guarantee when memory will be freed with paging + <slpz> a block level cache can, for most situations + <braunr> slpz: why ? + <braunr> slpz: or how i mean ? + <slpz> braunr: with a block-level page cache, GNU Mach should be able to + flush dirty pages directly to the underlaying device without all the + complexity and resource cost involved in a m_o_data_return message. It + can also throttle the rate at which pages are being cleaned, and do all + this while blocking new page allocations to deal with memory exhaustion + cases. + <slpz> braunr: in the current state, when cleaning dirty pages, GNU Mach + sends a bunch on m_o_data_return to the corresponding pagers, hoping they + will do their job as soon and as fast as possible. + <slpz> memory is not really freed, but transformed from page cache to + anonymous memory pertaining to the corresponding translator + <slpz> and GNU Mach never knows for sure when this memory is released, if + it ever is. + <slpz> not being able to flush dirty pages synchronously is a big problem + when you need to throttle memory usage + <slpz> and needing allocating more memory when you're trying to free (which + is the case for the m_o_data_return mechanism) makes the problem even + worse + <braunr> your idea of a block level cache means in kernel block drivers + <braunr> that's not the direction we're taking + <braunr> i agree flushing should be a synchronous process, which was one of + the proposed improvements in the thread migration papers + <braunr> (they didn't achieve it but thought about it for future works, so + that the thread at the origin of the fault would handle it itself) + <braunr> but it should be possible to have kernel threads similar to + pdflush and throttle flush requests too + <braunr> again, i really think it's a mach bug, and having a buffer cache + would be stepping backward + <braunr> the real design issue is allocating memory while trying to free + it, yes + <slpz> braunr: thread migration doesn't apply to asynchronous IPC, and the + entire paging mechanism is implemented this way + <slpz> in fact, trying to do a synchronous m_o_data_return will trigger a + deadlock for sure + <slpz> to achieve synchronous flushing with translators, the entire paging + model must be redesigned + <slpz> It's true that I'm not very confident of the viability of user space + drivers + <slpz> at least, not for every device + <slpz> I know this is against the current ideas for most ukernel designs, + but if we want to achieve real work functionality, I think some + sacrifices must be done. Or at least a reasonable compromise. + <braunr> slpz: thread migration for paging requests implies synchronous + RPC, we don't care much about the IPC layer there + <braunr> and it requires large changes of the VM code in addition, yes + <braunr> let's not talk about this, we don't have thread migration anyway + :p + <braunr> except the allocation-on-free-path issue, i really don't see how + the current pager interface or the page cache creates problems wrt + flushing .. + <braunr> monolithic systems also have that problem, with lower impacts + though, but still + <slpz> braunr: because as it doesn't know when memory is really freed, 1) + it just blindly sends a bunch of m_o_data_return to the pagers, usually + overloading them (causing thread storms), and 2) it can't properly + throttle new page requests to deal with resource exhaustion + <braunr> it does know when memory is really freed + <braunr> and yes, it blindly sends a bunch of requests, they can and should + be trottled + <slpz> but dirty pages freed become indistinguishable from common anonymous + chunks released, so it doesn't really know if page flushes are really + working or not (i.e. doesn't know how fast a device is processing write + requests) + <braunr> memory is freed when the pager deallocates it + <braunr> the speed of the operation is irrelevant + <braunr> no system can rely on disk speed to guarantee correct page flushes + <braunr> disk or anything else + <slpz> requests can't be throttled if Mach doesn't know when they are being + processed + <braunr> it can easily know it + <braunr> they are processed as soon as the request is sent from the kernel + <braunr> and processing is done when the pager acknowledges the end of the + flush + <braunr> memory backing the flushed pages should be released before + acknowleding that to avoid starting new requests too soon + <slpz> AFAIK pagers doesn't acknowledge the end of the flush + <braunr> well that's where the interface should be refined + <slpz> Mach just sends the m_o_data_return and continues on its own + <braunr> that's why flushing should be synrhconous + <braunr> are you sure about that however ? + <slpz> so the entire paging system needs a new design... :) + <slpz> pretty sure + <braunr> not a new design .. + <braunr> there is m_o_supply_completed, i don't see how difficult it would + be to add m_o_data_return_completed + <braunr> it's not a small change, but not a difficult one either + <braunr> i'm more worried about the allocation problem + <braunr> the default pager should probably be wired in memory + <braunr> maybe others + <slpz> let's suppose a case in which Mach needs to free memory due to an + increase in its pressure. vm_pageout_daemon starts running, clean pages + are freed easily, but for each dirty one a m_o_data_return in sent. 1) + when should this daemon stop sending m_o_data_return and start waiting + for m_o_data_return_completed? 2) what happens if the translator needs to + read new blocks to fulfill a write request (pretty common in ext2fs)? + <braunr> it should stop after an arbitrary limit is reached + <braunr> a reasonable one + <braunr> linux limits the number of pdflush threads for that reason as i + mentioned (to 8 iirc) + <braunr> the problem of reading blocks while flushing is what i'm worried + about too, hence the need to wire that code + <braunr> well, i'm nto sure it's needed + <braunr> again, a reasonable about of free memory should be reserved for + that at all times + <slpz> but the work for pdflush seems to be a lot easier, as it only deals + directly with block devices (if I understood it correctly, I just started + looking at it). + <braunr> i don't know how other systems compute that, but this is how they + seem to do as well + <braunr> no, i don't think so + <slpz> well, I'll try to invest a few days understanding how pdflush work, + to see if some ideas can be borrowed for Hurd + <braunr> iirc, freebsd has thresholds in percent for each part of its cache + (active, inactive, free, dirty) + <slpz> but I still think simple solutions work better, and using the memory + object for page cache is tremendously complex. + <braunr> the amount of free cache pages is generally sufficient to + guarantee much memory can be released at once if needed, without flushing + anything + <braunr> yes but that's the whole point of the Mach VM + <braunr> and its greatest advance .. + <slpz> what, memory objects? + <braunr> yes + <braunr> using physical memory as a cache for anything, not just block + buffers + <slpz> memory objects work great as a way to provide a shared image of + objects between processes, but as page cache they are an overkill (IMHO). + <slpz> or, at least, in the way we're using them + <braunr> probably + <braunr> http://lwn.net/Articles/326552/ + <braunr> this can help udnerstand the problems we may have without better + knowledge of the underlying devices, yes + <braunr> (e.g. not being able to send multiple requests to pagers that + don't share the same disk) + <braunr> slpz: actually i'm not sure it's that overkill + <braunr> the linux vm uses struct vm_file to represent memory objects iirc + <braunr> there are many links between that structure and some vfs related + subsystems + <braunr> when a system very actively uses the page cache, the kernel has to + maintain a lot of objects to accurately describe the cache content + <braunr> you could consider this overkill at first too + <braunr> the mach way of doing it just implies some ipc messages instead of + function calls, it's not that overkill for me + <braunr> the main problems are recursion (allocation while freeing, + handling page faults in order to handle flushes, that sort of things) + <braunr> struct file and struct address_space actually + <braunr> slpz: see struct address_space, it contains a set of function + pointers that can help understanding the linux pager interface + <braunr> they probably sufferred from similar caveats and worked around + them, adjusting that interface on the way + <slpz> but their strategy makes them able to treat the relationship between + the page cache and the block devices in a really simple way, almost as a + traditional storage cache. + <slpz> meanwhile on Mach+pager scenario, the relationship between a block + in a file and its underlying storage becomes really blurry + <slpz> this is a huge advantage when flusing out data, specially when + resources are scarce + <slpz> I think the idea of using abstract objects for page cache, loses a + bit the point that we just want to avoid accessing constantly to a slow + device + <slpz> and breaking the tight relationship between the device and its + cache, makes things a lot harder + <slpz> this also manifest itself when flushing clean pages, as things like + having an static maximum for cached memory objects + <slpz> we shouldn't care about the number of objects, we just need to + control the number of pages + <slpz> but as we need the pager to flush pages, we need to keep alive a lot + of control ports to them + <mcsim> slpz: When mo_data_return is called, once the memory manager no + longer needs supplied data, it should be deallocated using + vm_deallocate. So this way pagers acknowledges the end of flush. diff --git a/open_issues/metadata_caching.mdwn b/open_issues/metadata_caching.mdwn new file mode 100644 index 00000000..f7f4cb53 --- /dev/null +++ b/open_issues/metadata_caching.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011, 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_gnumach open_issue_hurd]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2012-07-08 + + <braunr> youpi: there is still quite a lot of I/O even for cached objects + <braunr> youpi: i strongly suspect these are for the metadata + <braunr> i.e. we don't have a "buffer cache", only a file cache + <braunr> (gnu is really not unix lol) + <youpi> doesn't ext2fs cache these? + <youpi> (as long as the corresponding object is cached + <youpi> ) + <braunr> i didn't look too much, but if it does, it does a bad job + <braunr> i would guess it does, but possibly only writethrough + <youpi> iirc it does writeback + <youpi> there's a sorta "node needs written" flag somewhere iirc + <braunr> but that's for the files, not the metadata + <youpi> I mean the metadata of the node + <braunr> then i have no idea what happens diff --git a/open_issues/mig_error_reply.mdwn b/open_issues/mig_error_reply.mdwn new file mode 100644 index 00000000..21a5b217 --- /dev/null +++ b/open_issues/mig_error_reply.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 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_mig]] + +\#hurd, freenode, 2010-05-19 + + <cfhammar> ugh, mig server stubs generated from *_reply.defs don't call the server functions when the reply is an error, since the message size is too small... + <cfhammar> term seems to get around it by turning of type checking + <cfhammar> s/of/off + <cfhammar> but streamio doesn't + <cfhammar> luckily the only other program that makes use of a *_reply.defs is crash, and crash_reply.defs' routines only return an error code so it isn't affected + <slpz> cfhammar: could you point me to a stub with that problem? + <cfhammar> slpz: trans/device_replyServer.c:_Xdevice_open_reply (in build dir) + <slpz> cfhammar: So, if I understand it correctly, the problem is that GNU Mach generated stub doesn't properly set the size of the message if there's an error in the function, thus the type checking in user generated stub discards the reply + <cfhammar> slpz: the size is correct, error messages contain just a return value + <cfhammar> slpz: it is the type checking that is at fault imho + <slpz> cfhammar: even when a server wants to return an error, the size of the message should be the same as the reply structure previously defined + <slpz> cfhammar: on the other hand, I can't understand why streamio is using device_open_request (async RPC) instead of device_open (sync RPC)... + <cfhammar> slpz: the server does not always know the proper size, e.g. when it doesn't understand the message + <slpz> cfhammar: what do you mean by "doesn't understand the message"? + <cfhammar> slpz: if it doesn't implement that interface or is the wrong type, etc. + <cfhammar> slpz: in that case the mig stub needs to send out a generic error reply + <cfhammar> slpz: i don't know why streamio uses it either + <slpz> cfhammar: OK, now I see your point. If the server answers with a generic error code (as MIG_*), device_open_reply will not be called, and device_open_request doesn't get an error. + <slpz> cfhammar: good catch :-) + <cfhammar> slpz: all errors are handled the same way, MIG_* is just an example of why it does so + <slpz> cfhammar: on an unrealted note, I think we should get rid of all asynchronous messages sent from the user to the kernel, since they aren't asynchronous except for sending the reply to a different port (the process is really done by the thread calling mach_msg) + <cfhammar> slpz: i'm not not all that familiar with the low-level parts of message passing so i can't really comment + <slpz> cfhammar: in that point I disagree. If the server function can understand the message (so there isn't a MIG_* error), it can send a reply message with the proper size + <cfhammar> slpz: it could, but what is the advantage if we still need to handle generic errors? + <cfhammar> slpz: "sending the reply to a different port", different from what? + <slpz> cfhammar: to differentiate between message marshalling errors and errors generated by the called function + <slpz> cfhammar: in a synchronous RPC, the same call to mach_msg will send the request and receive the reply by providing a mig generated reply port + <slpz> cfhammar: but in an asynchronous, the reply is received by a port previously generated by the function requesting the message + <cfhammar> slpz: ah, that's a clever optimization + <slpz> cfhammar: if the "asynchronous" message is sent to the kernel, the thread calling for mach_msg will execute the server's function, but the reply will be sent to one of these previously generated ports + <slpz> cfhammar: actually you have a synchronous operation replying to a different port. That doesn't make much sense to me :-) + <antrik> slpz: note that most kernel functions can be implemented by userspace servers, in which case they could be really async... + <cfhammar> slpz: not sure how differentiating mig errors from server errors is useful... + <slpz> antrik: define "most kernel functions" ;-) + <cfhammar> slpz: if nothing else kernel rpcs can be proxied, e.g. rpctrace + <slpz> cfhammar: well, think of device_open_request. If the result is not a mig error, you can still device_open_reply an expect it to properly process the return code from the message + <cfhammar> slpz: it should be able to handle all kinds of errors anyway, the result should be the same as with syncronous rpcs + <slpz> cfhammar: yes, you're right. User generated stub should be able to fill the reply with the error code and call to the reply function. + <slpz> cfhammar: Then someone needs to introduce some changes in MiG's magic... + <cfhammar> slpz: yes, a flag to generate reply side of an interface would be ideal + <cfhammar> slpz: then we could toss out *_reply.defs altogether + <slpz> cfhammar: well, that's a different change from what I was thinking + <cfhammar> slpz: how would you change it? + <slpz> cfhammar: just generating stubs which, in case of error, will properly call to the reply function with the error code in its arguments + <cfhammar> slpz: ah yes, i considered that as well, but i don't think mig can actually distinguish the error code from any other int argument + <cfhammar> slpz: i should double check it though + <slpz> cfhammar: I tag can be used to point to argument of this nature + <slpz> cfhammar: s/I/A/ + <cfhammar> slpz: oh, it already is tagged with retcode, intresting + <slpz> cfhammar: OMG, I'm thinking like MiG! ;-P + <cfhammar> slpz: is that a good or bad ; + <cfhammar> slpz: ;-) + <slpz> cfhammar: I don't know, but it's somewhat scary ;-) + <cfhammar> slpz: apparently retcode is only there for comatibility, mig just ignores it... diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn new file mode 100644 index 00000000..084d7454 --- /dev/null +++ b/open_issues/mig_portable_rpc_declarations.mdwn @@ -0,0 +1,58 @@ +[[!meta copyright="Copyright © 2011 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_mig]] + + +# IRC, freenode, #hurd, 2011-11-14 + + <braunr> also, what's the best way to deal with types such as + <braunr> type cache_info_t = struct[23] of integer_t; + <braunr> whereas cache_info_t contains longs, which are obviously not + integer-wide on 64-bits processors + <braunr> ? + <youpi> you mean, to port mach to 64bit? + <braunr> no, to make the RPC declaration portable + <braunr> just in case :) + <youpi> refine integer_t into something more precise + <youpi> such as size_t, off_t, etc. + <braunr> i can't use a single line then + <braunr> struct cache_info contains ints, vm_size_t, longs + <braunr> should i just use the maximum size it can get ? + <braunr> or declare two sizes depending on the word size ? + <youpi> well, I'd say three + <braunr> youpi: three ? + <youpi> the ints, the vm_size_ts, and the longs + <braunr> youpi: i don't get it + <braunr> youpi: how would i write it in mig language ? + <youpi> I don't know the mig language + <braunr> me neither :) + <youpi> but I'd say don't lie + <braunr> i just see struct[23] of smething + <braunr> the original zone_info struct includes both integer_t and + vm_size_t, and declares it as + <braunr> type zone_info_t = struct[9] of integer_t; + <braunr> in its mig defs file + <braunr> i don't have a good example to reuse + <youpi> which is lying + <braunr> yes + <braunr> which is why i was wondering if mach architects themselves + actually solved that problem :) + <braunr> "There is no way to specify the fields of a + <braunr> C structure to MIG. The size and type-desc are just used to + give the size of + <braunr> the structure. + <braunr> " + <braunr> well, this sucks :/ + <braunr> well, i'll do what the rest of the code seems to do, and let it + rot until a viable solution is available + <antrik> braunr: we discussed the problem of expressing structs with MIG in + the libburn thread + <antrik> (which I still need to follow up on... [sigh]) diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn new file mode 100644 index 00000000..17f148a9 --- /dev/null +++ b/open_issues/mission_statement.mdwn @@ -0,0 +1,660 @@ +[[!meta copyright="Copyright © 2011 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_documentation]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-10-12 + + <ArneBab> we have a mission statement: http://hurd.gnu.org + <Gorodish> yes + <Gorodish> but it's quite wishy washy + <Gorodish> considering all the elegant capability Hurd potentially has to + offer + <antrik> Gorodish: it's true that the mission statement is very + abstract... but then, it's hard to put anything more specific into 35 + words + <Gorodish> not with some practice + <Gorodish> I notice programers tend to speak and write in terms of what + something does + <Gorodish> not what it is + <Gorodish> the "What is Hurd" is a good example + <Gorodish> there's a lot of interesting information there + <Gorodish> but the way it's ordered is odd + <antrik> a mission statement is not primarily a PR instrument; but rather a + guide that allows separating things that benefit the common goal from + things that don't... + <antrik> I agree that some actual marketing material in addition would be + nice :-) + <Gorodish> yes + <Gorodish> the modesty of Developers that work on FOSS projects never + ceases to amaze me + <Gorodish> I agree that the informational, factual, results oriented + documentation is the primary objective of documenting + + +# IRC, freenode, #hurd, 2011-11-25 + + <antrik> heh, nice: http://telepathy.freedesktop.org/wiki/Rationale + <antrik> most of this could be read as a rationale for the Hurd just as + well ;-) + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> LibreMan: the real feature of the hurd is its extensibility + +[[/Extensibility]], [[/advantages]]. + + <braunr> LibreMan: (though it could be improved even further) + <LibreMan> braunr: yeah, I keep reading that ... but that sounds too + abstract, I can not imagine what useful could that provide to the actual + users + <braunr> LibreMan: say fuse, but improved + <braunr> LibreMan: do you see how useful fuse is ? + <braunr> if so, you shouldn't have trouble imagining the gap between linux + without fuse and linux with fuse is about the same as linux with fuse and + the hurd + <braunr> and yes, it's abstract + <braunr> translators are not only about file systems + <LibreMan> braunr: well, its main advantage is that it's running in + user-space and therefore doesn't need root priviledges to mount whatever + fs you want? + <braunr> no + <braunr> you don't need to change the kernel, or implement weird tricks to + get what you want working + <LibreMan> braunr: okay, but there is fuse for Linux ... so the + difference/advantages need to be between Linux WITH fuse and Hurd + <braunr> that's what i'm saying + <LibreMan> the issue I have is that I do not see why anyone would have any + incentive to switch to Hurd + <braunr> there isn't much, which is why we stick with unix instead of, + e.g. plan9 or other advanced systems + <pinotree> try to use fuse on a server where there is no fuse installed + <LibreMan> if I want fuse-like functionallity I just install FUSE, no need + for Hurd ... so the reson to use it is not there + <braunr> LibreMan: read what i wrote + <braunr> using the hurd compared to using linux with fuse is about the same + as using linux with fuse compared to using linux without fuse + <LibreMan> braunr: ah, sorry ... I see + <braunr> it's a step further + <braunr> in theory, developers can add/remove the components they want, + making system development faster and more reliable + <braunr> where with unix, you need stuff like user mode linux or a virtual + machine + <LibreMan> braunr: but in practice it was the opposite so far :) + <braunr> not really + <braunr> it's a lack of manpower + <braunr> not a problem of partice versus theory + <braunr> practice* + <LibreMan> braunr: what do you think are the reasons why Hurd developement + is so slow if it should be faster in theory? + +[[faq/how_many_developers]]. + + <braunr> 17:30 < braunr> it's a lack of manpower + <braunr> pay someone to do the job + <braunr> :p + <LibreMan> braunr: then why does Linux get the manpower but Hurd doesn't? + <braunr> $$ + <LibreMan> braunr: ?? + <braunr> linux developers are paid + <LibreMan> because companies are using it :) + <braunr> yes + <LibreMan> why are they not using Hurd then? + <braunr> because it wasn't reliable enough + <LibreMan> Linux wasn't either at some point + <braunr> sure + <braunr> but when it became, the switch towards its use began + <braunr> now that they have something free and already working, there is no + point switching again + <LibreMan> paid devs join only AFTER volunteers got it to the stage that it + was useful to companies + <braunr> well linux was easier to develop at the beginning (and is still + today because of several kernel hacking features) + <braunr> it followed the traditional unix model, nothing was really new + about it + <LibreMan> braunr: exactly! that's why I think that Hurd needs to have very + compelling technical advantages to overcome that barrier + <braunr> few people/companies really care about such technical advantages + <braunr> they don't care if there are ugly tricks to overcome some problems + <LibreMan> you mean about such that Hurd can provide, right? + <braunr> it's not elegant, but most of the time they're not even aware of + it + <braunr> yes + <LibreMan> that's eaxctly my point ... most people do not care if it's + "elegant" from a programmers POV, they care whether it WORKS + <braunr> well yes + <braunr> what's your point ? + <LibreMan> all I see about Hurd is how "elegant" it is ... but that doesn't + matter if it doesn't provide any practical advantages + <braunr> you want us to expose a killer feature amazing enough to make the + world use our code ? + <LibreMan> well, I want Hurd to succeed and try to identify the resons it + doesn't + <braunr> it does, but not to the point of making people use it + <braunr> unix *is* good enough + <braunr> same reason plan9 "failed" really + <LibreMan> define your idea of Hurd succeeding then, I thought it was to + make it useful to the point that people use it :) + <braunr> there are many other attempts to make better system architectures + <braunr> it is + <braunr> people are still using windows you know, and i really don't see + why, but it does the work for them + <LibreMan> <braunr> you want us to expose a killer feature amazing enough + to make the world use our code ? --- YES ;) + <braunr> other people can think about the same between unix and the hurd + <braunr> LibreMan: well too bad, there is none, because, again, unix isn't + that bad + <braunr> it doesn't prevent us from making a better system that is usable + <LibreMan> to explain my take on this - there are two kind of people, those + who care about philosophy behind software (and its consequences, FSF + etc.) and those who don't + <LibreMan> it's the job of those who do care to make the sw so good that + those who do not care switch to it = victory :) + <LibreMan> as I said the reasons I want Hurd to succeed are more + "political" than technical ... I do not know how many Hurd devs agree + with that kind of sentiment but I'd rather want a GNU project to be in + the forefront than that of a "benevolent dictator" that doesnt' really + care about user freedom + <LibreMan> from thechnical POV I agree that Linux isn't that bad ... it's + quite good, it's the "behind the scenes" stuff I do not like about it + <LibreMan> I'm kind of confused right now ... what exactly is to point of + Hurd then? I thought it was to make it good enough or better than Linux + so users start using it (privatly or corporate) + <LibreMan> is this just a research project that isn't intended to be used + by "general population"? + <braunr> LibreMan: it's an operating system project + <braunr> some people try to make it as good as it can be, but it's not easy + <braunr> it's not a pet or research only system + <LibreMan> braunr: I see what it is ... I'm struggling to see what is the + point of it being an "OS project", what's its intended purpose + <braunr> but it doesn't suit all the needs for a general OS yet + <braunr> LibreMan: a general purpose OS like most free unices + <LibreMan> what are the motivations behind making it as good as it can be + <braunr> for us developers ? + <LibreMan> yes + <braunr> for me, the architecture + <LibreMan> whe you say that linux is goos enough then what's the point? + <braunr> we can do better + <LibreMan> for you it's just a hobby that doesn't have any real goal except + challenging yourself to do it? + <braunr> because of lack of time, you could say that + <LibreMan> so you want Hurd to challenge Linux one day, right? + <braunr> challenging isn't the point + <braunr> i'd like to be able to use it for my needs + <LibreMan> well, that wasn't the right choise of word but to be better than + Linux + <braunr> again, you miss the point + <braunr> i don't care much about hurd vs linux + <LibreMan> your own needs, so you do not want others to use it? + <braunr> i care about the hurd and what i do + <braunr> others would think the same + <braunr> they would want it to work for their needs + <LibreMan> I'm asking about you, do YOU want others to use it? is that one + of your goals? + <braunr> not really + <braunr> i let them do what they want + <LibreMan> ah I see, so it is kind of a hobby project for you - you're + doing to for yourself and your own needs + <LibreMan> and don't care if anyone else uses it or not + <braunr> yes, i don't care much about the politics around such projects tb + <braunr> tbh + <LibreMan> is this kind of sentiment prevalent is the Hurd dev community? + <braunr> i don't work on software to break any benevolent dictator or + anyone in particular + <braunr> i don't know + <braunr> i'd say so, yes + <braunr> but not sure + <braunr> i'm not saying they don't care about freedom, don't get me wrong + <braunr> i'd say we sure prefer free software over open source + <braunr> but i don't think people work on the hurd specifically for these + reasons, rather than the technical ones + <LibreMan> interesting ... from the presentation of the project by + outsiders I got the impression that it is significantly about freedom, + GNU - that those are the main drivers + <braunr> if it really was so, we would have grabbed a bsd variant, + relicenced it with GPLv3, and call it FreeGNU or NetGNU + <LibreMan> and that's how I approached the project ... maybe I was wrong, + I'm kind of disappointed if that's so :) I care about those things a + great deal, in fact that's the only reason I care about Hurd really + + <lcc> the hurd is designed to offer more freedom, in various ways, to the + user. freedom from the admin. + <lcc> right? + <braunr> lcc: that's embedded in the term "extensibility", yes + <braunr> lcc: but there are technical solutions for that on other systems + as well now + + <antrik> as for the Hurd, people who said they are interested in it only + because of freedom aspects *never* contributed anything significant + <antrik> *all* serious contributors are motivated at least equally by the + technical merits; often more + <antrik> (though the fact that it's a GNU project is what has brought many + developers here in the first place...) + <LibreMan> antrik: I would phrase it the other way - why do people who have + contributed significantly not care about freedom that much? or ... how do + you know they don't? + <antrik> most of us *do* care about freedem. but it's not our primary + motivation. the freedom aspects are just not strong enough to motivate + anyone alone + <antrik> as braunr already pointed out, if the sole purpose was creating a + GNU kernel, there would be *much* more promising venues for that + <LibreMan> I do not think so ... if you someone where to just take BSD and + rebrand it as AWSOMEnewGNUkernel it wouldn't be looked upon too favorably + <LibreMan> there is an honor aspect to it, to have something developed by + the community that stands by it + <LibreMan> so I do not think it would work + <antrik> BSD has forked countless times, and several of these forks became + very popular. I don't see why a GNU one shouldn't do well enough + <antrik> bat that's beside the point. writing a new boring monolithic + UNIX-like kernel from scratch is not that hard + <antrik> (as Linus has proven, amonst others...) + <antrik> if the sole purpose would be having a GNU kernel, I'd be strongly + advocating writing a new monolithic kernel from scratch + <LibreMan> antrik: ah, snap! not that hard you say? with all the features + Linux has? sure, it's not hard to make a kernel that barely boots but + that's not the point, is it? :) + <antrik> (yes, even now, with the Hurd being almost usable, I still think + it would be easier to get a new monolithic kernel to production quality) + <LibreMan> antrik: and here is was braunr who was pitching extensibility + and faster developement of Hurd as its advantage - and here you come + saying that it would be easier to write monolithic kernel from scratch + <LibreMan> get your story striaght guys ;) + <antrik> the Hurd makes it easier to develop new features. it's not easier + to get it production-ready in the first place + <LibreMan> antrik: what's the difference of developing a feature that makes + it "production ready" and another one that make it "production ready" for + a different use? + <antrik> features don't make a system production ready + <LibreMan> what makes a system production ready? + <LibreMan> what do you consider a "production"? + <antrik> supporting enough use cases that a non-trivial number of users + have their needs covered; and being stable enough that it's not annoying + to use + <LibreMan> either it is easier to develop or it isn't ... either it is + modular from it's core or it isn't + <antrik> well, not only stable enough, but also performant, secure etc. + <antrik> wrong + <LibreMan> are you saying that the fruits of its modularity will show only + after enough modules have been written? + <antrik> a modular system with strong isolation is inherently more + complicated to get right + <LibreMan> that sure is a weird argument to make ... + <LibreMan> right ... but when you get it right, the further development is + much easier? + <antrik> depends. making fundamental changes to how the system works will + always be tricky. but adding new stuff that doesn't require fundamental + changes, building on the existing foundations, is way easier + <antrik> we believe that once we have the fundamentals mostly right, most + things people will be adding will fall into the latter catogory + <antrik> category + <LibreMan> o what's missing to Hurd before it "got it right" and the fast + pace development kicks in? + <antrik> but so far most of the work is in the former category, meaning + progress is slow + <LibreMan> because from readin the site it seems the core is pretty much + done ... what it needs are all the translators, drivers, user-space tools + to make use of that core - is that impression wrong? + <antrik> you are missing the point. there is no unified "development pace" + measurement. it is easier to add certain things right now. but to get the + system production ready, it still requires considerable work on the hard + parts + <antrik> well, it's not as simple ;-) + <LibreMan> are you sure the work on "the hard parts" is ever going to be + done? :) + <antrik> the core is working, but it is still missing some features, and + it's missing lots of performance optimisation and bug fixing + <LibreMan> it seems more hard parts pop up every time you think it is + almost production ready + <antrik> also, we know today that the core could work much better in some + regards if we make some major changes. not a priority right now, but + something that will have to be addressed in the long run to seriously + compete with other systems + <antrik> well, no software is ever done :-) + <antrik> but I hope we will get to a point where the hard parts work well + enough for most people + <LibreMan> in fact I remember the design of Hurd was specifically chose by + RMS because he thought it would be easier to implement modular system - + that was 20 yeras ago? :) + <antrik> yes, and he admitted later that he was totally wrong on that :-) + <LibreMan> yeah, that was one unlucky choice for GNU ... + <antrik> who knows. it's hard to estimate what would have happened it GNU + chose a different route back then + <LibreMan> so ... Hurd is a hobby project for you too? + <LibreMan> or ... what do you hope to achieve by working on Hurd? + <LibreMan> I'm really interested in the motivations of people behind Hurd + as I'm kind of surprised it's not that much freedom and GNU ... + <antrik> it's a hobby project for everyone -- nobody gets paid for working + on it + <antrik> in the long run, I hope the Hurd to be a good platform for my + higher-level ideas. I have a vision of a desktop environment working + quite differently from what exists today; and I believe the extensible + architecture of the Hurd makes it easier to implement these ideas + <LibreMan> that's not what I meant as you may have guessed from my line of + reasoning so far + <LibreMan> yeah, that's my definition of a hobby project :) not whether one + gets payed to do it or not but whether one does it to satisfy their own + curiosity + <antrik> well, curiosity is clearly too narrow + <LibreMan> as far as I'm concerned I'd have a more "political" goal of + influencing the wider world to move toward more freedom + <antrik> but hackers never work on volunteer projects except to scratch + their own itch, or to work on something they are genuinely interested + in. nobody hacks free software just to save the world + <LibreMan> I find some technical aspects very interesting and fun but if + they wouldn't further the goal of more freedom they'd be without purpose + to me + <antrik> just think of the GNU high priority projects list -- it has zery + effect + <antrik> zero + <LibreMan> yeah ... and I think that is a real shame + <LibreMan> I keep thinking that it's because most hackers do not realize + the importance of freedom and the consequences of not having it + <antrik> it's a shame that some people at the FSF seem to believe they can + tell hackers what to work on :-P + <LibreMan> I do not think anybody at FSF actually believes that + <LibreMan> they believe as I do that we can persuade hackers to work on + things after they themselves recognise the significance of it + <antrik> no. there are many many hackers who genuinely believe in + supporting software freedom (both in the Hurd and in other GNU projects) + -- but there are none who would work on projects they are not personally + interested in because of that + <LibreMan> well, how does one become "personally interested" in a project? + surely it's not something you;re born with ... after recognising a + significance of some project some may become personally interested in it + - and that's the point ;) + <antrik> well, if I you mean nobody realises that software freedom is so + important they should work on it instead of doing things they actually + enjoy... they yes, I guess you are right :-P + <antrik> significance is subjective. just because something may be + important to the general public, doesn't mean I personally care about it + <LibreMan> you keep projecting your own concerns into it + <LibreMan> just because you're not interested in something doesn't mean + someone else isn't + <LibreMan> you approach it from the POV that omebody is telling YOU what + you should do ... + <LibreMan> that is not the case + <antrik> LibreMan: well, but there are obviously things no hackers care + about -- or otherwise there would be no need for the high priority + projects list... it's a list of things that would be important for + software freedom, but nobody is interested in working on. and having a + list of them won't change that fact + <LibreMan> antrik: why do you feel entitled to speak for all hackers? the + projects are high priority exactly because there isn;t enough people + working on them, if they were they wouldn't be high priority :) + <LibreMan> so maybe you have cause and effect mixed up ... + <LibreMan> there is no need to list office suite as hight priority because + there is LibreOffice, if there wasn't I'm sure it would be right there on + the priority list + <antrik> LibreMan: err... how is that different from what I said? + <antrik> these projects are there because there are not enough people + working on them -- i.e. hackers are not interested in them + <LibreMan> you said it in a way the implied that hackers are not interested + in working on projects that are required for providing freedom - but + mostly there are, it's just a few project where aren't - and those are + listed as high priority to bring attention to them + <LibreMan> well, maybe after seeing them on a high priority list some + hackes become interested in them - that is the point :) + <antrik> yes, that's what I implied. the fact that there are projects + hackers aren't working on, although they would be important for software + freedom, proves that this is not sufficient motivation for volunteers + <antrik> if software freedom alone would motivate hackers, there would be + enough people working on important projects + <LibreMan> who ever claimed that freedom alone motivated hackers? :) + <antrik> but there aren't. we have the list, and people are *still* not + working on these projects -- q.e.d. + <LibreMan> I do not get what you're trying to prove + <antrik> the track record so far clearly shows that hackers do *not* become + interested in working on these projects just because they are on the list + <antrik> err... you pretty much claimed that Hurd hackers should be + motivated by freedom alone + <antrik> and expressed great disappointment that we aren't + <braunr> LibreMan: you expected the hurd developers to share the common + goal of freedom mainly, and now you're saying you don't think hackers + would work for freedom alone ? + <LibreMan> freedom mainly == freedom alone? + <braunr> antrik: would you see an objection to using netbsd as a code base + for a mach clone ? + <braunr> LibreMan: you said share the common goal of freedom + <LibreMan> you're twisting my word to suit your own line of reasoning + <braunr> implying we all agree this is the priority + <LibreMan> being a priority doesn't mean it is there "alone", does it? + <braunr> it means it's the only one + <LibreMan> in another words, do you reject the possibility of enjoying + working on a project and doing it for freedom? because it seems you + somehow do not allow for that possibility + <braunr> if we agree on it, we can't have multiple priorities per people + <braunr> yes, that's what we're saying + <braunr> freedom isn't a goal + <braunr> it's a constraint + <braunr> the project *has* to be free + <LibreMan> so if you;re doing something to achieve freedom you can not BY + DEFINITION enjoy it? :D + <braunr> LibreMan: more or less, yes + <braunr> i enjoy the technical aspect, i advocate freedom + <LibreMan> then I've just disproven you :) I do things for freedom and + enjoy them + <braunr> no, not for freedom + <LibreMan> yes, for freedom + <braunr> i'm telling you it's not what motivates me to write code + <LibreMan> if I did not believe in freedom I wouldn't do them + <LibreMan> and I'm not talking about you + <braunr> i believe in freedom, my job consists of developing mostly + proprietary software + <braunr> how can you disprove me if you're not talking about me on this ? + <LibreMan> you said it's not possible IN PRINCIPLE, well antrik did and you + agreed - if you did not follow his line of argument then do not try to + continue where he left off ;) + <braunr> what project have you worked on ? + <LibreMan> my personal ones, nothing big + <braunr> so you're not a hacker, you're excluded from the group considered + <LibreMan> I'll tell you when it cathes on :) + <braunr> (bam) + <LibreMan> so now you decide who is and is not a hacker, well ... :) + <braunr> :) + <LibreMan> but ok, let's not talk about me I concede that I'm a lousy one + if any :) + <LibreMan> what about RMS, do you consider him a hacker? + <braunr> i think he became a hacker for other reasons than freedom + <LibreMan> would you say he is not motivated by freedom (if that can be + even concieved of)? :) + <braunr> and sees freedom as necessary too + <braunr> i can't say, i don't know him + <antrik> braunr: nope. in fact we discussed this in the past. someone even + worked on GSoC project bringing Hurd/Mach features to NetBSD -- but AFAIK + nothing came out of it + <braunr> antrik: ok + <LibreMan> well, he is pretty vocal with plenty of writings ... on the + other hand you seemed to know me well enough to proclaim me a non-hacker + <braunr> i don't know why he worked on emacs and gcc rather than the hurd + :p + <braunr> but something other than freedom must have motivated such choices + <antrik> I'm uncertain though whether NetBSD is a more useful base than + Linux. it would offer advantages on the licensing front, but it would not + offer the advantage that people could just run it on their existing + systems... + <LibreMan> gcc seems pretty significant for Linux lol + <braunr> antrik: true + <LibreMan> or GNU + <braunr> antrik: there are already system call stubs, and the VM is very, + very similar + <braunr> LibreMan: the hurd was too, at the time + <LibreMan> he can not work on everything + <braunr> so he ahd to choose, and based his choice on something else than + freedom (since all these projects are free) + <braunr> i guess he enjoyed emacs more + <antrik> LibreMan: RMS is not much of a practicing hacker anymore + nowadays... + <antrik> braunr: yeah, that's another advantage of using NetBSD as a + base... it might be easier to do + <braunr> LibreMan: what was your original question again ? + <braunr> i've been somewhat ironic since that trademark stuff, i'm serious + again now + <antrik> LibreMan: again, freedom is a factor for many of us; but not the + primary motivation + <antrik> (as braunr put, being free software is mandatory for us; but that + doesn't mean the main reason for working on the Hurd is some indirect + benefit for the free software movement...) + <LibreMan> braunr: the original goal was to understand the strong points of + Hurd to I can help communicate them to other hackers who might be + interested in Hurd + <LibreMan> because I wanted it to succeed to advance freedom more + <antrik> LibreMan: well, practice what you preach ;-) + <LibreMan> but now that I've founf that not even devs themselves are that + much interested in freedom I do not have that desire anymore + <antrik> you will hardly motivate other hackers to work on something you do + not even work on yourself... + <LibreMan> and focus my attention somewhere else + <antrik> [sigh] + <braunr> well, you can now state that the hurd has an elegant architecture + allowing many ugly hacks to disappear, and that it doesn't yet handle + sata drives or usb keys or advandced multicast routing or ... + <antrik> LibreMan: how about you listen to what we are saying? + <LibreMan> antrik: so I should work on everything in the world that + advances freedom or shut up? + <antrik> LibreMan: we *are* interested in freedom. we would work on nothing + else than a free software system. it's just not the primary motivation + for working on the Hurd + <antrik> if you primary motivation is advancing free software, the Hurd is + probably indeed not the right project to work on. other projects are more + important for that + <antrik> and that's got nothing to do with our priorities + <antrik> it's simply a matter of what areas free software is most lacking + in. the kernel is not one of them. + <braunr> antrik: my primary concern with netbsd are drivers + <LibreMan> I naively assumed that people working on a GNU project will + share GNU vlaues, instead I find that some of them poke fun at its high + priority projects + <braunr> i poke fun at you + <braunr> because you think trademark has any real value on the free + software community + <LibreMan> braunr: I see, congratulations ... I hope you enjoy it + <antrik> if there were no suitable free software kernels around, many + people might work on the Hurd mostly to advance free software. but as it + stands, having a GNU kernel is secondary + <braunr> yes, freedom is a primary goal when there are no free alternatives + <antrik> LibreMan: you are accusing us of not sharing GNU values, which is + quite outrageous I must say + <braunr> LibreMan: actually no, i'd prefer converstation with someone who + understands what i'm saying + <braunr> even if he contradicts me, like antrik often does + <braunr> (but he's usually right) + <braunr> LibreMan: you just don't want to accept some (many) of us are here + more for technical reasons than ethical ones + <LibreMan> antrik: well, some of your reasoning and tone would seem to + suggest so ... + <braunr> i didn't see antrik being particularly aggressive, but personally, + i react badly to stupidity + <LibreMan> braunr: WHAT? I've never said anything about what you should or + should not do or believe + <braunr> you clearly expected something when you first arrived + <LibreMan> I said I personally expected more enhusiastic people concerning + GNU and freedom but that was my personal expectaion and my personal + disappointment + <antrik> what makes you think we are not enthusiastic about GNU and + software freedom? + <braunr> more enthusiastic is vague, you expected us to be some sort of + freedom fighters + <antrik> just for the record, I'm part of the German core team of the FSFE + <braunr> i even stated early that we're mostly part of the free software + rather than open source movement, and you still find our point of view + disappointing + <antrik> still, it's not my major motivation for working on the Hurd + <antrik> I don't see any contradiction in that + <LibreMan> I don;t know maybe I misunderstand you, I do not mean any + disrespect + <braunr> me neither + <LibreMan> maybe "hackers" truly do think differently than I expected them + to in general and it's not specific to Hurd + <braunr> well the very word hacker describe someone interested by "hacking" + down something to get to understand it + <braunr> it's strongly technical + <LibreMan> antrik: why are you a core team member of th FSFE? what do you + do there and why? is that not motivated by the desire for more freedom? + <braunr> and we're lucky, many of them aren't deeply concerned with money + and secrecy, and prefer being open about their work + <braunr> you still don't get it ... + <antrik> LibreMan: of course it is + <antrik> and hacking free software in general also is (partly) motivated by + that + <antrik> but hacking on the Hurd specifically not so much + <braunr> 20:23 < antrik> LibreMan: we *are* interested in freedom. we would + work on nothing else than a free software system. it's just not the + primary motivation for working on the Hurd + <braunr> he already answered your question there + <antrik> (as I already said, it *is* in fact part of the motivation in my + case... just not the major part) + <LibreMan> antrik: but if it ever achieved wide success and you would be + asy on a "board" to decide future direction would you choose for exacmple + to prevent TiVO-ization over wider adpotion? + <braunr> we already answered that too + <antrik> LibreMan: that's actually not even for us to decide, as long as we + are an official GNU project + <antrik> but of course we are a GNU project because we *do* believe in + software freedom, and obviously wouldn't accept Tivoisation + <braunr> (and our discussion about using netbsd as a code base is a + relevant example of license concerns) + <LibreMan> I'm really trying to get to the core of "not motivated by + freedom" but being "interested in freedom" ... I really do not get that, + if you are interested in freedom wouldn't you want a project you work on + being used to advance it as much as possible and therefore be also + motivated to do it the best while enjoying it to achieve the goal of more + freedom since you value it that much? + <braunr> LibreMan: except for the GPLv2 vs GPLv3 debate, i don't see where + there can be a conflict between freedom and technical interest + <LibreMan> braunr: the issues around freedom are mainly not technical + ... GPLv2 and GPLv3 is also not about technical interests + <braunr> that's my problem with you, i fail to see where the problem you + think of is + <LibreMan> it tends to be about the possibility to extract money and impose + your will on the users which turns out to be highly profitable and + politicaly desirable in some instances + <LibreMan> of course it's technically the best to open-source but how are + you going to sell a product like that? that is the main question + troubling most corporations + <LibreMan> ok, I'm not going to bore you any more ;) I found out what I + needed to know ... now I'm going to try to forget about Hurd and focus on + something else where my help can be more effective at achieving what I + want ;) good luck with your endavours + <antrik> LibreMan: of course we hope for the Hurd to advance the cause of + freedom, just like any free software we would work on... still, it's not + the primary reason why we work on the Hurd, instead of the myriads of + other free software projects out there + + +# IRC, freenode, #hurd, 2012-04-09 + + <antono> what is the most impressive thing about hurd you wold like to + promote? + <antono> killing feature + <antono> i've created some simple hurd screencasts here + http://shelr.tv/records/search?utf8=%E2%9C%93&q=hurd + <antono> but probably i could share something more interesting :) + <antrik> antono: if we had such an obvious killer feature, we wouldn't have + to struggle ;-) + <antrik> the problem is that the advantages of the Hurd architecture are + too abstract for the vast majority of people to take them seriously + <antrik> IMHO the most interesting part of the Hurd is the fully + decentralised (and thus infinitely extensible) VFS mechanism + <antrik> but even that is very abstract... + <antono> antrik: cand i do somenthing relly fundamental with hurd + translator? + <antono> for example i hate old school unix FHS + <antono> I would like to have only /Users/me and /System/GNU + <antono> and i would like to only see it, but behinde the scenes it should + be Debian with FHS layout + <antono> is it possible? + <antrik> antono: of course. not sure translators offer much advantage over + FUSE in this case though... it doesn't really change the functionality of + the VFS; only rearranges the tree a bit + <antrik> (might even be doable with standard Linux features) diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn new file mode 100644 index 00000000..4946a5a0 --- /dev/null +++ b/open_issues/mmap_crash_etc.mdwn @@ -0,0 +1,95 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +Several issues here: + + * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't + crash the process. + + * [[!tag open_issue_documentation]] The memory layout example should be + documented. + + * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be + desirable; see also [[placement_of_virtual_memory_regions]]. + + * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most + probably a bug*. + +IRC, freenode, #hurd, 2011-08-11 + + < zyg> oh, mmap sigsegvs, strange. + < braunr> hwo do you see that ? + < zyg> braunr: I'll try to paste a minimal case + < braunr> zyg: make sure you have a sane memory setup + < braunr> 512 RAM / 1G swap seems good + < braunr> have more swap than RAM + < zyg> I have those. Still it shouldn't sigsegv. + < braunr> gnumach is picky about that + < braunr> and yes, the hurd shouldn't have bugs + < zyg> braunr: ready to crash? #include <stdio.h> #include <sys/mman.h> int + main (int argc, char **argv) { mmap(0x10000, 0x8000, PROT_READ, MAP_ANON + | MAP_FIXED, -1, 0); return 0; } + < braunr> a fixed mapping at such an address is likely to fail, yes + < braunr> but a crash, hm + < zyg> why should it fail? + < braunr> because the hurd doesn't have a common text data bss heap stack + layout + < braunr> e.g. there are mappings below text, as show by vminfo : + < braunr> $ vminfo $$ + < braunr> 0[0x1000] (prot=0) + < braunr> 0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105) + < braunr> 0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105) + < braunr> 0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105) + < braunr> 0x24000[0x1000] (prot=0, max_prot=RWX) + < braunr> 0x25000[0xfff000] (prot=RWX, mem_obj=106) + < braunr> 0x1024000[0x1000] (prot=RWX, mem_obj=107) + < braunr> 0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108) + < braunr> 0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108, + offs=0x1000) + < braunr> 0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109) + < braunr> 0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110, + offs=0x1000) + < braunr> 0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111) + < braunr> (sorry for the long paste) + < zyg> oh.. my mmap falls into an occupied range? + < braunr> seems so + < zyg> thanks, that was really useful. + < braunr> MAP_FIXED isn't portable, this is clearly stated in most man + pages + < zyg> yes, implementation specific it says + < braunr> well the behaviour isn't specific, it's well defined, but the + memory layout isn't + < braunr> i personally think vm_map() should be slightly changed to include + a new flag for top-down allocations + < braunr> so that our stack and libraries are at high addresses, below the + kernel + < braunr> zyg: what kind of error do you get ? i don't get sigsegv + < zyg> I get both sigsegv and sigill depending on addr + < braunr> ok + < braunr> i get sigill with your example + < braunr> the error is the same (wrong memory access) but the behaviour + changes because of the special memory configuration + < zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an + guard + < braunr> some accesses cause invalid page faults (which are sent as + segmentation faults) while other cause general protection faults (which + are sent as illegal instructions) + < braunr> (this is quite weird since the GP fault is likely because the + access targets something out of the data or code segment eh) + < zyg> braunr: that's very os-specific. Do you mean hurd behaves that way? + < braunr> gnumach + < braunr> on i386 + < braunr> the segmant configuration isn't completely flat + < braunr> segment* + < braunr> hm nice + < braunr> your small program triggers the "task X deallocating an invalid + port Y, most probably a bug." message + < zyg> where do you see that? + < braunr> on the mach console diff --git a/open_issues/mmap_write-only.mdwn b/open_issues/mmap_write-only.mdwn new file mode 100644 index 00000000..467274c5 --- /dev/null +++ b/open_issues/mmap_write-only.mdwn @@ -0,0 +1,56 @@ +[[!meta copyright="Copyright © 2011, 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, freenode, #hurd, 2011-12-14 + + <pinotree> hm, interesting mmap bug + <youpi> ? + <pinotree> youpi: http://paste.debian.net/149252/ + #include <sys/types.h> + #include <sys/mman.h> + #include <fcntl.h> + #include <stdio.h> + #include <errno.h> + #include <stdlib.h> + #include <string.h> + #include <unistd.h> + + void die(int x, const char *s) + { + perror(s); + exit(x); + } + + static const char s_file[] = "foo-mmaptest"; + + int main() + { + int fd; + void *p; + + fd = creat(s_file, 0777); + if (fd < 0) die(1, "creat"); + errno = 0; + p = mmap(NULL, 1, PROT_READ, MAP_SHARED, fd, 0); + printf("> %p vs %p, %d (%s)\n", p, MAP_FAILED, errno, strerror(errno)); + unlink(s_file); + return (p != MAP_FAILED); + } + <pinotree> on linux it returns 0 and fails with EACCESS (as it seems it + should, by reading the mmap posix docs), on hurd it returns 1 and the + mmap succeeds + <pinotree> (taken from llvm's configure) + <youpi> why should it? file size extension ? + <pinotree> creat creates a o_wronly file, while the mmap specifies only + read protection + <youpi> oh, craet is always wo + <youpi> I didn't know that diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn new file mode 100644 index 00000000..562ccd83 --- /dev/null +++ b/open_issues/multiprocessing.mdwn @@ -0,0 +1,82 @@ +[[!meta copyright="Copyright © 2010, 2011 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_documentation open_issue_hurd]] + +We would expect that fine-grained, compartmentalized systems, that is, +microkernel-based multi-server systems in particular, would be ideal candidates +for applying multiprocessing. That is, however, only true from a first and +inexperienced point of view: there are many difficulties. + + +IRC, freenode, #hurd, August / September 2010 + + <marcusb> silver_hook: because multi-server systems depend on inter-process + communication, and inter-process communication is many times more + expensive across cpus + <marcusb> silver_hook: so you either force interrelated work on the same + cpu, or suffer heavy penalties. and in a typical fine-grained object + system, all objects are interconnected! + <marcusb> silver_hook: resources in today's systems, even in a single node + with one cpu, but more so in a network, are very non-uniform. scheduling + these resources efficiently is a huge problem. restricting the resource + distribution policies in the way microkernel systems tend to do is posing + serious research challenges + + +IRC, freenode, #hurd, 2011-07-26 + + < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a + multicore architecture than linux ? + < braunr> CTKArcher: short answer: no + < CTKArcher> it's easier to imagine one server pro core than the linux + kernel divided to be executed on multiple cores + < braunr> CTKArcher: this approach is less efficient + < braunr> CTKArcher: threads carry state, both explicit and implicit (like + cache data) + < braunr> CTKArcher: switching to another core means resetting and + refetching this state + < braunr> it's expensive and there is no gain obtained by doing this + < braunr> thread migration (having a thread from a client also run in + servers when making synchronous RPC, even handling its own page faults) + was implemented in mach4 and is imo a very good thing we should have + < braunr> CTKArcher: and concerning linux, it's actually very scalable + < braunr> it's already like if all client threads run in servers (the + kernel is the servers there) + < braunr> rcu is used a lot + < braunr> thread migration already takes into account smt, cores, and numa + < braunr> it's hard to do something better + < braunr> (here, thread migration means being dispatched on another cpu) + < braunr> some systems like dragonflybsd go as far as to pin threads on one + processor for their entire lifetime + < braunr> in order to have rcu-like locking almost everywhere + < braunr> (you could argue it's less efficient since in the worst case + everything runs on the same cpu, but it's very unlikely, and in practice + most patterns are well balanced) + + +debian-hurd list + +On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote: +> Georg Lehner writes: +> +> > - One promise of the microkernel architecture is better performance on +> > multiprocessor systems, or multicomputer systems. What is the status +> > of Gnu Mach with respect to these. +> +> This may or may not be true. The Hurd is built around a microkernel +> architecture because of its conceptual elegance and flexibility. +> Other touted advantages may be more illusory than real, at least, they +> aren't something *we* are proclaiming is our motivation. + + +--- + +See also: [[multithreading]]. diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn new file mode 100644 index 00000000..5924d3f9 --- /dev/null +++ b/open_issues/multithreading.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010, 2011, 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_hurd]] + +Hurd servers / VFS libraries are multithreaded. + + +# Implementation + + * well-known threading libraries + + * [[hurd/libthreads]] + + * [[hurd/libpthread]] + + +# Design + +See [[hurd/libports]]: roughly using one thread per +incoming request. This is not the best approach: it doesn't really make sense +to scale the number of worker threads with the number of incoming requests, but +instead they should be scaled according to the backends' characteristics. + +The [[hurd/Critique]] should have some more on this. + +[*Event-based Concurrency +Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.pdf), +Tom Van Cutsem, 2009. + + +## IRC, freenode, #hurd, 2012-07-08 + + <youpi> braunr: about limiting number of threads, IIRC the problem is that + for some threads, completing their work means triggering some action in + the server itself, and waiting for it (with, unfortunately, some lock + held), which never terminates when we can't create new threads any more + <braunr> youpi: the number of threads should be limited, but not globally + by libports + <braunr> pagers should throttle their writeback requests + <youpi> right + + +# Alternative approaches: + + * <http://www.concurrencykit.org/> + + * Continuation-passing style + + * [[microkernel/Mach]] internally [[uses + continuations|microkernel/mach/continuation]], too. + + * [[Erlang-style_parallelism]] + + * [[!wikipedia Actor_model]]; also see overlap with + {{$capability#wikipedia_object-capability_model}}. + + * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/) + + * <http://monkey.org/~provos/libevent/> + +--- + +See also: [[multiprocessing]]. diff --git a/open_issues/multithreading/erlang-style_parallelism.mdwn b/open_issues/multithreading/erlang-style_parallelism.mdwn new file mode 100644 index 00000000..75539848 --- /dev/null +++ b/open_issues/multithreading/erlang-style_parallelism.mdwn @@ -0,0 +1,201 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, #hurd, 2010-10-05 + + <sdschulze> antrik: Erlang-style parallelism might actually be interesting + for Hurd translators. + <sdschulze> There are certain similarities between Erlang's message boxes + and Mach ports. + <sdschulze> The problem is that all languages that implement the Erlang + actor model are VM-based. + <antrik> sdschulze: I guess that's because most systems don't offer this + kind of message passing functionality out of the box... perhaps on Hurd + it would be possible to implement an Erlang-like language natively? + <sdschulze> That would be quite attractive -- having the same API for + in-process parallelism and IPC. + <sdschulze> But I don't see why Erlang needs a VM... It could also be + implemented in a library. + [...] + <sdschulze> BTW, Scala doesn't require a VM by design. Its Erlang + implementation is a binary-compatible abstraction to Java. + [...] + <sdschulze> My point was that Erlang employs some ideas that might be + usable in the Hurd libraries. + <sdschulze> concerning multithreading stuff + <sdschulze> Unfortunately, it will not contribute to readability if done in + C. + <antrik> perhaps it's worth a look :-) + <sdschulze> Actually, a Mach port is pretty close to an Erlang actor. + <sdschulze> Currently, your I/O callbacks have to block when they're + waiting for something. + <sdschulze> What they should do is save the Mach port and respond as soon + as they can. + <sdschulze> So there should be a return status for "call me later, when I + tell you to" in the callbacks. + <sdschulze> Then the translator associates the Mach port with the summary + of the request in some data structure. + <sdschulze> As soon as the data is there, it tells the callback function to + appear again and fulfills the request. + <sdschulze> That's -- very roughly -- my idea. + <sdschulze> Actually, this eliminates the need for multithreading + completely. + <antrik> sdschulze: not sure whether you are talking about RPC level or + libc level here... + <sdschulze> It should be transparent to libc. + <sdschulze> If the client does a read() that cannot be answered immediatly, + it blocks. + <sdschulze> The difference is that there is no corresponding blocking + thread in the translator. + <antrik> ah, so you are talking about the server side only + <sdschulze> yes + <antrik> you mean the callback functions provided by the translator + implementation should return ASAP, and then the dispatcher would call + them again somehow + <sdschulze> allowing the server to be single-threaded, if desired + <sdschulze> exactly + <sdschulze> like: call_again (mach_port); + <antrik> but if the functions give up control, how does the dispatcher know + when they are ready to be activated again? or does it just poll? + <sdschulze> The translator knows this. + <sdschulze> hm... + <antrik> well, we are talking about the internal design of the translator, + right? + <antrik> I'm not saying it's impossible... but it's a bit tricky + <antrik> essentially, the callbacks would have to tell the dispatcher, + "call me again when there is an incoming message on this port" + <sdschulze> Say we have a filesystem translator. + <antrik> (or rather, it probably should actually call a *different* + callback when this happens) + <sdschulze> The client does a "read(...)". + <sdschulze> => A callback is called in the translator. + <antrik> let's call it disfs_S_io_read() ;-) + <antrik> err... diskfs + <sdschulze> The callback returns: SPECIAL_CALL_ME_LATER. + <sdschulze> yes, exactly that :) + <sdschulze> But before, it saves the position to be read in its internal + data structure. + <sdschulze> (a sorted tree, whatever) + <sdschulze> The main loop steps through the data structure, doing a read() + on the underlying translator (might be the disk partition). + <sdschulze> "Ah, gotcha, this is what the client with Mach port number 1234 + wanted! Call his callback again!" + <sdschulze> Then we're back in diskfs_S_io_read() and supply the data. + <antrik> so you want to move part of the handling into the main loop? while + I'm not fundamentally opposed to that, I'm not sure whether the + dispatcher/callback approach used by MIG makes much sense at all in this + case... + <antrik> my point is that this probably can be generalised. blocking + operations (I/O or other) usually wait for a reply message on a port -- + in this case the port for the underlying store + <antrik> so the main loop would just need to wait for a reply message on + the port, without really knowing what it means + <sdschulze> on what port? + <antrik> so disfs_S_io_read() would send a request message to the store; + then it would return to the dispatcher, informing it to call + diskfs_S_io_read_finish() or something like that when there is a message + on the reply port + <antrik> main loop would add the reply port to the listening port bucket + <antrik> and as soon as the store provides the reply message, the + dispatcher would then call diskfs_S_io_read_finish() with the reply + message + <sdschulze> yes + <antrik> this might actually be doable without changes to MIG, and with + fairly small changes to libports... though libdiskfs etc. would probably + need major rewrites + <sdschulze> What made me think about it is that Mach port communication + doesn't block per se. + <antrik> all this is however ignoring the problem I mentioned yesterdays: + we need to handle page faults as well... + <sdschulze> It's MIG and POSIX that block. + <sdschulze> What about page faults? + <antrik> when the translator has some data mapped, instead of doing + explicit I/O, blocking can occur on normal memory access + <sdschulze> antrik: Well, I've only been talking about the server side so + far. + <antrik> sdschulze: this *is* the server side + <antrik> sdschulze: a filesystem translator can map the underlying store + for example + <antrik> (in fact that's what the ext2 translator does... which is why we + had this 2G partition limit) + <sdschulze> antrik: Ah, OK, so in other words, there are requests that it + can answer immediatly and others that it can't? + <antrik> that's not the issue. the issue is the the ext2 translator doesn't + issue explicit blocking io_read() operations on the underlying + store. instead, it just copies some of it's own address space from or to + the client; and if the page is not in physical memory, blocking occurs + during the copy + <antrik> so essentially we would need a way to return control to the + dispatcher when a page fault occurs + <sdschulze> antrik: Ah, so MIG will find the translator unresponsive? (and + then do what?) + <antrik> sdschulze: again, this is not really a MIG thing. the main loop is + *not* in MIG -- it's provided by the tranlator, usually through libports + <sdschulze> OK, but as Mach IPC is asynchronous, a temporarily unresponsive + translator won't cause any severe harm? + <sdschulze> antrik: "Easy" solution: use a defined number of worker + threads. + <antrik> sdschulze: well, for most translators it doesn't do any harm if + they block. but if we want to accept that, there is no point in doing + this continuation stuff at all -- we could just use a single-threaded + implementation :-) + <sdschulze> Hard solution: do use explicit I/O and invent a + read_no_pagefault() call. + <antrik> not sure what you mean exactly. what I would consider is something + like an exception handler around the copy code + <antrik> so if an exception occurs during the copy, control is returned to + the dispatcher; and once the pager informs us that the memory is + available, the copy is restarted. but this is not exacly simple... + <sdschulze> antrik: Ah, right. If the read() blocks, you haven't gained + anything over blocking callbacks. + * sdschulze adopted an ML coding style for his C coding... + <sdschulze> antrik: Regarding it on the Mach level, all you want to do is + some communication on some ports. + <sdschulze> antrik: Only Unix's blocking I/O makes you want to use threads. + <sdschulze> Unless you have a multicore CPU, there's no good reason why you + would *ever* want multithreading. + <sdschulze> (except poor software design) + <sdschulze> antrik: Is there a reason why not to use io_read? + <antrik> sdschulze: I totally agree about multithreading... + <antrik> as for not using io_read(): some things are easier and/or more + efficient with mapping + <antrik> the Mach VM is really the most central part of Mach, and it's + greatest innovation... + <sdschulze> antrik: If you used explicit I/O, it would at least shift the + problem somewhere else... + <antrik> sure... but that's a workaround, not a solution + <sdschulze> I'm not sure how to deal with page faults then -- I know too + little about the Hurd's internal design. + <sdschulze> Non-blocking io_read only works if we address the client side, + too, BTW. + <sdschulze> which would be quite ugly in C IMHO + <sdschulze> announce_read (what, to, read, when_ready_callback); + <antrik> sdschulze: POSIX knows non-blocking I/O + <antrik> never checked how it works though + <sdschulze> Yes, but I doubt it does what we want. + <antrik> anyways, it's not too hard to do non-blocking io_read(). the + problem is that then you have to use MIG stubs directly, not the libc + function + <sdschulze> And you somehow need to get the answer. + <sdschulze> resp. get to know when it's ready + <antrik> the Hurd actually comes with a io_request.defs and io_reply.defs + by default. you just need to use them. + <sdschulze> oh, ok + <antrik> (instead of the usual io.defs, which does a blocking send/receive + in one step) + <sdschulze> I'd be interested how this works in Linux... + <antrik> what exactly? + <sdschulze> simultaneous requests on one FS + <antrik> ah, you mean the internal threading model of Linux? no idea + <sdschulze> if it uses threading at all + <antrik> youpi probably knows... and some others might as well + <sdschulze> Callbacks are still ugly... diff --git a/open_issues/neals_hurd-misc_papers.mdwn b/open_issues/neals_hurd-misc_papers.mdwn new file mode 100644 index 00000000..7f4e1e3b --- /dev/null +++ b/open_issues/neals_hurd-misc_papers.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 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_documentation]] + +<http://walfield.org/pub/people/neal/papers/hurd-misc/> + + <tschwinge> neal: We could put that into the wiki some day, I think. + <neal> sure diff --git a/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn b/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn new file mode 100644 index 00000000..de1d63a3 --- /dev/null +++ b/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, #hurd, August / September 2010 + + <jkoenig> btw, it should be possible to implement a network "filesystem" by + just forwarding RPCs over the network, right? + <jkoenig> (of course auth would be an additional concern) + <jkoenig> that would open all kinds of possibilities, possibly. + <LarstiQ> jkoenig: plan9? + <jkoenig> I don't know much about plan9 yet. I seem to remember some mach + extension for network transparency being mentionned somewhere.. diff --git a/open_issues/nfs_trailing_slash.mdwn b/open_issues/nfs_trailing_slash.mdwn new file mode 100644 index 00000000..90f138e3 --- /dev/null +++ b/open_issues/nfs_trailing_slash.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 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 open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-05-27 + + <gg0> ok, on nfs "mkdir dir0" succeeds, "mkdir dir0/" fails. RPC struct is bad + + +## IRC, freenode, #hurd, 2012-05-27 + + <gg0> 150->dir_mkdir ("foo1/" 493) = 0x40000048 (RPC struct is bad) + <gg0> task2876->mach_port_deallocate (pn{ 18}) = 0 + <gg0> mkdir: 136->io_write_request ("mkdir: " -1) = 0 7 + <gg0> cannot create directory `/nfsroot/foo1/' 136->io_write_request + ("cannot create directory `/nfsroot/foo1/'" -1) = 0 40 + <gg0> : RPC struct is bad 136->io_write_request (": RPC struct is bad" -1) + = 0 19 + <gg0> 136->io_write_request (" + <gg0> " -1) = 0 1 + <tschwinge> gg0: Yes, I think we knew about this before. Nobody felt like + working on it yet. Might be a nfs, libnetfs, glibc issue. + <tschwinge> gg0: If you want to work on it, please ask here or on bug-hurd + if you need some guidance. + <gg0> yeah found this thread + http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00069.html I don't + think I'll work on it diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn new file mode 100644 index 00000000..d731ef82 --- /dev/null +++ b/open_issues/nice_changes_priority_of_parent_shell.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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_gnumach open_issue_glibc]] + + * <http://bugs.debian.org/44039> + + * Also see [[nice_vs_mach_thread_priorities]]. diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn new file mode 100644 index 00000000..e6b68134 --- /dev/null +++ b/open_issues/nice_vs_mach_thread_priorities.mdwn @@ -0,0 +1,197 @@ +[[!meta copyright="Copyright © 2010 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_gnumach open_issue_glibc]] + +This issue has been known for some time, due to coreutils' testsuite choking +when testing *nice*: <http://bugs.debian.org/190581>. + +There has been older discussion about this, too, but this is not yet captured +here. + +IRC, #hurd, August 2010 + + <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems + <pochu> antrik said it would be better to reimplement everything instead of fixing the current Mach interfaces, though I'm not sure about that yet + <youpi> uh, so he changed his mind? + <pochu> it seems POSIX doesn't say nice values should be -20..20, but 0..(2*NZERO - 1) + <youpi> he said we could just change the max priority value and be done with it :) + <pochu> so we can probably define NZERO to 16 to match the Mach range of 0..31 + <youpi> s/said/had said previously/ + <antrik> youpi: POSIX is actually fucked up regarding the definition of nice values + <antrik> or at least the version I checked was + <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just set NZERO to 16 AFAICS: http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html + <antrik> it talkes about NZERO and all; making it *look* like this could be defined arbitrarily... but in other places, it's clear that the standard 40 level range is always assumed + <antrik> anyways, I totally see no point in deviating from other systems in this regard. it can only cause problems, and gives us no benefits + <cfhammar> it says NZERO should be at least 20 iirc + <youpi> agreed + <antrik> I don't remember the details; it's been a while since I looked at this + <antrik> youpi: changing the number of levels is only part of the issue. I'm not sure why I didn't mention it initially when we discussed this + <antrik> youpi: I already concluded years ago that it's not possible to implement nice levels correctly with the current Mach interfaces in a sane fashion + <antrik> (it's probably possible, but only with a stupid hack like setting all the thread priorities one by one) + <antrik> youpi: also, last time we discussed this, I checked how the nice stuff works currently on Hurd; and concluded that it's so utterly broken, that there is no point in trying to preserve *any* compatibility. I think we can safely throw away any handling that is alread there, and do it over from scratch in the most straightforward fashion + <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly what you've just said to be a hack (setting all the thread priorities one by one) + <pochu> but there seems to be consensus that that's undesirable... + <pochu> indeed, POSIX says NZERO should be at least 20 + <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the complexity of setting the thread max priorities individually + <pochu> antrik: I don't. would it be too complex? I imagined it would be a simple loop :) + <antrik> pochu: in order to prevent race conditions, you have to stop all other threads before obtaining the list of threads, and continue them after setting the priority for each + <antrik> I don't even know whether it can be done without interfering with other thread handling... in which case it gets really really ugly + <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the priority stuff as appropriate, and will change the tasks code later + <antrik> it seems to me that using a more suitable kernel interface will not only be more elegant, but quite possibly actually easier to implement... + <pochu> antrik: apparently it's not that hard to change the priority for all threads in a task, see task_priority() in gnumach/kern/task.c + <pochu> it looks like the nice test failures are mostly because of the not 1:1 mapping between nice values and Mach priorities + <marcusb> "Set priority of task; used only for newly created threads." + <marcusb> there is a reason I didn't fix nice 8 years ago + <marcusb> ah there is a change_threads option + <pochu> marcusb: I'm not sure that comment is correct. that syscall is used by setpriority() + <marcusb> yeah + <marcusb> I didn't read further, where it explains the change_threads options + <marcusb> I was shooting before asking questions :) + <marcusb> pochu: although there are some bad interactions if max_priorities are set per thread + <antrik> pochu: maybe we are talking past each other. my point was not that it's hard to do in the kernel. I was just saying that it would be painful to do from userspace with the current kernel interface + <pochu> antrik: you could still use that interface in user space, couldn't you? or maybe I'm misunderstanding... + <pochu> cfhammar, antrik: current patch: http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what to do with high-priority threads. are there cases where there should be a thread with a high priority but the task's priority shouldn't be high? e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c + <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a higher priority, but then either we raise the task's max_priority if we need a high-prio thread, or we treat them specially (e.g. new field in struct thread), or maybe it's a non-issue because in such cases, all the task is high-prio? + <pochu> also I wonder whether I can kill the processor set's max_priority. It seems totally unused (I've checked gnumach, hurd and glibc) + <pochu> (that would simplify the priority handling) + <cfhammar> pochu: btw what does your patch do? i can't remember what was decided + <pochu> cfhammar: it moves the max_priority from the thread to the task, so raising/lowering it has effect on all of its threads + <pochu> it also increases the number of run queues (and thus that of priority levels) from 32 to 40 so we can have a 1:1 mapping with nice values + <pochu> cfhammar: btw don't do a full review yet, just a quick look would be fine for now + <neal> why not do priorities from 0 to 159 + <neal> then both ranges can be scaled + <neal> without loss of precision + <pochu> neal: there would be from Mach to nice priorities, e.g. a task with a priority of 2 another with 3 would have the same niceness, though their priority isn't really the same + <neal> pochu: sure + <neal> pochu: but any posix priority would map to a current mach priority and back + <neal> sorry, that's not true + <neal> a posix priority would map to a new mach priority and bach + <neal> and a current mach priority would map to a new mach priority and back + <neal> which is I think more desirable than changing to 40 priority levels + <pochu> neal> and a current mach priority would map to a new mach priority and back <- why should we care about this? + <neal> to be compatible with existing mach code + <neal> why gratutiously break existing interfaces? + <pochu> they would break anyway, wouldn't them? i.e. if you do task_set_priority(..., 20), you can't know if the caller is assuming old or new priorities (to leave it as 20 or as 100) + <neal> you add a new interface + <neal> you should avoid changing the semantics of existing interfaces as much as possible + <pochu> ok, and deprecate the old ones I guess + <neal> following that rule, priorities only break if someone does task_set_priority_new(..., X) and task_get_priority () + <neal> there are other users of Mach + <neal> I'd add a configure check for the new interface + <neal> alternatively, you can check at run time + <pochu> well if you _set_priority_new(), you should _get_priority_new() :) + <neal> it's not always possible + <pochu> other users of GNU Mach? + <neal> you are assuming you have complete control of all the code + <neal> this is usually not the case + <neal> no, other users of Mach + <neal> even apple didn't gratuitously break Mach + <neal> in fact, it may make sense to see how apple handles this problem + <pochu> hmm, I hadn't thought about that + <pochu> the other thing I don't understand is: "I'd add a configure check for the new interface". a configure check where? in Mach's configure? that doesn't make sense to me + <neal> any users of the interface + <pochu> ok so in clients, e.g. glibc & hurd + <neal> yes. + <antrik> neal: I'm not sure we are winning anything by keeping compatibility with other users of Mach... + <antrik> neal: we *know* that to make Hurd work really well, we have to do major changes sooner or later. we can just as well start now IMHO + <antrik> keeping compatibility just seems like extra effort without any benefit for us + <guillem> just OOC have all other Mach forks, preserved full compatibility? + <neal> guillem: Darwin is pretty compatible, as I understand it + <antrik> pochu: the fundamental approach of changing the task_priority interface to serve as a max priority, and to drop the notion of max priorities from threads, looks fine + <antrik> pochu: I'm not sure about the thread priority handling + <antrik> I don't know how thread priorities are supposed to work in chreads and/or pthread + <antrik> I can only *guess* that they assume a two-stage scheduling process, where the kernel first decides what process to run; and only later which thread in a process... + <antrik> if that's indeed the case, I don't think it's even possible to implement with the current Mach scheduler + <antrik> I guess we could work with relative thread priorities if we really want: always have the highest-priority thread run with the task's max priority, and lower the priorities of the other threads accordingly + <antrik> however, before engaging into this, I think you should better check whether any of the code in Hurd or glibc actually uses thread priorities at all. my guess is that it doesn't + <antrik> I think we could get away with stubbing out thread priority handling alltogether for now, and just use the task priority for all threads + <antrik> I agree BTW that it would be useful to check how Darwin handles this + <pochu> btw do you know where to download the OS X kernel source? I found something called xnu, but I?m not sure that's it + <antrik> pochu: yeah, that's it + <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel... + <pochu> hmm, so they have both a task.priority and a task.max_priority + <neal> pochu: thoughts? + <pochu> neal: they have a priority and a max_priority in the task and in the threads, new threads inherit it from its parent task + <pochu> then they have a task_priority(task, priority, max_priority) that can change a task's priorities, and it also changes it for all its threads + <neal> how does the global run queue work? + <pochu> and they have 128 run queues, no idea if there's a special reason for that number + <pochu> neal: sorry, what do you mean? + <neal> I don't understand the point of the max_priority parameter + <pochu> neal: and I don't understand the point of the (base) priority ;) + <pochu> the max_priority is just that, the maximum priority of a thread, which can be lowered, but can't exceed the max one + <pochu> the (base) priority, I don't understand what it does, though I haven't looked too hard. maybe it's the one a thread starts at, and must be <= max_priority + <antrik> pochu: it's clearly documented in the manual, as well as in the code your initial patch changes... + <antrik> or do you mean the meaning is different in Darwin?... + <pochu> I was speaking of Darwin, though maybe it's the same as you say + <antrik> I would assume it's the same. I don't think there would be any point in having the base vs. max priority distinction at all, except to stay in line with standard Mach... + <antrik> at least I can't see a point in the base priority semantics for use in POSIX systems... + <pochu> right, it would make sense to always have priority == max_priority ... + <pochu> neal: so max_priority is that maximum priority, and priority is the one used to calculate the scheduled priority, and can be raised and lowered by the user without giving special permissions as long as he doesn't raise it above max_priority + <pochu> well this would allow a user to lower a process' priority, and raise it again later, though that may not be allowed by POSIX, so then we would want to have max_priority == priority (or get rid of one of them if possible and backwards compatible) + <antrik> pochu: right, that's what I think too + <antrik> BTW, did I bring up handling of thread priorities? I know that I meant to, but I don't remember whether I actually did... + <pochu> antrik: you told me it'd be ok to just get rid of them for now + <pochu> so I'm more thinking of fixing max_priority and (base) priority and leaving thread's scheduling priority as it currently is + <pochu> s/so/though/ + <antrik> pochu: well, my fear is that keeping the thread priority handling as ist while changing task priority handling would complicate the changes, while giving us no real benefit... + <antrik> though looking at what Darwin did there should give you an idea what it involves exactly... + <pochu> antrik: what would you propose, keeping sched_priority == max_priority ? + <pochu> s/keeping/making/ + <antrik> yes, if that means what I think it does ;-) + <antrik> and keeping the priority of all threads equal to the task priority for now + <antrik> of course this only makes sense if changing it like this is actually simpler than extending the current handling... + <antrik> again, I can't judge this without actually knowing the code in question. looking at Darwin should give you an idea... + <pochu> I think leaving it as is, making it work with the task's max_priority changes would be easier + <antrik> perhaps I'm totally overestimating the amount of changes required to do what Darwin does + <antrik> OTOH, carrying around dead code isn't exactly helping the maintainability and efficiency of gnumach... + <antrik> so I'm a bit ambivalent on this + <antrik> should we go for minimal changes here, or use this occasion to simplify things?... + <antrik> I guess it would be good to bring this up on the ML + <cfhammar> in the context of gsoc i'd say minimal changes + <pochu> there's also neal's point on keeping backwards compatibility as much as possible + <neal> my point was not backwards compatibility at all costs + <antrik> I'm still not convinced this is a valid point :-) + <neal> but to not gratutiously break things + <antrik> neal: well, I never suggested breaking things just because we can... I only suggested breaking things to make the code and interface simpler :-) + <antrik> I do not insist on it though + <neal> at that time, we did not know how Mac did it + <antrik> I only think it would be good to get into a habit that Mach interfaces are not sacred... + <neal> and, I also had a proposal, which I think is not difficult to implement given the existing patch + <antrik> but as I said, I do not feel strongly about this. if people feel more confident about a minimal change, I'm fine with that :-) + <antrik> neal: err... IIRC your proposal was only about the number of nice levels? we are discussing the interface change necessary to implement POSIX semantics properly + <antrik> or am I misremembering? + <pochu> antrik: he argues that with that number of nice levels, we could keep backwards compatibility for the 0..31 levels, and for 0..39 for POSIX compatibility + <antrik> pochu: yes, I remember that part + <neal> antrik : My suggestion was: raise the number of nice levels to 160 and introduce a new interface which uses those. Adjust the old interface to space by 160/32 + <antrik> neal: I think I said it before: the problem is not *only* in the number of priority levels. the semantics are also wrong. which is why Darwin added a max_priority for tasks + <neal> what do you mean the semantics are wrong? + <neal> I apologize if you already explained this. + <antrik> hm... I explained it at some point, but I guess you were not present at that conversation + <neal> I got disconnected recently so I likely don't have it in backlog. + <antrik> in POSIX, any process can lower its priority; while only privileged processes can raise it + <antrik> Mach distinguishes between "current" and "max" priority for threads: "max" behaves like POSIX; while "current" can be raised or lowered at will, as long as it stays below "max" + <antrik> for tasks, there is only a "current" priority + <antrik> (which applies to newly created threads, and optionally can be set for all current threads while changing the task priority) + <antrik> glibc currently uses the existing task priorities, which leads to *completely* broken semantics + <antrik> instead, we need something like a max task priority -- which is exactly what Darwin added + <neal> yes + <antrik> (the "current" task priority is useless for POSIX semantics as far as I can tell; and regarding thread priorities, I doubt we actually use them at all?...) + <cfhammar> where does a new thread get its initial max_priority from? + <antrik> cfhammar: from the creator thread IIRC + <pochu> yes + +2010-08-12 + + <pochu> my plan is to change the number of priority levels and the threads/tasks priority handling, then add new RPCs to play with them and make the old ones stay compatible, then make glibc use the new RPCs + +--- + +Another nice issue: [[nice_changes_priority_of_parent_shell]]. diff --git a/open_issues/nightly_builds.mdwn b/open_issues/nightly_builds.mdwn new file mode 100644 index 00000000..167e7375 --- /dev/null +++ b/open_issues/nightly_builds.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]] + +We'd like to have nightly builds for the whole [[toolchain]], and then do some +automatic [[unit_testing]] on them. + +Resources: + + * [[hurd/running/Nix]] + + * [[toolchain/cross-gnu]] + + * [[Debian_Cross_Toolchain]] + + * As reported in the [[news/2010-05-31]] news, there's Hydra doing nightly + builds / Nix packages. + + * <http://hudson-ci.org/>, <http://jenkins-ci.org/> + + * <http://buildbot.net/> + +--- + +See also [[nightly_builds_deb_packages]]. diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn new file mode 100644 index 00000000..11fc4c79 --- /dev/null +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +I'd be quite helpful to have nightly builds in form of Debian `.deb` +packages. + + * <http://noone.org/talks/vcs-buildd/> (german) + + * Need to have an automation to get from Hurd upstream Git branches to + a branch usable in Debian. + +--- + +There is infrastructure available to test whole OS installations. + + * <http://www.os-autoinst.org/> + +--- + +[[Debian_Cross_Toolchain]] for cross-building? + +--- + +See also [[nightly_builds]]. diff --git a/open_issues/notmuch_n_gmane.mdwn b/open_issues/notmuch_n_gmane.mdwn new file mode 100644 index 00000000..664c9876 --- /dev/null +++ b/open_issues/notmuch_n_gmane.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="Notmuch'n'Gmane"]] + +[[!taglink open_issue_documentation]]; [[ikiwiki]] issue. + +In `\[[!message-id +"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]]`, underscores +are replaced with spaces in the rendered output: [[!message-id +"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]]. diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn new file mode 100644 index 00000000..9ff5fb51 --- /dev/null +++ b/open_issues/nptl.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2010 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_libpthread open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + <tschwinge> Other question: how difficult is a NPTL port? Futexes and some kernel interfaces for scheduling stuff etc. -- what else? + <youpi> actually NPTL doesn't _require_ futexes + <youpi> it just requires low-level locks + <youpi> Mmm, it seems to be so only in principle + <youpi> I can see futex names here and there in the generic code + <youpi> looks like Drepper isn't disciplined enough in that area either + <tschwinge> (well, why would he...) + <youpi> I'm not sure we really want to port NPTL + <tschwinge> OK. + <youpi> Drepper will keep finding things to add + <youpi> while the interface between glibc and libpthread isn't increasing _so_ much + <tschwinge> ... and even less so the interfavce that actual applications are using. + <tschwinge> We'd need to evaluate which benefits NPTL would bring. + +--- + +# Resources + + * <http://www.akkadia.org/drepper/nptl-design.pdf> + + * <http://nptltracetool.sourceforge.net/> + + * <http://posixtest.sourceforge.net/> diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn new file mode 100644 index 00000000..3f77a0f2 --- /dev/null +++ b/open_issues/o_exec.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="O_EXEC"]] + +[[!tag open_issue_glibc open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-24 + + <pinotree> interesting, glibc on every OS except hurd (so including linux + too) does not define O_EXEC + <pinotree> can somebody please help me understand a POSIX behaviour? + <pinotree> it's about fexecve: + http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html + <pinotree> basically, it seems to me (reading the "errors" and "application + usage" sections) that O_EXEC for open() the fd is not mandatory, and if + not used fexecve will check for file permission at call time? + <pinotree> because currently libdiskfs and libnetfs require the fd to be + open with O_EXEC + <braunr> "Since execute permission is checked by fexecve(), the file + description fd need not have been opened with the O_EXEC flag" + <braunr> this one makes it clear checking for O_EXEC is wrong + <braunr> it looks like O_EXEC is only needed when you want to have files + for which only the execution permission is set + <braunr> but not the read one + <braunr> (i don't understand the "and write" part though) + <braunr> "exec will fail if the mode of the file associated with fd does + not grant execute permission to the calling process at the time fexecve() + is called." + <braunr> this one strengthens the impression you have, that fexecve indeed + checks file permissions at the time it's called + <braunr> pinotree: hope it helps + <pinotree> so it implies the following: + <pinotree> O_RDONLY → exec works if the file is readable + <braunr> exec works if the file is readable and/or executable (although + without read permissions you can't check it) + <braunr> (well, fexecve) + <pinotree> O_EXEC → exec requires that the permission of the file at + fexecve() time have +x + <braunr> i'd say ye so far + <braunr> yes + <pinotree> so we need to fix lib{disk,net}fs then + <braunr> seems so + <pinotree> enlighting, merci braunr + <braunr> de rien + <pinotree> :) diff --git a/open_issues/ogi.mdwn b/open_issues/ogi.mdwn new file mode 100644 index 00000000..e4372dc0 --- /dev/null +++ b/open_issues/ogi.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +Go through Ognyan Kulev's (ogi) pages, and archive / hunt down what's still +interesting. + + * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/links/> + + * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/> + + * SVN ext2fs (ext2fs / large stores doc) + + done + + * ext3fs et al. + + checking copyright situation, also for thesis / w.r.t. university + project diff --git a/open_issues/open_posix_test_suite.mdwn b/open_issues/open_posix_test_suite.mdwn new file mode 100644 index 00000000..089ea1b1 --- /dev/null +++ b/open_issues/open_posix_test_suite.mdwn @@ -0,0 +1,2715 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +[[!meta title="Open POSIX Test Suite"]] + +Here's a log of a [Open POSIX Test Suite](http://posixtest.sourceforge.net/) +run (get sources, `make`, inspect `logfile`); this is from 2009-07-27 HEAD +sources on a 2009-07-27 Debian GNU/Hurd system. + +The `logfile` has been post-processed with: + + $ sed ↩ + -e '/build: PASS$/d' ↩ + -e '/link: PASS$/d' ↩ + -e '/link: SKIP$/d' ↩ + -e '/execution: PASS$/d' + +The tests that failed as *INTERRUPTED* were hanging and have manually been +interrupted using `kill [PID]`. + + conformance/definitions/signal_h/16-1: build: FAILED: Compiler output: + conformance/definitions/signal_h/16-1.c:14: error: ‘SA_SIGINFO’ undeclared here (not in a function) + conformance/definitions/signal_h/16-1.c:15: error: ‘SA_NOCLDWAIT’ undeclared here (not in a function) + conformance/definitions/signal_h/26-1: build: FAILED: Compiler output: + conformance/definitions/signal_h/26-1.c:9: error: expected ‘)’ before ‘int’ + conformance/definitions/signal_h/26-1.c: In function ‘dummyfcn’: + conformance/definitions/signal_h/26-1.c:13: error: ‘pthread_kill_test’ undeclared (first use in this function) + conformance/definitions/signal_h/26-1.c:13: error: (Each undeclared identifier is reported only once + conformance/definitions/signal_h/26-1.c:13: error: for each function it appears in.) + conformance/definitions/signal_h/26-1.c:13: error: expected ‘;’ before ‘dummyvar’ + conformance/definitions/signal_h/26-1.c:14: error: ‘dummyvar’ undeclared (first use in this function) + conformance/definitions/signal_h/26-1.c:14: error: ‘pthread_kill’ undeclared (first use in this function) + conformance/interfaces/aio_cancel/3-1: build: FAILED: Compiler output: + conformance/interfaces/aio_cancel/3-1.c: In function ‘main’: + conformance/interfaces/aio_cancel/3-1.c:96: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_cancel/3-1.c:96: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_cancel/3-1.c:96: error: for each function it appears in.) + conformance/interfaces/aio_cancel/3-1.c:97: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_fsync/1-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/1-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/1-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/1-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/10-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/10-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/10-1.c:33: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/10-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/11-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/11-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/11-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/11-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/13-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/13-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/13-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/6-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/6-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/6-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/6-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/7-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/7-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/7-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/7-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/12-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/12-1.c: In function ‘main’: + conformance/interfaces/aio_read/12-1.c:34: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/12-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/13-1.c: In function ‘main’: + conformance/interfaces/aio_read/13-1.c:33: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/13-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/14-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/14-1.c: In function ‘main’: + conformance/interfaces/aio_read/14-1.c:34: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/14-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/15-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/15-1.c: In function ‘main’: + conformance/interfaces/aio_read/15-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/15-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/6-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/6-1.c: In function ‘main’: + conformance/interfaces/aio_read/6-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/6-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_suspend/1-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/1-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/1-1.c:120: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/1-1.c:120: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/1-1.c:120: error: for each function it appears in.) + conformance/interfaces/aio_suspend/1-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/2-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_suspend/2-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/2-1.c:31: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_suspend/2-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_suspend/6-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/6-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/6-1.c:116: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/6-1.c:116: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/6-1.c:116: error: for each function it appears in.) + conformance/interfaces/aio_suspend/6-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/7-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/7-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/7-1.c:118: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/7-1.c:118: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/7-1.c:118: error: for each function it appears in.) + conformance/interfaces/aio_suspend/7-1.c:124: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/8-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/8-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/8-1.c:121: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/8-1.c:121: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/8-1.c:121: error: for each function it appears in.) + conformance/interfaces/aio_suspend/8-1.c:127: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_write/10-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/10-1.c: In function ‘main’: + conformance/interfaces/aio_write/10-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/10-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/11-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/11-1.c: In function ‘main’: + conformance/interfaces/aio_write/11-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/11-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/12-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/12-1.c: In function ‘main’: + conformance/interfaces/aio_write/12-1.c:31: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/12-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/13-1.c: In function ‘main’: + conformance/interfaces/aio_write/13-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/13-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/4-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/4-1.c: In function ‘main’: + conformance/interfaces/aio_write/4-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/4-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/fork/2-1: build: FAILED: Compiler output: + conformance/interfaces/fork/2-1.c: In function ‘main’: + conformance/interfaces/fork/2-1.c:240: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/fork/2-1.c:240: error: (Each undeclared identifier is reported only once + conformance/interfaces/fork/2-1.c:240: error: for each function it appears in.) + conformance/interfaces/fork/2-1.c:241: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function) + conformance/interfaces/lio_listio/1-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/1-1.c: In function ‘main’: + conformance/interfaces/lio_listio/1-1.c:110: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/1-1.c:110: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/1-1.c:110: error: for each function it appears in.) + conformance/interfaces/lio_listio/1-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/10-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/10-1.c: In function ‘main’: + conformance/interfaces/lio_listio/10-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/10-1.c:107: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/10-1.c:107: error: for each function it appears in.) + conformance/interfaces/lio_listio/10-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/11-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/11-1.c: In function ‘main’: + conformance/interfaces/lio_listio/11-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/11-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/11-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/11-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/14-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/14-1.c: In function ‘main’: + conformance/interfaces/lio_listio/14-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/14-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/14-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/14-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/15-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/15-1.c: In function ‘main’: + conformance/interfaces/lio_listio/15-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/15-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/15-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/15-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/16-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/16-1.c: In function ‘main’: + conformance/interfaces/lio_listio/16-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/16-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/17-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/17-1.c: In function ‘main’: + conformance/interfaces/lio_listio/17-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/17-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/19-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/19-1.c: In function ‘main’: + conformance/interfaces/lio_listio/19-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/19-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/2-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/2-1.c: In function ‘main’: + conformance/interfaces/lio_listio/2-1.c:106: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/2-1.c:106: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/2-1.c:106: error: for each function it appears in.) + conformance/interfaces/lio_listio/2-1.c:118: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/20-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/20-1.c: In function ‘main’: + conformance/interfaces/lio_listio/20-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/20-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/21-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/21-1.c: In function ‘main’: + conformance/interfaces/lio_listio/21-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/21-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/22-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/22-1.c: In function ‘main’: + conformance/interfaces/lio_listio/22-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/22-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/23-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/23-1.c: In function ‘main’: + conformance/interfaces/lio_listio/23-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/23-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/24-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/24-1.c: In function ‘main’: + conformance/interfaces/lio_listio/24-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/24-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/25-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/25-1.c: In function ‘main’: + conformance/interfaces/lio_listio/25-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/25-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/3-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/3-1.c: In function ‘main’: + conformance/interfaces/lio_listio/3-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/3-1.c:107: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/3-1.c:107: error: for each function it appears in.) + conformance/interfaces/lio_listio/3-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/4-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/4-1.c: In function ‘main’: + conformance/interfaces/lio_listio/4-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/4-1.c:114: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/4-1.c:114: error: for each function it appears in.) + conformance/interfaces/lio_listio/4-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/7-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/7-1.c: In function ‘main’: + conformance/interfaces/lio_listio/7-1.c:113: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/7-1.c:113: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/7-1.c:113: error: for each function it appears in.) + conformance/interfaces/lio_listio/7-1.c:125: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/mq_open/27-1: build: FAILED: Compiler output: + conformance/interfaces/mq_open/27-1.c: In function ‘main’: + conformance/interfaces/mq_open/27-1.c:27: error: ‘PATH_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_open/27-1.c:27: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_open/27-1.c:27: error: for each function it appears in.) + cc1: warnings being treated as errors + conformance/interfaces/mq_open/27-1.c:27: error: unused variable ‘qname’ + conformance/interfaces/mq_send/13-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/13-1.c:30: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function) + conformance/interfaces/mq_send/4-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-1.c: In function ‘main’: + conformance/interfaces/mq_send/4-1.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-1.c:41: error: for each function it appears in.) + conformance/interfaces/mq_send/4-2: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-2.c: In function ‘main’: + conformance/interfaces/mq_send/4-2.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-2.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-2.c:41: error: for each function it appears in.) + conformance/interfaces/mq_send/4-3: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-3.c: In function ‘main’: + conformance/interfaces/mq_send/4-3.c:51: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-3.c:51: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-3.c:51: error: for each function it appears in.) + conformance/interfaces/mq_send/7-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/7-1.c: In function ‘main’: + conformance/interfaces/mq_send/7-1.c:60: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/7-1.c:60: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/7-1.c:60: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/13-1: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/13-1.c:31: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function) + conformance/interfaces/mq_timedsend/4-1: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-1.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-1.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-1.c:45: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/4-2: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-2.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-2.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-2.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-2.c:45: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/4-3: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-3.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-3.c:55: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-3.c:55: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-3.c:55: error: for each function it appears in.) + conformance/interfaces/pthread_attr_getstack/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_getstack/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: for each function it appears in.) + conformance/interfaces/pthread_attr_getstacksize/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_getstacksize/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/2-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/2-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/4-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/4-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/6-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/6-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/7-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/7-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/2-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/2-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/4-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/4-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: for each function it appears in.) + conformance/interfaces/pthread_key_create/speculative/5-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_key_create/speculative/5-1.c:37: error: ‘PTHREAD_KEYS_MAX’ undeclared here (not in a function) + conformance/interfaces/pthread_once/3-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_once/3-1.c: In function ‘main’: + conformance/interfaces/pthread_once/3-1.c:71: error: expected expression before ‘{’ token + conformance/interfaces/pthread_once/6-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_once/6-1.c: In function ‘test’: + conformance/interfaces/pthread_once/6-1.c:199: error: expected expression before ‘{’ token + conformance/interfaces/sched_yield/1-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/sched_yield/1-1.c: In function ‘set_process_affinity’: + conformance/interfaces/sched_yield/1-1.c:87: error: implicit declaration of function ‘__CPU_ZERO_S’ + conformance/interfaces/sched_yield/1-1.c:89: error: implicit declaration of function ‘__CPU_SET_S’ + conformance/interfaces/sched_yield/1-1.c: In function ‘set_thread_affinity’: + conformance/interfaces/sched_yield/1-1.c:119: error: implicit declaration of function ‘pthread_setaffinity_np’ + conformance/interfaces/sched_yield/1-1.c: In function ‘runner’: + conformance/interfaces/sched_yield/1-1.c:136: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’ + conformance/interfaces/sched_yield/1-1.c: In function ‘busy_thread’: + conformance/interfaces/sched_yield/1-1.c:159: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’ + conformance/interfaces/sem_init/6-1: build: FAILED: Compiler output: + conformance/interfaces/sem_init/6-1.c: In function ‘main’: + conformance/interfaces/sem_init/6-1.c:29: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function) + conformance/interfaces/sem_init/6-1.c:29: error: (Each undeclared identifier is reported only once + conformance/interfaces/sem_init/6-1.c:29: error: for each function it appears in.) + conformance/interfaces/sem_open/5-1: build: FAILED: Compiler output: + conformance/interfaces/sem_open/5-1.c: In function ‘main’: + conformance/interfaces/sem_open/5-1.c:32: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function) + conformance/interfaces/sem_open/5-1.c:32: error: (Each undeclared identifier is reported only once + conformance/interfaces/sem_open/5-1.c:32: error: for each function it appears in.) + conformance/interfaces/sigaction/10-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/10-1.c: In function ‘main’: + conformance/interfaces/sigaction/10-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/10-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/10-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigaction/11-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/11-1.c: In function ‘main’: + conformance/interfaces/sigaction/11-1.c:50: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/11-1.c:50: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/11-1.c:50: error: for each function it appears in.) + conformance/interfaces/sigaction/19-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-1.c: In function ‘main’: + conformance/interfaces/sigaction/19-1.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-1.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-1.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-10: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-10.c: In function ‘main’: + conformance/interfaces/sigaction/19-10.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-10.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-10.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-11: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-11.c: In function ‘main’: + conformance/interfaces/sigaction/19-11.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-11.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-11.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-12: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-12.c: In function ‘main’: + conformance/interfaces/sigaction/19-12.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-12.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-12.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-13: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-13.c: In function ‘main’: + conformance/interfaces/sigaction/19-13.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-13.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-13.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-14: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-14.c: In function ‘main’: + conformance/interfaces/sigaction/19-14.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-14.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-14.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-15: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-15.c: In function ‘main’: + conformance/interfaces/sigaction/19-15.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-15.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-15.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-16: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-16.c: In function ‘main’: + conformance/interfaces/sigaction/19-16.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-16.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-16.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-17: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-17.c: In function ‘main’: + conformance/interfaces/sigaction/19-17.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-17.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-17.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-18: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-18.c: In function ‘main’: + conformance/interfaces/sigaction/19-18.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-18.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-18.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-19: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-19.c: In function ‘main’: + conformance/interfaces/sigaction/19-19.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-19.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-19.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-2: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-2.c: In function ‘main’: + conformance/interfaces/sigaction/19-2.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-2.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-2.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-20: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-20.c: In function ‘main’: + conformance/interfaces/sigaction/19-20.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-20.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-20.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-21: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-21.c: In function ‘main’: + conformance/interfaces/sigaction/19-21.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-21.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-21.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-22: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-22.c: In function ‘main’: + conformance/interfaces/sigaction/19-22.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-22.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-22.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-23: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-23.c: In function ‘main’: + conformance/interfaces/sigaction/19-23.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-23.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-23.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-24: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-24.c: In function ‘main’: + conformance/interfaces/sigaction/19-24.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-24.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-24.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-25: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-25.c: In function ‘main’: + conformance/interfaces/sigaction/19-25.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-25.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-25.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-26: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-26.c: In function ‘main’: + conformance/interfaces/sigaction/19-26.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-26.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-26.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-3: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-3.c: In function ‘main’: + conformance/interfaces/sigaction/19-3.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-3.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-3.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-4: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-4.c: In function ‘main’: + conformance/interfaces/sigaction/19-4.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-4.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-4.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-5: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-5.c: In function ‘main’: + conformance/interfaces/sigaction/19-5.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-5.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-5.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-6: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-6.c: In function ‘main’: + conformance/interfaces/sigaction/19-6.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-6.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-6.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-7: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-7.c: In function ‘main’: + conformance/interfaces/sigaction/19-7.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-7.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-7.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-8: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-8.c: In function ‘main’: + conformance/interfaces/sigaction/19-8.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-8.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-8.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-9: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-9.c: In function ‘main’: + conformance/interfaces/sigaction/19-9.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-9.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-9.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/21-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/21-1.c: In function ‘main’: + conformance/interfaces/sigaction/21-1.c:36: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function) + conformance/interfaces/sigaction/21-1.c:36: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/21-1.c:36: error: for each function it appears in.) + conformance/interfaces/sigaction/29-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/29-1.c: In function ‘handler’: + conformance/interfaces/sigaction/29-1.c:95: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/29-1.c:95: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/29-1.c:95: error: for each function it appears in.) + conformance/interfaces/sigaction/29-1.c: In function ‘main’: + conformance/interfaces/sigaction/29-1.c:133: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/29-1.c:145: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/30-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/30-1.c: In function ‘main’: + conformance/interfaces/sigaction/30-1.c:117: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/30-1.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/30-1.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-1.c: In function ‘main’: + conformance/interfaces/sigaction/6-1.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-1.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-1.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-10: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-10.c: In function ‘main’: + conformance/interfaces/sigaction/6-10.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-10.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-10.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-11: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-11.c: In function ‘main’: + conformance/interfaces/sigaction/6-11.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-11.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-11.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-12: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-12.c: In function ‘main’: + conformance/interfaces/sigaction/6-12.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-12.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-12.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-13: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-13.c: In function ‘main’: + conformance/interfaces/sigaction/6-13.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-13.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-13.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-14: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-14.c: In function ‘main’: + conformance/interfaces/sigaction/6-14.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-14.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-14.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-15: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-15.c: In function ‘main’: + conformance/interfaces/sigaction/6-15.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-15.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-15.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-16: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-16.c: In function ‘main’: + conformance/interfaces/sigaction/6-16.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-16.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-16.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-17: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-17.c: In function ‘main’: + conformance/interfaces/sigaction/6-17.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-17.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-17.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-18: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-18.c: In function ‘main’: + conformance/interfaces/sigaction/6-18.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-18.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-18.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-19: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-19.c: In function ‘main’: + conformance/interfaces/sigaction/6-19.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-19.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-19.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-2: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-2.c: In function ‘main’: + conformance/interfaces/sigaction/6-2.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-2.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-2.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-20: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-20.c: In function ‘main’: + conformance/interfaces/sigaction/6-20.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-20.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-20.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-21: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-21.c: In function ‘main’: + conformance/interfaces/sigaction/6-21.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-21.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-21.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-22: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-22.c: In function ‘main’: + conformance/interfaces/sigaction/6-22.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-22.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-22.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-23: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-23.c: In function ‘main’: + conformance/interfaces/sigaction/6-23.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-23.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-23.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-24: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-24.c: In function ‘main’: + conformance/interfaces/sigaction/6-24.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-24.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-24.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-25: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-25.c: In function ‘main’: + conformance/interfaces/sigaction/6-25.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-25.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-25.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-26: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-26.c: In function ‘main’: + conformance/interfaces/sigaction/6-26.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-26.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-26.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-3: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-3.c: In function ‘main’: + conformance/interfaces/sigaction/6-3.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-3.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-3.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-4: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-4.c: In function ‘main’: + conformance/interfaces/sigaction/6-4.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-4.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-4.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-5: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-5.c: In function ‘main’: + conformance/interfaces/sigaction/6-5.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-5.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-5.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-6: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-6.c: In function ‘main’: + conformance/interfaces/sigaction/6-6.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-6.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-6.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-7: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-7.c: In function ‘main’: + conformance/interfaces/sigaction/6-7.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-7.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-7.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-8: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-8.c: In function ‘main’: + conformance/interfaces/sigaction/6-8.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-8.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-8.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-9: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-9.c: In function ‘main’: + conformance/interfaces/sigaction/6-9.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-9.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-9.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/9-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/9-1.c: In function ‘main’: + conformance/interfaces/sigaction/9-1.c:49: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/9-1.c:49: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/9-1.c:49: error: for each function it appears in.) + conformance/interfaces/sigqueue/1-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/1-1.c: In function ‘myhandler’: + conformance/interfaces/sigqueue/1-1.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/1-1.c:33: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/1-1.c:33: error: for each function it appears in.) + conformance/interfaces/sigqueue/1-1.c: In function ‘main’: + conformance/interfaces/sigqueue/1-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/1-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/4-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/4-1.c: In function ‘main’: + conformance/interfaces/sigqueue/4-1.c:45: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/4-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/4-1.c:45: error: for each function it appears in.) + conformance/interfaces/sigqueue/4-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/5-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/5-1.c: In function ‘main’: + conformance/interfaces/sigqueue/5-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/5-1.c:48: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/5-1.c:48: error: for each function it appears in.) + conformance/interfaces/sigqueue/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/6-1.c: In function ‘main’: + conformance/interfaces/sigqueue/6-1.c:55: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/6-1.c:55: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/6-1.c:55: error: for each function it appears in.) + conformance/interfaces/sigqueue/6-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/7-1.c: In function ‘main’: + conformance/interfaces/sigqueue/7-1.c:52: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1.c:52: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/7-1.c:52: error: for each function it appears in.) + conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/8-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/8-1.c: In function ‘main’: + conformance/interfaces/sigqueue/8-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/8-1.c:46: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/8-1.c:46: error: for each function it appears in.) + conformance/interfaces/sigqueue/8-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/9-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/9-1.c: In function ‘main’: + conformance/interfaces/sigqueue/9-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/9-1.c:46: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/9-1.c:46: error: for each function it appears in.) + conformance/interfaces/sigqueue/9-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/2-1: build: FAILED: Compiler output: + conformance/interfaces/sigwait/2-1.c: In function ‘main’: + conformance/interfaces/sigwait/2-1.c:45: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/2-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwait/2-1.c:45: error: for each function it appears in.) + conformance/interfaces/sigwait/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigwait/7-1.c: In function ‘main’: + conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/7-1.c:114: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwait/7-1.c:114: error: for each function it appears in.) + conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/2-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/2-1.c:44: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1.c:44: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/2-1.c:44: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/5-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/5-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/5-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/5-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/5-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/6-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/6-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/6-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/6-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/7-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/7-1.c:48: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/7-1.c:48: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/7-1.c:48: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/7-1.c:51: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/8-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/8-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/8-1.c:47: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/8-1.c:47: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/8-1.c:47: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/8-1.c:50: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/definitions/mqueue_h/1-1: execution: UNTESTED: Output: + Not Implemented! + conformance/definitions/mqueue_h/10-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/11-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/2-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/3-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/4-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/5-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/6-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/7-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/8-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/9-1: execution: UNTESTED: Output: + Test not implemented! + conformance/interfaces/aio_cancel/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/10-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/2-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/12-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/14-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/4-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-3: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-4: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/10-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/11-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/11-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/3-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/3-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/1-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/8-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/9-2: execution: UNSUPPORTED: Output: + conformance/interfaces/clock_getcpuclockid/1-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_getcpuclockid/2-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_getres/3-1: execution: FAILED: Output: + clock_getres() failed + Test FAILED + conformance/interfaces/clock_getres/7-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME not supported + conformance/interfaces/clock_getres/8-1: execution: UNSUPPORTED: Output: + _POSIX_THREAD_CPUTIME not supported + conformance/interfaces/clock_gettime/3-1: execution: UNSUPPORTED: Output: + CLOCK_MONOTONIC unsupported + conformance/interfaces/clock_gettime/4-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_nanosleep/10-1: execution: FAILED: Output: + In handler + errno != EINTR + Test FAILED + conformance/interfaces/clock_nanosleep/9-1: execution: FAILED: Output: + In handler + clock_nanosleep() did not return EINTR + Child did not exit normally. + Test FAILED + conformance/interfaces/clock_settime/1-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/19-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/4-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/4-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/clock_settime/5-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/5-2: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/7-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/7-2: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/8-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/speculative/4-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/clock_settime/speculative/4-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/fork/1-1: execution: UNRESOLVED: Output: + [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore) + [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore) + conformance/interfaces/fork/11-1: execution: INTERRUPTED: Output: + conformance/interfaces/fork/12-1: execution: FAILED: Output: + [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork + [09:57:13]SIGUSR1 and SIGUSR2 are blocked in child + [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: The new process was created with SIGUSR1 pending + [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork + [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: Child exited abnormally + conformance/interfaces/fork/13-1: execution: UNRESOLVED: Output: + [09:57:14]Test conformance/interfaces/fork/13-1.c unresolved: got 1073741902 (Function not implemented) on line 117 (Failed to set interval timer for ITIMER_VIRTUAL) + conformance/interfaces/fork/14-1: execution: UNRESOLVED: Output: + [09:57:14]Test conformance/interfaces/fork/14-1.c unresolved: got 1073741869 (Operation not supported) on line 100 (Failed to create the named semaphore) + conformance/interfaces/fork/17-1: execution: UNRESOLVED: Output: + [09:57:15]Test conformance/interfaces/fork/17-1.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value) + conformance/interfaces/fork/17-2: execution: UNRESOLVED: Output: + [09:57:15]Test conformance/interfaces/fork/17-2.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value) + conformance/interfaces/fork/18-1: execution: UNRESOLVED: Output: + [09:57:16]Test conformance/interfaces/fork/18-1.c unresolved: got 1073741902 (Function not implemented) on line 128 (Failed to create a timer) + conformance/interfaces/fork/19-1: execution: UNRESOLVED: Output: + [09:57:16]Test conformance/interfaces/fork/19-1.c unresolved: got 1073741902 (Function not implemented) on line 114 (Failed to create the message queue descriptor) + conformance/interfaces/fork/21-1: execution: UNRESOLVED: Output: + [09:57:17]Test conformance/interfaces/fork/21-1.c unresolved: got 1073741869 (Operation not supported) on line 128 (Failed to open the semaphore) + conformance/interfaces/fork/22-1: execution: UNTESTED: Output: + [09:57:17]File conformance/interfaces/fork/22-1.c cannot test: The testcase needs CPUTIME or THREAD_CPUTIME support + conformance/interfaces/fork/8-1: execution: FAILED: Output: + [09:57:20]Test conformance/interfaces/fork/8-1.c FAILED: The process is created with non-zero tms_cutime or tms_cstime + conformance/interfaces/fsync/7-1: execution: FAILED: Output: + fsync/7-1.c Test Fail: Expect EINVAL, get: (ipc/mig) bad request message ID + conformance/interfaces/lio_listio/12-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/13-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/18-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/mlock/10-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlock/5-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlock/8-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlockall/13-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/13-2: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/3-6: execution: UNRESOLVED: Output: + An error occurs when calling mlockall(): Function not implemented + conformance/interfaces/mlockall/3-7: execution: UNRESOLVED: Output: + An error occurs when calling mlockall(): Function not implemented + conformance/interfaces/mlockall/8-1: execution: UNRESOLVED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/speculative/15-1: execution: UNRESOLVED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mmap/11-4: execution: FAILED: Output: + pa: 0x28000 + pa_2: 0x29000 + Test Fail: mmap/11-4.c Modification of the partial page at the end of an object is written out + conformance/interfaces/mmap/11-5: execution: FAILED: Output: + Test Fail: mmap/11-5.c Modification of the partial page at the end of an object is written out + conformance/interfaces/mmap/13-1: execution: FAILED: Output: + Time before write(): 1248767904 + Time before mmap(): 1248767905 + Time before munmap(): 1248767906 + atime1: 1248767904, atime2: 1248767904, atime3: 1248767904 + Test Fail mmap/13-1.c st_atime did not update properly + conformance/interfaces/mmap/14-1: execution: FAILED: Output: + Time before write(): 1248767907 + Time before mmap(): 1248767908 + Time before write reference: 1248767909 + Time before msync(): 1248767910 + ctime1: 1248767909, ctime2: 1248767909 + mtime1: 1248767909, mtime2: 1248767909 + Test Fail mmap/14-1.c st_ctime and st_mtime were not updated properly + conformance/interfaces/mmap/18-1: execution: UNRESOLVED: Output: + mmap/18-1.c Error at mlockall(): Function not implemented + conformance/interfaces/mmap/21-1: execution: FAILED: Output: + Test FAIL + +Kernel panic [[!tag open_issue_gnumach]] (at conformance/interfaces/mmap/24-1): + + Assertion `(object == VM_OBJECT_NULL) || (object->ref_count > 0) || ((object->paging_in_progress != 0) && internal)' failed in file "../gnumach-1-branch-Xen-branch/vm/vm_object.c", line 2087 + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006abc1,20067354,2006708c,827,2e4e5514) + 0x20020ace(20067354,2006708c,827,2001c900,2e3b54f4) + 0x20035ef2(2e4e5514,1000,0,200194c0,2e3b54f4) + 0x2003929f(2e3b4d64,2fc6ff9c,400,0,1) + 0x200577ea(1,15ff998,400,0,1) + 0x20006838(1,15ff998,400,0,1) + >>>>> user space <<<<< + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x20035ef2 0x2003929f 0x200577ea 0x20006838 + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + Assert + ??:0 + vm_object_enter + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_object.c:2109 + vm_map + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_user.c:326 + syscall_vm_map + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_mig.c:657 + mach_call_call + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083 + +Disable the panic-causing test (conformance/interfaces/mmap/24-1) and restart: + + [...] + conformance/interfaces/mmap/24-2: execution: INTERRUPTED: Output: + conformance/interfaces/mmap/27-1: execution: UNTESTED: Output: + Test Untested: MAP_FIXED defined + conformance/interfaces/mmap/28-1: execution: FAILED: Output: + Test Fail: mmap/28-1.c Got no error at mmap() + conformance/interfaces/mmap/31-1: execution: FAILED: Output: + Test FAIL: expect EOVERFLOW but get other error: Cannot allocate memory + off: fffff000, len: fffff000 + conformance/interfaces/mmap/6-4: execution: FAILED: Output: + Test Fail: Did not get EACCES as expected + conformance/interfaces/mmap/6-6: execution: FAILED: Output: + Test Fail: Did not get EACCES as expected + conformance/interfaces/mmap/7-1: execution: UNRESOLVED: Output: + mmap/7-1.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/mmap/7-2: execution: UNRESOLVED: Output: + mmap/7-2.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/mq_close/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_close/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 2-1: mq_open: Function not implemented + unexpected error: mq_close 2-1: read: EOF + conformance/interfaces/mq_close/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 3-1: mq_open: Function not implemented + conformance/interfaces/mq_close/3-2: execution: FAILED: Output: + errno != EBADF on invalid descriptor + Test FAILED + conformance/interfaces/mq_close/3-3: execution: FAILED: Output: + errno != EBADF on invalid descriptor + Test FAILED + conformance/interfaces/mq_close/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 4-1: mq_open: Function not implemented + conformance/interfaces/mq_close/5-1: execution: UNTESTED: Output: + Functionality of using mqdes after mq_close() and before + mq_open() will not be tested as POSIX says this is undefined. + conformance/interfaces/mq_getattr/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 2-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/2-2: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 2-2: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 3-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 4-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/speculative/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 7-1: mq_open(): Function not implemented + conformance/interfaces/mq_notify/1-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 1-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 2-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 3-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 4-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/5-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 5-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/8-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 8-1: mq_open(): Function not implemented + conformance/interfaces/mq_notify/9-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 9-1: mq_open: Function not implemented + conformance/interfaces/mq_open/1-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/10-1: execution: UNTESTED: Output: + Will not test the user ID and group ID of a created + message queue as we would need multiple users and + groups on the system to test. + Will not test the file permissions as testing would + be implementation defined. + conformance/interfaces/mq_open/11-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/12-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/13-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/14-1: execution: UNTESTED: Output: + Will not test calling process privileges on name + as POSIX does not define when this error occurs. + conformance/interfaces/mq_open/15-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/16-1: execution: FAILED: Output: + Test FAILED - mq_open() never succeeded + conformance/interfaces/mq_open/17-1: execution: UNTESTED: Output: + Will not test setting O_EXCL without O_CREAT because + results are undefined. + conformance/interfaces/mq_open/18-1: execution: FAILED: Output: + mq_open() did not return success w/O_NONBLOCK set: Function not implemented + Test FAILED + conformance/interfaces/mq_open/19-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/20-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/22-1: execution: UNTESTED: Output: + Will not test returning EACCESS when privileges are denied + as POSIX does not define when this error occurs. + conformance/interfaces/mq_open/23-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/24-1: execution: UNTESTED: Output: + Will not test mq_open() being interrupted as it is + not possible to predictably interrupt an mq_open(). + conformance/interfaces/mq_open/25-1: execution: UNTESTED: Output: + Will not test mq_open() failing with EINVAL if mq_open() + is not supported for the name parameter as + unsupported names are implementation defined. + conformance/interfaces/mq_open/25-2: execution: FAILED: Output: + errno != EINVAL for mq_maxmsg 0 + errno != EINVAL for mq_maxmsg -1 + errno != EINVAL for mq_maxmsg -2147483648 + errno != EINVAL for mq_msgsize 0 + errno != EINVAL for mq_msgsize -1 + errno != EINVAL for mq_msgsize -2147483648 + Test FAILED + conformance/interfaces/mq_open/27-2: execution: FAILED: Output: + errno != ENAMETOOLONG + Test FAILED + conformance/interfaces/mq_open/28-1: execution: UNTESTED: Output: + Will not test returning with ENFILE if the system has + too many message queues as this is beyond this + test's domain. + conformance/interfaces/mq_open/29-1: execution: FAILED: Output: + errno != ENOENT + Test FAILED + conformance/interfaces/mq_open/30-1: execution: UNTESTED: Output: + Will not test mq_open() failing with ENOSPC when there + is not enough space to create the message queue + as system space cannot be controlled from this test. + conformance/interfaces/mq_open/4-1: execution: UNTESTED: Output: + Will not test that {OPEN_MAX} file and message queues can + be opened as we cannot determine at run-time if a given + implementation is implemented with a file descriptor. + conformance/interfaces/mq_open/7-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/7-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/7-3: execution: FAILED: Output: + mq_open() for read-only queue did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/8-1: execution: UNRESOLVED: Output: + mq_open() for write-only queue did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/8-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success on read-write queue: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/9-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/speculative/26-1: execution: FAILED: Output: + mq_open() failed before expected + errno != EMFILE on > _POSIX_OPEN_MAX or _POSIX_MQ_OPEN_MAX queues + Test FAILED + conformance/interfaces/mq_receive/1-1: execution: FAILED: Output: + unexpected error: mq_receive 1-1: mq_open: Function not implemented + unexpected error: mq_receive 1-1: mq_send: Function not implemented + unexpected error: mq_receive 1-1: mq_send: Function not implemented + unexpected error: mq_receive 1-1: mq_receive: Function not implemented + unexpected error: mq_receive 1-1: mq_receive: Function not implemented + unexpected error: mq_receive 1-1: mq_close: Function not implemented + unexpected error: mq_receive 1-1: mq_unlink: Function not implemented + FAIL: mq_receive didn't receive the highest priority message + FAIL: receive priority 134520252 != send priority 2 + FAIL: mq_receive didn't receive the correct message + FAIL: receive priority 134520252 != send priority 1 + Test FAILED + conformance/interfaces/mq_receive/10-1: execution: FAILED: Output: + unexpected error: mq_receive 10-1: mq_open: Function not implemented + unexpected error: mq_receive 10-1: mq_close: Function not implemented + unexpected error: mq_receive 10-1: mq_unlink: Function not implemented + errno != EAGAIN + Test FAILED + conformance/interfaces/mq_receive/11-1: execution: FAILED: Output: + unexpected error: mq_receive 11-1: mq_open(): Function not implemented + unexpected error: mq_receive 11-1: mq_close(): Function not implemented + unexpected error: mq_receive 11-1: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_receive/11-2: execution: FAILED: Output: + unexpected error: mq_receive 11-2: mq_open(): Function not implemented + unexpected error: mq_receive 11-2: mq_close: Function not implemented + unexpected error: mq_receive 11-2: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_receive/12-1: execution: FAILED: Output: + unexpected error: mq_receive 12-1: mq_open: Function not implemented + unexpected error: mq_receive 12-1: mq_send: Function not implemented + unexpected error: mq_receive 12-1: mq_close: Function not implemented + unexpected error: mq_receive 12-1: mq_unlink: Function not implemented + errno != EMSGSIZE + Test FAILED + conformance/interfaces/mq_receive/13-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 13-1: mq_open: Function not implemented + mq_close() did not return success: Function not implemented + mq_unlink() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 2-1: mq_open: Function not implemented + unexpected error: mq_receive 2-1: mq_send: Function not implemented + unexpected error: mq_receive 2-1: mq_close: Function not implemented + unexpected error: mq_receive 2-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/5-1: execution: FAILED: Output: + unexpected error: mq_receive 5-1: mq_open: Function not implemented + unexpected error: mq_receive 5-1: mq_send: Function not implemented + unexpected error: mq_receive 5-1: mq_receive: Function not implemented + unexpected error: mq_receive 5-1: mq_close: Function not implemented + unexpected error: mq_receive 5-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_receive/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 7-1: mq_open: Function not implemented + unexpected error: mq_receive 7-1: mq_close: Function not implemented + unexpected error: mq_receive 7-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/8-1: execution: FAILED: Output: + unexpected error: mq_receive 8-1: mq_open: Function not implemented + unexpected error: mq_receive 8-1: mq_send: Function not implemented + unexpected error: mq_receive 8-1: mq_send: Function not implemented + unexpected error: mq_receive 8-1: mq_close: Function not implemented + unexpected error: mq_receive 8-1: mq_unlink: Function not implemented + FAIL: mq_receive didn't return the selected message size correctly + FAIL: mq_receive didn't return the selected message size correctly + Test FAILED + conformance/interfaces/mq_send/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/10-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/11-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/11-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/12-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/14-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/3-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/3-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/5-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/5-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/6-1: execution: UNTESTED: Output: + Priority Scheduling needed to make a reliable test case + for this instance. Will not be tested. + conformance/interfaces/mq_send/8-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/1-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/5-1: execution: UNRESOLVED: Output: + unexpected error: mq_setattr 5-1: mq_open(): Function not implemented + conformance/interfaces/mq_timedreceive/1-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 1-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't receive the highest priority message + FAIL: receive priority 134520424 != send priority 2 + FAIL: mq_timedreceive didn't receive the correct message + FAIL: receive priority 134520424 != send priority 1 + Test FAILED + conformance/interfaces/mq_timedreceive/10-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented + FAIL: mq_receive fails unexpectly + : Function not implemented + unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_timedreceive/10-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented + Unexpected error at mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_timedreceive/11-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 11-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't return the selected message size correctly + FAIL: mq_timedreceive didn't return the selected message size correctly + Test FAILED + conformance/interfaces/mq_timedreceive/13-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 13-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 13-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 13-1: mq_unlink: Function not implemented + errno != EAGAIN + Test FAILED + conformance/interfaces/mq_timedreceive/14-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 14-1: mq_open(): Function not implemented + unexpected error: mq_timedreceive 14-1: mq_close(): Function not implemented + unexpected error: mq_timedreceive 14-1: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_timedreceive/15-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 15-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_unlink: Function not implemented + errno != EMSGSIZE + Test FAILED + conformance/interfaces/mq_timedreceive/17-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-1: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/17-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-2: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/17-3: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-3: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-3: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-3: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/18-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 18-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 18-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 18-1: mq_unlink: Function not implemented + errno != ETIMEDOUT + Test FAILED + conformance/interfaces/mq_timedreceive/18-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 18-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 18-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 18-2: mq_unlink: Function not implemented + errno != ETIMEDOUT + Test FAILED + conformance/interfaces/mq_timedreceive/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 2-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/5-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 5-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_unlink: Function not implemented + mq_timedreceive didn't block on waiting + Test FAILED + conformance/interfaces/mq_timedreceive/5-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 5-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 5-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 5-2: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't block until timout expires + Test FAILED + conformance/interfaces/mq_timedreceive/5-3: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 5-3: mq_open: Function not implemented + mq_close() did not return success: Function not implemented + mq_unlink() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 7-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 7-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 7-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/8-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 8-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 8-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 8-1: mq_unlink: Function not implemented + Using CLOCK_REALTIME + FAIL: mq_timedreceive didn't block until timout expires + Test FAILED + conformance/interfaces/mq_timedreceive/speculative/10-2: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 10-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_send: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_unlink: Function not implemented + mq_timedreceive() did fail on invalid abs_time + Test UNRESOLVED + conformance/interfaces/mq_timedsend/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/10-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/11-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/11-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/12-1: execution: INTERRUPTED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/14-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/15-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/16-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/17-1: execution: UNTESTED: Output: + Will not test timeout resolution. + conformance/interfaces/mq_timedsend/18-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/19-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/20-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/3-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/3-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-3: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/6-1: execution: UNTESTED: Output: + Priority Scheduling needed to make a reliable test case + for this instance. Will not be tested. + conformance/interfaces/mq_timedsend/7-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/8-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/speculative/18-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_unlink/1-1: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 1-1: mq_open: Function not implemented + conformance/interfaces/mq_unlink/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 2-1: mq_open: Function not implemented + unexpected error: mq_unlink 2-1: read: EOF + conformance/interfaces/mq_unlink/2-2: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 2-2: mq_open: Function not implemented + unexpected error: mq_unlink 2-2: read: EOF + conformance/interfaces/mq_unlink/2-3: execution: UNTESTED: Output: + Difficult to detect whether mq_unlink will block until all the reference have been closed + for this instance. Will not be tested. + conformance/interfaces/mq_unlink/7-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/mq_unlink/speculative/7-2: execution: FAILED: Output: + Test FAILED, error is Function not implemented + conformance/interfaces/munlock/10-1: execution: UNRESOLVED: Output: + Unexpected error: Operation not permitted + conformance/interfaces/munlock/11-1: execution: UNRESOLVED: Output: + Unexpected error: Operation not permitted + conformance/interfaces/munlock/7-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/munmap/3-1: execution: FAILED: Output: + Test FAILED: munmap/3-1.c munmap returns: No such file or directory + conformance/interfaces/munmap/4-1: execution: UNRESOLVED: Output: + munmap/4-1.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/munmap/8-1: execution: FAILED: Output: + Test FAILED: Expect EINVAL but get: (os/kern) successful + conformance/interfaces/munmap/9-1: execution: FAILED: Output: + Test Fail: Expect EINVAL while get No such file or directory + conformance/interfaces/nanosleep/10000-1: execution: INTERRUPTED: Output: + conformance/interfaces/nanosleep/5-1: execution: FAILED: Output: + nanosleep() did not return -1 on failure + conformance/interfaces/nanosleep/5-2: execution: FAILED: Output: + In handler + Child did not exit normally. + Test FAILED + conformance/interfaces/nanosleep/6-1: execution: UNRESOLVED: Output: + sleep -1 + nanosleep() did not return -1 on failure + conformance/interfaces/nanosleep/7-1: execution: FAILED: Output: + In handler + nanosleep did not return -1 + Child did not exit normally. + Test FAILED + conformance/interfaces/nanosleep/7-2: execution: FAILED: Output: + In handler + nanosleep() was not interrupted + Child did not exit normally. + Test FAILED + conformance/interfaces/pthread_atfork/1-1: execution: UNRESOLVED: Output: + Error in pthread_atfork + conformance/interfaces/pthread_atfork/1-2: execution: UNRESOLVED: Output: + [11:58:02]Test conformance/interfaces/pthread_atfork/1-2.c unresolved: got 1073741902 (Function not implemented) on line 216 (Failed to register the atfork handlers) + conformance/interfaces/pthread_atfork/2-1: execution: FAILED: Output: + Test FAILED: Expected return value success, instead received 1073741902 + conformance/interfaces/pthread_atfork/2-2: execution: UNRESOLVED: Output: + [11:58:03]Test conformance/interfaces/pthread_atfork/2-2.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers(N,N,N)) + conformance/interfaces/pthread_atfork/3-2: execution: UNRESOLVED: Output: + [11:58:03]Test conformance/interfaces/pthread_atfork/3-2.c unresolved: got 1073741902 (Function not implemented) on line 213 (Failed to register the atfork handlers) + conformance/interfaces/pthread_atfork/3-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_atfork/4-1: execution: UNRESOLVED: Output: + [12:10:53]Test conformance/interfaces/pthread_atfork/4-1.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers) + conformance/interfaces/pthread_attr_getschedparam/1-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_getschedparam 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_getschedpolicy/2-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_getschedpolicy 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setinheritsched/2-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setinheritsched 2-1: pthread_attr_setschedpolicy: (os/kern) successful + conformance/interfaces/pthread_attr_setinheritsched/2-2: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setinheritsched 2-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setinheritsched/2-3: execution: UNRESOLVED: Output: + unexpected error: scheduler 4-1: pthread_setschedparam + conformance/interfaces/pthread_attr_setinheritsched/2-4: execution: UNRESOLVED: Output: + unexpected error: scheduler 4-2: pthread_setschedparam + conformance/interfaces/pthread_attr_setschedparam/1-1: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-2: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 1-2: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-3: execution: UNRESOLVED: Output: + unexpected error: scheduler 3-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-4: execution: UNRESOLVED: Output: + unexpected error: scheduler 3-2: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/speculative/3-1: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 3-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/speculative/3-2: execution: FAILED: Output: + unexpected error: pthread_attr_setschedpaarm 3-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setschedpolicy/1-1: execution: FAILED: Output: + Error on pthread_attr_setschedpolicy() rc=1073741942 + conformance/interfaces/pthread_attr_setschedpolicy/speculative/5-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setschedpolicy 5-1: pthread_attr_setinheritsched + conformance/interfaces/pthread_attr_setscope/5-1: execution: UNTESTED: Output: + Untested for now, cannot find a unsupported inheritsched value + conformance/interfaces/pthread_barrierattr_getpshared/2-1: execution: UNRESOLVED: Output: + Error at pthread_barrierattr_setpshared() + conformance/interfaces/pthread_barrierattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Error at pthread_barrierattr_setpshared() + conformance/interfaces/pthread_cancel/3-1: execution: UNRESOLVED: Output: + unexpected error: pthread_cancel 3-1: pthread_setschedparam + conformance/interfaces/pthread_cancel/5-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_broadcast/1-2: execution: UNRESOLVED: Output: + [12:42:33]Test starting + [12:42:33]System abilities: + [12:42:33] TPS : -1 + [12:42:33] CS : 200112 + [12:42:33] MON : -1 + [12:42:33] MF : 200112 + [12:42:33]Process-shared attributes won't be tested + [12:42:33]Alternative clock won't be tested + [12:42:33]Test conformance/interfaces/pthread_cond_broadcast/1-2.c unresolved: got 1073741846 (Invalid argument) on line 393 ([parent] Failed to set thread stack size) + conformance/interfaces/pthread_cond_broadcast/2-3: execution: UNRESOLVED: Output: + [12:42:36]Test starting + [12:42:36]System abilities: + [12:42:36] TPS : -1 + [12:42:36] CS : 200112 + [12:42:36] MON : -1 + [12:42:36] MF : 200112 + [12:42:36]Process-shared attributes won't be tested + [12:42:36]Alternative clock won't be tested + [12:42:36]Test conformance/interfaces/pthread_cond_broadcast/2-3.c unresolved: got 1073741846 (Invalid argument) on line 384 ([parent] Failed to set thread stack size) + conformance/interfaces/pthread_cond_broadcast/4-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_destroy/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_init/1-2: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/1-2.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/1-3: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/1-3.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/2-2: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/2-2.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/4-1: execution: UNRESOLVED: Output: + Test conformance/interfaces/pthread_cond_init/4-1.c unresolved: got 1073741942 (Not supported) on line 145 (Cond attribute PSHARED failed) + conformance/interfaces/pthread_cond_init/4-2: execution: INTERRUPTED: Output: + Test conformance/interfaces/pthread_cond_init/4-2.c unresolved: got 1073741942 (Not supported) on line 171 (Cond attribute PSHARED failed) + conformance/interfaces/pthread_cond_signal/1-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_signal/4-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_timedwait/4-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_wait/4-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_condattr_getpshared/1-2: execution: UNRESOLVED: Output: + Error in pthread_condattr_setpshared(), error: 1073741942 + conformance/interfaces/pthread_condattr_setclock/1-2: execution: UNSUPPORTED: Output: + UNSUPPORTED: CLOCK_MONOTONIC is unsupported + conformance/interfaces/pthread_condattr_setclock/1-3: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/pthread_condattr_setpshared/1-2: execution: FAILED: Output: + Test FAILED: Could not set pshared to PTHREAD_PROCESS_SHARED, error: 1073741942 + conformance/interfaces/pthread_create/1-4: execution: UNTESTED: Output: + [13:44:56]System abilities: + [13:44:56] TSA: -1 + [13:44:56] TSS: -1 + [13:44:56] TPS: -1 + [13:44:56] pagesize: 4096 + [13:44:56] min stack size: -1 + [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/1-5: execution: UNTESTED: Output: + [13:44:56]System abilities: + [13:44:56] TSA: -1 + [13:44:56] TSS: -1 + [13:44:56] TPS: -1 + [13:44:56] pagesize: 4096 + [13:44:56] min stack size: -1 + [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/1-6: execution: UNTESTED: Output: + [13:44:57]System abilities: + [13:44:57] TSA: -1 + [13:44:57] TSS: -1 + [13:44:57] TPS: -1 + [13:44:57] pagesize: 4096 + [13:44:57] min stack size: -1 + [13:44:57]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/11-1: execution: UNSUPPORTED: Output: + _POSIX_THREAD_CPUTIME not supported + conformance/interfaces/pthread_create/14-1: execution: UNTESTED: Output: + [13:45:08]System abilities: + [13:45:08] TSA: -1 + [13:45:08] TSS: -1 + [13:45:08] TPS: -1 + [13:45:08] pagesize: 4096 + [13:45:08] min stack size: -1 + [13:45:08]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/15-1: execution: UNTESTED: Output: + [13:45:09]System abilities: + [13:45:09] TSA: -1 + [13:45:09] TSS: -1 + [13:45:09] TPS: -1 + [13:45:09] pagesize: 4096 + [13:45:09] min stack size: -1 + [13:45:09]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/3-2: execution: UNTESTED: Output: + [13:45:11]Growing down stack started upon 0x19fffa0 and we are currently down to 0x19fff60 + [13:45:11]Test starting + Stack tests will be executed. + Sched tests won't be executed. + [13:45:11]System abilities: + [13:45:11] TSA: -1 + [13:45:11] TSS: -1 + [13:45:11] TPS: -1 + [13:45:11] pagesize: 4096 + [13:45:11] min stack size: -1 + [13:45:11]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/8-2: execution: UNTESTED: Output: + [13:45:13]System abilities: + [13:45:13] TSA: -1 + [13:45:13] TSS: -1 + [13:45:13] TPS: -1 + [13:45:13] pagesize: 4096 + [13:45:13] min stack size: -1 + [13:45:13]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/1-2: execution: UNTESTED: Output: + [13:45:13]System abilities: + [13:45:13] TSA: -1 + [13:45:13] TSS: -1 + [13:45:13] TPS: -1 + [13:45:13] pagesize: 4096 + [13:45:13] min stack size: -1 + [13:45:13]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/2-2: execution: UNTESTED: Output: + [13:45:14]System abilities: + [13:45:14] TSA: -1 + [13:45:14] TSS: -1 + [13:45:14] TPS: -1 + [13:45:14] pagesize: 4096 + [13:45:14] min stack size: -1 + [13:45:14]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/4-3: execution: UNTESTED: Output: + [13:45:15]System abilities: + [13:45:16] TSA: -1 + [13:45:16] TSS: -1 + [13:45:16] TPS: -1 + [13:45:16] pagesize: 4096 + [13:45:16] min stack size: -1 + [13:45:16]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_equal/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_exit/1-2: execution: UNTESTED: Output: + [15:01:43]System abilities: + [15:01:43] TSA: -1 + [15:01:43] TSS: -1 + [15:01:43] TPS: -1 + [15:01:43] pagesize: 4096 + [15:01:43] min stack size: -1 + [15:01:43]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/2-2: execution: UNTESTED: Output: + [15:01:44]System abilities: + [15:01:44] TSA: -1 + [15:01:44] TSS: -1 + [15:01:44] TPS: -1 + [15:01:44] pagesize: 4096 + [15:01:44] min stack size: -1 + [15:01:44]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/3-2: execution: UNTESTED: Output: + [15:01:45]System abilities: + [15:01:45] TSA: -1 + [15:01:45] TSS: -1 + [15:01:45] TPS: -1 + [15:01:45] pagesize: 4096 + [15:01:45] min stack size: -1 + [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/4-1: execution: UNTESTED: Output: + [15:01:45]System abilities: + [15:01:45] TSA: -1 + [15:01:45] TSS: -1 + [15:01:45] TPS: -1 + [15:01:45] pagesize: 4096 + [15:01:45] min stack size: -1 + [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/5-1: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/6-1: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/6-2: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_getschedparam/1-1: execution: FAILED: Output: + Error at pthread_getschedparam: rc=1073741902 + conformance/interfaces/pthread_getschedparam/1-2: execution: UNRESOLVED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_getschedparam/1-3: execution: UNRESOLVED: Output: + [15:01:49]Test conformance/interfaces/pthread_getschedparam/1-3.c unresolved: got 1073741902 (Function not implemented) on line 223 (Failed to get min priority) + conformance/interfaces/pthread_getschedparam/4-1: execution: UNRESOLVED: Output: + [15:01:49]Test conformance/interfaces/pthread_getschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 200 (Unexpected error returned) + conformance/interfaces/pthread_join/1-2: execution: UNTESTED: Output: + [15:01:54]System abilities: + [15:01:54] TSA: -1 + [15:01:54] TSS: -1 + [15:01:54] TPS: -1 + [15:01:54] pagesize: 4096 + [15:01:54] min stack size: -1 + [15:01:54]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_join/3-1: execution: UNRESOLVED: Output: + Error in pthread_testcancel(). Cancel request timed out. + : (os/kern) successful + conformance/interfaces/pthread_join/4-1: execution: UNTESTED: Output: + [15:02:06]System abilities: + [15:02:06] TSA: -1 + [15:02:06] TSS: -1 + [15:02:06] TPS: -1 + [15:02:06] pagesize: 4096 + [15:02:06] min stack size: -1 + [15:02:06]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_join/6-3: execution: UNTESTED: Output: + [15:02:07]System abilities: + [15:02:07] TSA: -1 + [15:02:07] TSS: -1 + [15:02:07] TPS: -1 + [15:02:07] pagesize: 4096 + [15:02:07] min stack size: -1 + [15:02:07]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_key_create/2-1: execution: INTERRUPTED: Output: + 2-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/hurd/pt-getspecific.c:30: pthread_getspecific: Assertion `key < __pthread_key_count' failed. + conformance/interfaces/pthread_kill/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/7-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/8-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_getprioceiling/1-1: execution: FAILED: Output: + Test FAILED: Error obtaining the priority ceiling + +Another system crash, due to conformance/interfaces/pthread_mutex_init/5-1: + + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + +Disable the panic-causing test (conformance/interfaces/pthread_mutex_init/5-1) +and restart: + + conformance/interfaces/pthread_mutex_init/speculative/5-2: execution: UNTESTED: Output: + Implementation is: + GNU + 0.3 + GNU-Mach 1.3.99/Hurd-0.3 + This implementation is not tested yet + conformance/interfaces/pthread_mutex_timedlock/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_timedlock/5-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_trylock/4-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutexattr_getprioceiling/1-1: execution: UNRESOLVED: Output: + Error obtaining the attribute process-shared + conformance/interfaces/pthread_mutexattr_getprioceiling/1-2: execution: UNRESOLVED: Output: + Error setting prioceiling to -1 + conformance/interfaces/pthread_mutexattr_getprioceiling/3-1: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_getprotocol/1-2: execution: UNRESOLVED: Output: + Error setting protocol to 1 + conformance/interfaces/pthread_mutexattr_getpshared/1-2: execution: UNRESOLVED: Output: + Error in pthread_mutexattr_setpshared(), error: 1073741942 + conformance/interfaces/pthread_mutexattr_gettype/speculative/3-1: execution: FAILED: Output: + Test FAILED: Incorrect return code. Expected EINVAL, but got: 0 + conformance/interfaces/pthread_mutexattr_setprioceiling/1-1: execution: FAILED: Output: + Test FAILED: Error setting prioceiling to -1 + conformance/interfaces/pthread_mutexattr_setprioceiling/3-1: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_setprioceiling/3-2: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_setprotocol/1-1: execution: UNRESOLVED: Output: + Error setting protocol to 1 + conformance/interfaces/pthread_mutexattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Cannot set pshared attribute to PTHREAD_PROCESS_SHARED. Error code: 1073741942 + conformance/interfaces/pthread_mutexattr_setpshared/2-2: execution: FAILED: Output: + Test FAILED: Expected return code 0, got: 1073741942 + conformance/interfaces/pthread_rwlock_rdlock/2-1: execution: FAILED: Output: + main: has priority: 1 + main: attempt read lock + main: acquired read lock + main: create wr_thread, with priority: 0 + wr_thread: attempt write lock + main: create rd_thread, with priority: -1 + rd_thread: attempt read lock + rd_thread: acquired read lock + rd_thread: unlock read lock + Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and a higher priority writer is waiting for the lock + conformance/interfaces/pthread_rwlock_rdlock/2-2: execution: FAILED: Output: + main: attempt read lock + main: acquired read lock + main: create wr_thread, with priority: 0 + wr_thread: attempt write lock + main: create rd_thread, with priority: 0 + rd_thread: attempt read lock + rd_thread: acquired read lock + rd_thread: unlock read lock + Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and an equal priority writer is waiting for the lock + conformance/interfaces/pthread_rwlock_unlock/3-1: execution: FAILED: Output: + main: write lock + main: create writer1, with priority: 1 + writer1: attempt write lock + main: create reader, with priority: 1 + reader: attempt read lock + main: create writer2, with priority: -1 + writer2: attempt write lock + main: release write lock + writer2: acquired writer lock + Test fail: writer did not get write lock, when main release the lock + conformance/interfaces/pthread_rwlock_unlock/4-1: execution: INTERRUPTED: Output: + 4-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed. + conformance/interfaces/pthread_rwlock_unlock/4-2: execution: INTERRUPTED: Output: + 4-2.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed. + main: attempt read lock + main: acquired read lock + main: create un_thread + un_thread: unlock read lock + conformance/interfaces/pthread_rwlock_wrlock/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_rwlockattr_getpshared/2-1: execution: UNRESOLVED: Output: + Error at pthread_rwlockattr_setpshared() + conformance/interfaces/pthread_rwlockattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Error at pthread_rwlockattr_setpshared(), return error: 1073741942 + conformance/interfaces/pthread_setschedparam/1-1: execution: FAILED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_setschedparam/1-2: execution: UNTESTED: Output: + [08:51:19]File conformance/interfaces/pthread_setschedparam/1-2.c cannot test: Failed to get min SCHED_RR range + conformance/interfaces/pthread_setschedparam/4-1: execution: UNRESOLVED: Output: + [08:51:20]Test conformance/interfaces/pthread_setschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 132 (Failed to set thread policy -- need to be root?) + conformance/interfaces/pthread_setschedparam/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_setschedprio/1-1: execution: UNRESOLVED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_sigmask/10-1: execution: FAILED: Output: + FAIL: SIGKILL was added to the signal mask + Test FAILED + conformance/interfaces/pthread_sigmask/18-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/4-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/6-1: execution: HUNG: Output: + conformance/interfaces/pthread_sigmask/9-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_spin_lock/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/sched_get_priority_max/1-1: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/1-2: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/1-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_get_priority_max/1-4: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/2-1: execution: FAILED: Output: + error is not EINVAL: Function not implemented + conformance/interfaces/sched_get_priority_min/1-1: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/1-2: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/1-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_get_priority_min/1-4: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/2-1: execution: FAILED: Output: + error is not EINVAL: Function not implemented + conformance/interfaces/sched_getparam/1-1: execution: FAILED: Output: + Return code is not zero. + conformance/interfaces/sched_getparam/2-1: execution: FAILED: Output: + Different results between pid == 0 and pid == getpid(). + conformance/interfaces/sched_getparam/3-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getparam/4-1: execution: FAILED: Output: + errno is not ESRCH: Function not implemented + conformance/interfaces/sched_getparam/6-1: execution: UNRESOLVED: Output: + errno is not EPERM: The system allows a non-rootuser to use sched_getparam(): Function not implemented + conformance/interfaces/sched_getparam/speculative/7-1: execution: UNRESOLVED: Output: + sched_getparam() return -1 and sets errno == 1073741902. + conformance/interfaces/sched_getscheduler/1-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getscheduler/2-1: execution: UNTESTED: Output: + Will not test the behavior of sched_getscheduler() when pid is negative + because it is unspecified. + conformance/interfaces/sched_getscheduler/3-1: execution: FAILED: Output: + Returned code is -1. + conformance/interfaces/sched_getscheduler/4-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getscheduler/7-1: execution: FAILED: Output: + errno is not EPERM: Function not implemented + conformance/interfaces/sched_rr_get_interval/1-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_rr_get_interval/2-1: execution: FAILED: Output: + interval.tv_sec not updated. + conformance/interfaces/sched_rr_get_interval/3-1: execution: FAILED: Output: + Returned error is not ESRCH: Function not implemented + conformance/interfaces/sched_rr_get_interval/speculative/5-1: execution: UNRESOLVED: Output: + sched_rr_get_interval() return -1 and sets errno == 1073741902. + conformance/interfaces/sched_setparam/1-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/10-1: execution: UNRESOLVED: Output: + An error occurs when calling shmget(): Invalid argument + conformance/interfaces/sched_setparam/12-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/13-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/14-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/15-1: execution: UNTESTED: Output: + Will not test the effects of the sched_ss_low_priority, + sched_ss_repl_period, and sched_ss_init_budget members when the scheduling + policy of the target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC. + It is implementation-defined. + conformance/interfaces/sched_setparam/16-1: execution: UNTESTED: Output: + Will not test the result of sched_setparam when the scheduling policy of the + target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC. + It is implementation-defined. + conformance/interfaces/sched_setparam/17-1: execution: UNTESTED: Output: + Will not test that sched_setparam have no effect on the scheduling of threads + with system scheduling contention scope. + conformance/interfaces/sched_setparam/18-1: execution: UNTESTED: Output: + Will not test that the threads scheduling policy and associated parameters + are not affected. + conformance/interfaces/sched_setparam/19-1: execution: UNTESTED: Output: + Will not test that the underlying kernel-scheduled entities for the system + contention scope threads are not be affected by this sched_setparam(). + conformance/interfaces/sched_setparam/2-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_setscheduler(): Function not implemented + conformance/interfaces/sched_setparam/2-2: execution: UNRESOLVED: Output: + An error occurs when calling sched_setscheduler(): Function not implemented + conformance/interfaces/sched_setparam/22-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-5: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-6: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-7: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/25-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getscheduler(): Function not implemented + conformance/interfaces/sched_setparam/25-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/26-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/27-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/3-1: execution: UNTESTED: Output: + Will not test the behavior of sched_setparam() when pid is negative because + it is unspecified. + conformance/interfaces/sched_setparam/5-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/6-1: execution: UNTESTED: Output: + Will not test the conditions under which one process has permission to + change the scheduling parameters of another process, because they are + implementation-defined. + conformance/interfaces/sched_setparam/7-1: execution: UNTESTED: Output: + Will not test that implementations may require the requesting process to + have the appropriate privilege to set its own scheduling parameters or those + of another process. + conformance/interfaces/sched_setparam/8-1: execution: UNTESTED: Output: + Will not test that the target process is moved to the tail of the thread + list for its priority when it is running. + conformance/interfaces/sched_setparam/9-1: execution: UNRESOLVED: Output: + An error occurs when calling shmget(): Invalid argument + conformance/interfaces/sched_setscheduler/1-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + Error calling sched_setscheduler() for SCHED_FIFO policy + Policy: SCHED_RR + Error calling sched_setscheduler() for SCHED_RR policy + Policy: SCHED_OTHER + Error calling sched_setscheduler() for SCHED_OTHER policy + conformance/interfaces/sched_setscheduler/10-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setscheduler/11-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setscheduler/12-1: execution: UNTESTED: Output: + Will not test that sched_setscheduler have no effect on the scheduling of + threads with system scheduling contention scope. + conformance/interfaces/sched_setscheduler/13-1: execution: UNTESTED: Output: + Will not test that the threads scheduling policy and associated parameters + are not affected. + conformance/interfaces/sched_setscheduler/14-1: execution: UNTESTED: Output: + Will not test that the underlying kernel-scheduled entities for the system + contention scope threads are not be affected by sched_setscheduler(). + conformance/interfaces/sched_setscheduler/15-1: execution: UNSUPPORTED: Output: + Process contention scope threads are not supported. + conformance/interfaces/sched_setscheduler/16-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getscheduler(): Function not implemented + conformance/interfaces/sched_setscheduler/17-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-5: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-6: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-7: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/19-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + An error occurs when calling sched_get_priority_max(): Function not implemented + conformance/interfaces/sched_setscheduler/19-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-5: execution: FAILED: Output: + Unknow error: Function not implemented + conformance/interfaces/sched_setscheduler/2-1: execution: UNTESTED: Output: + Will not test the behavior of sched_setscheduler() when pid is negative + because it is unspecified. + conformance/interfaces/sched_setscheduler/20-1: execution: FAILED: Output: + errno is not EPERM: Function not implemented + conformance/interfaces/sched_setscheduler/21-1: execution: FAILED: Output: + errno is not ESRCH: Function not implemented + conformance/interfaces/sched_setscheduler/4-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/5-1: execution: UNTESTED: Output: + Will not test the condition under which one process has the appropriate + privilege to change the scheduling parameters of another process because + they are implementation-defined. + conformance/interfaces/sched_setscheduler/6-1: execution: UNTESTED: Output: + Will not test that implementations may require that the requesting process + have permission to set its own scheduling parameters or those of another + process. + conformance/interfaces/sched_setscheduler/7-1: execution: UNTESTED: Output: + Will not test if implementation-defined restrictions apply as to the + appropriate privileges required to set a process' own scheduling policy, or + another process' scheduling policy, to a particular value. + conformance/interfaces/sched_setscheduler/9-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sem_close/1-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 1-1: sem_open: Operation not supported + conformance/interfaces/sem_close/2-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 2-1: sem_open: Operation not supported + conformance/interfaces/sem_close/3-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 3-1: sem_open: Operation not supported + conformance/interfaces/sem_close/3-2: execution: UNRESOLVED: Output: + [08:56:54]Test conformance/interfaces/sem_close/3-2.c unresolved: got 1073741869 (Operation not supported) on line 113 (Failed to create the semaphore) + conformance/interfaces/sem_getvalue/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 1-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 2-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/4-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 4-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/5-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 5-1: sem_open: Operation not supported + conformance/interfaces/sem_init/3-2: execution: UNRESOLVED: Output: + [08:56:59]Test conformance/interfaces/sem_init/3-2.c unresolved: got 1073741869 (Operation not supported) on line 135 (Failed to init the semaphore) + conformance/interfaces/sem_init/3-3: execution: UNRESOLVED: Output: + [08:57:00]Test conformance/interfaces/sem_init/3-3.c unresolved: got 1073741869 (Operation not supported) on line 134 (Failed to init the semaphore) + conformance/interfaces/sem_init/7-1: execution: UNTESTED: Output: + [08:57:01]sysconf( _SC_SEM_NSEMS_MAX ) = -1 + [08:57:01]File conformance/interfaces/sem_init/7-1.c cannot test: There is no constraint on SEM_NSEMS_MAX + conformance/interfaces/sem_open/1-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/1-3: execution: UNRESOLVED: Output: + unexpected error: sem_open 1-3: sem_open: Operation not supported + conformance/interfaces/sem_open/1-4: execution: UNRESOLVED: Output: + unexpected error: sem_open 1-4: sem_open: Operation not supported + conformance/interfaces/sem_open/10-1: execution: UNRESOLVED: Output: + unexpected error: sem_open 10-1: sem_open: Operation not supported + conformance/interfaces/sem_open/15-1: execution: UNRESOLVED: Output: + [08:57:03]Test conformance/interfaces/sem_open/15-1.c unresolved: got 1073741869 (Operation not supported) on line 106 (Failed to sem_open) + conformance/interfaces/sem_open/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_open 2-1: sem_open: Operation not supported + conformance/interfaces/sem_open/2-2: execution: UNRESOLVED: Output: + unexpected error: sem_open 2-2: sem_open: Operation not supported + conformance/interfaces/sem_open/3-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/4-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/6-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_post/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 1-1: sem_open: Operation not supported + conformance/interfaces/sem_post/1-2: execution: UNRESOLVED: Output: + unexpected error: sem_post 1-2: sem_open: Operation not supported + conformance/interfaces/sem_post/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 2-1: sem_open: Operation not supported + conformance/interfaces/sem_post/4-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 4-1: sem_open: Operation not supported + conformance/interfaces/sem_post/5-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 5-1: sem_open: Operation not supported + conformance/interfaces/sem_post/6-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 6-1: sem_open: Operation not supported + conformance/interfaces/sem_post/8-1: execution: UNTESTED: Output: + _POSIX_PRIORITY_SCHEDULING not defined + conformance/interfaces/sem_timedwait/9-1: execution: FAILED: Output: + In handler + TEST FAILED: errno != EINTR + conformance/interfaces/sem_unlink/1-1: execution: INTERRUPTED: Output: + unexpected error: sem_unlink 1-1: sem_open: Operation not supported + conformance/interfaces/sem_unlink/2-1: execution: INTERRUPTED: Output: + unexpected error: sem_unlink 2-1: sem_open: Operation not supported + conformance/interfaces/sem_unlink/2-2: execution: UNRESOLVED: Output: + [08:57:23]Test conformance/interfaces/sem_unlink/2-2.c unresolved: got 1073741869 (Operation not supported) on line 158 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/3-1: execution: UNRESOLVED: Output: + [08:57:23]Test conformance/interfaces/sem_unlink/3-1.c unresolved: got 1073741869 (Operation not supported) on line 156 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/4-1: execution: FAILED: Output: + TEST FAILED: semaphore does exist + conformance/interfaces/sem_unlink/4-2: execution: FAILED: Output: + [08:57:24]Error 1073741869: Operation not supported + [08:57:24]Test conformance/interfaces/sem_unlink/4-2.c FAILED: The error was not ENOENT + conformance/interfaces/sem_unlink/6-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/6-1.c unresolved: got 1073741869 (Operation not supported) on line 107 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/7-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/7-1.c unresolved: got 1073741869 (Operation not supported) on line 126 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/9-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/9-1.c unresolved: got 1073741869 (Operation not supported) on line 133 (Failed to create the semaphore) + conformance/interfaces/sem_wait/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 1-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/1-2: execution: UNRESOLVED: Output: + unexpected error: sem_wait 2-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/11-1: execution: UNRESOLVED: Output: + unexpected error: sem_trywait 11-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/12-1: execution: INTERRUPTED: Output: + unexpected error: sem_trywait 12-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/3-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 3-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/5-1: execution: INTERRUPTED: Output: + unexpected errno: sem_trywait 5-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/7-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 7-1: sem_open: Operation not supported + conformance/interfaces/shm_open/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/10-1: execution: UNTESTED: Output: + Will not test whether the file offset is set because it is unspecified. + conformance/interfaces/shm_open/12-1: execution: UNTESTED: Output: + Will not test the behavior of implementation when an application does not + specify exactly one of two values: O_RDONLY and O_RDWR. + conformance/interfaces/shm_open/14-2: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/19-1: execution: UNTESTED: Output: + Will not test the effect of calling shm_open() when the shared memory object + does not exists, the O_CREAT flags is set, and bits in mode other than the + file permission bits are set. It is unspecified. + conformance/interfaces/shm_open/2-1: execution: UNTESTED: Output: + Will not test that the shm_open() function create an open file description + that refers to the shared memory object and a file descriptor that refers to + conformance/interfaces/shm_open/23-1: execution: UNRESOLVED: Output: + error at sem_open: Operation not supported + conformance/interfaces/shm_open/24-1: execution: UNTESTED: Output: + Will not test the result of shm_open() when O_EXCL is set and O_CREAT is not + set because it is undefined. + conformance/interfaces/shm_open/26-2: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/shm_open/27-1: execution: UNTESTED: Output: + Will not test the result of shm_open() when using O_TRUNC with O_RDONLY. + It is undefined. + conformance/interfaces/shm_open/28-1: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/28-3: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/29-1: execution: UNTESTED: Output: + Will not test whether the name and shared memory object state remain valid + after a system reboot. It is unspecified. + conformance/interfaces/shm_open/3-1: execution: UNTESTED: Output: + Will not test whether the name appears in the file system and is visible to + other functions that take pathnames as arguments because it is unspecified. + conformance/interfaces/shm_open/36-1: execution: UNTESTED: Output: + It is very difficult to test that the shm_open() function sets errno = EINTR + when it is interrupted by a signal. + conformance/interfaces/shm_open/37-1: execution: FAILED: Output: + Name: '[GARBAGE]' + OK: open with success. + Name: '[GARBAGE]' + OK: open with success. + Name: '..' + Unexpected error: Is a directory + Name: '/' + OK: errno == EINVAL + Name: '//' + OK: errno == EINVAL + Name: '/abc' + OK: open with success. + Test FAILED + conformance/interfaces/shm_open/39-2: execution: UNRESOLVED: Output: + An error occurs when calling pathconf(): Invalid argument + conformance/interfaces/shm_open/42-1: execution: UNTESTED: Output: + Will not test that the shm_open() function sets errno to ENOSPC if there is + insufficient space for the creation of the new shared memory object. + conformance/interfaces/shm_open/5-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/shm_open/6-1: execution: UNTESTED: Output: + Will not test the effect of a name which does not begin with the slash + character because it is implementation-defined. + conformance/interfaces/shm_open/7-1: execution: UNTESTED: Output: + Will not test the interpretation of slash characters other than the leading + slash character in name because it is implementation-defined. + conformance/interfaces/shm_open/9-1: execution: UNTESTED: Output: + Will not test that the open file description is new. + conformance/interfaces/shm_unlink/10-2: execution: UNRESOLVED: Output: + An error occurs when calling pathconf(): Invalid argument + conformance/interfaces/shm_unlink/8-1: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/shm_unlink/9-1: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/sigaction/4-37: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-23: execution: FAILED: Output: + Caught SIGURG + Test FAILED + conformance/interfaces/sigaction/12-41: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-4: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-28: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-26: execution: FAILED: Output: + Caught SIGXFSZ + Test FAILED + conformance/interfaces/sigaction/12-49: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-8: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-45: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-18: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-42: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-15: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-25: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-7: execution: FAILED: Output: + Caught SIGHUP + Test FAILED + conformance/interfaces/sigaction/4-48: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-23: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-34: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-24: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-43: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-22: execution: FAILED: Output: + Caught SIGTRAP + Test FAILED + conformance/interfaces/sigaction/12-31: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-35: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-46: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-7: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-34: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-3: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-52: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-30: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-51: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-13: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-36: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-21: execution: FAILED: Output: + Caught SIGSYS + Test FAILED + conformance/interfaces/sigaction/17-11: execution: FAILED: Output: + Caught SIGQUIT + Test FAILED + conformance/interfaces/sigaction/4-38: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-47: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-30: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-44: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-50: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-27: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-20: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-40: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-19: execution: FAILED: Output: + Caught SIGPOLL + Test FAILED + conformance/interfaces/sigaction/12-16: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-51: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-21: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-1: execution: FAILED: Output: + Caught SIGABRT + Test FAILED + conformance/interfaces/sigaction/4-32: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-12: execution: FAILED: Output: + Caught SIGSEGV + Test FAILED + conformance/interfaces/sigaction/12-52: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-10: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-36: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-9: execution: FAILED: Output: + Caught SIGINT + Test FAILED + conformance/interfaces/sigaction/4-47: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-11: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-10: execution: FAILED: Output: + Caught SIGPIPE + Test FAILED + conformance/interfaces/sigaction/12-5: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-48: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-19: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-46: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-17: execution: FAILED: Output: + Caught SIGUSR1 + Test FAILED + conformance/interfaces/sigaction/12-14: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-14: execution: FAILED: Output: + Caught SIGTSTP + Test FAILED + conformance/interfaces/sigaction/17-18: execution: FAILED: Output: + Caught SIGUSR2 + Test FAILED + conformance/interfaces/sigaction/4-41: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-43: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-28: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-6: execution: FAILED: Output: + Caught SIGFPE + Test FAILED + conformance/interfaces/sigaction/4-45: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-35: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-6: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-29: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-16: execution: FAILED: Output: + Caught SIGTTOU + Test FAILED + conformance/interfaces/sigaction/4-39: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-29: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-9: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-25: execution: FAILED: Output: + Caught SIGXCPU + Test FAILED + conformance/interfaces/sigaction/17-4: execution: FAILED: Output: + Caught SIGCHLD + Test FAILED + conformance/interfaces/sigaction/12-22: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-13: execution: FAILED: Output: + Caught SIGTERM + Test FAILED + conformance/interfaces/sigaction/4-31: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-38: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-12: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-44: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-49: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-40: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-42: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-15: execution: FAILED: Output: + Caught SIGTTIN + Test FAILED + conformance/interfaces/sigaction/17-3: execution: FAILED: Output: + Caught SIGBUS + Test FAILED + conformance/interfaces/sigaction/12-2: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-5: execution: FAILED: Output: + Caught SIGCONT + Test FAILED + conformance/interfaces/sigaction/12-33: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-17: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-2: execution: FAILED: Output: + Caught SIGALRM + Test FAILED + conformance/interfaces/sigaction/12-37: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-20: execution: FAILED: Output: + Caught SIGPROF + Test FAILED + conformance/interfaces/sigaction/17-8: execution: FAILED: Output: + Caught SIGILL + Test FAILED + conformance/interfaces/sigaction/4-33: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-39: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-50: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-32: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-27: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-24: execution: FAILED: Output: + Caught SIGVTALRM + Test FAILED + conformance/interfaces/sigaction/12-26: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/11-1: execution: FAILED: Output: + Test FAILED: Expected return value of -1. + conformance/interfaces/sigaltstack/12-1: execution: FAILED: Output: + Test FAILED: Expected return value of -1. + conformance/interfaces/sigaltstack/2-1: execution: FAILED: Output: + Test FAILED: ss_sp of the handler's stack changed even though SS_DISABLE was set + conformance/interfaces/sigaltstack/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/6-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/7-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigpause/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigpending/1-2: execution: INTERRUPTED: Output: + Not all pending signals found + conformance/interfaces/sigpending/1-3: execution: INTERRUPTED: Output: + Error with send signals + Test FAILED + conformance/interfaces/sigqueue/10-1: execution: FAILED: Output: + sigqueue() failed on EINVAL but errno not set correctly + conformance/interfaces/sigqueue/11-1: execution: FAILED: Output: + sigqueue() failed on ESRCH but errno not set correctly + conformance/interfaces/sigqueue/12-1: execution: FAILED: Output: + sigqueue() failed but errno not set correctly + conformance/interfaces/sigqueue/2-1: execution: FAILED: Output: + Could not call sigqueue with sig = 0 + conformance/interfaces/sigqueue/2-2: execution: FAILED: Output: + sigqueue() failed on ESRCH but errno not set correctly + At least one test FAILED -- see output for status + conformance/interfaces/sigqueue/3-1: execution: FAILED: Output: + Test FAILED: EPERM error not received + conformance/interfaces/sigset/6-1: execution: UNRESOLVED: Output: + Unexpected error while using sigset(): (os/kern) successful + conformance/interfaces/sigset/7-1: execution: UNRESOLVED: Output: + Unexpected error while using sigset(): (os/kern) successful + conformance/interfaces/sigset/8-1: execution: FAILED: Output: + Test FAILED: sigset() didn't return SIG_HOLD + conformance/interfaces/sigsuspend/1-1: execution: UNRESOLVED: Output: + suspending child + SIGUSR2 called. Inside handler + parent sending child a SIGUSR2 signal + parent sending child a SIGUSR1 signal + Exit status from child is 1 + Test UNRESOLVED: Either sigsuspend did not successfully block SIGUSR2, OR sigsuspend returned before handling the signal SIGUSR1 + conformance/interfaces/sigtimedwait/1-1: execution: FAILED: Output: + Test FAILED: sigtimedwait() did not return in the required time + conformance/interfaces/sigtimedwait/4-1: execution: FAILED: Output: + Call to sigtimedwait() failed + : Function not implemented + conformance/interfaces/sigtimedwait/6-1: execution: FAILED: Output: + Test FAILED: sigtimedwait() did set errno to EAGAIN + conformance/interfaces/sigwait/1-1: execution: FAILED: Output: + Signal SIGALRM is not pending! + conformance/interfaces/sigwait/3-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/sigwait/6-1: execution: FAILED: Output: + [09:04:10]0 threads were awaken + [09:04:10]Test conformance/interfaces/sigwait/6-1.c FAILED: Unexpected number of threads awaken + conformance/interfaces/sigwaitinfo/1-1: execution: UNRESOLVED: Output: + Call to sigwaitinfo() failed + : Function not implemented + conformance/interfaces/sigwaitinfo/3-1: execution: FAILED: Output: + Call to sigwaitinfo() failed + : Function not implemented + Child calling sigwaitinfo() + parent sending child a SIGUSR1 signal + Exit status from child is 2 + Test FAILED + conformance/interfaces/sigwaitinfo/9-1: execution: FAILED: Output: + Call to sigwaitinfo() failed + : Function not implemented + conformance/interfaces/strftime/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/timer_create/1-1: execution: FAILED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/10-1: execution: UNRESOLVED: Output: + sysconf(_SC_CPUTIME) returns: -1 + conformance/interfaces/timer_create/11-1: execution: UNSUPPORTED: Output: + rc = -1 + _POSIX_THREAD_CPUTIME unsupported + conformance/interfaces/timer_create/16-1: execution: FAILED: Output: + errno != EINVAL + Test FAILED + conformance/interfaces/timer_create/3-1: execution: FAILED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/7-1: execution: UNSUPPORTED: Output: + CLOCK_MONOTONIC unsupported + conformance/interfaces/timer_create/8-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/9-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/speculative/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/speculative/5-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/speculative/5-1: execution: FAILED: Output: + timer_delete() returned -1, but didn't set errno!=EINVAL + conformance/interfaces/timer_delete/speculative/5-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/3-1: execution: UNTESTED: Output: + Cannot be tested as DELAYTIMER_MAX is too large. + DELAYTIMER_MAX is ffffffff + conformance/interfaces/timer_getoverrun/speculative/6-1: execution: FAILED: Output: + fcn returned -1, but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_getoverrun/speculative/6-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/speculative/6-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/2-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/3-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/speculative/6-1: execution: FAILED: Output: + fcn returned -1 but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_gettime/speculative/6-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/speculative/6-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/13-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/6-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/9-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/9-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/speculative/12-1: execution: FAILED: Output: + fcn returned -1, but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_settime/speculative/12-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/speculative/12-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + functional/threads/schedule/1-1: execution: UNRESOLVED: Output: + unexpected error: scheduler 5-4: pthread_attr_setschedpolicy + functional/threads/schedule/1-2: execution: UNRESOLVED: Output: + unexpected error: scheduler 5-5: pthread_setschedparam diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn new file mode 100644 index 00000000..20e4a4fe --- /dev/null +++ b/open_issues/open_symlink.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 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, freenode, #hurd, 2012-01-02 + + <pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY | + O_NOFOLLOW) does not fail with ELOOP? + <youpi> pinotree: iirc there is code for it, maybe not the same behavior as + on linux diff --git a/open_issues/osf_mach.mdwn b/open_issues/osf_mach.mdwn new file mode 100644 index 00000000..d689bfcb --- /dev/null +++ b/open_issues/osf_mach.mdwn @@ -0,0 +1,237 @@ +[[!meta copyright="Copyright © 2011 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 open_issue_gnumach open_issue_hurd]] + +IRC, freenode, #hurd, 2011-09-07 + + <slpz> tschwinge: do you think that should be possible/convenient to + maintain hurd and glibc versions for OSF Mach as branches in the offical + git repo? + <tschwinge> Is OSF Mach the MkLinux one? + <slpz> Yes, it is + <tschwinge> slpz: If there's a suitable license, then yes, of course! + <tschwinge> Unless there is a proper upstream, of course. + <tschwinge> But I don't assume there is? + <tschwinge> slpz: What is interesting for us about OSF Mach? + <slpz> tschwinge: Peter Bruin and Jose Marchesi did a gnuified version some + time ago (gnu-osfmach), so I suppose the license is not a problem. But + I'm going to check it, though + <slpz> OSF Mach has a number of interesting features + <slpz> like migrating threads, advisory pageout, clustered pageout, kernel + loaded tasks, short circuited RPC... + <tschwinge> Oh! + <tschwinge> Good. + <slpz> right now I'm testing if it's really worth the effort + <tschwinge> Yes. + <tschwinge> But if the core codebase is the same (is it?) it may be + possible to merge some things? + <tschwinge> If the changes can be identified reasonably... + <slpz> comparing performance of the specialized RPC of OSF Mach with + generic IPC + <slpz> That was my first intention, but I think that porting all those + features will be much more work than porting Hurd/glibc to it + <braunr> slpz: ipc performance currently matters less than clustered + pageouts + <braunr> slpz: i'm really not sure .. + <braunr> i'd personnally adapt the kernel + <slpz> braunr: well, clustered pageouts is one of the changes that can be + easily ported + <slpz> braunr: We can consider OSF Mach code as reasonably stable, and + porting its features to GNU Mach will take us to the point of having to + debug all that code again + <slpz> probably, the hardest feature to be ported is migrating threads + <braunr> isn't that what was tried for gnu mach 2 ? or was it only about + oskit ? + <slpz> IIRC only oskit + <tschwinge> slpz: But there have been some advancements in GNU Mach, too. + For example the Xen port. + <tschwinge> But wen can experiment with it, of course. + <slpz> tschwinge: I find easier to move the Xen support from GNU Mach to + OSF Mach, than porting MT in the other direction + <tschwinge> slpz: And I think MkLinux is a single-server, so I don't this + they used IPC as much as we did? + <tschwinge> slpz: OK, I see. + <braunr> slpz: MT aren't as needed as clustered pageouts :p + <braunr> gnumach already has ipc handoff, so MT would just consume less + stack space, and only slightly improve raw ipc performance + <tschwinge> slpz: But we will surely accept patches that get the Hurd/glibc + ported to OSF Mach, no question. + <braunr> (it's required for other issues we discussed already, but not a + priority imo) + <slpz> tschwinge: MkLinux makes heavy use of IPC, but it tries to + "short-circuit" it when running as a kernel loaded task + <tschwinge> And it's obviously best to keep it in one place. Luckily it's + not CVS branches anymore... :-) + <slpz> braunr: well, I'm a bit obsessed with IPC peformance, if the RPC on + OSF Mach really makes a difference, I want it for Hurd right now + <slpz> braunr: clustered pages can be implemented at any time :-) + <slpz> tschwinge: great! + <tschwinge> slpz: In fact, haven'T there already been some Savannah + repositories created, several (five?) years ago? + <braunr> slpz: the biggest performance issue on the hurd is I/O + <braunr> and the easiest way to improve that is better VM transfers + <slpz> tschwinge: yes, the HARD project, but I think it wasn't too well + received... + <tschwinge> slpz: Quite some things changed since then, I'd say. + <slpz> braunr: I agree, but IPC is the hardest part to optimize + <slpz> braunr: If we have a fast IPC, the rest of improvements are way + easier + <braunr> slpz: i don't see how faster IPC makes I/O faster :( + <braunr> slpz: read + http://www.sceen.net/~rbraun/the_increasing_irrelevance_of_ipc_performance_for_microkernel_based_operating_systems.pdf + again :) + <slpz> braunr: IPC puts the upper limit of how fast I/O could be + <braunr> the abstract for my thesis on x15 mach was that the ipc code was + the most focused part of the kernel + <braunr> so my approach was to optimize everything *else* + <braunr> the improvements in UVM (and most notably clustered page + transfers) show global system improvements up to 30% in netbsd + <braunr> we should really focus on the VM first (which btw, is a pain in + the ass with the crappy panicking swap code in place) + <braunr> and then complete the I/O system + <slpz> braunr: If a system can't transfer data between translators faster + than 100 MB/s, faster devices doesn't make much sense + <guillem> has anyone considered switching the syscalls to use + sysenter/syscall instead of soft interrupts? + <slpz> braunr: but I agree on the VM part + <braunr> guillem: it's in my thesis .. but only there :) + <braunr> slpz: let's reach 100 MiB/s first, then improve IPC + <slpz> guillem: that's a must do, also moving to 64 bits :-) + <braunr> guillem: there are many tiny observations in it, like the use of + global page table entries, which was added by youpi around that time + <guillem> slpz: I wanted to fix all warnings first before sending my first + batch of 64 bit fixes, but I think I'll just send them after checking + they don't introduce regressions on i386 + <guillem> braunr: interesting I think I might have skimmed over your + thesis, maybe I should read it properly some time :) + <slpz> braunr: I see exactly as the opposite. First push IPC to its limit, + then improve devices/VM + <slpz> guillem: that's great :-) + <braunr> slpz: improving ipc now will bring *nothing*, whereas improving + vm/io now will make the system considerably more useable + <guillem> but then fixing 64-bit issues in the Linux code is pretty + annoying given that the latest code from upstream has that already fixed, + and we are “supposed” to drop the linux code from gnumach at some point + :) + <braunr> slpz: that's a basic principle in profiling, improve what brings + the best gains + <slpz> braunr: I'm not thinking about today, I'm thinking about how fast + Hurd could be when running on Mach. And, as I said, IPC is the absolute + upper limit. + <braunr> i'm really not convinced + <braunr> there are that many tasks making extensive use of IPCs + <braunr> most are cpu/IO bound + <slpz> but I have to acknowledge that this concern has been really + aliviated by the EPT improvement discovery + <braunr> there aren't* that many tasks + <slpz> braunr: create a ramdisk an write some files on it + <slpz> braunr: there's no I/O in that case, an performance it's really low + too + <braunr> well, ramdisks don't even work correctly iirc + <slpz> I must say that I consider improvements in OOL data moving as if it + were in IPC itself + <slpz> braunr: you can simulate one with storeio + <braunr> slpz: then measure what's slow + <braunr> slpz: it couldn't simply be the vm layer + <slpz> braunr: + http://www.gnu.org/s/hurd/hurd/libstore/examples/ramdisk.html + <braunr> ok, it's not a true ramdisk + <braunr> it's a stack of a ramdisk and extfs servers + <braunr> ext2fs* + <braunr> i was thinking about tmpfs + <slpz> True, but one of Hurd main advantages is the ability of doing that + kind of things + <slpz> so they must work with a reasonable performance + <braunr> other systems can too .. + <braunr> anyway + <braunr> i get your point, you want faster IPCs, like everyone does + <slpz> braunr: yes, and I also want to know how fast could be, to have a + reference when profiling complex services + <antrik> slpz: really improving IPC performance probably requires changing + the semantics... but we don't know which semantics we want until we have + actually tried fixing the existing bottlenecks + <antrik> well, not only bottlenecks... also other issues such as resource + management + <slpz> antrik: I think fixing bottlenecks would probably require changes in + some Mach interfaces, not in the IPC subsystem + <slpz> antrik: I mean, IPC semantics just provide the basis for messaging, + I don't think we will need to change them further + <antrik> slpz: right, but only once we have addressed the bottlenecks (and + other major shortcomings), we will know how the IPC mechanisms needs to + change to get further improvements... + <antrik> of course improving Mach IPC performance is interesting too -- if + nothing else, then to see how much of a difference it really makes... I + just don't think it should be considered an overriding priority :-) + <youpi> slpz: I agree with braunr, I don't think improving IPC will bring + much on the short term + <youpi> the buildds are slow mostly because of bad VM + <youpi> like lack of read-ahead, the randomness of object cache pageout, + etc. + <youpi> that doesn't mean IPC shouldn't be improved of course + <youpi> but we have a big margin for iow + <youpi> s/iow/now + <slpz> youpi: I agree with you and with braunr in that regard. I'm not + looking for an inmediate improvement, I just want to see how fast the IPC + (specially, OOL data transfers) could be. + <slpz> also, migrating threads will help to fix some problems related with + resource management + <antrik> slpz: BTW, what about Apple's Mach? isn't it essentialy OSF Mach + with some further improvements?... + <slpz> antrik: IPC is an area with very little room for improvement, so I + don't we will fix that bottlenecks by applying some changes there + <antrik> well, for large OOL transfers, the limiting facter is certainly + also VM rather than the thread model?... + <slpz> antrik: yes, but I think is encumbered with the APPLv2 license + <antrik> ugh + <slpz> antrik: for OOL transfers, VM plays a big role, but IPC also has + great deal of responsibility + <antrik> as for resource management, migrating threads do not really help + much IMHO, as they only affect CPU scheduling. memory usage is a much + more pressing issue + <antrik> BTW, I have thought about passive objects in the past, but didn't + reach any conclusion... so I'm a bit ambivalent about migrating threads + :-) + <slpz> As an example, in Hurd on GNU Mach, an io_read can't take advantage + from copy-on-write, as buffers from the translator always arrive outside + user's buffer + <slpz> antrik: well, I think cpu scheduling is a big deal ;-) + <slpz> antrik: and for memory management, until a better design is + implemented, some fixes could be applied to get us to the same level as a + monolithic kernel + <antrik> to get even close to monolithic systems, we need either a way to + account server resources used on client's behalf, or to make servers use + client-provided resources. both require changes in the IPC mechanism I + think... + <antrik> (though *if* we go for the latter option, the CPU scheduling + changes of migrating threads would of course be necessary, in addition to + any changes regarding memory management...) + <antrik> slpz: BTW, I didn't get the point about io_read and COW... + <slpz> antrik: AFAIK, the FS cache (which is our primary concern) in most + monolithic system is agnostic with respect the users, and only deals with + absolute numbers. In our case we can do almost the same by combining Mach + and pagers knowledege. + <antrik> slpz: my primary concern is that anything program having a hiccup + crashes the system... and I'm not sure this can be properly fixed without + working memory accounting + <antrik> (I guess in can be worked around to some extent by introducing + various static limits on processes... but I'm not sure how well) + <antrik> it can + <slpz> antrik: monolithic system also suffer that problem (remember fork + bombs) and it's "solved" by imposing static limits to user processes + (ulimit). + <slpz> antrik: we do have more problems due to port management, but I think + some degree of control can be archieved with a reasonably amount of + changes. + <antrik> slpz: in a client-server architecture static limits are much less + effective... that problem exists on traditional systems too, but only in + some specific cases (such as X server); while on a microkernel system + it's ubiquitous... that's why we need a *better* solution to this problem + to get anywhere close to monolithic systems diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn new file mode 100644 index 00000000..d243aaaa --- /dev/null +++ b/open_issues/packaging_libpthread.mdwn @@ -0,0 +1,139 @@ +[[!meta copyright="Copyright © 2010, 2011, 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_libpthread open_issue_glibc]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2010-07-31 + + <tschwinge> My idea was to have a separate libpthread package. What do you + think about that? + <youpi> in the long term, that can't work with glibc + <youpi> because of the thread stub stuff + +[[libpthread_dlopen]], for example. + + <youpi> it's not really possible to keep synchronized + <youpi> because you have to decide which package you unpack first + <youpi> (when upgrading) + <tschwinge> Hmm, how is that different if two shared libraries are in one + package vs. two packages? It isn't atomic either way? Aren't sonames / + versioned library packages solving that? + <tschwinge> ... for incompatible forward changes? + <youpi> that'd be a mess to maintain + <youpi> Drepper doesn't have this constraint and thus adds members of + private fields at will + <tschwinge> OK, but how is it different then if the libpthread is in the + Hurd package? + <youpi> I'm not saying it's better to have libpthread in the Hurd package + <tschwinge> OK. + <youpi> I'm saying it's useless to package it separately when Drepper makes + everything to have us put it along glibc + <tschwinge> Then, to goal is to have it in glibc? + <tschwinge> OK. :-) + <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to + switch libpthread to something else so quickly. + <tschwinge> So our official goal is to have libpthread in glibc, at least + for Debian purposese? + <youpi> for any port purpose + <tschwinge> Ack. + <youpi> provided you're using glibc, you're deemed to ship libpthread with + it + <youpi> because of the strong relations Drepper puts between them + <youpi> (just to remind: we already have bugs just because our current + libpthread isn't bound enough to glibc: dlopen()ing a library depending + on libpthread doesn't work, for instance) + <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread + isn't used + <pinotree> (would be nice to not have those issues anymore...) + <tschwinge> So -- what do we need to put it into glibc? We can make + libpthread a Git submodule (or move the code; but it's shared also for + Neal's viengoos, so perhaps the submodule is better?), plus some glibc + make foo, plus some other adaptions (stubs, etc.) + <tschwinge> Does that sound about right, or am I missing something + fundamental? + <youpi> I actually don't know what a git submodule permits :) + <youpi> looks like a good thing for this, yes + <tschwinge> Unfortunately I can't allocate much time at the moment to work + on this. :-/ + <youpi> well, as long as I know where we're going, I can know how to + package stuff in Debian + <tschwinge> That sounds like a plan to me. libpthread -> glibc as + submodule. + <youpi> (note: actually, the interface between glibc and the libpthread is + the responsibility of the libpthread: it gives a couple of .c files to be + shipped in libc.so) + + +# IRC, freenode, #hurd, 2012-04-21 + + <youpi> had you tried to build libpthread as a glibc addon? + <tschwinge> youpi: No, I only know about libpthread in Hurd build system, + and libpthread stand-alone (with the Auto* stuff that I added), but not + yet as a glibc add-on. + <youpi> k + <youpi> I'm trying it atm + <tschwinge> Oh, OK. + <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as + the pthread_threads assertion errors in threaded plugins + <youpi> (once I add forward.c, but that part should not be hard) + <pinotree> that means also less use of pthread-stubs^ + <pinotree> ? + <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used + by anybody? + <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and + come in the way when building in glibc + <youpi> also, any reason for using ia32 and not i386? glibc uses the latter + <youpi> pinotree: rid of pthread-stubs yes + <pinotree> \o/ + <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea + about that one, sorry. + <youpi> I'm talking about libpthread + <youpi> not glibc + <tschwinge> Oh. + <tschwinge> sysdeps/ia32/bits/spin-lock.h:# define + __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + <tschwinge> Anyway, no idea about that either. + <youpi> that one is meant to be used with the spin-lock.h just below + <youpi> +-inline + <youpi> also, I guess signal/ was for the l4 port? + <tschwinge> youpi: I guess so. + <youpi> tschwinge: I have an issue with sysdeps pt files: + sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into + sysdeps/mach/hurd/pt-getspecific.c works + <youpi> we don't have a non-mach sysdeps directory? + <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only + "hurd", does sysdeps/hurd work? + <youpi> ah, right + <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or + in libpthread/sysdeps/mach/hurd?) + <youpi> pinotree: it worked, it was for libpthread + <youpi> good: I got libpthread built and forward working + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> phew + <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils + no-add-needed issue + + +## IRC, freenode, #hurd, 2012-04-27 + + <pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in + libpthread? + <pinotree> after all, Makefile hardcodes it, Makefile.am sets the variable + for it, and glibc expects i386 + <youpi> I know, I've asked tschwinge about it + <youpi> it's not urging anyway + <pinotree> right diff --git a/open_issues/page_cache.mdwn b/open_issues/page_cache.mdwn new file mode 100644 index 00000000..fd503fdc --- /dev/null +++ b/open_issues/page_cache.mdwn @@ -0,0 +1,79 @@ +[[!meta copyright="Copyright © 2011, 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_gnumach]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-11-28 + + <braunr> youpi: would you find it reasonable to completely disable the page + cache in gnumach ? + <braunr> i'm wondering if it wouldn't help make the system more stable + under memory pressure + <youpi> assuming cache=writeback in gnumach? + <youpi> because disabling the page cache will horribly hit performance + <braunr> no, it doesn't have anything to do with the host + <braunr> i'm not so sure + <braunr> while observing the slab allocator, i noticed our page cache is + not used that often + <youpi> eeh? + <youpi> apart from the damn 4000 limitation, I've seen it used + <youpi> (and I don't why it wouldn't be used) + <youpi> (e.g. for all parts of libc) + <youpi> ah, no, libc would be kept open by ext2fs + <braunr> taht's precisely because of the 4k limit + <youpi> but e.g. .o file emitted during make + <braunr> well, no + <youpi> well, see the summary I had posted some time ago, the 4k limit + makes it completely randomized + <youpi> and thus you lose locality + <braunr> yes + <youpi> but dropping the limit would just fix it + <braunr> that's my point + <youpi> which I had tried to do, and there were issues, you mentioned why + <youpi> and (as usual), I haven't had anyu time to have a look at the issue + again + <braunr> i'm just trying to figure out the pros and cons for having teh + current page cache implementation + <braunr> but are you saying you tried with a strict limit of 0 ? + <youpi> non, I'm saying I tried with no limit + <youpi> but then memory fills up + <braunr> yes + <youpi> so trying to garbage collect + <braunr> i tried that too, the system became unstable very quickly + <youpi> but refs don't falldown to 0, you said + <braunr> did i ? + <youpi> or maybe somebody else + <youpi> see the list archives + <braunr> that's possible + <braunr> i'd imagine someone like sergio lopez + <youpi> possibly + <youpi> somebody that knows memory stuff way better than me in any case + <braunr> youpi: i'm just wondering how much we'd loose by disabling the + page cache, and if we actually gain more stability (and ofc, if it's + worth it) + <youpi> no idea, measures will tell + <youpi> fixing the page cache shouldn't be too hard I believe, however + <youpi> you just need to know what you are doing, which I don't + <youpi> I do believe the cache is still at least a bit useful + <youpi> even if dumb because of randomness + <youpi> e.g. running make lib in the glibc tree gets faster on second time + <youpi> because the cache wouldbe filled at least randomly with glibc tree + stuff + <braunr> yes, i agree on that + <youpi> braunr: btw, the current stability is fine for the buildds + <youpi> restarting them every few days is ok + <youpi> so I'd rather keep the performance :) + <braunr> ok + + +# [[gnumach_page_cache_policy]] diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn new file mode 100644 index 00000000..8dbe1160 --- /dev/null +++ b/open_issues/performance.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]] + +*Performance analysis* ([[!wikipedia Performance_analysis desc="Wikipedia +article"]]) deals with analyzing how computing resources are used for +completing a specified task. + +[[Profiling]] is one relevant tool. + +In [[microkernel]]-based systems, there is generally a considerable [[RPC]] +overhead. + +In a multi-server system, it is non-trivial to implement a high-performance +[[I/O System|community/gsoc/project_ideas/disk_io_performance]]. + +When providing [[faq/POSIX_compatibility]] (and similar interfaces) in an +environemnt that doesn't natively implement these interfaces, there may be a +severe performance degradation. For example, in this [[`fork` system +call|/glibc/fork]]'s case. + +[[Unit_testing]] can be used for tracking performance regressions. + +--- + + * [[Degradation]] + + * [[fork]] + + * [[IPC_virtual_copy]] + + * [[microbenchmarks]] + + * [[microkernel_multi-server]] + + * [[gnumach_page_cache_policy]] + + * [[metadata_caching]] + +--- + + +# IRC, freenode, #hurd, 2012-07-05 + + <braunr> the more i study the code, the more i think a lot of time is + wasted on cpu, unlike the common belief of the lack of performance being + only due to I/O diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn new file mode 100644 index 00000000..1aaae4d2 --- /dev/null +++ b/open_issues/performance/degradation.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2011, 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]]."]]"""]] + +[[!meta title="Degradation of GNU/Hurd ``system performance''"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[[!toc]] + + +# Email, [[!message-id "87mxg2ahh8.fsf@kepler.schwinge.homeip.net"]] (bug-hurd, 2011-07-25, Thomas Schwinge) + +> Building a certain GCC configuration on a freshly booted system: 11 h. +> Remove build tree, build it again (2nd): 12 h 50 min. Huh. Remove build +> tree, reboot, build it again (1st): back to 11 h. Remove build tree, build +> it again (2nd): 12 h 40 min. Remove build tree, build it again (3rd): 15 h. + +IRC, freenode, #hurd, 2011-07-23: + + < antrik> tschwinge: yes, the system definitely gets slower with + time. after running for a couple of weeks, it needs at least twice as + long to open a new shell for example + < antrik> I don't know whether this is only related to swap usage, or there + are some serious fragmentation issues + < braunr> antrik: both could be induced by fragmentation + + +# During [[IPC_virtual_copy]] testing + +IRC, freenode, #hurd, 2011-09-02: + + <manuel> interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + <braunr> manuel: i observed the same behaviour + [...] + + +# IRC, freenode, #hurd, 2011-09-22 + +See [[/open_issues/resource_management_problems/pagers]], IRC, freenode, #hurd, +2011-09-22. + + +# [[ext2fs_page_cache_swapping_leak]] diff --git a/open_issues/performance/fork.mdwn b/open_issues/performance/fork.mdwn new file mode 100644 index 00000000..5ceb6455 --- /dev/null +++ b/open_issues/performance/fork.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2010, 2011 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 open_issue_hurd]] + +Our [[`fork` implementation|glibc/fork]] is nontrivial. + +To do: hard numbers. +[[Microbenchmarks]]? + + +# Windows / Cygwin + + * <http://www.google.com/search?q=cygwin+fork> + + * <http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html> + + In particular, *5.6. Process Creation*. + + * <http://archive.gamedev.net/community/forums/topic.asp?topic_id=360290> + + * <http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?cvsroot=src> + + > Cygwin has recently adopted something called the "cygwin heap". This is + > an internal heap that is inherited by forked/execed children. It + > consists of process specific information that should be inherited. So + > things like the file descriptor table, the current working directory, and + > the chroot value live there. + + * <http://www.perlmonks.org/?node_id=588994> diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn new file mode 100644 index 00000000..931fd0ee --- /dev/null +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2010, 2011 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_hurd]] + +This one may be considered as a testcase for [[I/O system +optimization|community/gsoc/project_ideas/disk_io_performance]]. + +It is taken from the [[binutils testsuite|binutils]], +`ld/ld-elf/sec64k.exp`, where this +test may occasionally [[trigger a timeout|binutils#64ksec]]. It is +extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24. + + $ wget -O - http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz | xz -d | tar -x + $ cd test/ + $ \time ./ld-new.stripped -o dump dump?.o dump??.o + 0.00user 0.00system 2:46.11elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + +On the idle grubber, this one repeatedly takes a few minutes wall time to +complete successfully, contrary to a few seconds on a GNU/Linux system. + +While processing the object files, there is heavy interaction with the relevant +[[hurd/translator/ext2fs]] process. Running [[hurd/debugging/rpctrace]] on +the testee shows that (primarily) an ever-repeating series of `io_seek` and +`io_read` is being processed. Running the testee on GNU/Linux with strace +shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't +as slow as the Hurd's. + +As Samuel figured out later, this slowness may in fact be due to a Xen-specific +issue, see [[Xen_lseek]]. After the latter has been addressed, we can +re-evaluate this issue here. diff --git a/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz b/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz Binary files differnew file mode 100644 index 00000000..6d7c606c --- /dev/null +++ b/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn new file mode 100644 index 00000000..a3baf30d --- /dev/null +++ b/open_issues/performance/io_system/clustered_page_faults.mdwn @@ -0,0 +1,162 @@ +[[!meta copyright="Copyright © 2011 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_gnumach open_issue_hurd]] + +[[community/gsoc/project_ideas/disk_io_performance]]. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-02-16 + + <braunr> exceptfor the kernel, everything in an address space is + represented with a VM object + <braunr> those objects can represent anonymous memory (from malloc() or + because of a copy-on-write) + <braunr> or files + <braunr> on classic Unix systems, these are files + <braunr> on the Hurd, these are memory objects, backed by external pagers + (like ext2fs) + <braunr> so when you read a file + <braunr> the kernel maps it from ext2fs in your address space + <braunr> and when you access the memory, a fault occurs + <braunr> the kernel determines it's a region backed by ext2fs + <braunr> so it asks ext2fs to provide the data + <braunr> when the fault is resolved, your process goes on + <etenil> does the faul occur because Mach doesn't know how to access the + memory? + <braunr> it occurs because Mach intentionnaly didn't back the region with + physical memory + <braunr> the MMU is programmed not to know what is present in the memory + region + <braunr> or because it's read only + <braunr> (which is the case for COW faults) + <etenil> so that means this bit of memory is a buffer that ext2fs loads the + file into and then it is remapped to the application that asked for it + <braunr> more or less, yes + <braunr> ideally, it's directly written into the right pages + <braunr> there is no intermediate buffer + <etenil> I see + <etenil> and as you told me before, currently the page faults are handled + one at a time + <etenil> which wastes a lot of time + <braunr> a certain amount of time + <etenil> enough to bother the user :) + <etenil> I've seen pages have a fixed size + <braunr> yes + <braunr> use the PAGE_SIZE macro + <etenil> and when allocating memory, the size that's asked for is rounded + up to the page size + <etenil> so if I have this correctly, it means that a file ext2fs provides + could be split into a lot of pages + <braunr> yes + <braunr> once in memory, it is managed by the page cache + <braunr> so that pages more actively used are kept longer than others + <braunr> in order to minimize I/O + <etenil> ok + <braunr> so a better page cache code would also improve overall performance + <braunr> and more RAM would help a lot, since we are strongly limited by + the 768 MiB limit + <braunr> which reduces the page cache size a lot + <etenil> but the problem is that reading a whole file in means trigerring + many page faults just for one file + <braunr> if you want to stick to the page clustering thing, yes + <braunr> you want less page faults, so that there are less IPC between the + kernel and the pager + <etenil> so either I make pages bigger + <etenil> or I modify Mach so it can check up on a range of pages for faults + before actually processing + <braunr> you *don't* change the page size + <etenil> ah + <etenil> that's hardware isn't it? + <braunr> in Mach, yes + <etenil> ok + <braunr> and usually, you want the page size to be the CPU page size + <etenil> I see + <braunr> current CPU can support multiple page sizes, but it becomes quite + hard to correctly handle + <braunr> and bigger page sizes mean more fragmentation, so it only suits + machines with large amounts of RAM, which isn't the case for us + <etenil> ok + <etenil> so I'll try the second approach then + <braunr> that's what i'd recommand + <braunr> recommend* + <etenil> ok + + +# IRC, freenode, #hurd, 2011-02-16 + + <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one + place to start looking... + <antrik> (KAM ported the OSF code to gnumach IIRC) + <antrik> there is also an existing patch for clustered paging in libpager, + which needs some adaptation + <antrik> the biggest part of the task is probably modifying the Hurd + servers to use the new interface + <antrik> but as I said, KAM's code should be available through google, and + can serve as a starting point + +<http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html> + + +# IRC, freenode, #hurd, 2011-07-22 + + <braunr> but concerning clustered pagins/outs, i'm not sure it's a mach + interface limitation + <braunr> the external memory pager interface does allow multiple pages to + be transfered + <braunr> isn't it an internal Mach VM problem ? + <braunr> isn't it simply the page fault handler ? + <antrik> braunr: are you sure? I was under the impression that changing the + pager interface was among the requirements... + <antrik> hm... I wonder whether for pageins, it could actually be handled + in the pages instead of Mach... though this wouldn't work for pageouts, + so probably not very helpful + <antrik> err... in the pagers + <braunr> antrik: i'm almost sure + <braunr> but i've be proven wrong many times, so .. + <braunr> there are two main facts that lead me to think this + <braunr> 1/ + http://www.gnu.org/software/hurd/gnumach-doc/Memory-Objects-and-Data.html#Memory-Objects-and-Data + says lengths are provided and doesn't mention the limitation + <braunr> 2/ when reading about UVM, one of the major improvements (between + 10 and 30% of global performance depending on the benchmarks) was + implementing the madvise semantics + <braunr> and this didn't involve a new pager interface, but rather a new + page fault handler + <antrik> braunr: hm... the interface indeed looks like it can handle + multiple pages in both directions... perhaps it was at the Hurd level + where the pager interface needs to be modified, not the Mach one?... + <braunr> antrik: would be nice wouldn't it ? :) + <braunr> antrik: more probably the page fault handler + + +# IRC, freenode, #hurd, 2011-09-28 + + <slpz> antrik: I've just recovered part of my old multipage I/O work + <slpz> antrik: I intend to clean and submit it after finishing the changes + to the pageout system. + <antrik> slpz: oh, great! + <antrik> didn't know you worked on multipage I/O + <antrik> slpz: BTW, have you checked whether any of the work done for GSoC + last year is any good?... + <antrik> (apart from missing copyright assignments, which would be a + serious problem for the Hurd parts...) + <slpz> antrik: It was seven years ago, but I did: + http://www.mail-archive.com/bug-hurd@gnu.org/msg10285.html :-) + <slpz> antrik: Sincerely, I don't think the quality of that code is good + enough to be considered... but I think it was my fault as his mentor for + not correcting him soon enough... + <antrik> slpz: I see + <antrik> TBH, I feel guilty myself, for not asking about the situation + immediately when he stopped attending meetings... + <antrik> slpz: oh, you even already looked into vm_pageout_scan() back then + :-) diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn new file mode 100644 index 00000000..710c746b --- /dev/null +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -0,0 +1,1567 @@ +[[!meta copyright="Copyright © 2011, 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_gnumach open_issue_hurd]] + +[[!toc]] + + +# [[community/gsoc/project_ideas/disk_io_performance]] + + +# [[gnumach_page_cache_policy]] + + +# 2011-02 + +[[Etenil]] has been working in this area. + + +## IRC, freenode, #hurd, 2011-02-13 + + <etenil> youpi: Would libdiskfs/diskfs.h be in the right place to make + readahead functions? + <youpi> etenil: no, it'd rather be at the memory management layer, + i.e. mach, unfortunately + <youpi> because that's where you see the page faults + <etenil> youpi: Linux also provides a readahead() function for higher level + applications. I'll probably have to add the same thing in a place that's + higher level than mach + <youpi> well, that should just be hooked to the same common implementation + <etenil> the man page for readahead() also states that portable + applications should avoid it, but it could be benefic to have it for + portability + <youpi> it's not in posix indeed + + +## IRC, freenode, #hurd, 2011-02-14 + + <etenil> youpi: I've investigated prefetching (readahead) techniques. One + called DiskSeen seems really efficient. I can't tell yet if it's patented + etc. but I'll keep you informed + <youpi> don't bother with complicated techniques, even the most simple ones + will be plenty :) + <etenil> it's not complicated really + <youpi> the matter is more about how to plug it into mach + <etenil> ok + <youpi> then don't bother with potential pattents + <antrik> etenil: please take a look at the work KAM did for last year's + GSoC + <youpi> just use a trivial technique :) + <etenil> ok, i'll just go the easy way then + + <braunr> antrik: what was etenil referring to when talking about + prefetching ? + <braunr> oh, madvise() stuff + <braunr> i could help him with that + + +## IRC, freenode, #hurd, 2011-02-15 + + <etenil> oh, I'm looking into prefetching/readahead to improve I/O + performance + <braunr> etenil: ok + <braunr> etenil: that's actually a VM improvement, like samuel told you + <etenil> yes + <braunr> a true I/O improvement would be I/O scheduling + <braunr> and how to implement it in a hurdish way + <braunr> (or if it makes sense to have it in the kernel) + <etenil> that's what I've been wondering too lately + <braunr> concerning the VM, you should look at madvise() + <etenil> my understanding is that Mach considers devices without really + knowing what they are + <braunr> that's roughly the interface used both at the syscall() and the + kernel levels in BSD, which made it in many other unix systems + <etenil> whereas I/O optimisations are often hard disk drives specific + <braunr> that's true for almost any kernel + <braunr> the device knowledge is at the driver level + <etenil> yes + <braunr> (here, I separate kernels from their drivers ofc) + <etenil> but Mach also contains some drivers, so I'm going through the code + to find the apropriate place for these improvements + <braunr> you shouldn't tough the drivers at all + <braunr> touch + <etenil> true, but I need to understand how it works before fiddling around + <braunr> hm + <braunr> not at all + <braunr> the VM improvement is about pagein clustering + <braunr> you don't need to know how pages are fetched + <braunr> well, not at the device level + <braunr> you need to know about the protocol between the kernel and + external pagers + <etenil> ok + <braunr> you could also implement pageout clustering + <etenil> if I understand you well, you say that what I'd need to do is a + queuing system for the paging in the VM? + <braunr> no + <braunr> i'm saying that, when a page fault occurs, the kernel should + (depending on what was configured through madvise()) transfer pages in + multiple blocks rather than one at a time + <braunr> communication with external pagers is already async, made through + regular ports + <braunr> which already implement message queuing + <braunr> you would just need to make the mapped regions larger + <braunr> and maybe change the interface so that this size is passed + <etenil> mmh + <braunr> (also don't forget that page clustering can include pages *before* + the page which caused the fault, so you may have to pass the start of + that region too) + <etenil> I'm not sure I understand the page fault thing + <etenil> is it like a segmentation error? + <etenil> I can't find a clear definition in Mach's manual + <braunr> ah + <braunr> it's a fundamental operating system concept + <braunr> http://en.wikipedia.org/wiki/Page_fault + <etenil> ah ok + <etenil> I understand now + <etenil> so what's currently happening is that when a page fault occurs, + Mach is transfering pages one at a time and wastes time + <braunr> sometimes, transferring just one page is what you want + <braunr> it depends on the application, which is why there is madvise() + <braunr> our rootfs, on the other hand, would benefit much from such an + improvement + <braunr> in UVM, this optimization is account for around 10% global + performance improvement + <braunr> accounted* + <etenil> not bad + <braunr> well, with an improved page cache, I'm sure I/O would matter less + on systems with more RAM + <braunr> (and another improvement would make mach support more RAM in the + first place !) + <braunr> an I/O scheduler outside the kernel would be a very good project + IMO + <braunr> in e.g. libstore/storeio + <etenil> yes + <braunr> but as i stated in my thesis, a resource scheduler should be as + close to its resource as it can + <braunr> and since mach can host several operating systems, I/O schedulers + should reside near device drivers + <braunr> and since current drivers are in the kernel, it makes sens to have + it in the kernel too + <braunr> so there must be some discussion about this + <etenil> doesn't this mean that we'll have to get some optimizations in + Mach and have the same outside of Mach for translators that access the + hardware directly? + <braunr> etenil: why ? + <etenil> well as you said Mach contains some drivers, but in principle, it + shouldn't, translators should do disk access etc, yes? + <braunr> etenil: ok + <braunr> etenil: so ? + <etenil> well, let's say if one were to introduce SATA support in Hurd, + nothing would stop him/her to do so with a translator rather than in Mach + <braunr> you should avoid the term translator here + <braunr> it's really hurd specific + <braunr> let's just say a user space task would be responsible for that + job, maybe multiple instances of it, yes + <etenil> ok, so in this case, let's say we have some I/O optimization + techniques like readahead and I/O scheduling within Mach, would these + also apply to the user-space task, or would they need to be + reimplemented? + <braunr> if you have user space drivers, there is no point having I/O + scheduling in the kernel + <etenil> but we also have drivers within the kernel + <braunr> what you call readahead, and I call pagein/out clustering, is + really tied to the VM, so it must be in Mach in any case + <braunr> well + <braunr> you either have one or the other + <braunr> currently we have them in the kernel + <braunr> if we switch to DDE, we should have all of them outside + <braunr> that's why such things must be discussed + <etenil> ok so if I follow you, then future I/O device drivers will need to + be implemented for Mach + <braunr> currently, yes + <braunr> but preferrably, someone should continue the work that has been + done on DDe so that drivers are outside the kernel + <etenil> so for the time being, I will try and improve I/O in Mach, and if + drivers ever get out, then some of the I/O optimizations will need to be + moved out of Mach + <braunr> let me remind you one of the things i said + <braunr> i said I/O scheduling should be close to their resource, because + we can host several operating systems + <braunr> now, the Hurd is the only system running on top of Mach + <braunr> so we could just have I/O scheduling outside too + <braunr> then you should consider neighbor hurds + <braunr> which can use different partitions, but on the same device + <braunr> currently, partitions are managed in the kernel, so file systems + (and storeio) can't make good scheduling decisions if it remains that way + <braunr> but that can change too + <braunr> a single storeio representing a whole disk could be shared by + several hurd instances, just as if it were a high level driver + <braunr> then you could implement I/O scheduling in storeio, which would be + an improvement for the current implementation, and reusable for future + work + <etenil> yes, that was my first instinct + <braunr> and you would be mostly free of the kernel internals that make it + a nightmare + <etenil> but youpi said that it would be better to modify Mach instead + <braunr> he mentioned the page clustering thing + <braunr> not I/O scheduling + <braunr> theseare really two different things + <etenil> ok + <braunr> you *can't* implement page clustering outside Mach because Mach + implements virtual memory + <braunr> both policies and mechanisms + <etenil> well, I'd rather think of one thing at a time if that's alright + <etenil> so what I'm busy with right now is setting up clustered page-in + <etenil> which need to be done within Mach + <braunr> keep clustered page-outs in mind too + <braunr> although there are more constraints on those + <etenil> yes + <etenil> I've looked up madvise(). There's a lot of documentation about it + in Linux but I couldn't find references to it in Mach (nor Hurd), does it + exist? + <braunr> well, if it did, you wouldn't be caring about clustered page + transfers, would you ? + <braunr> be careful about linux specific stuff + <etenil> I suppose not + <braunr> you should implement at least posix options, and if there are + more, consider the bsd variants + <braunr> (the Mach VM is the ancestor of all modern BSD VMs) + <etenil> madvise() seems to be posix + <braunr> there are system specific extensions + <braunr> be careful + <braunr> CONFORMING TO POSIX.1b. POSIX.1-2001 describes posix_madvise(3) + with constants POSIX_MADV_NORMAL, etc., with a behav‐ ior close to that + described here. There is a similar posix_fadvise(2) for file access. + <braunr> MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK, MADV_HWPOISON, + MADV_MERGEABLE, and MADV_UNMERGEABLE are Linux- specific. + <etenil> I was about to post these + <etenil> ok, so basically madvise() allows tasks etc. to specify a usage + type for a chunk of memory, then I could apply the relevant I/O + optimization based on this + <braunr> that's it + <etenil> cool, then I don't need to worry about knowing what the I/O is + operating on, I just need to apply the optimizations as advised + <etenil> that's convenient + <etenil> ok I'll start working on this tonight + <etenil> making a basic readahead shouldn't be too hard + <braunr> readahead is a misleading name + <etenil> is pagein better? + <braunr> applies to too many things, doesn't include the case where + previous elements could be prefetched + <braunr> clustered page transfers is what i would use + <braunr> page prefetching maybe + <etenil> ok + <braunr> you should stick to something that's already used in the + literature since you're not inventing something new + <etenil> yes I've read a paper about prefetching + <etenil> ok + <etenil> thanks for your help braunr + <braunr> sure + <braunr> you're welcome + <antrik> braunr: madvise() is really the least important part of the + picture... + <antrik> very few applications actually use it. but pretty much all + applications will profit from clustered paging + <antrik> I would consider madvise() an optional goody, not an integral part + of the implementation + <antrik> etenil: you can find some stuff about KAM's work on + http://www.gnu.org/software/hurd/user/kam.html + <antrik> not much specific though + <etenil> thanks + <antrik> I don't remember exactly, but I guess there is also some + information on the mailing list. check the archives for last summer + <antrik> look for Karim Allah Ahmed + <etenil> antrik: I disagree, madvise gives me a good starting point, even + if eventually the optimisations should run even without it + <antrik> the code he wrote should be available from Google's summer of code + page somewhere... + <braunr> antrik: right, i was mentioning madvise() because the kernel (VM) + interface is pretty similar to the syscall + <braunr> but even a default policy would be nice + <antrik> etenil: I fear that many bits were discussed only on IRC... so + you'd better look through the IRC logs from last April onwards... + <etenil> ok + + <etenil> at the beginning I thought I could put that into libstore + <etenil> which would have been fine + + <antrik> BTW, I remembered now that KAM's GSoC application should have a + pretty good description of the necessary changes... unfortunately, these + are not publicly visible IIRC :-( + + +## IRC, freenode, #hurd, 2011-02-16 + + <etenil> braunr: I've looked in the kernel to see where prefetching would + fit best. We talked of the VM yesterday, but I'm not sure about it. It + seems to me that the device part of the kernel makes more sense since + it's logically what manages devices, am I wrong? + <braunr> etenil: you are + <braunr> etenil: well + <braunr> etenil: drivers should already support clustered sector + read/writes + <etenil> ah + <braunr> but yes, there must be support in the drivers too + <braunr> what would really benefit the Hurd mostly concerns page faults, so + the right place is the VM subsystem + +[[clustered_page_faults]] + + +# 2012-03 + + +## IRC, freenode, #hurd, 2012-03-21 + + <mcsim> I thought that readahead should have some heuristics, like + accounting size of object and last access time, but i didn't find any in + kam's patch. Are heuristics needed or it will be overhead for + microkernel? + <youpi> size of object and last access time are not necessarily useful to + take into account + <youpi> what would usually typically be kept is the amount of contiguous + data that has been read lately + <youpi> to know whether it's random or sequential, and how much is read + <youpi> (the whole size of the object does not necessarily give any + indication of how much of it will be read) + <mcsim> if big object is accessed often, performance could be increased if + frame that will be read ahead will be increased too. + <youpi> yes, but the size of the object really does not matter + <youpi> you can just observe how much data is read and realize that it's + read a lot + <youpi> all the more so with userland fs translators + <youpi> it's not because you mount a CD image that you need to read it all + <mcsim> youpi: indeed. this will be better. But on other hand there is + principle about policy and mechanism. And kernel should implement + mechanism, but heuristics seems to be policy. Or in this case moving + readahead policy to user level would be overhead? + <antrik> mcsim: paging policy is all in kernel anyways; so it makes perfect + sense to put the readahead policy there as well + <antrik> (of course it can be argued -- probably rightly -- that all of + this should go into userspace instead...) + <mcsim> antrik: probably defpager partly could do that. AFAIR, it is + possible for defpager to return more memory than was asked. + <mcsim> antrik: I want to outline what should be done during gsoc. First, + kernel should support simple readahead for specified number of pages + (regarding direction of access) + simple heuristic for changing frame + size. Also default pager could make some analysis, for instance if it has + many data located consequentially it could return more data then was + asked. For other pagers I won't do anything. Is it suitable? + <antrik> mcsim: I think we actually had the same discussion already with + KAM ;-) + <antrik> for clustered pageout, the kernel *has* to make the decision. I'm + really not convinced it makes sense to leave the decision for clustered + pagein to the individual pagers + <antrik> especially as this will actually complicate matters because a) it + will require work in *every* pager, and b) it will probably make handling + of MADVISE & friends more complex + <antrik> implementing readahead only for the default pager would actually + be rather unrewarding. I'm pretty sure it's the one giving the *least* + benefit + <antrik> it's much, much more important for ext2 + <youpi> mcsim: maybe try to dig in the irc logs, we discussed about it with + neal. the current natural place would be the kernel, because it's the + piece that gets the traps and thus knows what happens with each + projection, while the backend just provides the pages without knowing + which projection wants it. Moving to userland would not only be overhead, + but quite difficult + <mcsim> antrik: OK, but I'm not sure that I could do it for ext2. + <mcsim> OK, I'll dig. + + +## IRC, freenode, #hurd, 2012-04-01 + + <mcsim> as part of implementing of readahead project I have to add + interface for setting appropriate behaviour for memory range. This + interface than should be compatible with madvise call, that has a lot of + possible advises, but most part of them are specific for Linux (according + to man page). Should mach also support these Linux-specific values? + <mcsim> p.s. these Linux-specific values shouldn't affect readahead + algorithm. + <youpi> the interface shouldn't prevent from adding them some day + <youpi> so that we don't have to add them yet + <mcsim> ok. And what behaviour with value MADV_NORMAL should be look like? + Seems that it should be synonym to MADV_SEQUENTIAL, isn't it? + <youpi> no, it just means "no idea what it is" + <youpi> in the linux implementation, that means some given readahead value + <youpi> while SEQUENTIAL means twice as much + <youpi> and RANDOM means zero + <mcsim> youpi: thank you. + <mcsim> youpi: Than, it seems to be better that kernel interface for + setting behaviour will accept readahead value, without hiding it behind + such constants, like VM_BEHAVIOR_DEFAULT (like it was in kam's + patch). And than implementation of madvise will call vm_behaviour_set + with appropriate frame size. Is that right? + <youpi> question of taste, better ask on the list + <mcsim> ok + + +## IRC, freenode, #hurd, 2012-06-09 + + <mcsim> hello. What fictitious pages in gnumach are needed for? + <mcsim> I mean why real page couldn't be grabbed straight, but in sometimes + fictitious page is grabbed first and than converted to real? + <braunr> mcsim: iirc, fictitious pages are needed by device pagers which + must comply with the vm pager interface + <braunr> mcsim: specifically, they must return a vm_page structure, but + this vm_page describes device memory + <braunr> mcsim: and then, it must not be treated like normal vm_page, which + can be added to page queues (e.g. page cache) + + +## IRC, freenode, #hurd, 2012-06-22 + + <mcsim> braunr: Ah. Patch for large storages introduced new callback + pager_notify_evict. User had to define this callback on his own as + pager_dropweak, for instance. But neal's patch change this. Now all + callbacks could have any name, but user defines structure with pager ops + and supplies it in pager_create. + <mcsim> So, I just changed notify_evict to confirm it to new style. + <mcsim> braunr: I want to changed interface of mo_change_attributes and + test my changes with real partitions. For both these I have to update + ext2fs translator, but both partitions I have are bigger than 2Gb, that's + why I need apply this patch.z + <mcsim> But what to do with mo_change_attributes? I need somehow inform + kernel about page fault policy. + <mcsim> When I change mo_ interface in kernel I have to update all programs + that use this interface and ext2fs is one of them. + + <mcsim> braunr: Who do you think better to inform kernel about fault + policy? At the moment I've added fault_strategy parameter that accepts + following strategies: randow, sequential with single page cluster, + sequential with double page cluster and sequential with quad page + cluster. OSF/mach has completely another interface of + mo_change_attributes. In OSF/mach mo_change_attributes accepts structure + of parameter. This structure could have different formats depending o + <mcsim> This rpc could be useful because it is not very handy to update + mo_change_attributes for kernel, for hurd libs and for glibc. Instead of + this kernel will accept just one more structure format. + <braunr> well, like i wrote on the mailing list several weeks ago, i don't + think the policy selection is of concern currently + <braunr> you should focus on the implementation of page clustering and + readahead + <braunr> concerning the interface, i don't think it's very important + <braunr> also, i really don't like the fact that the policy is per object + <braunr> it should be per map entry + <braunr> i think it mentioned that in my mail too + <braunr> i really think you're wasting time on this + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00064.html + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00029.html + <braunr> mcsim: any reason you completely ignored those ? + <mcsim> braunr: Ok. I'll do clustering for map entries. + <braunr> no it's not about that either :/ + <braunr> clustering is grouping several pages in the same transfer between + kernel and pager + <braunr> the *policy* is held in map entries + <antrik> mcsim: I'm not sure I properly understand your question about the + policy interface... but if I do, it's IMHO usually better to expose + individual parameters as RPC arguments explicitly, rather than hiding + them in an opaque structure... + <antrik> (there was quite some discussion about that with libburn guy) + <mcsim> antrik: Following will be ok? kern_return_t vm_advice(map, address, + length, advice, cluster_size) + <mcsim> Where advice will be either random or sequential + <antrik> looks fine to me... but then, I'm not an expert on this stuff :-) + <antrik> perhaps "policy" would be clearer than "advice"? + <mcsim> madvise has following prototype: int madvise(void *addr, size_t + len, int advice); + <mcsim> hmm... looks like I made a typo. Or advi_c_e is ok too? + <antrik> advise is a verb; advice a noun... there is a reason why both + forms show up in the madvise prototype :-) + <mcsim> so final variant should be kern_return_t vm_advise(map, address, + length, policy, cluster_size)? + <antrik> mcsim: nah, you are probably right that its better to keep + consistency with madvise, even if the name of the "advice" parameter + there might not be ideal... + <antrik> BTW, where does cluster_size come from? from the filesystem? + <antrik> I see merits both to naming the parameter "policy" (clearer) or + "advice" (more consistent) -- you decide :-) + <mcsim> antrik: also there is variant strategy, like with inheritance :) + I'll choose advice for now. + <mcsim> What do you mean under "where does cluster_size come from"? + <antrik> well, madvise doesn't have this parameter; so the value must come + from a different source? + <mcsim> in madvise implementation it could fixed value or somehow + calculated basing on size of memory range. In OSF/mach cluster size is + supplied too (via mo_change_attributes). + <antrik> ah, so you don't really know either :-) + <antrik> well, my guess is that it is derived from the cluster size used by + the filesystem in question + <antrik> so for us it would always be 4k for now + <antrik> (and thus you can probably leave it out alltogether...) + <antrik> well, fatfs can use larger clusters + <antrik> I would say, implement it only if it's very easy to do... if it's + extra effort, it's probably not worth it + <mcsim> There is sense to make cluster size bigger for ext2 too, since most + likely consecutive clusters will be within same group. + <mcsim> But anyway I'll handle this later. + <antrik> well, I don't know what cluster_size does exactly; but by the + sound of it, I'd guess it makes an assumption that it's *always* better + to read in this cluster size, even for random access -- which would be + simply wrong for 4k filesystem clusters... + <antrik> BTW, I agree with braunr that madvice() is optional -- it is way + way more important to get readahead working as a default policy first + + +## IRC, freenode, #hurd, 2012-07-01 + + <mcsim> youpi: Do you think you could review my code? + <youpi> sure, just post it to the list + <youpi> make sure to break it down into logical pieces + <mcsim> youpi: I pushed it my branch at gnumach repository + <mcsim> youpi: or it is still better to post changes to list? + <youpi> posting to the list would permit feedback from other people too + <youpi> mcsim: posix distinguishes normal, sequential and random + <youpi> we should probably too + <youpi> the system call should probably be named "vm_advise", to be a verb + like allocate etc. + <mcsim> youpi: ok. A have a talk with antrik regarding naming, I'll change + this later because compiling of glibc take a lot of time. + <youpi> mcsim: I find it odd that vm_for_every_page allocates non-existing + pages + <youpi> there should probably be at least a flag to request it or not + <mcsim> youpi: normal policy is synonym to default. And this could be + treated as either random or sequential, isn't it? + <braunr> mcsim: normally, no + <youpi> yes, the normal policy would be the default + <youpi> it doesn't mean random or sequential + <youpi> it's just to be a compromise between both + <youpi> random is meant to make no read-ahead, since that'd be spurious + anyway + <youpi> while by default we should make readahead + <braunr> and sequential makes even more aggressive readahead, which usually + implies a greater number of pages to fetch + <braunr> that's all + <youpi> yes + <youpi> well, that part is handled by the cluster_size parameter actually + <braunr> what about reading pages preceding the faulted paged ? + <mcsim> Shouldn't sequential clean some pages (if they, for example, are + not precious) that are placed before fault page? + <braunr> ? + <youpi> that could make sense, yes + <braunr> you lost me + <youpi> and something that you wouldn't to with the normal policy + <youpi> braunr: clear what has been read previously + <braunr> ? + <youpi> since the access is supposed to be sequential + <braunr> oh + <youpi> the application will proabably not re-read what was already read + <braunr> you mean to avoid caching it ? + <youpi> yes + <braunr> inactive memory is there for that + <youpi> while with the normal policy you'd assume that the application + might want to go back etc. + <youpi> yes, but you can help it + <braunr> yes + <youpi> instead of making other pages compete with it + <braunr> but then, it's for precious pages + <youpi> I have to say I don't know what a precious page it + <youpi> s + <youpi> does it mean dirty pages? + <braunr> no + <braunr> precious means cached pages + <braunr> "If precious is FALSE, the kernel treats the data as a temporary + and may throw it away if it hasn't been changed. If the precious value is + TRUE, the kernel treats its copy as a data repository and promises to + return it to the manager; the manager may tell the kernel to throw it + away instead by flushing and not cleaning the data" + <braunr> hm no + <braunr> precious means the kernel must keep it + <mcsim> youpi: According to vm_for_every_page. What kind of flag do you + suppose? If object is internal, I suppose not to cross the bound of + object, setting in_end appropriately in vm_calculate_clusters. + <mcsim> If object is external we don't know its actual size, so we should + make mo request first. And for this we should create fictitious pages. + <braunr> mcsim: but how would you implement this "cleaning" with sequential + ? + <youpi> mcsim: ah, ok, I thought you were allocating memory, but it's just + fictitious pages + <youpi> comment "Allocate a new page" should be fixed :) + <mcsim> braunr: I don't now how I will implement this specifically (haven't + tried yet), but I don't think that this is impossible + <youpi> braunr: anyway it's useful as an example where normal and + sequential would be different + <braunr> if it can be done simply + <braunr> because i can see more trouble than gains in there :) + <mcsim> braunr: ok :) + <braunr> mcsim: hm also, why fictitious pages ? + <braunr> fictitious pages should normally be used only when dealing with + memory mapped physically which is not real physical memory, e.g. device + memory + <mcsim> but vm_fault could occur when object represent some device memory. + <braunr> that's exactly why there are fictitious pages + <mcsim> at the moment of allocating of fictitious page it is not know what + backing store of object is. + <braunr> really ? + <braunr> damn, i've got used to UVM too much :/ + <mcsim> braunr: I said something wrong? + <braunr> no no + <braunr> it's just that sometimes, i'm confusing details about the various + BSD implementations i've studied + <braunr> out-of-gsoc-topic question: besides network drivers, do you think + we'll have other drivers that will run in userspace and have to implement + memory mapping ? like framebuffers ? + <braunr> or will there be a translation layer such as storeio that will + handle mapping ? + <youpi> framebuffers typically will, yes + <youpi> that'd be antrik's work on drm + <braunr> hmm + <braunr> ok + <youpi> mcsim: so does the implementation work, and do you see performance + improvement? + <mcsim> youpi: I haven't tested it yet with large ext2 :/ + <mcsim> youpi: I'm going to finish now moving of ext2 to new interface, + than other translators in hurd repository and than finish memory policies + in gnumach. Is it ok? + <youpi> which new interface? + <mcsim> Written by neal. I wrote some temporary code to make ext2 work with + it, but I'm going to change this now. + <youpi> you mean the old unapplied patch? + <mcsim> yes + <youpi> did you have a look at Karim's work? + <youpi> (I have to say I never found the time to check how it related with + neal's patch) + <mcsim> I found only his work in kernel. I didn't see his work in applying + of neal's patch. + <youpi> ok + <youpi> how do they relate with each other? + <youpi> (I have never actually looked at either of them :/) + <mcsim> his work in kernel and neal's patch? + <youpi> yes + <mcsim> They do not correlate with each other. + <youpi> ah, I must be misremembering what each of them do + <mcsim> in kam's patch was changes to support sequential reading in reverse + order (as in OSF/Mach), but posix does not support such behavior, so I + didn't implement this either. + <youpi> I can't find the pointer to neal's patch, do you have it off-hand? + <mcsim> http://comments.gmane.org/gmane.os.hurd.bugs/351 + <youpi> thx + <youpi> I think we are not talking about the same patch from Karim + <youpi> I mean lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html + <mcsim> I mean this patch: + http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00024.html + <mcsim> Oh. + <youpi> ok + <mcsim> seems, this is just the same + <youpi> yes + <youpi> from a non-expert view, I would have thought these patches play + hand in hand, do they really? + <mcsim> this patch is completely for kernel and neal's one is completely + for libpager. + <youpi> i.e. neal's fixes libpager, and karim's fixes the kernel + <mcsim> yes + <youpi> ending up with fixing the whole path? + <youpi> AIUI, karim's patch will be needed so that your increased readahead + will end up with clustered page request? + <mcsim> I will not use kam's patch + <youpi> is it not needed to actually get pages in together? + <youpi> how do you tell libpager to fetch pages together? + <youpi> about the cluster size, I'd say it shouldn't be specified at + vm_advise() level + <youpi> in other OSes, it is usually automatically tuned + <youpi> by ramping it up to a maximum readahead size (which, however, could + be specified) + <youpi> that's important for the normal policy, where there are typically + successive periods of sequential reads, but you don't know in advance for + how long + <mcsim> braunr said that there are legal issues with his code, so I cannot + use it. + <braunr> did i ? + <braunr> mcsim: can you give me a link to the code again please ? + <youpi> see above :) + <braunr> which one ? + <youpi> both + <youpi> they only differ by a typo + <braunr> mcsim: i don't remember saying that, do you have any link ? + <braunr> or log ? + <mcsim> sorry, can you rephrase "ending up with fixing the whole path"? + <mcsim> cluster_size in vm_advise also could be considered as advise + <braunr> no + <braunr> it must be the third time we're talking about this + <youpi> mcsim: I mean both parts would be needed to actually achieve + clustered i/o + <braunr> again, why make cluster_size a per object attribute ? :( + <youpi> wouldn't some objects benefit from bigger cluster sizes, while + others wouldn't? + <youpi> but again, I believe it should rather be autotuned + <youpi> (for each object) + <braunr> if we merely want posix compatibility (and for a first attempt, + it's quite enough), vm_advise is good, and the kernel selects the + implementation (and thus the cluster sizes) + <braunr> if we want finer grained control, perhaps a per pager cluster_size + would be good, although its efficiency depends on several parameters + <braunr> (e.g. where the page is in this cluster) + <braunr> but a per object cluster size is a large waste of memory + considering very few applications (if not none) would use the "feature" + .. + <braunr> (if any*) + <youpi> there must be a misunderstanding + <youpi> why would it be a waste of memory? + <braunr> "per object" + <youpi> so? + <braunr> there can be many memory objects in the kernel + <youpi> so? + <braunr> so such an overhead must be useful to accept it + <youpi> in my understanding, a cluster size per object is just a mere + integer for each object + <youpi> what overhead? + <braunr> yes + <youpi> don't we have just thousands of objects? + <braunr> for now + <braunr> remember we're trying to remove the page cache limit :) + <youpi> that still won't be more than tens of thousands of objects + <youpi> times an integer + <youpi> that's completely neglectible + <mcsim> braunr: Strange, Can't find in logs. Weird things are happening in + my memory :/ Sorry. + <braunr> mcsim: i'm almost sure i never said that :/ + <braunr> but i don't trust my memory too much either + <braunr> youpi: depends + <youpi> mcsim: I mean both parts would be needed to actually achieve + clustered i/o + <mcsim> braunr: I made I call vm_advise that applies policy to memory range + (vm_map_entry to be specific) + <braunr> mcsim: good + <youpi> actually the cluster size should even be per memory range + <mcsim> youpi: In this sense, yes + <youpi> k + <mcsim> sorry, Internet connection lags + <braunr> when changing a structure used to create many objects, keep in + mind one thing + <braunr> if its size gets larger than a threshold (currently, powers of + two), the cache used by the slab allocator will allocate twice the + necessary amount + <youpi> sure + <braunr> this is the case with most object caching allocators, although + some can have specific caches for common sizes such as 96k which aren't + powers of two + <braunr> anyway, an integer is negligible, but the final structure size + must be checked + <braunr> (for both 32 and 64 bits) + <mcsim> braunr: ok. + <mcsim> But I didn't understand what should be done with cluster size in + vm_advise? Should I delete it? + <braunr> to me, the cluster size is a pager property + <youpi> to me, the cluster size is a map property + <braunr> whereas vm_advise indicates what applications want + <youpi> you could have several process accessing the same file in different + ways + <braunr> youpi: that's why there is a policy + <youpi> isn't cluster_size part of the policy? + <braunr> but if the pager abilities are limited, it won't change much + <braunr> i'm not sure + <youpi> cluster_size is the amount of readahead, isn't it? + <braunr> no, it's the amount of data in a single transfer + <mcsim> Yes, it is. + <braunr> ok, i'll have to check your code + <youpi> shouldn't transfers permit unbound amounts of data? + <mcsim> braunr: than I misunderstand what readahead is + <braunr> well then cluster size is per policy :) + <braunr> e.g. random => 0, normal => 3, sequential => 15 + <braunr> why make it per map entry ? + <youpi> because it depends on what the application doezs + <braunr> let me check the code + <youpi> if it's accessing randomly, no need for big transfers + <youpi> just page transfers will be fine + <youpi> if accessing sequentially, rather use whole MiB of transfers + <youpi> and these behavior can be for the same file + <braunr> mcsim: the call is vm_advi*s*e + <braunr> mcsim: the call is vm_advi_s_e + <braunr> not advice + <youpi> yes, he agreed earlier + <braunr> ok + <mcsim> cluster_size is the amount of data that I try to read at one time. + <mcsim> at singe mo_data_request + <mcsim> *single + <youpi> which, to me, will depend on the actual map + <braunr> ok so it is the transfer size + <youpi> and should be autotuned, especially for normal behavior + <braunr> youpi: it makes no sense to have both the advice and the actual + size per map entry + <youpi> to get big readahead with all apps + <youpi> braunr: the size is not only dependent on the advice, but also on + the application behavior + <braunr> youpi: how does this application tell this ? + <youpi> even for sequential, you shouldn't necessarily use very big amounts + of transfers + <braunr> there is no need for the advice if there is a cluster size + <youpi> there can be, in the case of sequential, as we said, to clear + previous pages + <youpi> but otherwise, indeed + <youpi> but for me it's the converse + <youpi> the cluster size should be tuned anyway + <braunr> and i'm against giving the cluster size in the advise call, as we + may want to prefetch previous data as well + <youpi> I don't see how that collides + <braunr> well, if you consider it's the transfer size, it doesn't + <youpi> to me cluster size is just the size of a window + <braunr> if you consider it's the amount of pages following a faulted page, + it will + <braunr> also, if your policy says e.g. "3 pages before, 10 after", and + your cluster size is 2, what happens ? + <braunr> i would find it much simpler to do what other VM variants do: + compute the I/O sizes directly from the policy + <youpi> don't they autotune, and use the policy as a maximum ? + <braunr> depends on the implementations + <youpi> ok, but yes I agree + <youpi> although casting the size into stone in the policy looks bogus to + me + <braunr> but making cluster_size part of the kernel interface looks way too + messy + <braunr> it is + <braunr> that's why i would have thought it as part of the pager properties + <braunr> the pager is the true component besides the kernel that is + actually involved in paging ... + <youpi> well, for me the flexibility should still be per application + <youpi> by pager you mean the whole pager, not each file, right? + <braunr> if a pager can page more because e.g. it's a file system with big + block sizes, why not fetch more ? + <braunr> yes + <braunr> it could be each file + <braunr> but only if we have use for it + <braunr> and i don't see that currently + <youpi> well, posix currently doesn't provide a way to set it + <youpi> so it would be useless atm + <braunr> i was thinking about our hurd pagers + <youpi> could we perhaps say that the policy maximum could be a fraction of + available memory? + <braunr> why would we want that ? + <youpi> (total memory, I mean) + <youpi> to make it not completely cast into stone + <youpi> as have been in the past in gnumach + <braunr> i fail to understand :/ + <youpi> there must be a misunderstanding then + <youpi> (pun not intended) + <braunr> why do you want to limit the policy maximum ? + <youpi> how to decide it? + <braunr> the pager sets it + <youpi> actually I don't see how a pager could decide it + <youpi> on what ground does it make the decision? + <youpi> readahead should ideally be as much as 1MiB + <braunr> 02:02 < braunr> if a pager can page more because e.g. it's a file + system with big block sizes, why not fetch more ? + <braunr> is the example i have in mind + <braunr> otherwise some default values + <youpi> that's way smaller than 1MiB, isn't it? + <braunr> yes + <braunr> and 1 MiB seems a lot to me :) + <youpi> for readahead, not really + <braunr> maybe for sequential + <youpi> that's what we care about! + <braunr> ah, i thought we cared about normal + <youpi> "as much as 1MiB", I said + <youpi> I don't mean normal :) + <braunr> right + <braunr> but again, why limit ? + <braunr> we could have 2 or more ? + <youpi> at some point you don't get more efficiency + <youpi> but eat more memory + <braunr> having the pager set the amount allows us to easily adjust it over + time + <mcsim> braunr: Do you think that readahead should be implemented in + libpager? + <youpi> than needed + <braunr> mcsim: no + <braunr> mcsim: err + <braunr> mcsim: can't answer + <youpi> mcsim: do you read the log of what you have missed during + disconnection? + <braunr> i'm not sure about what libpager does actually + <mcsim> yes + <braunr> for me it's just mutualisation of code used by pagers + <braunr> i don't know the details + <braunr> youpi: yes + <braunr> youpi: that's why we want these values not hardcoded in the kernel + <braunr> youpi: so that they can be adjusted by our shiny user space OS + <youpi> (btw apparently linux uses minimum 16k, maximum 128 or 256k) + <braunr> that's more reasonable + <youpi> that's just 4 times less :) + <mcsim> braunr: You say that pager should decide how much data should be + read ahead, but each pager can't implement it on it's own as there will + be too much overhead. So the only way is to implement this in libpager. + <braunr> mcsim: gni ? + <braunr> why couldn't they ? + <youpi> mcsim: he means the size, not the actual implementation + <youpi> the maximum size, actually + <braunr> actually, i would imagine it as the pager giving per policy + parameters + <youpi> right + <braunr> like how many before and after + <youpi> I agree, then + <braunr> the kernel could limit, sure, to avoid letting pagers use + completely insane values + <youpi> (and that's just a max, the kernel autotunes below that) + <braunr> why not + <youpi> that kernel limit could be a fraction of memory, then? + <braunr> it could, yes + <braunr> i see what you mean now + <youpi> mcsim: did you understand our discussion? + <youpi> don't hesitate to ask for clarification + <mcsim> I supposed cluster_size to be such parameter. And advice will help + to interpret this parameter (whether data should be read after fault page + or some data should be cleaned before) + <youpi> mcsim: we however believe that it's rather the pager than the + application that would tell that + <youpi> at least for the default values + <youpi> posix doesn't have a way to specify it, and I don't think it will + in the future + <braunr> and i don't think our own hurd-specific programs will need more + than that + <braunr> if they do, we can slightly change the interface to make it a per + object property + <braunr> i've checked the slab properties, and it seems we can safely add + it per object + <braunr> cf http://www.sceen.net/~rbraun/slabinfo.out + <braunr> so it would still be set by the pager, but if depending on the + object, the pager could set different values + <braunr> youpi: do you think the pager should just provide one maximum size + ? or per policy sizes ? + <youpi> I'd say per policy size + <youpi> so people can increase sequential size like crazy when they know + their sequential applications need it, without disturbing the normal + behavior + <braunr> right + <braunr> so the last decision is per pager or per object + <braunr> mcsim: i'd say whatever makes your implementation simpler :) + <mcsim> braunr: how kernel knows that object are created by specific pager? + <braunr> that's the kind of things i'm referring to with "whatever makes + your implementation simpler" + <braunr> but usually, vm_objects have an ipc port and some properties + relatedto their pagers + <braunr> -usually + <braunr> the problem i had in mind was the locking protocol but our spin + locks are noops, so it will be difficult to detect deadlocks + <mcsim> braunr: and for every policy there should be variable in vm_object + structure with appropriate cluster_size? + <braunr> if you want it per object, yes + <braunr> although i really don't think we want it + <youpi> better keep it per pager for now + <braunr> let's imagine youpi finishes his 64-bits support, and i can + successfully remove the page cache limit + <braunr> we'd jump from 1.8 GiB at most to potentially dozens of GiB of RAM + <braunr> and 1.8, mostly unused + <braunr> to dozens almost completely used, almost all the times for the + most interesting use cases + <braunr> we may have lots and lots of objects to keep around + <braunr> so if noone really uses the feature ... there is no point + <youpi> but also lots and lots of memory to spend on it :) + <youpi> a lot of objects are just one page, but a lof of them are not + <braunr> sure + <braunr> we wouldn't be doing that otherwise :) + <braunr> i'm just saying there is no reason to add the overhead of several + integers for each object if they're simply not used at all + <braunr> hmm, 64-bits, better page cache, clustered paging I/O :> + <braunr> (and readahead included in the last ofc) + <braunr> good night ! + <mcsim> than, probably, make system-global max-cluster_size? This will save + some memory. Also there is usually no sense in reading really huge chunks + at once. + <youpi> but that'd be tedious to set + <youpi> there are only a few pagers, that's no wasted memory + <youpi> the user being able to set it for his own pager is however a very + nice feature, which can be very useful for databases, image processing, + etc. + <mcsim> In conclusion I have to implement following: 3 memory policies per + object and per vm_map_entry. Max cluster size for every policy should be + set per pager. + <mcsim> So, there should be 2 system calls for setting memory policy and + one for setting cluster sizes. + <mcsim> Also amount of data to transfer should be tuned automatically by + every page fault. + <mcsim> youpi: Correct me, please, if I'm wrong. + <youpi> I believe that's what we ended up to decide, yes + + +## IRC, freenode, #hurd, 2012-07-02 + + <braunr> is it safe to say that all memory objects implemented by external + pagers have "file" semantics ? + <braunr> i wonder if the current memory manager interface is suitable for + device pagers + <mcsim> braunr: What does "file" semantics mean? + <braunr> mcsim: anonymous memory doesn't have the same semantics as a file + for example + <braunr> anonymous memory that is discontiguous in physical memory can be + contiguous in swap + <braunr> and its location can change with time + <braunr> whereas with a memory object, the data exchanged with pagers is + identified with its offset + <braunr> in (probably) all other systems, this way of specifying data is + common to all files, whatever the file system + <braunr> linux uses the struct vm_file name, while in BSD/Solaris they are + called vnodes (the link between a file system inode and virtual memory) + <braunr> my question is : can we implement external device pagers with the + current interface, or is this interface really meant for files ? + <braunr> also + <braunr> mcsim: something about what you said yesterday + <braunr> 02:39 < mcsim> In conclusion I have to implement following: 3 + memory policies per object and per vm_map_entry. Max cluster size for + every policy should be set per pager. + <braunr> not per object + <braunr> one policy per map entry + <braunr> transfer parameters (pages before and after the faulted page) per + policy, defined by pagers + <braunr> 02:39 < mcsim> So, there should be 2 system calls for setting + memory policy and one for setting cluster sizes. + <braunr> adding one call for vm_advise is good because it mirrors the posix + call + <braunr> but for the parameters, i'd suggest changing an already existing + call + <braunr> not sure which one though + <mcsim> braunr: do you know how mo_change_attributes implemented in + OSF/Mach? + <braunr> after a quick reading of the reference manual, i think i + understand why they made it per object + <braunr> mcsim: no + <braunr> did they change the call to include those paging parameters ? + <mcsim> it accept two parameters: flavor and pointer to structure with + parameters. + <mcsim> flavor determines semantics of structure with parameters. + <mcsim> + http://www.darwin-development.org/cgi-bin/cvsweb/osfmk/src/mach_kernel/vm/memory_object.c?rev=1.1 + <mcsim> structure can have 3 different views and what exect view will be is + determined by value of flavor + <mcsim> So, I thought about implementing similar call that could be used + for various purposes. + <mcsim> like ioctl + <braunr> "pointer to structure with parameters" <= which one ? + <braunr> mcsim: don't model anything anywhere like ioctl please + <mcsim> memory_object_info_t attributes + <braunr> ioctl is the very thing we want NOT to have on the hurd + <braunr> ok attributes + <braunr> and what are the possible values of flavour, and what kinds of + attributes ? + <mcsim> and then appears something like this on each case: behave = + (old_memory_object_behave_info_t) attributes; + <braunr> ok i see + <mcsim> flavor could be OLD_MEMORY_OBJECT_BEHAVIOR_INFO, + MEMORY_OBJECT_BEHAVIOR_INFO, MEMORY_OBJECT_PERFORMANCE_INFO etc + <braunr> i don't really see the point of flavour here, other than + compatibility + <braunr> having attributes is nice, but you should probably add it as a + call parameter, not inside a structure + <braunr> as a general rule, we don't like passing structures too much + to/from the kernel, because handling them with mig isn't very clean + <mcsim> ok + <mcsim> What policy parameters should be defined by pager? + <braunr> i'd say number of pages to page-in before and after the faulted + page + <mcsim> Only pages before and after the faulted page? + <braunr> for me yes + <braunr> youpi might have different things in mind + <braunr> the page cleaning in sequential mode is something i wouldn't do + <braunr> 1/ applications might want data read sequentially to remain in the + cache, for other sequential accesses + <braunr> 2/ applications that really don't want to cache anything should + use O_DIRECT + <braunr> 3/ it's complicated, and we're in july + <braunr> i'd rather have a correct and stable result than too many unused + features + <mcsim> braunr: MADV_SEQUENTIAL Expect page references in sequential order. + (Hence, pages in the given range can be aggressively read ahead, and may + be freed soon after they are accessed.) + <mcsim> this is from linux man + <mcsim> braunr: Can I at least make keeping in mind that it could be + implemented? + <mcsim> I mean future rpc interface + <mcsim> braunr: From behalf of kernel pager is just a port. + <mcsim> That's why it is not clear for me how I can make in kernel + per-pager policy + <braunr> mcsim: you can't + <braunr> 15:19 < braunr> after a quick reading of the reference manual, i + think i understand why they made it per object + <braunr> + http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_madvise.html + <braunr> POSIX_MADV_SEQUENTIAL + <braunr> Specifies that the application expects to access the specified + range sequentially from lower addresses to higher addresses. + <braunr> linux might free pages after their access, why not, but this is + entirely up to the implementation + <mcsim> I know, when but applications might want data read sequentially to + remain in the cache, for other sequential accesses this kind of access + could be treated rather normal or random + <braunr> we can do differently + <braunr> mcsim: no + <braunr> sequential means the access will be sequential + <braunr> so aggressive readahead (e.g. 0 pages before, many after), should + be used + <braunr> for better performance + <braunr> from my pov, it has nothing to do with caching + <braunr> i actually sometimes expect data to remain in cache + <braunr> e.g. before playing a movie from sshfs, i sometimes prefetch it + using dd + <braunr> then i use mplayer + <braunr> i'd be very disappointed if my data didn't remain in the cache :) + <mcsim> At least these pages could be placed into inactive list to be first + candidates for pageout. + <braunr> that's what will happen by default + <braunr> mcsim: if we need more properties for memory objects, we'll adjust + the call later, when we actually implement them + <mcsim> so, first call is vm_advise and second is changed + mo_change_attributes? + <braunr> yes + <mcsim> there will appear 3 new parameters in mo_c_a: policy, pages before + and pages after? + <mcsim> braunr: With vm_advise I didn't understand one thing. This call is + defined in defs file, so that should mean that vm_advise is ordinal rpc + call. But on the same time it is defined as syscall in mach internals (in + mach_trap_table). + <braunr> mcsim: what ? + <braunr> were is it "defined" ? (it doesn't exit in gnumach currently) + <mcsim> Ok, let consider vm_map + <mcsim> I define it both in mach_trap_table and in defs file. + <mcsim> But why? + <braunr> uh ? + <braunr> let me see + <mcsim> Why defining in defs file is not enough? + <mcsim> and previous question: there will appear 3 new parameters in + mo_c_a: policy, pages before and pages after? + <braunr> mcsim: give me the exact file paths please + <braunr> mcsim: we'll discuss the new parameters after + <mcsim> kern/syscall_sw.c + <braunr> right i see + <mcsim> here mach_trap_table in defined + <braunr> i think they're not used + <braunr> they were probably introduced for performance + <mcsim> and ./include/mach/mach.defs + <braunr> don't bother adding vm_advise as a syscall + <braunr> about the parameters, it's a bit more complicated + <braunr> you should add 6 parameters + <braunr> before and after, for the 3 policies + <braunr> but + <braunr> as seen in the posix page, there could be more policies .. + <braunr> ok forget what i said, it's stupid + <braunr> yes, the 3 parameters you had in mind are correct + <braunr> don't forget a "don't change" value for the policy though, so the + kernel ignores the before/after values if we don't want to change that + <mcsim> ok + <braunr> mcsim: another reason i asked about "file semantics" is the way we + handle the cache + <braunr> mcsim: file semantics imply data is cached, whereas anonymous and + device memory usually isn't + <braunr> (although having the cache at the vm layer instead of the pager + layer allows nice things like the swap cache) + <mcsim> But this shouldn't affect possibility of implementing of device + pager. + <braunr> yes it may + <braunr> consider how a fault is actually handled by a device + <braunr> mach must use weird fictitious pages for that + <braunr> whereas it would be better to simply let the pager handle the + fault as it sees fit + <mcsim> setting may_cache to false should resolve the issue + <braunr> for the caching problem, yes + <braunr> which is why i still think it's better to handle the cache at the + vm layer, unlike UVM which lets the vnode pager handle its own cache, and + removes the vm cache completely + <mcsim> The only issue with pager interface I see is implementing of + scatter-gather DMA (as current interface does not support non-consecutive + access) + <braunr> right + <braunr> but that's a performance issue + <braunr> my problem with device pagers is correctness + <braunr> currently, i think the kernel just asks pagers for "data" + <braunr> whereas a device pager should really map its device memory where + the fault happen + <mcsim> braunr: You mean that every access to memory should cause page + fault? + <mcsim> I mean mapping of device memory + <braunr> no + <braunr> i mean a fault on device mapped memory should directly access a + shared region + <braunr> whereas file pagers only implement backing store + <braunr> let me explain a bit more + <braunr> here is what happens with file mapped memory + <braunr> you map it, access it (some I/O is done to get the page content in + physical memory), then later it's flushed back + <braunr> whereas with device memory, there shouldn't be any I/O, the device + memory should directly be mapped (well, some devices need the same + caching behaviour, while others provide direct access) + <braunr> one of the obvious consequences is that, when you map device + memory (e.g. a framebuffer), you expect changes in your mapped memory to + be effective right away + <braunr> while with file mapped memory, you need to msync() it + <braunr> (some framebuffers also need to be synced, which suggests greater + control is needed for external pagers) + <mcsim> Seems that I understand you. But how it is implemented in other + OS'es? Do they set something in mmu? + <braunr> mcsim: in netbsd, pagers have a fault operatin in addition to get + and put + <braunr> the device pager sets get and put to null and implements fault + only + <braunr> the fault callback then calls the d_mmap callback of the specific + driver + <braunr> which usually results in the mmu being programmed directly + <braunr> (e.g. pmap_enter or similar) + <braunr> in linux, i think raw device drivers, being implemented as + character device files, must provide raw read/write/mmap/etc.. functions + <braunr> so it looks pretty much similar + <braunr> i'd say our current external pager interface is insufficient for + device pagers + <braunr> but antrik may know more since he worked on ggi + <braunr> antrik: ^ + <mcsim> braunr: Seems he used io_map + <braunr> mcsim: where ar eyou looking at ? the incubator ? + <mcsim> his master's thesis + <braunr> ah the thesis + <braunr> but where ? :) + <mcsim> I'll give you a link + <mcsim> http://dl.dropbox.com/u/36519904/kgi_on_hurd.pdf + <braunr> thanks + <mcsim> see p 158 + <braunr> arg, more than 200 pages, and he says he's lazy :/ + <braunr> mcsim: btw, have a look at m_o_ready + <mcsim> braunr: This is old form of mo_change attributes + <mcsim> I'm not going to change it + <braunr> mcsim: these are actually the default object parameters right ? + <braunr> mcsim: if you don't change it, it means the kernel must set + default values until the pager changes them, if it does + <mcsim> yes. + <antrik> mcsim: madvise() on Linux has a separate flag to indicate that + pages won't be reused. thus I think it would *not* be a good idea to + imply it in SEQUENTIAL + <antrik> braunr: yes, my KMS code relies on mapping memory objects for the + framebuffer + <antrik> (it should be noted though that on "modern" hardware, mapping + graphics memory directly usually gives very poor performance, and drivers + tend to avoid it...) + <antrik> mcsim: BTW, it was most likely me who warned about legal issues + with KAM's work. AFAIK he never managed to get the copyright assignment + done :-( + <antrik> (that's not really mandatory for the gnumach work though... only + for the Hurd userspace parts) + <antrik> also I'd like to point out again that the cluster_size argument + from OSF Mach was probably *not* meant for advice from application + programs, but rather was supposed to reflect the cluster size of the + filesystem in question. at least that sounds much more plausible to me... + <antrik> braunr: I have no idea whay you mean by "device pager". device + memory is mapped once when the VM mapping is established; there is no + need for any fault handling... + <antrik> mcsim: to be clear, I think the cluster_size parameter is mostly + orthogonal to policy... and probably not very useful at all, as ext2 + almost always uses page-sized clusters. I'm strongly advise against + bothering with it in the initial implementation + <antrik> mcsim: to avoid confusion, better use a completely different name + for the policy-decided readahead size + <mcsim> antrik: ok + <antrik> braunr: well, yes, the thesis report turned out HUGE; but the + actual work I did on the KGI port is fairly tiny (not more than a few + weeks of actual hacking... everything else was just brooding) + <antrik> braunr: more importantly, it's pretty much the last (and only + non-trivial) work I did on the Hurd :-( + <antrik> (also, I don't think I used the word "lazy"... my problem is not + laziness per se; but rather inability to motivate myself to do anything + not providing near-instant gratification...) + <braunr> antrik: right + <braunr> antrik: i shouldn't consider myself lazy either + <braunr> mcsim: i agree with antrik, as i told you weeks ago + <braunr> about + <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size + parameter is mostly orthogonal to policy... and probably not very useful + at all, as ext2 almost always uses page-sized clusters. I'm strongly + advise against bothering with it + <braunr> in the initial implementation + <braunr> antrik: but how do you actually map device memory ? + <braunr> also, strangely enough, here is the comment in dragonflys + madvise(2) + <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size + parameter is mostly orthogonal to policy... and probably not very useful + at all, as ext2 almost always uses page-sized clusters. I'm strongly + advise against bothering with it + <braunr> in the initial implementation + <braunr> arg + <braunr> MADV_SEQUENTIAL Causes the VM system to depress the priority of + pages immediately preceding a given page when it is faulted in. + <antrik> braunr: interesting... + <antrik> (about SEQUENTIAL on dragonfly) + <antrik> as for mapping device memory, I just use to device_map() on the + mem device to map the physical address space into a memory object, and + then through vm_map into the driver (and sometimes application) address + space + <antrik> formally, there *is* a pager involved of course (implemented + in-kernel by the mem device), but it doesn't really do anything + interesting + <antrik> thinking about it, there *might* actually be page faults involved + when the address ranges are first accessed... but even then, the handling + is really trivial and not terribly interesting + <braunr> antrik: it does the most interesting part, create the physical + mapping + <braunr> and as trivial as it is, it requires a special interface + <braunr> i'll read about device_map again + <braunr> but yes, the fact that it's in-kernel is what solves the problem + here + <braunr> what i'm interested in is to do it outside the kernel :) + <antrik> why would you want to do that? + <antrik> there is no policy involved in doing an MMIO mapping + <antrik> you ask for the pysical memory region you are interested in, and + that's it + <antrik> whether the kernel adds the page table entries immediately or on + faults is really an implementation detail + <antrik> braunr: ^ + <braunr> yes it's a detail + <braunr> but do we currently have the interface to make such mappings from + userspace ? + <braunr> and i want to do that because i'd like as many drivers as possible + outside the kernel of course + <antrik> again, the userspace driver asks the kernel to establish the + mapping (through device_map() and then vm_map() on the resulting memory + object) + <braunr> hm i'm missing something + <braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Device-Map.html#Device-Map + <= this one ? + <antrik> yes, this one + <braunr> but this implies the device is implemented by the kernel + <antrik> the mem device is, yes + <antrik> but that's not a driver + <braunr> ah + <antrik> it's just the interface for doing MMIO + <antrik> (well, any physical mapping... but MMIO is probably the only real + use case for that) + <braunr> ok + <braunr> i was thinking about completely removing the device interface from + the kernel actually + <braunr> but it makes sense to have such devices there + <antrik> well, in theory, specific kernel drivers can expose their own + device_map() -- but IIRC the only one that does (besides mem of course) + is maptime -- which is not a real driver either... + <braunr> oh btw, i didn't know you had a blog :) + <antrik> well, it would be possible to replace the device interface by + specific interfaces for the generic pseudo devices... I'm not sure how + useful that would be + <braunr> there are lots of interesting stuff there + <antrik> hehe... another failure ;-) + <braunr> failure ? + <antrik> well, when I realized that I'm speding a lot of time pondering + things, and never can get myself to actually impelemnt any of them, I had + the idea that if I write them down, there might at least be *some* good + from it... + <antrik> unfortunately it turned out that I need so much effort to write + things down, that most of the time I can't get myself to do that either + :-( + <braunr> i see + <braunr> well it's still nice to have it + <antrik> (notice that the latest entry is two years old... and I haven't + even started describing most of my central ideas :-( ) + <braunr> antrik: i tried to create a blog once, and found what i wrote so + stupid i immediately removed it + <antrik> hehe + <antrik> actually some of my entries seem silly in retrospect as well... + <antrik> but I guess that's just the way it is ;-) + <braunr> :) + <braunr> i'm almost sure other people would be interested in what i had to + say + <antrik> BTW, I'm actually not sure whether the Mach interfaces are + sufficient to implement GEM/TTM... we would certainly need kernel support + for GART (as for any other kind IOMMU in fact); but beyond that it's not + clear to me + <braunr> GEM ? TTM ? GART ? + <antrik> GEM = Graphics Execution Manager. part of the "new" DRM interface, + closely tied with KMS + <antrik> TTM = Translation Table Manager. does part of the background work + for most of the GEM drivers + <braunr> "The Graphics Execution Manager (GEM) is a computer software + system developed by Intel to do memory management for device drivers for + graphics chipsets." hmm + <antrik> (in fact it was originally meant to provide the actual interface; + but the Inter folks decided that it's not useful for their UMA graphics) + <antrik> GART = Graphics Aperture + <antrik> kind of an IOMMU for graphics cards + <antrik> allowing the graphics card to work with virtual mappings of main + memory + <antrik> (i.e. allowing safe DMA) + <braunr> ok + <braunr> all this graphics stuff looks so complex :/ + <antrik> it is + <antrik> I have a whole big chapter on that in my thesis... and I'm not + even sure I got everything right + <braunr> what is nvidia using/doing (except for getting the finger) ? + <antrik> flushing out all the details for KMS, GEM etc. took the developers + like two years (even longer if counting the history of TTM) + <antrik> Nvidia's proprietary stuff uses a completely own kernel interface, + which is of course not exposed or docuemented in any way... but I guess + it's actually similar in what it does) + <braunr> ok + <antrik> (you could ask the nouveau guys if you are truly + interested... they are doing most of their reverse engineering at the + kernel interface level) + <braunr> it seems graphics have very special needs, and a lot of them + <braunr> and the interfaces are changing often + <braunr> so it's not that much interesting currently + <braunr> it just means we'll probably have to change the mach interface too + <braunr> like you said + <braunr> so the answer to my question, which was something like "do mach + external pagers only implement files ?", is likely yes + <antrik> well, KMS/GEM had reached some stability; but now there are + further changes ahead with the embedded folks coming in with all their + dedicated hardware, calling for unified buffer management across the + whole pipeline (from capture to output) + <antrik> and yes: graphics hardware tends to be much more complex regarding + the interface than any other hardware. that's because it's a combination + of actual I/O (like most other devices) with a very powerful coprocessor + <antrik> and the coprocessor part is pretty much unique amongst peripherial + devices + <antrik> (actually, the I/O part is also much more complex than most other + hardware... but that alone would only require a more complex driver, not + special interfaces) + <antrik> embedded hardware makes it more interesting in that the I/O + part(s) are separate from the coprocessor ones; and that there are often + several separate specialised ones of each... the DRM/KMS stuff is not + prepared to deal with this + <antrik> v4l over time has evolved to cover such things; but it's not + really the right place to implement graphics drivers... which is why + there are not efforts to unify these frameworks. funny times... + + +## IRC, freenode, #hurd, 2012-07-03 + + <braunr> mcsim: vm_for_every_page should be static + <mcsim> braunr: ok + <braunr> mcsim: see http://gcc.gnu.org/onlinedocs/gcc/Inline.html + <braunr> and it looks big enough that you shouldn't make it inline + <braunr> let the compiler decide for you (which is possible only if the + function is static) + <braunr> (otherwise a global symbol needs to exist) + <braunr> mcsim: i don't know where you copied that comment from, but you + should review the description of the vm_advice call in mach.Defs + <mcsim> braunr: I see + <mcsim> braunr: It was vm_inherit :) + <braunr> mcsim: why isn't NORMAL defined in vm_advise.h ? + <braunr> mcsim: i figured actually ;) + <mcsim> braunr: I was going to do it later when. + <braunr> mcsim: for more info on inline, see + http://www.kernel.org/doc/Documentation/CodingStyle + <braunr> arg that's an old one + <mcsim> braunr: I know that I do not follow coding style + <braunr> mcsim: this one is about linux :p + <braunr> mcsim: http://lxr.linux.no/linux/Documentation/CodingStyle should + have it + <braunr> mcsim: "Chapter 15: The inline disease" + <mcsim> I was going to fix it later during refactoring when I'll merge + mplaneta/gsoc12/working to mplaneta/gsoc12/master + <braunr> be sure not to forget :p + <braunr> and the best not to forget is to do it asap + <braunr> +way + <mcsim> As to inline. I thought that even if I specify function as inline + gcc makes final decision about it. + <mcsim> There was a specifier that made function always inline, AFAIR. + <braunr> gcc can force a function not to be inline, yes + <braunr> but inline is still considered as a strong hint + + +## IRC, freenode, #hurd, 2012-07-05 + + <mcsim1> braunr: hello. You've said that pager has to supply 2 values to + kernel to give it an advice how execute page fault. These two values + should be number of pages before and after the page where fault + occurred. But for sequential policy number of pager before makes no + sense. For random policy too. For normal policy it would be sane to make + readahead symmetric. Probably it would be sane to make pager supply + cluster_size (if it is necessary to supply any) that w + <mcsim1> *that will be advice for kernel of least sane value? And maximal + value will be f(free_memory, map_entry_size)? + <antrik> mcsim1: I doubt symmetric readahead would be a good default + policy... while it's hard to estimate an optimum over all typical use + cases, I'm pretty sure most situtations will benefit almost exclusively + from reading following pages, not preceeding ones + <antrik> I'm not even sure it's useful to read preceding pages at all in + the default policy -- the use cases are probably so rare that the penalty + in all other use cases is not justified. I might be wrong on that + though... + <antrik> I wonder how other systems handle that + <LarstiQ> antrik: if there is a mismatch between pages and the underlying + store, like why changing small bits of data on an ssd is slow? + <braunr> mcsim1: i don't see why not + <braunr> antrik: netbsd reads a few pages before too + <braunr> actually, what netbsd does vary on the version, some only mapped + in resident pages, later versions started asynchronous transfers in the + hope those pages would be there + <antrik> LarstiQ: not sure what you are trying to say + <braunr> in linux : + <braunr> 321 * MADV_NORMAL - the default behavior is to read clusters. + This + <braunr> 322 * results in some read-ahead and read-behind. + <braunr> not sure if it's actually what the implementation does + <antrik> well, right -- it's probably always useful to read whole clusters + at a time, especially if they are the same size as pages... that doesn't + mean it always reads preceding pages; only if the read is in the middle + of the cluster AIUI + <LarstiQ> antrik: basically what braunr just pasted + <antrik> and in most cases, we will want to read some *following* clusters + as well, but probably not preceding ones + * LarstiQ nods + <braunr> antrik: the default policy is usually rather sequential + <braunr> here are the numbers for netbsd + <braunr> 166 static struct uvm_advice uvmadvice[] = { + <braunr> 167 { MADV_NORMAL, 3, 4 }, + <braunr> 168 { MADV_RANDOM, 0, 0 }, + <braunr> 169 { MADV_SEQUENTIAL, 8, 7}, + <braunr> 170 }; + <braunr> struct uvm_advice { + <braunr> int advice; + <braunr> int nback; + <braunr> int nforw; + <braunr> }; + <braunr> surprising isn't it ? + <braunr> they may suggest sequential may be backwards too + <braunr> makes sense + <antrik> braunr: what are these numbers? pages? + <braunr> yes + <antrik> braunr: I suspect the idea behind SEQUENTIAL is that with typical + sequential access patterns, you will start at one end of the file, and + then go towards the other end -- so the extra clusters in the "wrong" + direction do not actually come into play + <antrik> only situation where some extra clusters are actually read is when + you start in the middle of a file, and thus do not know yet in which + direction the sequential read will go... + <braunr> yes, there are similar comments in the linux code + <braunr> mcsim1: so having before and after numbers seems both + straightforward and in par with other implementations + <antrik> I'm still surprised about the almost symmetrical policy for NORMAL + though + <antrik> BTW, is it common to use heuristics for automatically recognizing + random and sequential patterns in the absence of explicit madise? + <braunr> i don't know + <braunr> netbsd doesn't use any, linux seems to have different behaviours + for anonymous and file memory + <antrik> when KAM was working on this stuff, someone suggested that... + <braunr> there is a file_ra_state struct in linux, for per file read-ahead + policy + <braunr> now the structure is of course per file system, since they all use + the same address + <braunr> (which is why i wanted it to be per pager in the first place) + <antrik> mcsim1: as I said before, it might be useful for the pager to + supply cluster size, if it's different than page size. but right now I + don't think this is something worth bothering with... + <antrik> I seriously doubt it would be useful for the pager to supply any + other kind of policy + <antrik> braunr: I don't understand your remark about using the same + address... + <antrik> braunr: pre-mapping seems the obvious way to implement readahead + policy + <antrik> err... per-mapping + <braunr> the ra_state (read ahead state) isn't the policy + <braunr> the policy is per mapping, parts of the implementation of the + policy is per file system + <mcsim1> braunr: How do you look at following implementation of NORMAL + policy: We have fault page that is current. Than we have maximal size of + readahead block. First we find first absent pages before and after + current. Than we try to fit block that will be readahead into this + range. Here could be following situations: in range RBS/2 (RBS -- size of + readahead block) there is no any page, so readahead will be symmetric; if + current page is first absent page than all + <mcsim1> RBS block will consist of pages that are after current; on the + contrary if current page is last absent than readahead will go backwards. + <mcsim1> Additionally if current page is approximately in the middle of the + range we can decrease RBS, supposing that access is random. + <braunr> mcsim1: i think your gsoc project is about readahead, we're in + july, and you need to get the job done + <braunr> mcsim1: grab one policy that works, pages before and after are + good enough + <braunr> use sane default values, let the pagers decide if they want + something else + <braunr> and concentrate on the real work now + <antrik> braunr: I still don't see why pagers should mess with that... only + complicates matters IMHO + <braunr> antrik: probably, since they almost all use the default + implementation + <braunr> mcsim1: just use sane values inside the kernel :p + <braunr> this simplifies things by only adding the new vm_advise call and + not change the existing external pager interface diff --git a/open_issues/performance/ipc_virtual_copy.mdwn b/open_issues/performance/ipc_virtual_copy.mdwn new file mode 100644 index 00000000..9708ab96 --- /dev/null +++ b/open_issues/performance/ipc_virtual_copy.mdwn @@ -0,0 +1,395 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-09-02: + + <slpz> what's the usual throughput for I/O operations (like "dd + if=/dev/zero of=/dev/null") in one of those Xen based Hurd machines + (*bber)? + <braunr> good question + <braunr> slpz: but don't use /dev/zero and /dev/null, as they don't have + anything to do with true I/O operations + <slpz> braunr: in fact, I want to test the performance of IPC's virtual + copy operations + <braunr> ok + <slpz> braunr: sorry, the "I/O" was misleading + <braunr> use bs=4096 then i guess + <slpz> bs > 2k + <braunr> ? + <slpz> braunr: everything about 2k is copied by vm_map_copyin/copyout + <slpz> s/about/above/ + <slpz> braunr: MiG's stubs check for that value and generate complex (with + out_of_line memory) messages if datalen is above 2k, IIRC + <braunr> ok + <braunr> slpz: found it, thanks + <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 13469 + <tschwinge> 17091+0 records in + <tschwinge> 17090+0 records out + <tschwinge> 70000640 bytes (70 MB) copied, 17.1436 s, 4.1 MB/s + <tschwinge> Note, however 10 s vs. 17 s! + <tschwinge> And this is slow compared to heal hardware: + <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! && + sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 28290 + <tschwinge> 93611+0 records in + <tschwinge> 93610+0 records out + <tschwinge> 383426560 bytes (383 MB) copied, 9.99 s, 38.4 MB/s + <braunr> tschwinge: is the first result on xen vm ? + <tschwinge> I think so. + <braunr> :/ + <slpz> tschwinge: Thanks! Could you please try with a higher block size, + something like 128k or 256k? + <tschwinge> strauss is on a machine that also hosts a buildd, I think. + <braunr> oh ok + <pinotree> yes, aside either rossini or mozart + <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). + +[[open_issues/time]] + + <braunr> slpz: i'll set up xen hosts soon and can try those tests while + nothing else runs to have more accurate results + <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=256k & + p=$! && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 13482 + <tschwinge> 4566+0 records in + <tschwinge> 4565+0 records out + <tschwinge> 1196687360 bytes (1.2 GB) copied, 13.6751 s, 87.5 MB/s + <braunr> slpz: gains are logarithmic beyond the page size + <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=256k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 28295 + <tschwinge> 6335+0 records in + <tschwinge> 6334+0 records out + <tschwinge> 1660420096 bytes (1.7 GB) copied, 9.99 s, 166 MB/s + <tschwinge> This time a the sleep 10 decided to take 13.6 s. + ``Interesting.'' + <slpz> tschwinge: Thanks again. The results for the Xen machine are not bad + though. I can't obtain a throughput over 50MB/s with KVM. + <tschwinge> slpz: Want more data (bs)? Just tell. + <braunr> slpz: i easily get more than that + <braunr> slpz: what buffer size do you use ? + <slpz> tschwinge: no, I just wanted to see if Xen has an upper limit beyond + KVM's. Thank you. + <slpz> braunr: I try with different sizes until I find the maximum + throughput for a certain amount of requests (count) + <slpz> braunr: are you working with KVM? + <braunr> yes + <braunr> slpz: my processor is a model name : Intel(R) Core(TM)2 Duo + CPU E7500 @ 2.93GHz + <braunr> Linux silvermoon 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC + 2011 x86_64 GNU/Linux + <braunr> (standard amd64 squeeze kernel) + <slpz> braunr: and KVM's version? + <braunr> squeeze (0.12.5) + <braunr> bbl + <gnu_srs> 212467712 bytes (212 MB) copied, 9.95 s, 21.4 MB/s on kvm for me! + <slpz> gnu_srs: which block size? + <gnu_srs> 4k, and 61.7 MB/s with 256k + <slpz> gnu_srs: could you try with 512k and 1M? + <gnu_srs> 512k: 56.0 MB/s, 1024k: 40.2 MB/s Looks like the peak is around a + few 100k + <slpz> gnu_srs: thanks! + <slpz> I've just obtained 1.3GB/s with bs=512k on other (newer) machine + <braunr> on which hw/vm ? + <slpz> I knew this is a cpu-bound test, but I couldn't imagine faster + processors could make this difference + <slpz> braunr: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz + <slpz> braunr: KVM + <braunr> ok + <braunr> how much time did you wait before reading the result ? + <slpz> that was 20x times better than the same test on my Intel(R) + Core(TM)2 Duo CPU T7500 @ 2.20GHz + <slpz> braunr: I've repeated the test with a fixed "count" + <gnu_srs> My box is: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz: Max + is 67 MB/s around 140k block size + <braunr> yes but how much time did dd run ? + <gnu_srs> 10 s plus/minus a few fractions of a second, + <braunr> try waiting 30s + <slpz> braunr: didn't check, let me try again + <braunr> my kvm peaks at 130 MiB/s with bs 512k / 1M + <gnu_srs> 2029690880 bytes (2.0 GB) copied, 30.02 s, 67.6 MB/s, bs=140k + <braunr> gnu_srs: i'm very surprised with slpz's result of 1.3 GiB/s + <slpz> braunr: over 60 s running, same performance + <braunr> nice + <braunr> i wonder what makes it so fast + <braunr> how much cache ? + <gnu_srs> Me too, I cannot get better values than around 67 MB/s + <braunr> gnu_srs: same questions + <slpz> braunr: 4096KB, same as my laptop + <braunr> slpz: l2 ? l3 ? + <gnu_srs> kvm: cache=writeback, CPU: 4096 KB + <braunr> gnu_srs: this has nothing to do with the qemu option, it's about + the cpu + <slpz> braunr: no idea, it's the first time I touch this machine. I going + to see if I find the model in processorfinder + <braunr> under my host linux system, i get a similar plot, that is, + performance drops beyond bs=1M + <gnu_srs> braunr: OK, bu I gave you the cache size too, same as slpz. + <braunr> i wonder what dd actually does + <braunr> read() and writes i guess + <slpz> braunr: read/write repeatedly, nothing fancy + <braunr> slpz: i don't think it's a good test for virtual copy + <braunr> io_read_request, vm_deallocate, io_write_request, right + <braunr> slpz: i really wonder what it is about i5 that improves speed so + much + <slpz> braunr: me too + <slpz> braunr: L2: 2x256KB, L3: 4MB + <slpz> and something calling "SmartCache" + <gnu_srs> slpz: where did you find these values? + <slpz> gnu_srs: ark.intel.com and wikipedia + <gnu_srs> aha, cpuinfo just gives cache size. + <slpz> that "SmartCache" thing seems to be just L2 cache sharing between + cores. Shouldn't make a different since we're using only one core, and I + don't see KVM hooping between them. + <manuel> with bs=256k: 7004487680 bytes (7.0 GB) copied, 10 s, 700 MB/s + <manuel> (qemu/kvm, 3 * Intel(R) Xeon(R) E5504 2GHz, cache size 4096 KB) + <slpz> manuel: did you try with 512k/1M? + <manuel> bs=512k: 7730626560 bytes (7.7 GB) copied, 10 s, 773 MB/s + <manuel> bs=1M: 7896825856 bytes (7.9 GB) copied, 10 s, 790 MB/s + <slpz> manuel: those are pretty good numbers too + <braunr> xeon processor + <gnu_srs> lshw gave me: L1 Cache 256KiB, L2 cache 4MiB + <slpz> sincerely, I've never seen Hurd running this fast. Just checked + "uname -a" to make sure I didn't take the wrong image :-) + <manuel> for bs=256k, 60s: 40582250496 bytes (41 GB) copied, 60 s, 676 MB/s + <braunr> slpz: i think you can assume processor differences alter raw + copies too much to get any valuable results about virtual copy operations + <braunr> you need a specialized test program + <manuel> and bs=512k, 60s, 753 MB/s + <slpz> braunr: I'm using the mach_perf suite from OSFMach to do the + "serious" testing. I just wanted a non-synthetic test to confirm the + readings. + +[[!taglink open_issue_gnumach]] -- have a look at *mach_perf*. + + <braunr> manuel: how much cache ? 2M ? + <braunr> slpz: ok + <braunr> manuel: hmno, more i guess + <manuel> braunr: /proc/cpuinfo says cache size : 4096 KB + <braunr> ok + <braunr> manuel: performance should drop beyond bs=2M + <braunr> but that's not relevant anyway + <gnu_srs> Linux: bs=1M, 10.8 GB/s + <slpz> I think this difference is too big to be only due to a bigger amount + of CPU cycles... + <braunr> slpz: clearly + <slpz> gnu_srs: your host system has 64 or 32 bits? + <slpz> braunr: I'm going to investigate a bit + <slpz> but this accidental discovery just made my day. We're able to run + Hurd at decent speeds on newer hardware! + <braunr> slpz: what result do you get with the same test on your host + system ? + <manuel> interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + +[[Degradataion]]. + + <slpz> braunr: probably an almost infinite throughput, but I don't consider + that a valid test, since in Linux, the write operation to "/dev/null" + doesn't involve memory copying/moving + <braunr> manuel: i observed the same behaviour + <gnu_srs> slpz: Host system is 64 bit + <braunr> slpz: it doesn't on the hurd either + <braunr> slpz: (under 2k, that is) + <braunr> over* + <slpz> braunr: humm, you're right, as the null translator doesn't "touch" + the memory, CoW rules apply + <braunr> slpz: the only thing which actually copies things around is dd + <braunr> probably by simply calling read() + <braunr> which gets its result from a VM copy operation, but copies the + content to the caller provided buffer + <braunr> then vm_deallocate() the data from the storeio (zero) translator + <braunr> if storeio isn't too dumb, it doesn't even touch the transfered + buffer (as anonymous vm_map()ped memory is already cleared) + +[[!taglink open_issue_documentation]] + + <braunr> so this is a good test for measuring (profiling?) our ipc overhead + <braunr> and possibly the vm mapping operations (which could partly explain + why the results get worse over time) + <braunr> manuel: can you run vminfo | wc -l on your gnumach process ? + <slpz> braunr: Yes, unless some special situation apply, like the source + address/offset being unaligned, or if the translator decides to return + the result in a different buffer (which I assume is not the case for + storeio/zero) + <manuel> braunr: 35 + <braunr> slpz: they can't be unaligned, the vm code asserts that + <braunr> manuel: ok, this is normal + <slpz> braunr: address/offset from read() + <braunr> slpz: the caller provided buffer you mean ? + <slpz> braunr: yes, and the offset of the memory_object, if it's a pager + based translator + <braunr> slpz: highly unlikely, the compiler chooses appropriate alignments + for such buffers + <slpz> braunr: in those cases, memcpy is used over vm_copy + <braunr> slpz: and the glibc memcpy() optimized versions can usually deal + with that + <braunr> slpz: i don't get your point about memory objects + <braunr> slpz: requests on memory objects always have aligned values too + <slpz> braunr: sure, but can't deal with the user requesting non + page-aligned sizes + <braunr> slpz: we're considering our dd tests, for which we made sure sizes + were page aligned + <slpz> braunr: oh, I was talking in a general sense, not just in this dd + tests, sorry + <slpz> by the way, dd on the host tops at 12 GB/s with bs=2M + <braunr> that's consistent with our other results + <braunr> slpz: you mean, even on your i5 processor with 1.3 GiB/s on your + hurd kvm ? + <slpz> braunr: yes, on the GNU/Linux which is running as host + <braunr> slpz: well that's not consistent + <slpz> braunr: consistent with what? + <braunr> slpz: i get roughly the same result on my host, but ten times less + on my hurd kvm + <braunr> slpz: what's your kernel/kvm versions ? + <slpz> 2.6.32-5-amd64 (debian's build) 0.12.5 + <braunr> same here + <braunr> i'm a bit clueless + <braunr> why do i only get 130 MiB/s where you get 1.3 .. ? :) + <slpz> well, on my laptop, where Hurd on KVM tops on 50 MB/s, Linux gets a + bit more than 10 GB/s + <braunr> see + <braunr> slpz: reduce bs to 256k and test again if you have time please + <slpz> braunr: on which system? + <braunr> slpz: the fast one + <braunr> (linux host) + <slpz> braunr: Hurd? + <slpz> ok + <slpz> 12 GB/s + <braunr> i get 13.3 + <slpz> same for 128k, only at 64k starts dropping + <slpz> maybe, on linux we're being limited by memory speed, while on Hurd's + this test is (much) more CPU-bound? + <braunr> slpz: maybe + <braunr> too bad processor stalls aren't easy to measure + <slpz> braunr: that's very true. It's funny when you read a paper which + measures performance by cycles on an old RISC processor. That's almost + impossible to do (with reliability) nowadays :-/ + <slpz> I wonder which throughput can achieve Hurd running bare-metal on + this machine... + <antrik> both the Xeon and the i5 use cores based on the Nehalem + architecture + <antrik> apparently Nehalem is where Intel first introduces nested page + tables + <antrik> which pretty much explains the considerably lower overhead of VM + magic + <cjuner> antrik, what are nested page tables? (sounds like the 4-level page + tables we already have on amd64, or 2-level or 3-level on x86 pae) + <antrik> page tables were always 2-level on x86 + <antrik> that's unrelated + <antrik> nested page tables means there is another layer of address + translation, so the VMM can do it's own translation and doesn't care what + the guest system does => no longer has to intercept all page table + manipulations + <braunr> antrik: do you imply it only applies to virtualized systems ? + <antrik> braunr: yes + <slpz> antrik: Good guess. Looks like Intel's EPT are doing the trick by + allowing the guest OS deal with its own page faults + <slpz> antrik: next monday, I'll try disabling EPT support in KVM on that + machine (the fast one). That should confirm your theory empirically. + <slpz> this also means that there're too many page faults, as we should be + doing virtual copies of memory that is not being accessed + <slpz> and looking at how the value of "page faults" in "vmstat" increases, + shows that page faults are directly proportional to the number of pages + we are asking from the translator + <slpz> I've also tried doing a long read() directly, to be sure that "dd" + is not doing something weird, and it shows the same behaviour. + <braunr> slpz: dd does copy buffers + <braunr> slpz: i told you, it's not a good test case for pure virtual copy + evaluation + <braunr> antrik: do you know if xen benefits from nested page tables ? + <antrik> no idea + +[[!taglink open_issue_xen]] + + <slpz> braunr: but my small program doesn't, and still provokes a lot of + page faults + <braunr> slpz: are you certain it doesn't ? + <slpz> braunr: looking at google, it looks like recent Xen > 3.4 supports + EPT + <braunr> ok + <braunr> i'm ordering my new server right now, core i5 :) + <slpz> braunr: at least not explicitily. I need to look at MiG stubs again, + I don't remember if they do something weird. + <antrik> braunr: sandybridge or nehalem? :-) + <braunr> antrik: no idea + <antrik> does it tell a model number? + <braunr> not yet + <braunr> but i don't have a choice for that, so i'll order it first, check + after + <antrik> hehe + <antrik> I'm not sure it makes all that much difference anyways for a + server... unless you are running it at 100% load ;-) + <braunr> antrik: i'm planning on running xen guests suchs as new buildd + <antrik> hm... note though that some of the nehalem-generation i5s were + dual-core, while all the new ones are quad + <braunr> it's a quad + <antrik> the newer generation has better performance per GHz and per + Watt... but considering that we are rather I/O-limited in most cases, it + probably won't make much difference + <antrik> not sure whether there are further virtualisation improvements + that could be relevant... + <braunr> buildds spend much time running gcc, so even such improvements + should help + <braunr> there, server ordered :) + <braunr> antrik: model name : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz + +IRC, freenode, #hurd, 2011-09-06: + + <slpz> youpi: what machines are being used for buildd? Do you know if they + have EPT/RVI? + <youpi> we use PV Xen there + <slpz> I think Xen could also take advantage of those technologies. Not + sure if only in HVM or with PV too. + <youpi> only in HVM + <youpi> in PV it does not make sense: the guest already provides the + translated page table + <youpi> which is just faster than anything else + +IRC, freenode, #hurd, 2011-09-09: + + <antrik> oh BTW, for another data point: dd zero->null gets around 225 MB/s + on my lowly 1 GHz Pentium3, with a blocksize of 32k + <antrik> (but only half of that with 256k blocksize, and even less with 1M) + <antrik> the system has been up for a while... don't know whether it's + faster on a freshly booted one + +IRC, freenode, #hurd, 2011-09-15: + + <sudoman> + http://www.reddit.com/r/gnu/comments/k68mb/how_intelamd_inadvertently_fixed_gnu_hurd/ + <sudoman> so is the dd command pointed to by that article a measure of io + performance? + <antrik> sudoman: no, not really + <antrik> it's basically the baseline of what is possible -- but the actual + slowness we experience is more due to very unoptimal disk access patterns + <antrik> though using KVM with writeback caching does actually help with + that... + <antrik> also note that the title of this post really makes no + sense... nested page tables should provide similar improvements for *any* + guest system doing VM manipulation -- it's not Hurd-specific at all + <sudoman> ok, that makes sense. thanks :) + +IRC, freenode, #hurd, 2011-09-16: + + <slpz> antrik: I wrote that article (the one about How AMD/Intel fixed...) + <slpz> antrik: It's obviously a bit of an exaggeration, but it's true that + nested pages supposes a great improvement in the performance of Hurd + running on virtual machines + <slpz> antrik: and it's Hurd specific, as this system is more affected by + the cost of page faults + <slpz> antrik: and as the impact of virtualization on the performance is + much higher than (almost) any other OS. + <slpz> antrik: also, dd from /dev/zero to /dev/null it's a measure on how + fast OOL IPC is. diff --git a/open_issues/performance/microbenchmarks.mdwn b/open_issues/performance/microbenchmarks.mdwn new file mode 100644 index 00000000..de3a54b7 --- /dev/null +++ b/open_issues/performance/microbenchmarks.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +Microbenchmarks may give useful hints, or they may not. + +<http://www.ibm.com/developerworks/java/library/j-jtp02225.html> diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn new file mode 100644 index 00000000..111d2b88 --- /dev/null +++ b/open_issues/performance/microkernel_multi-server.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2011 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_documentation]] + +Performance issues due to the microkernel/multi-server system architecture? + +IRC, freenode, #hurd, 2011-07-26 + + < CTKArcher> I read that, because of its microkernel+servers design, the + hurd was slower than a monolithic kernel, is that confirmed ? + < youpi> the hurd is currently slower than current monolithic kernels, but + it's not due to the microkernel + servers design + < youpi> the microkernel+servers design makes the system call path longer + < youpi> but you're bound by disk and network speed + < youpi> so the extra overhead will not hurt so much + < youpi> except dumb applications keeping doing system calls all the time + of course, but they are usually considered bogus + < braunr> there may be some patterns (like applications using pipes + extensively, e.g. git-svn) which may suffer from the design, but still in + an acceptable range + < CTKArcher> so, you are saying that disk and network are more slowing the + system than the longer system call path and because of that, it wont + really matter ? + < youpi> braunr: they should sitll be fixed because they'll suffer (even if + less) on monolithic kernels + < youpi> CTKArcher: yes + < braunr> yes + < CTKArcher> mmh + < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10 + iirc, about minix + < youpi> they even go as far as using an IPC for each low-level in/out + < youpi> for security + < braunr> this has been expected for a long time + < braunr> which is what motivated research in microkernels + < CTKArcher> I've already downloaded the video :) + < youpi> and it has been more and more true with faster and faster cpus + < braunr> but in 95, processors weren't that fast compared to other + components as they are now + < youpi> while disk/mem haven't evovled so fast diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn new file mode 100644 index 00000000..48343e3e --- /dev/null +++ b/open_issues/perl.mdwn @@ -0,0 +1,101 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="Foster Perl programming"]] + +[[!template id=note text="""**2011-08**. A dependency loop in Debian GNU/Hurd +currently leads to: *Could not perform immediate configuration on 'perl'*. +Easy workaround: + + # apt-get install perl perl-base -o APT::Immediate-Configure=false + +"""]] + + +Resolve issues uncovered by Perl's test suite, and enable Hurd-specific +features. + +There is a [[!FF_project 264]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + + +## IRC, OFTC, #debian-hurd, 2011-11-08 + + <Dom> pinotree: so, with your three fixes applied to 5.14.2, there are + still 9 tests failing. They don't seem to be regressions in perl, since + they also fail when I build 5.14.0 (even though the buildd managed it). + <Dom> What do you suggest as the way forward? + <Dom> (incidentally I'm trying on strauss's sid chroot to see how that + compares) + <pinotree> Dom: samuel makes buildds build perl with nocheck (otherwise + we'd have no perl at all) + <pinotree> which tests still fail? + <Dom> ../cpan/Sys-Syslog/t/syslog.t ../cpan/Time-HiRes/t/HiRes.t + ../cpan/autodie/t/recv.t ../dist/IO/t/io_pipe.t ../dist/threads/t/libc.t + ../dist/threads/t/stack.t ../ext/Socket/t/socketpair.t io/pipe.t + op/sigdispatch.t + <Dom> buildds> I see + <pinotree> ah ok, those that are failing for me even with my patches + <Dom> I hadn't spotted that the builds were done with nocheck. + <Dom> (but only sometimes...) + <Dom> Explains a lot + <pinotree> syslog is kind of non-working on hurd, and syslog.t succeeds in + buildds (as opposted to crash the machine...) because there's no /var/log + in chroots + <pinotree> libc.t appears to succeed too in buildds + * Dom notices how little memory strauss has, and cancels the build, now + that he *knows* that running out of memory caused the crahses + <pinotree> iirc HiRes.t, io_pipe.t , pipe.t and sigdispatch.t fails because + of trobules we have with posix signals + <pinotree> socketpair.t is kind of curious, it seems to block on + socketpair()... + * Dom wonders if a wiki page tracking this would be worthwhile + <pinotree> stack.t fails because we cannot set a different size for pthread + stacks, yet (similar failing test cases are also in the python test + suite) + <Dom> if there are problems which aren't going to get resolved any time + soon, it may be worth a few SKIPs conditional on architecture, depending + on how serious the issue is + <Dom> then we'd get better visibility of other/new issues + <Dom> (problems which aren't bugs in perl, that is) + <pinotree> understandable, yes + <pinotree> i think nobody digged much deeper in the failing ones yet, to + actually classify them as due to glibc/hurd/mach + <pinotree> (eg unlike the pipe behaviour in sysconf.t i reported) + +### 2011-11-26 + + <pinotree> cool, my recvfrom() fix also makes the perl test recv.t pass + + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in Perl. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/perlmagick.mdwn b/open_issues/perlmagick.mdwn new file mode 100644 index 00000000..8a57a8fd --- /dev/null +++ b/open_issues/perlmagick.mdwn @@ -0,0 +1,107 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +[[!debbug 557771]] + +# Bisecting + + * Good + + * 7:6.4.0.9.dfsg1-1 (2008-04-22) built from + <http://snapshot.debian.net/package/imagemagick> + * 6.4.0-11 + * 6.4.1-0 + * 6.4.1-1 + + * Bad + + * 6.4.1-2 + * 6.4.1-5 + * 6.4.1-10 + * 6.4.2-10 + * 6.4.5-9 + * 6.4.8-0 / Debian 6.4.8.0-1 + * 6.5.5-3 / Debian 6.5.5.3-1 + * 6.5.8.3-1 from Debian unstable (also in testing) + * Svn trunk (r848) + + +# 6.4.1-1 -> 6.4.1-2 + + -CFLAGS = -g -O2 -Wall -W -pthread + +CFLAGS = -fopenmp -g -O2 -Wall -W -pthread + -GOMP_LIBS = + +GOMP_LIBS = -lgomp + -LDFLAGS = -lfreetype -lz + +LDFLAGS = -fopenmp -lfreetype -lz + +Etc. + + +/usr/include/pthread.h: + + + +/usr/include/pthread/pthread.h: + + + +/usr/include/bits/spin-lock-inline.h: + + + +/usr/include/bits/cancelation.h: + + + +/usr/include/bits/pthread-np.h: + + + +/usr/lib/gcc/i486-gnu/4.4.2/include/omp.h: + + +# State as of 2011-03-06 + +freenode, #hurd channel, 2011-03-06: + + <pinotree> tschwinge: (speaking on working perl, how did it en with that + "(glibc) double free" crash with perl?) + <pinotree> *end + <tschwinge> I think I remember I suspected it's a libgomp (!) issue in the + end. I have not yet continued working on that. + <pinotree> libogmp? looks like you know more than me, then :) + <youpi> tschwinge: oh, I'm interested + <youpi> I know a bit about libgomp :) + <tschwinge> I bisected this down to where Imagemagick added -fgomp (or + whatever it is). And then the perl library (Imagemagick.pm?) which loads + the imagemagick.so segfaulted. + <tschwinge> ImageMagick did this change in the middle of a x.x.x.something + release.. + <tschwinge> My next step would have been to test whether libgomp works at + all for us. + <youpi> ./usr/sbin/debootstrap:DEBOOTSTRAP_CHECKSUM_FIELD="SHA$SHA_SIZE" + <youpi> erf + <youpi> so they switched to another checksum + <youpi> but we don't have that one on all of our packages :) + <youpi> tschwinge: + <youpi> buildd@bach:~$ OMP_NUM_THREADS=2 ./test + <youpi> I'm 0x1 + <youpi> I'm 0x3 + <youpi> libgomp works at least a bit + <tschwinge> OK. + <pinotree> i guess we should hope the working bits don't stop at that point + ;) + <tschwinge> If open_issues/perlmagick is to be believed a diff of 6.4.1-1 + and 6.4.1-2 should tell what exactly was changed. + <tschwinge> Oh! + <tschwinge> I even have it on the page already! ;-) + <tschwinge> -fopenmp + <youpi> I've tried the pragmas that imagemagick uses + <youpi> they work + <tschwinge> Might be the issue fixed itself? + <youpi> I don't know, it's the latest libc here + <youpi> (and latest hurd, to be uploaded) + + +# Other + +[[!debbug 551017]] + +Code in Svn: `+ 1` missing to account for both `/` and `\0`. diff --git a/open_issues/pfinet.mdwn b/open_issues/pfinet.mdwn new file mode 100644 index 00000000..7aadd736 --- /dev/null +++ b/open_issues/pfinet.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +In certain situations, pfinet spawns more and more threads, +apparently without any bounds. + +The thread creation happens in bursts rather than continuously. +According to a backtrace in GDB, +all the threads are functional and waiting for client requests. +(The bursts are getting smaller as the number of threads rises, +but probably only because the enormous number of existing threads +slows down processing in general.) + +This can be triggered quite reliably by X clients running on the Hurd system, +connected to an X server on another machine over TCP, +and transferring fairly large amounts of data. +The easiest way to reproduce it I found is launching freeciv-gtk2, +pressing the "new game" button, and then simply waiting for a while. diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn new file mode 100644 index 00000000..46705047 --- /dev/null +++ b/open_issues/pfinet_vs_system_time_changes.mdwn @@ -0,0 +1,82 @@ +[[!meta copyright="Copyright © 2010, 2011, 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_hurd]] + +IRC, unknown channel, unknown date. + + <grey_gandalf> I did a sudo date... + <grey_gandalf> and the machine hangs + +This was very likely a misdiagnosis: + +IRC, freenode, #hurd, 2011-03-25: + + <tschwinge> antrik: I suspect it'S some timing stuff in pfinet that perhaps + uses absolute time, and somehow wildely gets confused? + <antrik> tschwinge: BTW, pfinet doesn't actually die I think -- it just + drops open connections... + <antrik> perhaps it thinks they timed out + <tschwinge> antrik: Isn't the translator restarted instead? + <antrik> don't think so + <antrik> when pfinet actually dies, I also loose the NFS mounts, which + doesn't happen in this case + <antrik> hehe "... and the machine hangs" + <antrik> he didn't bother to check that the machine is perfectly fine, only + the SSH connection got dropped + <tschwinge> Ah, I see. So it'S perhaps indeed simply closes TCP + connections that have been without data for ``too long''? + <antrik> yeah, that's my guess + <antrik> my clock is speeding, so ntpdate sets it in the past + <antrik> perhaps there is some math that concludes the connection have been + inactive for -200 seconds, which (unsigned) is more than any timeout :-) + <tschwinge> (The other way round, you might likely get some integer + wrap-around, and thus the same result.) + <tschwinge> Yes. + +IRC, freenode, #hurd, 2011-10-26: + + <antrik> anyways, when ntpdate adjusts to the past, the connections hang, + roughly for the amount of time being adjusted + <antrik> they do not die though + <antrik> (well, if it's long enough, they probably timeout on the other + side...) + +IRC, freenode, #hurd, 2011-10-27: + + <antrik> oh, another interesting thing I observed is that the the subhurd + pfinet did *not* drop the connection... only the main Hurd one. I thought + the clock is system-wide?... + <tschwinge> It is. + <antrik> it's really fascinating that only the pfinet on the Hurd instance + where I set the date is affected, and not the pfinet in the other + instance + +IRC, freenode, #hurd, 2012-06-28: + + <bddebian> great, now setting the date/time fucked my machine + <pinotree> yes, we lack a monotonic clock + <pinotree> there are select() loops that use gettimeofday to determine how + much time to wait + <pinotree> thus if the time changes (eg goes back), the calculation goes + crazy + <antrik> pinotree: didn't you implement a monotonic clock?... + <pinotree> started to + <antrik> bddebian: did it really fuck the machine? normally it only resets + TCP connections... + <pinotree> yeah, i remember such gettimeofay-based select-loops at least in + pfinet + <antrik> I don't think it's a loop. it just drops the connections, + believing they have timed out + <bddebian> antrik: Well in this case I don't know because I am at work but + it fucked me because I now cannot get to it.. :) + <antrik> bddebian: that's odd... you should be able to just log in again + IIRC diff --git a/open_issues/pflocal_reauth.mdwn b/open_issues/pflocal_reauth.mdwn new file mode 100644 index 00000000..839e383d --- /dev/null +++ b/open_issues/pflocal_reauth.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2011 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 open_issue_hurd]] + +IRC, freenode, #hurd, 2011-04-02 + + <pinotree> youpi: i'm playing with pflocal, and noticing that a simple C + executable doesn't trigger reauthenticate + <pinotree> youpi: i've put a debug output (to file) in S_io_reauthenticate, + and with a simple C test (which uses unix sockets) it isn't called + <youpi> pinotree: it seems pflocal should return FS_RETRY_REAUTH in + retry_type + <youpi> to make glibc call reauthentication + <pinotree> pflocal? + <youpi> yes, in the dir_lookup handler + <pinotree> isn't that ext2fs? + <youpi> libtrivfs had dir_lookup() too + <youpi> trivfs_check_open_hook can be used to tweak its behavior + <pinotree> ah, missed that pflocal was using libtrivfs, sorry + <youpi> there are probably very few translators which don't use one of the + lib*fs :) + <antrik> pinotree: what are you trying to do with pflocal? + <pinotree> local socket scredentials (SCM_CREDS) + <antrik> ah + <antrik> don't really know what that is, but I remember reading some + mention of it ;-) + +--- + +See also [[pflocal_socket_credentials_for_local_sockets]] and +[[sendmsg_scm_creds]]. diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn new file mode 100644 index 00000000..dfdc213c --- /dev/null +++ b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <pinotree> basically, i'm trying to implement socket credentials for local + sockets, and i guessed doing it in pflocal would be the appropriate place + <pinotree> what i thought was filling the cmsg data for MSG_CRED at + S_socket_recv() call + <pinotree> in case i missed it, would there be a way to "identify" the + other side of the port associated to the sock_user of that call? + <pochu> pinotree: that's needed by dbus right? cool! (and I don't know) + <pinotree> (yes, and gamin) + <youpi> pinotree: you have them already, they're just not stored + <youpi> see S_io_reauthenticate + <youpi> Throw away the ids we went through all that trouble to get... + <youpi> (comment) + * pinotree looks + <pinotree> hm, and who calls that rpc? + <youpi> everybody + <youpi> since that's how ext2fs knows the permission to apply, for instance + <pinotree> ah, i was referring to the reauthenticate of pflocal, not + auth_server_authenticate() + <youpi> that's what I'm saying + <youpi> see __hurd_file_name_lookup_retry, which is the very internal part + of open() + <youpi> it calls io_reauthenticate() + <youpi> to authenticate itself to the underlying translator of the opened + node + <pinotree> youpi: so, hm, could be an option make the result of pflocal's + S_io_reauthenticate cached in the sock_user struct? + <youpi> yes + <pinotree> nice thanks, i will try that change first + +--- + +See also [[pflocal_reauth]] and [[sendmsg_scm_creds]]. diff --git a/open_issues/pflocal_x_slowness.mdwn b/open_issues/pflocal_x_slowness.mdwn new file mode 100644 index 00000000..9bc18128 --- /dev/null +++ b/open_issues/pflocal_x_slowness.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, #hurd, 2010-08-10 + + <antrik> m1k11e: I think the X slowness is a problem in pflocal, i.e. the translator handling UNIX domain sockets + <antrik> (X clients communicate with a local X server using domain sockets) diff --git a/open_issues/phython.mdwn b/open_issues/phython.mdwn new file mode 100644 index 00000000..62f70be0 --- /dev/null +++ b/open_issues/phython.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +Go through James Morrison's (phython) pages, <http://hurd.dyndns.org/>, (via +Intrernet Archive Wayback Machine), and archive / hunt down what's still +interesting. diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn new file mode 100644 index 00000000..39478f20 --- /dev/null +++ b/open_issues/placement_of_virtual_memory_regions.mdwn @@ -0,0 +1,103 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +# IRC, freenode, #hurd, 2011-07-13 + + <braunr> does anyone know if posix (or mach) has requirements or a policy + about the placement of allocations of virtual space ? + <braunr> a policy such as bottom-up ? + <braunr> or "find lowest vailable space" ? + <jkoenig> braunr, you mean for vm_allocate ? You may want to check mmap() + but I can't remember ever coming across such a thing (except maybe + wrt. alignment) + <braunr> i was wondering how e.g. libraries are linked near the stack + (possibly at slightly random addresses) + <braunr> does the linker walk the address space entries top-down ? + <braunr> jkoenig: i didn't see anything either in the mach interface, but i + may have missed something + <braunr> jkoenig: most systems i've been studying mark the vm regions for + the heap and the stack + <braunr> but for mach, the stack is just allocated virtual memory at the + top of the space + <braunr> so the "placement policy" is either completely outside the kernel, + or relies on its interface + <jkoenig> braunr, actually I'm surprised Mach would even dictate where the + (one?) stack should be, I would have expected it to be the job of + whatever creates a thread to make this kind of choice + <braunr> jkoenig: threads have their own stacks, under the responsibility + of the user trhead implementation + <braunr> but a program usually needs a stack even before it runs + <braunr> i had to set one to bootstrap modules in v0.1 + <braunr> but i wonder if it's just for bootstrapping (and then propagated + by fork()) or part of the interface + <braunr> but this doesn't matter much actually, the allocation mechanism i + have in mind can actually support multiple policies + <jkoenig> I would guess the former (just for bootstrapping), since a new + task has no thread, and a new thread has no state. (but I'm no expert) + <braunr> i think so + <braunr> i'll have a look at the exec server + <braunr> jkoenig: did the previous implementation of procfs show task maps + ? + <jkoenig> braunr, I don't think so, I would probably have felt compelled to + include them in the new one if it did :-) + <braunr> hmmm + <braunr> we definitely need that + <jkoenig> is there a compelling use case you think about in particular? + <braunr> yes + <braunr> i failed to understand how gnumach behaved wrt ipc right spaces + +[[rework_gnumach_ipc_spaces]] + + <braunr> and when i did, i found out my work was impossible to integrate + <jkoenig> "ipc right spaces" ? + <braunr> each task have an ipc space, which contains righs + <braunr> rights + <braunr> the ipc translation layer converts space/name and space/port + tuples to rights + <braunr> i wanted to replace the splay tree with a radix tree but didn't + get how the ipc table made the splay tree almost unused + <braunr> i don't want to make this kind of mistake again, so i'd like a + clear and detailed view of the vm spaces + <braunr> (it's only compelling for myself, all right) + <braunr> but + <braunr> we have vminfo + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1046 + <braunr> oh my + <braunr> in comparison, a firefox instance has less than 500 on linux + <jkoenig> you mean there's some kind of port name table (or functional + equivalent) which actually resides in the task's memory? (and that's what + shows up at the beginning of the address space with prot=0?) + <braunr> jkoenig: sorry for being confusing, it's not that at all + <jkoenig> (btw feel free to tell me to just go read the source or whatever) + <braunr> jkoenig: don't worry + <jkoenig> braunr, no problem + <braunr> jkoenig: i just compared a previous attempt to improve gnumach + which failed because i didn't have enough insight of the inner workings + of the kernel + <braunr> jkoenig: i really want to miss as little as possible on the vm + part, so having detailed information about what actually happens on + running hurd systems is something i need + + +# IRC, freenode, #hurd, 2011-07-24 + + <braunr> oh btw, i noticed there are many mappings below the program text + <braunr> most notably, the stack + <braunr> except for special applications like wine, could this break + anything ? + <braunr> i also wonder how libraries are mapped, because there is nothing + to perform top-down allocations + <braunr> which means if the region below the program text is exhausted, + libraries could be mapped right after the heap + <youpi> it shouldn't break anything except things like wine & libgc, yes + <braunr> which could make malloc() fail :/ diff --git a/open_issues/populate_hurd_git_with_submodules_etc.mdwn b/open_issues/populate_hurd_git_with_submodules_etc.mdwn new file mode 100644 index 00000000..c89b95e9 --- /dev/null +++ b/open_issues/populate_hurd_git_with_submodules_etc.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="populate hurd.git with submodules, etc."]] + +Populate the top-level *[Savannah]/hurd.git* with a bunch of submodules +(various translators; everything that's intersting), have it serve as sort of a +tested distribution (because the submodules are versioned), plus adding build +machinery / cross-compilation support, etc. diff --git a/open_issues/posix_fadv_volatile.mdwn b/open_issues/posix_fadv_volatile.mdwn new file mode 100644 index 00000000..6bd25e3e --- /dev/null +++ b/open_issues/posix_fadv_volatile.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="POSIX_FADV_VOLATILE"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +May be interesting to watch what happens: LWN, Jonathan Corbet, +[`POSIX_FADV_VOLATILE`](http://lwn.net/Articles/468896/), 2011-11-22. diff --git a/open_issues/prelink.mdwn b/open_issues/prelink.mdwn new file mode 100644 index 00000000..ad85b9e2 --- /dev/null +++ b/open_issues/prelink.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2011 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_porting]] + +The *prelink* package, as distributed via Debian unstable, does build on +GNU/Hurd. After installing the satisfiable dependencies, use +`dpkg-buildpackage -b -uc -d` to ignore SELinux and libc6-dev dependencies. + +It is unclear whether it also does work. The testsuite (run manually) does +*FAIL* on all tests, which is due to the prelinker doing something to the +copied `ld.so.1` so that it faults on every invocation. This does not happen +on GNU/Linux. + +Not much in the prelinker is Linux-specific. `src/get.c`'s `is_ldso_soname` +should already cover our `ld.so.1` case (and what about `ld.so`?). At the end +of `src/arch-i386.c`, `.dynamic_linker` has to be set properly. And, in that +file there are some Linux process VM constants, of which `REG2S` and `REG2E` +are the only relevant in the `!exec_shield` case. Probably these need to be +adjusted. What else? diff --git a/open_issues/proc_server_proc_exception_raise.mdwn b/open_issues/proc_server_proc_exception_raise.mdwn new file mode 100644 index 00000000..1d0e92a3 --- /dev/null +++ b/open_issues/proc_server_proc_exception_raise.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +IRC, freenode, #hurd, 2011-08-11 + + < youpi> in which error cases a reply port will actually have been consumed + by mach_msg ? + < youpi> it seems at least MACH_SEND_NOTIFY_IN_PROGRESS do? + < braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send + < braunr> "These return codes imply that the message was returned to the + caller with a pseudo-receive operation: " + < braunr> isn't it what you're looking for ? + < youpi> well, it's hard to tell from the name + < youpi> I don't know what "pseudo-receiv operation" means + < braunr> it's described below + < youpi> ew + < braunr> it looks close enough to a normal receive to assume it consumes + the reply port + < youpi> so it's even more complex than what I thought + < youpi> well, no, it returns the right + < youpi> actually the error I'm getting is MACH_RCV_INVALID_NAME + < youpi> which I guess means the sending part succeeded + < youpi> the case at stake is proc/mgt.c: S_proc_exception_raise() + < youpi> when the proc_exception_raise() forward fails + < youpi> currently we always return 0, but if proc_exception_raise() + actually managed to send the message, the reply port was consumed and + MIG_NO_REPLY should be returned instead diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn new file mode 100644 index 00000000..7e3c7350 --- /dev/null +++ b/open_issues/profiling.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +*Profiling* ([[!wikipedia Profiling_(computer_programming) desc="Wikipedia +article"]]) is a tool for tracing where CPU time is spent. This is usually +done for [[performance analysis|performance]] reasons. + + * [[gprof]] + + Should be working, but some issues have been reported, regarding GCC spec + files. Should be possible to fix (if not yet done) easily. + + * [[community/gsoc/project_ideas/dtrace]] + + Have a look at this, integrate it into the main trees. + + * [[LTTng]] + + * [[SystemTap]] + + * ... or some other Linux thing. diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn index bf9c70d7..12bf5098 100644 --- a/open_issues/pth.mdwn +++ b/open_issues/pth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 @@ -10,8 +11,18 @@ is included in the section entitled [[!tag open_issue_porting]] +IRC, unknown channel, unknown date. + <azeem> seems pth still doesn't work <bddebian> Doesn't build or doesn't work? <azeem> both <azeem> some configure test keep grinding the CPU, same for the test suite <azeem> which apparently runs pth_init() and never returns + + <azeem> actually, pth fails to build right now + <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union + + <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed + <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard... + + <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus) diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn new file mode 100644 index 00000000..ac724cf0 --- /dev/null +++ b/open_issues/pthread_atfork.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2011 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_libpthread]] + +pthread_atfork is not actually implemented, making some programs fail. Code can probably be borrowed from nptl/sysdeps/unix/sysv/linux/register-atfork.c diff --git a/open_issues/python.mdwn b/open_issues/python.mdwn new file mode 100644 index 00000000..403ff8aa --- /dev/null +++ b/open_issues/python.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!meta title="Foster Python programming"]] + +Resolve issues uncovered by Python's test suite, and enable Hurd-specific +features. + +There is a [[!FF_project 260]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + + +## Analysis + + * [[select_bogus_fd]] + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in Python. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index 57c6bdbf..8f752d61 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_gnumach open_issue_hurd open_issue_viengoos]] @@ -19,3 +20,67 @@ discardable, for example. These issues are what Neal Walfield is working on with his new kernel [[microkernel/viengoos]]. + + +# Kernel + +Inside the [[kernel]], there is commonly a need to allocate resources according +to externally induced demand, dynamically. For example, for memory-management +data structures (page tables), process table entries, thread control blocks, +[[capability]] tables, incoming network packages, blocks that are read in from +disk, the keyboard type-ahead buffer for a in-kernel keyboard driver. Some of +these are due to actions driven by user-space requests, others are due to +actions internal to the the kernel itself. Some of these buffers can be sized +statically (keyboard type-ahead buffer), and are thus unproblematic. Others +are not, and should thus be attributed to their user space entities. In the +latter (ideal) case, all resources -- that is, including those needed inside +the kernel -- that a user space task needs for execution are provided by itself +(and, in turn, provided by its parent / principal), and the kernel itself does +not need to allocate any resources dynamically out of an its own memory pool. +This avoids issues like [[microkernel/Mach]]'s [[zalloc_panics]] upon user +space processes allocating too many [[microkernel/mach/port]]s, for example. + +[[!toggleable id=fof_plos09 text="""[[!template id=note +text="*[[fof\_plos09|microkernel/barrelfish]]*: +{{$microkernel/barrelfish#fof_plos09}}"]]"""]] + +[[!toggleable id=sel4 text="""[[!template id=note +text="[[*sel4*|microkernel/l4]]: {{$microkernel/l4#sel4}}"]]"""]] + +In [[!toggle id=fof_plos09 text="[fof\_plos09]"]], the authors describe in +section 3 how they model their [[capability]] system according to [[!toggle +id=sel4 text="[sel4]"]] using a *retype* operation that *takes an existing +capability and produces one or more derived capabilities [...] used to create +new kernel-level memory objects (such as page tables or execution contexts) +from capabilities to raw regions of RAM*. + +This is, of course, non-trivial to implement, and also requires changing the +[[RPC]] interfaces, for example, but it is a valid approach, a research topic. + +([[!taglink open_issue_documentation]]: compare this to Linux [`vmsplice`'s +SPLICE_F_GIFT +flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).) + +IRC, freenode, #hurd, 2011-07-31 + + < braunr> one of the biggest problems on the hurd is that, when a client + makes a call, kernel (and other) resources are allocated on behalf of the + server performaing the requested action + < braunr> performing* + < braunr> this makes implementing scheduling and limits difficult + < CTKArcher> And could changing the kernel change anything to that ? + < braunr> yes but you'd probably need to change its interface as well + < braunr> iirc, the critique describes resource containers + < braunr> but no work has been done on the current hurd (hence the hurdng + attempts) + + +# Further Examples + + * [[hurd/critique]] + + * [[IO_accounting]] + + * [[translators_set_up_by_untrusted_users]], and [[pagers]] + + * [[configure max command line length]] diff --git a/open_issues/grub2.mdwn b/open_issues/resource_management_problems/configure_max_command_line_length.mdwn index 235950a4..6c0a0d99 100644 --- a/open_issues/grub2.mdwn +++ b/open_issues/resource_management_problems/configure_max_command_line_length.mdwn @@ -5,17 +5,13 @@ 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]]."]]"""]] - -[[!meta title="GRUB2"]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] -Just like [[GRUB (legacy)|grub_legacy]], GRUB2 needs to be ported for being -installable when attempted to be installed *from* GNU/Hurd systems: - - $ sudo grub-probe --target=device /boot/grub - grub-probe: error: cannot find a device for /boot/grub. - -Etc. + <terpstra> do the buildds also crash? + <youpi> sometimes + <youpi> usually when a configure scripts tries to find out how large a + command line can be + <youpi> (thus eating all memory) diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn new file mode 100644 index 00000000..113b965a --- /dev/null +++ b/open_issues/resource_management_problems/io_accounting.mdwn @@ -0,0 +1,49 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-07-22 + + <braunr> an interesting question i've had in mind for a few weeks now is + I/O accounting + <braunr> what *is* I/O on a microkernel based system ? + <braunr> can any cross address space transfer be classified as I/O ? + +IRC, freenode, #hurd, 2011-07-29 + + < braunr> how does the hurd account I/O ? + < youpi> I don't think it does + < youpi> not an easy task, actually + < youpi> since gnumach has no idea about it + < braunr> yes + < braunr> another centralization issue + < braunr> does network access count as I/O on linux ? + < youpi> no + < braunr> not even nfs ? + < youpi> else you'd get 100% for servers :) + < braunr> right + < youpi> nfs goes through vfs first + < braunr> i'll rephrase my question + < youpi> I'd need to check but I believe it can check nfs + < braunr> does I/O accounting occur at the vfs level or block layer ? + < youpi> I don't know, but I beleive vfs + < youpi> (at least that's how I'd do it) + < braunr> i don't have any more nfs box to test that :/ + < braunr> personally i'd do it at the block layer :) + < youpi> well, both + < youpi> so e2fsck can show up too + < braunr> yes + < youpi> it's just a matter of ref counting + < youpi> apparently nfs doesn't account + < youpi> find . -printf "" doesn't show up in waitio + < braunr> good + < youpi> well, depends on the point of view + < youpi> as a user, you'd like to know whether your processes are stuck on + i/o (be it disk or net) + < braunr> this implies clearly defining what io is diff --git a/open_issues/resource_management_problems/pagers.mdwn b/open_issues/resource_management_problems/pagers.mdwn new file mode 100644 index 00000000..4c36703c --- /dev/null +++ b/open_issues/resource_management_problems/pagers.mdwn @@ -0,0 +1,322 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-09-14 + +Coming from [[translators_set_up_by_untrusted_users]], 2011-09-14 discussion: + + <slpz> antrik: I think a tunable option for preventing non-root users from + creating pagers and attaching translators could also be desirable + <antrik> slpz: why would you want to prevent creating pagers and attaching + translators? + <tschwinge> Preventing resource exhaustion, I guess. + <slpz> antrik: security and (as tschwinge says) for prevent a rouge pager + from exhausting the system. + <slpz> antrik: without the ability to use translators for non-root users, + Hurd can provide (almost) the same level of resource protection than + other *nixes + +See also: [[translators_set_up_by_untrusted_users]], +[[hurd/translator/tmpfs/tmpfs_vs_defpager]]. + + <braunr> the hurd is about that though + <slpz> there should be also a limit on the number of outstanding requests + that a task can have, and some other easily traceable values + <braunr> port messages queues have limits + <antrik> slpz: anything can exhaust the system. there are much more basic + limits that are missing... and I don't see how translators or pagers are + special in that regard + <slpz> braunr: that's what I said tunable. If I don't share my computer + with untrusted users, I want full functionality. Otherwise, I can enable + that limitation + <slpz> braunr: but I think those limits are on reception + <braunr> that's a wrong solution + <slpz> antrik: because pagers are external memory objects, and those are + treated differently + <braunr> compared to what ? + <braunr> and yes, the limit is on the message queue, on reception + <braunr> why is that a problem ? + <slpz> antrik: forbidding the use of translator was for security, to avoid + the problem of traversing an untrusted FS + <slpz> braunr: compared to anonymous memory + <slpz> braunr: because if the limit is on reception, a task can easily do a + DoS against a server + <braunr> hm actually, the problems we have with swap handling is that + anonymous memory is handled in a very similar way as other objects + <slpz> braunr: I want to limit the number of outstanding (unprocessed + messages in queues) requests + <braunr> slpz: the solution isn't about forbidding the use of translators, + but changing common code (libc i guess) not to use them, they can still + run beside + <slpz> braunr: that's because, currently, the external page limit is not + enforced + <braunr> i'm also not sure about DoS attacks + <braunr> if i'm right, there is often one port for each managed object, + which usually exist per client + <slpz> braunr: yes, that could an option too (for translators, not for + pagers) + <braunr> i don't see how pagers wouldn't be translators on the hurd + <slpz> braunr: all pagers are translators, but not all translators are + pagers ;-) + <braunr> so if it works for translators, it also works for pagers + <slpz> braunr: it would fix the security issue, but not the resource + exhaustion problem, with only affects to pagers + <braunr> i just don't see a point in implementing resource limits before + even fixing other fundamental issues + <braunr> the only way to avoid resource exhaustion is resource limits + <antrik> slpz: just not following untrusted translators is much more useful + than forbidding them alltogether + <braunr> and the main problem of mach is resource accounting + <braunr> so first, fix that, using the critique as a starting point + +[[hurd/critique]]. + + <slpz> braunr: i'm not saying that this should be implemented right now, + i'm just pointing out this possibility + <braunr> i think we're all mostly aware of it + <slpz> braunr: resource accounting, as it's expressed in the critique, + would be wonderful, but it's just too complex IMHO + <braunr> it requires carefully designed changes to the interface yes + <slpz> to the interface, to the internals, to user space tasks... + <braunr> the internals wouldn't be impacted that much + <braunr> user space tasks would mostly include hurd servers + <braunr> if the changes are centralized in libraries, it should be easy to + provide to the servers + + +# IRC, freenode, #hurd, 2011-09-22 + + <slpz> antrik: I've also implemented a simple resource control on dirty + pages and changed pageout_scan to free external pages, and only touch + anonymous memory if it's really needed + <slpz> antrik: those combined make the system work better under heavy load + <slpz> antrik: 1.5 GB of RAM and another 1.5 GB of swap helps a lot, too + :-) + <antrik> hm... I'm not sure what these things mean exactly TBH... but I + wonder whether some of these could fix the performance degradation (and + ultimate crash) I described recently... + +[[/open_issues/default_pager]], [[system performance degradation +(?)|performance/degradation]]. + + <antrik> care to explain them to a noob like me? + <slpz> probably not. During my tests, I've noticed that, at some points, + the system performance starts to degrade, and this doesn't change until + it's restarted + <slpz> but I wasn't able to create a test case to reproduce the bug... + <slpz> antrik: Sure. First, I've changed GNU Mach to: + <slpz> - Classify all pages from data_supply as external, and count them + in vm_page_external_count (previously, this variable was always zero) + +[[/open_issues/mach_vm_pageout]] + + <slpz> - Count all pages for which a data_unlock has been requested as + potentially dirty pages + <antrik> there is one important bit I forgot to mention in my recent + report: one "reliable" way to cause growing swap usage is simply + installing a lot of debian packages (e.g. running an apt-get upgrade) + <antrik> some other kinds of I/O also seem to have such an effect, but I + wasn't able to pinpoint specific situations + <slpz> - Establish a limit on how many potentially dirty pages are + allowed. If it's reached, a notification (right now it's just a bogus + m_o_data_unlock, to avoid implementing a new RPC) it's sent to the pager + which has generated the page fault + <slpz> - Establish a hard limit on those dirt pages. If it's reached, + threads asking for a data_unlock are blocked until someone cleans some + pages. This should be improved with a forced pageout, if needed. + <slpz> - And finally, in vm_pageout_scan, run over the inactive queue + searching for clean, external pages, freeing them. If it's not possible + to free enough pages, or if vm_page_external_count is less than 10% of + system's memory, the "normal" pageout is used. + <slpz> I need to clean up things a little, but I want to send a preliminary + patch to bug-hurd ASAP, to have more people testing it. + <slpz> antrik: Do you thing that performance degradation can be related + with the number of threads of your ext2fs translators? + <antrik> slpz: hm... I didn't watch that recently; but in the past, I + observe that the thread count is pretty constant after it reaches + something like 14000 on heavy load... + <antrik> err... wait, 14000 was ports :-) + <antrik> I doubt my system would survive 14000 threads ;-) + <antrik> don't remember thread count... I guess I should start watching + this again + <slpz> antrik: I was thinking that 14000 threads sound like a lot :-) + <slpz> what I know for sure, is that when operating with large files, the + deactivation of all pages of the memory object which is done after every + operation really hurts to performance + <antrik> right now my root FS has 5100 ports and a mere 71 thread... but + then, it's almost freshly booted :-) + <slpz> that's why I've just commented that operation in my code, since it's + not really needed anymore :-) + <slpz> anyway, after submitting all my pending mails to bug-hurd, I'll try + to hunt that bug. Sounds funny. + <antrik> regarding your explanation, I'm still trying to wrap my head + around some of the details. I must admit that I don't remember what + data_unlock does... or maybe I never fully understood it + <antrik> the limit on dirty pages is global? + <slpz> yes, right now it's global + <marcusb> I try to find the old discussion of the thread storm stuff + <marcusb> there was some concern about deadlocks + <slpz> marcusb: yes, because we were talking about putting an static limit + for the server threads of a translators + <slpz> marcusb: and that was wrong (my fault, I was even dumber back then + :-P) + <marcusb> oh boy digging in old mail is no fun. first I see mistakes in my + english. then I see quite complicated pager stuff I don't ever remember + touching. but there is a patch, and it has my name on it + <marcusb> I think I lost a couple of the early years of my hurd hacking :) + <antrik> hm... I reread the chapter on locking, and it's still above me :-( + <marcusb> not sure what you are talking about, but if there are any + specific questions... + <antrik> marcusb: external pager interface + +[[microkernel/mach/external_pager_mechanism]]. + + <marcusb> uuuuh ;) + <antrik> memory_object_lock_request(), memory_object_lock_completed(), + memory_object_data_unlock() + <marcusb> is that from the mach manual? + <antrik> yes + <antrik> I didn't really understand that part when I first read it a couple + of years ago, and I still don't understand it now :-( + <marcusb> I am sure I didn't understand it either + <marcusb> and maybe I missed my window :) + <marcusb> let's see + <antrik> hehe + <antrik> slpz: what exactly do you mean by "the pager which has generated + the page fault"? + <antrik> marcusb: essentially I'm trying to understand the explanation of + the changes slpz did, but there are several bits totally obscure to me + :-( + <slpz> antrik: when a I/O operation is requested to ext2fs, it maps the + object in question to it's own space, and then memcpy's from/to there + <slpz> antrik: so the translator (which is also a pager) is the one who + generates the page fault + <marcusb> yeah + <marcusb> antrik: it's important to understand which messages are sent by + the kernel to the manager and which are sent the other way + <marcusb> if the dest port is memory_object_t, that indicates a msg from + kernel to manager. if it is memory_object_control_t, it's a msg from + manager to kernel + <slpz> antrik: m_o_lock_request it's used by the pager to "settle" the + status of a memory object, m_o_lock_completed is the answer from the + kernel when the lock has been completed (only if the client has requested + to be notified), and m_o_data_unlock is a request from the kernel to + change the level of protection for a page (it's called from vm_fault.c) + <marcusb> slpz: but it's not pagers generating page faults, but users of + the memory object on the other side + <antrik> marcusb: well, I think the direction is clear to me... but the + purpose not really :-) + <marcusb> ie a client that mapped a file + <slpz> antrik: in ext2fs, all pages are initially provided to the kernel + (via data_supply) write protected. When a write operation is done over + one of those pages, a page fault it's generated, which sends a + m_o_data_unlock to the pager, which answers (if convenient) which a + page_lock decreasing the protection level + <marcusb> antrik: one use of lock_request is when you want to shut down + cleanly and want to get the dirty pages written back to you from the + kernel. + <marcusb> antrik: the other thing may be COW strategies + <slpz> marcusb: well, pagers and clients are in the same task for most + translators, like ext2fs + <marcusb> slpz: oh. + <slpz> marcusb: but yes, a read operation in a mmap'ed file would trigger + the fault in a client user task + <marcusb> slpz: I think I forgot everything about pagers :) + <slpz> marcusb: pager-memcpy.c is the key :-) + <marcusb> slpz: what becomes of the fault then? the kernel sees it's a + mapped memory object. will it then talk to the manager or to a pager? + <antrik> slpz: the translator causes the faults itself when it handles + io_read()/io_write() requests I suppose, as opposed to clients accessing + mmap()ed objects which then generate the faults?... + <antrik> ah, that's actually what you already said above :-) + <slpz> marcusb: I'm not sure what do you mean by "manager"... + <marcusb> manager == memory object + <marcusb> mh + <slpz> marcusb: for all external objects, it will ask to their current + pager + <marcusb> slpz: I think I am missing a couple of details, so nevermind. + It's starting to come back to me, but I am a bit afraid of that ;) + <marcusb> what I love about the Hurd is how damn readable the code is + <marcusb> considering it's an object system, it's so much nicer to read + than gtk stuff + <slpz> when you get the big picture, it's actually somewhat fun to see how + data moves around just to fulfill a simple read() + <marcusb> you should make a diagram! + <marcusb> bonus point for animated video ;) + +[[hurd/IO_path]]. + + <slpz> marcusb: heh, take a look at the hurd specific parts of glibc... I + cry in pain every time a do that... + <marcusb> slpz: oh yeah, rdwr-internal. + <marcusb> oh man + <marcusb> slpz: funny thing, I just looked at them the other day because of + the security issue + <slpz> marcusb: I think there was one, maybe a slice from someone's + presentation... + <marcusb> I think I was always confused about the pager/memobj/kernel + interactions + <slpz> marcusb: I'm barely able to read Roland's glibc code. I think it's + out of my reach. + <antrik> marcusb: I think part of the problem is confusing terminology + <marcusb> it's good that you are instrumenting the mach kernel to see + what's actually going on in there. it was a black book for me, but neal + too a peek and got a much better understanding of the performance issues + than I ever did + <antrik> when talking about "pager", we usually mean the process doing the + paging; but in mach terminology this actually seems to be the "manager", + while a "pager" is an individual object in the manager process... or + something like that ;-) + <marcusb> antrik: I just never took a look at the big picture. I look at + the parts + <marcusb> I knew the tail, ears, and legs of the elephant. + <marcusb> it's a lot of code for a beginner + <antrik> I never understood the distinction between "pager" and "memory + object" though... + <antrik> maybe "pager" refers to the object in the external pager, while + "memory object" is the part managed in Mach itself?... + <marcusb> memory object is a real object, to which you can send messages. + it's implemented in the server + <antrik> hm... maybe it's the other way around then ;-) + <marcusb> there is also the default pager + <marcusb> I think the pager is just another name for the process that + serves the memory object (default pager == memory object for anonymous + memory == swap) + <marcusb> but! + <marcusb> there is also libpager + +[[hurd/libpager]] + + <marcusb> and that's a more complicated beast + <antrik> actually, the correct term seems to be "default memory manager"... + <marcusb> yeah + <marcusb> from mach's pov + <marcusb> we always called it default pager in the Hurd + <antrik> marcusb: problem is that "pager" is sometimes used in the Mach + documentation to refer to memory object ports IIRC + <marcusb> isn't it defpager executable? + <marcusb> could be + <marcusb> it's the same thing, really + <antrik> indeed, the program implementing the default memory manager is + called "default pager"... so the terminology is really inconsistent + <marcusb> the hurd's pager library is a high level abstraction for mach's + external memory object interface. + <marcusb> i wouldn't worry about it too much + <antrik> I never looked at libpager + <marcusb> you should! + <marcusb> it's an important beast + <antrik> never seemed relevant to anything I did so far... + <antrik> though maybe it would help understanding + <marcusb> it's related to what you are looking now :) diff --git a/open_issues/resource_management_problems/zalloc_panics.mdwn b/open_issues/resource_management_problems/zalloc_panics.mdwn new file mode 100644 index 00000000..9c29b07c --- /dev/null +++ b/open_issues/resource_management_problems/zalloc_panics.mdwn @@ -0,0 +1,99 @@ +[[!meta copyright="Copyright © 2005, 2007, 2008, 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_gnumach open_issue_hurd]] + +Written by antrik / Olaf Buddenhagen, last updated: 12 Apr 2007. + +The Hurd sometimes crashes with a kernel panic saying someting like: "Panic: zalloc failed: zone map exhausted". + +These panics are generally caused by some kind of kernel resource exhaustion, but there are several differnt reasons for that. + +It used to happen very often under heavy disk load (like large compile jobs), or in a reproducible test case by opening a large number of ports to /dev/null and then closing them all very quickly. The reason for this particular problem has been identified a while back: The multithreaded Hurd servers create a new worker thread whenever a new request (RPC) comes in while all existing threads are busy. When the server is hammered with lots of requests -- which happens both under heavy disk load, and when quickly closing many ports to one server -- it will create an absurd number of threads, causing the resource exhaustion. + +The Debian hurd package contains a patch by k0ro (Sergio Lopez), which fixes this by limiting the amount of created threads in a rather simplistic but very effective manner. This patch however hasn't been included in upstream CVS so far. A more elegant solution, suitable for upstream inclusion, would be desirable. + +Some panics still seem to happen in very specific situations, like the one described at <https://savannah.gnu.org/bugs/?19426> . These are probably the result of bugs that cause port leaks, accidental fork bombs, or similar problems. + +In principle, resource exhaustion can also happen by normal use, though this is rather unlikely in the absence of bugs or malicious programs. Nevertheless, all these problems could be avoided (or limited in effect) by introducing some limits on number of processes per user, number of threads and ports per process/user etc. + +Trying to track down causes for the panics, I got some interesting results. (UPDATE: Many of my original observations were clearly related to the server thread explosion problem. To avoid confusion, I now removed these, as this is no longer an open issue.) + +* It all started with someone (probably azeem) mentioning that builing some package always crashes Hurd at the same stage of the Debian packaging process (UPDATE: Almost all of these panics when building packages were a result of the thread explosion and don't happen anymore.) +* Someone (maybe he himself) pointed out that this stage is characterized by many processes being quickly created and destroyed +* Someone else (probably hde) started some experimenting, to get a reproducible test case +* He realized that just starting and killing five child processes in quick succession suffices to kill some Hurd systems +* I tried to confirm this, but it turned out my system is more robust + +As I could never reproduce the problem with a small number of quickly killed processes, I can't say whether this problem still exists. While I could reproduce such an effect with first opening and then very quickly closing many ports (which is more or less what happens when quickly killing many processes), I needed really large numbers of processes/ports for that. The thread throtteling patch fixed my test case; but it seems unlikely that killing only five processes could have caused a thread explosion, so maybe hde's observation was a different problem really... + +I started various other experiments with creating child processes (fork bombs), resulting in a number of interesting observations: + +* Just forking a large number of processes crashes the Hurd reliably (not surprising) +* The number of processes at which the panic occurs is very constant (typicallly +-2) under stable conditions, as long as forking doesn't happen too fast +* The exact number depends on various conditions: + * Run directly from the Mach console, it's around 1040 on my machine (given enough RAM); however, it drops to 940 when started through a raw ssh session, and to 990 when run under screen through ssh (TODO: check number of ports open per process depending on how it is started) UPDATE: In a later test, I got somewhat larger numbers (don't remember exactly, but well above 1000), but still very constant between successive runs. Not sure what effected this change. + * It doesn't depend on whether normal user or root + * With only 128 MiB of RAM, the numbers drop slightly (like 100 less or so); no further change between 256 and 384 MiB + * Lowering zone\_map\_size in mach/kern/zalloc.c reduces the numbers (quite exactly half from 8 MiB to 4 MiB) + * There seems to be some saturation near 16 MiB however: The difference between 8 MiB and 16 MiB is significantly smaller + * Also, with 8 MiB or 4 MiB, the difference between console/ssh/screen becomes much more apparent (500 vs. 800, 250 vs. 400) + * With more than 16 MiB, Mach doesn't even boot +* Creating the processes very fast results in a sooner and less predictable crash (TODO: Check whether this is still the case with thread throtteling?) +* Creating processes recursively (fork only one child which forks the next one etc.) results in faster crash +* rpcinfo shows that child processes have more ports open by default, which is very likely the reason for the above observation +* Opening many ports from a few processes doesn't usually cause a system crash; there are only lots of open() failures and translator faults once some limit is reached... Seems the zalloc-full condition is better caught on open() than on fork() (TODO: investigate this further, with different memory sizes, different zone\_map\_size, different kinds of resources using zalloc etc.) +* After opening/leaking lots of ports to /dev/null (32768 it seems), the NULL translator somehow becomes disfunctional, and a new instance is started + +While most of these Observations clearly show an exhaustion of kernel memory which is not surprising, some of the oddities seem to indicate problems that might deserve further investigation. + + +# IRC, freenode, #hurd, 2012-04-01 + + <mel__> antrik: i just found + http://www.gnu.org/software/hurd/open_issues/resource_management_problems/zalloc_panics.html + -- that is from 2007. is this still the current status? + <youpi> mel__: probably + <mcsim> mel__: gnumach has no more zalloc allocator, so I doubt if it could + be a problem. + +[[gnumach_memory_management]]. + + <youpi> mcsim: but it still has an allocator + <youpi> which can run out of resources + <mcsim> AFAIR, now there is no such limit. + <youpi> err, there is + <youpi> the size of your RAM :) + <mcsim> In zalloc appearing of this message didn't depend of available size + of free ram. + <youpi> then update the description, but I'm still getting allocation + errors, when userland makes crazy things like creating millions of tasks + <mcsim> At least it could appear when there still was free memory + <youpi> and that's not surprising + <youpi> sure, I know that *some* limits have been removed, but there + weren't so many, and I have seen cases where it's simply mach running out + of memory + <youpi> also, we have a limited amount of virtual addressing space + <antrik> mel__: this writeup is outdated in several regards. *some* of the + observations might still be relevant, but nothing that seems + particularily important + <antrik> the zalloc panics have pretty much disappeared after the default + zalloc zone size has been considerably extended (which was not possible + before because of some bug) + <mel__> i see + <antrik> but as mcsim pointed out, with the new allocator not relying on a + fixed-sized zalloc zone at all, they are even less likely, and should + happen only if all memory is exhausted + <antrik> I guess this outdated report can just be dropped + <mcsim> I think, that now it is problem rather of absence of OOM-killer or + resource manager + <antrik> mcsim: right :-) + <antrik> (and we have separate articles about that) diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn new file mode 100644 index 00000000..7c66776b --- /dev/null +++ b/open_issues/rework_gnumach_ipc_spaces.mdwn @@ -0,0 +1,723 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 + + <braunr> things that are referred to as "system calls" in glibc are + actually RPCs to the kernel or other tasks, those RPCs have too lookup + port rights + <braunr> the main services have tens of thousands of ports, looking up one + is slow + +There is a [[!FF_project 268]][[!tag bounty]] on this task. + + +# IRC, freenode, #hurd, 2011-04-23 + + <braunr> youpi: is there any use of the port renaming facility ? + <youpi> I don't know + <braunr> at least, did you see such use ? + <braunr> i wonder why mach mach_port_insert_right() lets the caller specify + the port name + <youpi> ../hurd-debian/hurd/serverboot/default_pager.c: kr = + mach_port_rename( default_pager_self, + <braunr> mach_port_rename() is used only once, in the default pager + <braunr> so it's not that important + <braunr> but mach_port_insert_right() lets userspace task decide the port + name value + <youpi> just to repeat myself again, I don't know port stuff very much :) + <braunr> well you know that a port denotes a right, which denotes a port + <youpi> yes, but I don't have any real experience with it + <braunr> err + <braunr> port name + <braunr> the only reason I see is that the caller, say /hurd/exec running a + fork() + <braunr> hm + <braunr> no, i don't even see the reason here + <braunr> port names should be allocated by the kernel only, like file + descriptors + <youpi> you can choose file descriptor values too + <braunr> really ? + <youpi> with dup2, yes + <braunr> oh + <braunr> hm + <braunr> what's the data structure in current unices to store file + descriptors ? + <braunr> a hash table ? + <youpi> I don't know + <braunr> i'll have to look at that + <braunr> FYI, i'm asking these questions because i'm thinking of reworking + ipc spaces + <braunr> i believe the use of splay trees completely destroys performance + of tasks with many many port names such as the root file system + <youpi> that can be a problem yes + <youpi> since there are 3 ports per opened file, and like 3 per thread too + <braunr> + the page cache + <youpi> with a few thousand opened files and threads, that makes a lot + <youpi> by "opened file" I meant page cache actually + <braunr> i saw numbers up to 30k + <braunr> ok + <youpi> on buildds I easily see 100k ports + <braunr> for a single task ? + <braunr> wow + <youpi> yes + <youpi> the page cache is 4k files + <braunr> so that's definitely worth the try + <youpi> so that already makes 12k ports + <youpi> and 4k is not so big + <braunr> it's limited to 4K ? + <youpi> I haven't been able to check where the 100k come from yet + <youpi> braunr: yas + <braunr> could be leaks :/ + <youpi> yes + <braunr> omg, a hard limit on the page cache .. + <youpi> vm/vm_object.c:int vm_object_cached_max = 4000; /* may + be patched*/ + <braunr> mach is really old :( + <youpi> I've raised it + <youpi> before it was 200 + <youpi> ... + <braunr> oO + <youpi> I tried to dro pthe limit, but then I was lacking memory + <youpi> which I believe have fixed the other day, but I have to test again + <braunr> that implementation doesn't know how to deal with memory pressure + <youpi> yes + <braunr> i saw your recent changes about adding warnings in such cases + <braunr> so, back to ipc spaces + <braunr> i think splay trees 1/ can get very unbalanced easily + <braunr> which isn't hard to imagine + <braunr> and 2/ make poor usage of the cpu caches because they're BST and + write a lot to memory + <youpi> maybe you could write a patch which would dump statistics on that? + <braunr> that's part of the job i'm assigning to myself + <youpi> ok + <braunr> i'd like to try replacing splay trees with radix trees + <youpi> I can run it on the buildds + <youpi> buildds are very good stress-tests :) + <braunr> :) + <youpi> 22h building -> 77k ports + <youpi> 26h building -> 97k ports + <youpi> the problem is that when I add leak debugging (backtraces), I'm + getting out of memory :) + <braunr> that will be a small summer of code outside the gsoc :p + <braunr> :/ + <braunr> backtraces are very consuming + <youpi> but that's only because of hardcoded limits + <youpi> I'll have to test again with bigger limits + <braunr> again .. + <braunr> evil hard limits + <youpi> well, actually we could as well just drop them + <youpi> but we'd also need to easily get statistics on zone/vm_maps usage + <youpi> because else we don't see leaks + <youpi> (except that the machine eventually crashes) + <braunr> hm + <braunr> i haven't explained why i was asking my questions actually + <braunr> so, i want radix trees, because they're nice + <braunr> they reduce the paths lengths + <braunr> they don't get too unbalanced (they're invariant wrt the order of + operations) + <braunr> they don't need to write to memory on lookups + <braunr> the only drawback is that they can create much overhead if their + usage pattern isn't appropriate + <braunr> elements in such a structure should be close, so that they share + common nodes + <youpi> the common usage pattern in ext2fs is a big bunch of ever-open + ports :) + <braunr> if there is one entry per node, it's a big waste + <braunr> yes + <youpi> there are 3, actually + <braunr> but the port names have low values + <braunr> they're allocated sequentially, beginning at 0 + <braunr> (or 1 actually) + <braunr> which is perfect for radix trees + <youpi> yes + <youpi> 97989: send + <braunr> but if anyone can rename + <braunr> this introduces a new potential weakness + <youpi> ah, if it's just a weakness it's probably not a problem + <youpi> I thought it was even a no-go + <braunr> i think so + <youpi> I guess port rename is very seldom + <braunr> but in a future version, it would be nice not to allow port + renaming + <braunr> unless there are similar issues in current unix kernels + <braunr> in which case i'd say it's acceptable + <youpi> there are + <braunr> of that order ? + <youpi> and it'd be useful for e.g. processing + tracing/debugging/tweaking/whatever + <youpi> it's also used to hide fds from a process + <braunr> port renaming you mean ? + <youpi> you allocate them very high + <youpi> yes + <braunr> ok + <youpi> choosing your port name, generally + <youpi> to match what the process expects for instance + <braunr> then it would be a matter of resource limiting (which we totally + lack afaik) + <braunr> along the number of maximum open files, you would have a number of + maximum rights + <braunr> does that seem fine to you ? + <youpi> if done throught rlimits, sure + <braunr> something similar yes + <youpi> (_no_ PORTS_MAX ;) ) + <braunr> oh and, in addition, i remember gnumach has a special + configuration of the processor in which caching is limited + <braunr> like write-through only + <youpi> didn't I fix that recently ? + <braunr> i don't know :) + <braunr> CR0=e001003b + <braunr> i don't think it's fixed + <youpi> I mean, in the git + <braunr> ah + <youpi> not in the debian package + <braunr> didn't tried the git version yet + <braunr> last time i tried (which was a long time ago), it made the kernel + crash + <braunr> have you figured why ? + <youpi> I'm not aware of that + <braunr> anyway, splay trees write a lot, and most trees write a lot even + at insertion/removal to rebalance + <youpi> braunr: Mmm, there's no clearance of CD in the kernel actually + <braunr> with radix trees, even if caching can't be fully enabled, it would + make much better use of it + <braunr> so if port renaming isn't a true issue, i'll choose that data + structure + <youpi> that'd probably be better yes + <youpi> I'm surprised by the CD, I do remember fixing something like this + lately + <braunr> there are several levels where CD can be set + <braunr> the processors ORs all those if i'm right + <braunr> to determine if caching is enabled + <youpi> I know + <braunr> ok + <youpi> but in my memory that was at the CR* level, precisely + <braunr> maybe for xen only ? + <youpi> no + <braunr> well good luck if you hunt that one, i'm off, see you :) + <youpi> braunr: ah, no, it was the PGE flag that I had fixed + + <antrik> braunr: explicit port naming is used for example to pass some + initial ports to a new task at well-known places IIRC + <antrik> braunr: but these tend to be low numbers, so I don't see a problem + there + <antrik> (I'm not familiar with radix trees... why would high numbers be a + problem?) + + <youpi> braunr: iirc the ipc space is limited to ~192k ports + + <braunr> antrik: in most cases i've seen, the insert_right() call is used + on task_self() + <braunr> and if there really are special ports (like the bootstrap or + device ports), they should have special names + <braunr> IIRC, these ports are given through command line expansion by the + kernel at boot time + <braunr> but it seems reasonable to think of port renaming as a potentially + useful feature + <braunr> antrik: the problem with radix trees isn't them being high, it's + them being sparse + <braunr> you get the most efficient trees when entries have keys that are + close to each other + <braunr> because radix trees are a type of tries (the path in the tree is + based on the elements composing the key) + <braunr> so the more common prefixes you have, the less external nodes you + need + <braunr> here, keys are port names, but they can be memory addresses or + offsets in memory objects (like in the page cache) + <braunr> the radix algorithm takes a few bits, say 4 or 6, at a time from a + key, and uses that as an index in a node + <braunr> if keys are sparse, there can be as little as one entry per node + <braunr> IIRC, the worst case (on entry per node with the maximum possible + number of nodes for a 32-bits key) is 2% entries + <braunr> the reste being null entries and almost-empty nodes containing + them + <braunr> so if you leave the ability to give port rights the names you + want, you can create such worst case trees + <braunr> which may consume several MiB of memory per tree + <braunr> tens of MiB i'd say + <braunr> on the other hand, in the current state, almost all hurd + applications use sequentially allocated port names, close to 0 (which + allows a nice optimization) + <braunr> so a radix ree would be the most efficient + <antrik> well, if some processes really feel they must use random numbers + for port names, they *ought* to be penalized ;-) + + +# IRC, freenode, #hurd, 2011-04-27 + + <braunr> antrik: remember when you asked why high numbers would be a + problem with radix trees ? + <braunr> here is a radix tree with one entry, which key is around 5000 + <braunr> [ 656.296412] tree height: 3 + <braunr> [ 656.296412] index: 0, level: 0, height: 3, count: 1, + bitmap: 0000000000000002 + <braunr> [ 656.296412] index: 1, level: 1, height: 2, count: 1, + bitmap: 0000000000004000 + <braunr> [ 656.296412] index: 14, level: 2, height: 1, count: 1, + bitmap: 0000000000000080 + <braunr> three levels, each with an external node (dynamically allocated), + for one entry + <braunr> so in the worst case of entries with keys close to the highest + values, the could be many external nodes with higher paths lengths than + when keys are close to 0 + <braunr> which also brings the problem of port name allocation + <braunr> can someone with access to a buildd which has an uptime of at + least a few days (and did at least one build) show me the output of + portinfo 3 | tail ? + <braunr> port names are allocated linearly IIRC, like PIDs, and some parts + of the kernel may rely on them not being reused often + <braunr> but for maximum effifiency, they should be + <braunr> efficiency* + <braunr> 00:00 < braunr> can someone with access to a buildd which has an + uptime of at least a few days (and did at least one build) show me the + output of portinfo 3 | tail ? + <braunr> :) + <youpi> it's almost like wc -l + <youpi> 4905: receive + <youpi> vs 4647 + <youpi> for / + <youpi> 52902: receive + <youpi> vs 52207 + <youpi> for the chroot + <braunr> even after several builds ? + <braunr> and several days ? + <youpi> that's after 2 days + <youpi> it's not so many builds + <youpi> rossini is not so old + <youpi> (7h) + <youpi> but many builds + <youpi> 70927: send + <youpi> vs 70938 + <braunr> ok + <braunr> so it seems port names are reused + <braunr> good + <youpi> yes they are clearly + <braunr> i think i remember a comment about why the same port name + shouldn't be reused too soon + <youpi> well, it could help catching programming errors + <braunr> that it helped catch bugs in applications that could + deallocate/reallote quickly + <braunr> reallocate* + <braunr> without carefuly synchronization + <braunr> careful + <braunr> damn, i'm tired :/ + <youpi> but that's about debugging + <youpi> so we don't care about performance there + <braunr> yes + <braunr> i'll try to improve allocation performance too + <braunr> using e.g. bitmaps in each external node back to the root so that + unused slots are quickly found + <braunr> i thknk that's what idr does in linux + <antrik> braunr: idr? + <braunr> antrik: a data structure used to map integers to pointers + <braunr> http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6 + + +# IRC, freenode, #hurd, 2011-06-08 + + <braunr> hm, reverse space/port to name lookups also suck + <braunr> having separate types for simple ipc entries and splay tree + entries really makes many parts of the ipc code complicated + <braunr> and a global hash table for these operations is scary + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> hm nice, my radix tree code runs inside gnumach, along with the + original splay tree code and assertions making sure results are the same + <braunr> there is this "collision" thing i'm not sure to understand but + once this is solved, replacing the splay trees should be easy + + <braunr> youpi: is there a way to easily know the number of send rights + associated to a port ? + <youpi> portinfo ? + <braunr> portinfo gives information in a space + <braunr> but this is specific to a port + <braunr> is there an option for that ? + <youpi> -v + <braunr> hm ok + <youpi> 25: send (refs: 550) + <braunr> nice + <braunr> youpi: if you have time, could you give me the min/max/avg numbers + of send rights referring to the same port on buildds ? + <braunr> i'm trying to estimate if it's better to have space->list_of_ports + or port->list_of_spaces to replace the global ipc hash table + <braunr> the latter seems better but there could be unexpected cases on + machines using large amounts of resources like the buildds + <youpi> max is 64k + <youpi> min is 1 of course :) + <braunr> 64k + <braunr> then it's not what i'm looking for + <youpi> avg is 55 + <braunr> isn't this the number of urefs ? + <youpi> I don't know + <braunr> hmm + <braunr> what i'm looking for is the number of *pure send rights* for the + same port + <braunr> i don't think portinfo can give it + <braunr> there can only be one such send right per task for the same port + <braunr> 64k would mean there are 64k tasks + <youpi> ok, so it's more difficult + <youpi> it means using -t + <braunr> ahh + <youpi> and run n^2 portinfo over the n processes + <braunr> i see + <youpi> Mmm, that will however still show any duplicate send right + <youpi> but then by min/max/avg, you mean, over time ? + <braunr> i'll change the source code, simpler + <youpi> e.g. min would be right after boot? + <braunr> min is 1 + <youpi> 1 what ? + <braunr> 1 send right to a port + <youpi> ah, 1 for a given port + <braunr> yes + <youpi> ok, it becomes really hairy to compute, I don't hav ethe time :) + <braunr> avg and max are more interesting :) + <braunr> no worries + <youpi> braunr: I wouldn't be surprised that max is the number of tasks + <youpi> e.g. for a send port to the proc server for instance + <braunr> youpi: it is, but i'm not looking for potential numbers + <youpi> I'm not talking about a potential number, but an actual number + that's almost always true + <braunr> for one port, yes + <braunr> but yes, ok for max + <braunr> this makes choosing an appropriate data structure difficult + + <antrik> braunr: actually, min number of send rights to a port is 0... but + I'm sure you know that already :-) + + <antrik> youpi: normally each client gets a separate port. I'm not sure + there are any ports with send rights distributed over many tasks... + + <jkoenig> antrik, what about / ? + + <youpi> antrik: not necessarily + + <antrik> jkoenig: not sure... isn't the "/" port authenticated to the + specific user? + + <jkoenig> antrik, I guess so, but a single user could still have many + tasks. + <jkoenig> (wrt /) + <antrik> jkoenig: well, in theory the tasks having exactly the same UIDs + and GITs could probably share an auth token... but that's not how things + are handled in general + <antrik> at least I don't think so + <antrik> tasks are authenticated, not users + <antrik> err... GIDs :-) + <jkoenig> antrik, still, my quick glance to the fork() code seemed to + indicate the port is inherited as-is, maybe authentication happens only + when something is actually looked up? + <jkoenig> hmm "rpctrace ls -d /" does not show any authentication calls, + only a lookup("") on the root which returns a different port + <jkoenig> so I guess the root port is "deauthenticated" or something when + the uid of a process is changed. + <antrik> too bad cfhammer isn't around, he digged into all this stuff... + <antrik> I know that there is a mechanism which reauths all FDs when the + IDs of a process change + <antrik> but I'm not sure the "/" port uses this mechanism + + <braunr> antrik: but the radix tree codee is really used as is, which means + no locking, no preloading before locking, all of this because simple + locks don't exist on UP, and because the kernel isn't preemptible + + <braunr> antrik: and yes, min number is 0, but in that case you don't need + (space, port) -> right lookups :) + <braunr> antrik: or put in another way, whichever reasonable structure you + use, when it's empty, you don't care much + <braunr> which also means that the min number has actually no value here + <braunr> because the same applies to 1 + + <braunr> then what seems to take most time is forks + <braunr> and i hope my upcoming kernel changes will help the situation a + bit + <pinotree> what are your incoming gnumach changes about? + <braunr> the ipc translation layer speed + <braunr> which basically means operating on port names (looking them up, + inserting, removing, renaming, looking up send rights to a specific + ports) will be faster + <braunr> and i believe forks are (one of) the most demanding use cases wrt + ipc space manipulation + <braunr> i'm really surprised how badly the splay trees are used + <braunr> the worst case for this data structure is traversal + <braunr> and this is done in many situations + <braunr> leaving the tree in its worst case shape + <braunr> and i didn't mentioned the bunch of memory writes occurring, event + for things like lookups or traversals + <braunr> this is slow and can disrupt many cpu cache lines + <braunr> and when there are 10k to 100+k (e.g. in some ext2fs instances on + buildds), just imagine the number of operations involved in those + operations + <braunr> a simple traversal_next involves a rotation *gasp* + <braunr> this means potentially writing on 3 different cache lines, for + *one* next operation + <pinotree> what are you replacing that splay tree with? + <braunr> radix trees + <braunr> much shorter paths + <braunr> extremely few memory writes + <braunr> locality of reference when traversing + <braunr> good cache usage (as many of the top nodes are reused) + <braunr> the two drawbacks are 1/ memory allocation for external nodes, + which means the tree must be preloaded before locking + <braunr> and 2/ high memory overhead if the keys are sparse + <braunr> but this isn't the case with port names, unless someone messes it + up by assigning random names to many rights + + <antrik> braunr: so, when will we see the first performance comparision? + :-) + <braunr> antrik: that's a topic of itself, how to compare ? + <braunr> antrik: the thing is, my current gnumach patches only makes + assertions + <braunr> this is the best way i found to test my tree in real life + conditions + <braunr> much cleanup is needed + <braunr> and what i'd like to do is to completely replace all teh + translation layer structures with it + <braunr> which means removing much code, making sure it still works as + expected + <braunr> this is tedious + <braunr> so one month at least + <antrik> braunr: comparing shouldn't be too hard... the average configure + script does a lot of forking, which should be a good benchmark according + to your observations + <braunr> rough estimates are easy, yes + <braunr> but my observations my be wrong :p + <antrik> braunr: well, we don't really need precise numbers... + <antrik> unless you need to do some kind of fine-tuning? + <braunr> i don't know yet + + +# IRC, freenode, #hurd, 2011-06-18 + + < braunr> hmm, i'm having a problem with integrating my radix tree code in + gnumach + < braunr> inserting into such a tree can trigger memory allocation + < braunr> so commonly, the tree i loaded with nodes before insertion, + usually if it requires strong locking + < braunr> ipc spaces are locked using "simple locks" (which are spin locks) + < braunr> but spin locks are noops on UP, and gnumach is always UP .. + < braunr> so, should i still include preloading code, even if it'll end up + dead code ? + < antrik> hm... I think we discussed this before; but isn't gnumach + supposed to be SMP-capable, minus bugs?... + < braunr> it is + < braunr> but ofc, if i choose not to include preloading, i'll write + #errors so that the day gnumach is built for SMP again, such support will + be included + < antrik> oh, sorry, I think I misread. what is UP? + < braunr> uniprocessor + < antrik> well, if it's just bugs forcing the current UP state, I think + saying that gnumach is always UP is a stretch... + < braunr> sure, but it's a practical consideration + < antrik> does the locking complicate stuff? or is it just performance + considerations? + < braunr> no it's about correctness and completeness + < braunr> if you don't preload a tree before locking + < braunr> and memory allocation occurs while you're holding a simple lock + < braunr> and memory allocation requires the kernel to sleep + < braunr> you're screwed + < braunr> but i hate the idea of including code that won't be used and + which won't be easy to test + < braunr> so i'm wondering if it's ok for now to just put this in a TODO + comment and write it when the time is right + < braunr> or if i should spens the week adding this and tweaking the + userspace implementation to "emulate" spin locks + < antrik> well, it's tricky situation. on one hand, it seems stupid to + include handling for something that presently isn't used, and it's not + clear when it will. on the other hand, I'd rather not see additional + problems introduced that will make fixing SMP even harder... + < braunr> that's why i'm asking here + < antrik> of course, you could resolve this question by fixing SMP + first... ;-) + < braunr> ew + < antrik> well, I guess it would be best first to make the code work... and + we can still decide about the locking thing before it goes mainline I'd + say? + < braunr> "make the code work" ? + < antrik> I mean make gnumach work with your radix tree code + < braunr> without preloading then + < antrik> yeah... as a first step... I guess adding it later won't be any + harder than adding it right now? + < braunr> not much + < braunr> testing is what requires time really + + +# IRC, freenode, #hurd, 2011-06-27 + + < braunr> ok, here is the radix tree code: + http://git.sceen.net/rbraun/libbraunr.git/ + < braunr> the preloading stuff will be added in the kernel only, as it's + really pointless and not easily doable in userspace + < youpi> preloading? + < braunr> youpi: yes, preloading + < braunr> radix trees allocate external nodes + < youpi> well, providing a url at some random time of some random day is + not a great way to get eyes on it :) + < braunr> and ipc spaces are locked when inserting/allocating names + < braunr> we normally don't need preloading in gnumach + < braunr> since there is no preemption nor SMP + < braunr> but in case someone changes that, i'd like the code to be mostly + ready + < braunr> and correctly handle those ugly simple locks + < braunr> youpi: is what i say clear enough or do you need more background + on what is done ? + < youpi> about preloading? + < braunr> yes + < youpi> I guess it means allocating nodes in advance? + < braunr> yes + < youpi> k + < braunr> before locking the ipc spaces + + +# IRC, freenode, #hurd, 2011-06-28 + + < braunr> antrik: i think i won't write the code for the preloading stuff + actually + < braunr> antrik: it's not very difficult, but i really hate the idea of + not being able to reliably test it + < braunr> antrik: and i'd rather concentrate on integrating the radix tree + code in gnu mach now + < braunr> (i've already removed much code, even some files which weren't + actually used before my changes !) + < braunr> hmm, i won't be able not to write the preloading code after all + < antrik> braunr: not able not to write? how's that? + < braunr> antrik: it's actually required + < braunr> there are three functions, ipc_entry_get, ipc_entry_alloc, and + ipc_entry_grow_table + < braunr> ipc_entry_get cannot allocate memory + < braunr> if it fails, ipc_entry_grow_table is called, which will allocate + memory + < braunr> ipc_entry_alloc calls both of them depending on the result of + ipc_entry_get + < braunr> this is the equivalent of the preloading thing i had in mind + < braunr> not a bad thing after all + < braunr> the only thing i'm afraid of are the "optimized" version of those + ipc functions in te so-called fast paths + < braunr> i'm afraid if i don't deal right with those, the kernel may end + up using mostly slow paths + < braunr> but considering the purpose of those fast paths was merely to + avoid the overhead of function calls and some locking functions, it + shouldn't be that bad + < braunr> this is such a mess eh + < antrik> hurray microoptimisations ;-) + < braunr> there, the preload functions are done, easy :) + < antrik> braunr: seems you spent less time implementing it than pondering + whether you should implement it ;-) + < braunr> well, i couldn't implement it correctly before knowing what + should have been done exactly + < braunr> and there are still other problems :/ + < braunr> and the other problems make me reconsider if this was useful at + all eh + < braunr> youpi: i'm unable to find where ipc tree entries are released + except in ipc_entry_alloc_name(), which could mean they're leaked ... + < braunr> youpi: would you have time to take a look ? + < youpi> they aren't in ipc_entry_dealloc() ? + < braunr> no ..... + < youpi> it's not so unprobable that they're only freed when the task quits + < braunr> i don't see that either + < braunr> i only see them released in ipc_entry_alloc_name() + < braunr> so maybe they're reused + < braunr> but i'm not sure about that when reading the code + < braunr> oh wait, yes, they are :/ + < braunr> my bad + < youpi> in the ipc_splay_tree_* fucntions I guess? + < braunr> yes + < braunr> it's just surprsing to see them allocated outside the tree code + only + < braunr> but released in both the entry and the splay tree code ... + + +# IRC, freenode, #hurd, 2011-06-29 + + < braunr> hmm i missed an important thing :/ + < braunr> and it's scary + < braunr> it looks like the splay tree is mainly used when names are + provided + < braunr> whereas the entry table is used when names are allocated + < braunr> which means the table is the main ipc data structure, even for + tasks with lots of rights + < braunr> i can make my root ext2fs have more than 10k rights, and i see + the ipc table table grow along that number ... + < braunr> now thetable has 15k+ entries + < braunr> IOW there is no point to put the radix tree code in gnumach :( + < antrik> braunr: what do you mean by "provided" and "allocated"? + < antrik> and what is that table you are talking about? + < braunr> antrik: provided means the user space tasks gives the name of the + new right + < braunr> antrik: allocated means the kernel generates it + < braunr> antrik: the table i'm talking about is is_table in struct + ipc_space + < braunr> 55 * Every space has a non-NULL is_table with + is_table_size entries. + < braunr> 56 * A space may have a NULL is_tree. is_tree_small + records the + < braunr> 57 * number of entries in the tree that, if the table were + to grow + < braunr> 58 * to the next larger size, would move from the tree to + the table. + < braunr> here is the description which mislead me (in addition of the + obscure code) + < braunr> 50 * Spaces hold capabilities for ipc_object_t's (ports + and port sets). + < braunr> 51 * Each ipc_entry_t records a capability. Most + capabilities have + < braunr> 52 * small names, and the entries are elements of a table. + < braunr> 53 * Capabilities can have large names, and a splay tree + holds + < braunr> 54 * those entries. The cutoff point between the table + and the tree + < braunr> 55 * is adjusted dynamically to minimize memory + consumption. + < antrik> ah, so the rights with a low name are in a linear table, and only + those with "random" high names are stored in the splay tree instead? + < antrik> seems a rather complex design... I guess though there isn't much + room for further optimisation there :-( + < antrik> (well, except for code size optimisation -- which could in fact + make a considerable difference...) + < braunr> well there are problems with this approach, but most don't + concern performance + < braunr> when the table gets big (close to the page size or more), it gets + remapped when reallocated + < braunr> which will incur some penalty because of the tlb + < braunr> but it's annoying even for small tables + < braunr> the initial table size is 4 entries, and from what i can see, + most tables are 128 entries wide when tasks are destroyed + < braunr> an obvious simple optimization is to set a larger default size + < braunr> the same applies for the dead name tables + < braunr> those reallocations are a pain, and they're due to this design + < braunr> they can also fail because of fragmentation + < braunr> there would be a point to radix trees if they would replace all + that, and not just the splay tree + < braunr> but this would cause a lot of changes in a lot of places, and in + particular the "optimized" fast paths i mentioned yesterday + < braunr> we'll see how they perform in x15 :> + < braunr> there is a slight noticeable improvement when increasing the + initial size of the entry table + < antrik> braunr: well, if you use them in a completely different + implementation, there will be no way of telling whether they make a + difference + < antrik> how did you test the improvement? + < braunr> antrik: no actually it's completely negligeable + < braunr> hm + < braunr> is that a valid word ? :) + < braunr> negligible + < braunr> youpi: did you see my comments about the ipc stuff this earlier + today ? + < braunr> youpi: well to make things short, when port names are allocated, + the right they refer to is allocated from the ipc table + < braunr> youpi: the splay tree is only used for user provided names + < braunr> youpi: i had tables as large as the number of rights in a space + (i could easily reach 20k) + < braunr> youpi: whereas the splay trees had at most ~40 entries .. diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn new file mode 100644 index 00000000..aab52d97 --- /dev/null +++ b/open_issues/rm_fr.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +From: Samuel Thibault <samuel.thibault@gnu.org> +Subject: rm -fr slowness + +I have always been surprised by the slowness of a mere rm -fr. Looking a +bit inside, I see that diskfs_dirremove_hard() calls diskfs_file_update +(dp, 1) (as does diskfs_truncate, diskfs_direnter_hard, and +diskfs_dirrewrite_hard). diskfs_file_update then calls pager_sync on +the pager, which thus writes back the whole ext2fs pager! + +This sounds a bit excessive to me, an unlink could just record it in +memory and actually sync later. Also, the wait flag is set, so we +really waits for all I/Os, which basically means strictly serializing +file removals: remove one file, wait for the disk to have done it +(~10ms), remove the next one, etc. I guess this is for safety reasons +against crashes, but isn't the sync option there for such kind of + + +# IRC, freenode, #hurd, 2011-07-23 + + <antrik> youpi: hm... async deletion does have one downside: I just removed + something to make space, and retried the other command immediately + afterwards, and it still said "no space left on device"... a few seconds + later (after the next regular sync I suppose?) it worked + <youpi> well, that's sorta expected, yes + <youpi> we get the same on Linux + <youpi> Mmm, on second thought, I'm not sure how that can happen + <youpi> the asynchronous thing is for disk writes, not cache writes diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn new file mode 100644 index 00000000..d32bd509 --- /dev/null +++ b/open_issues/robustness.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2011 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_documentation open_issue_hurd]] + + +# IRC, freenode, #hurd, 2011-11-18 + + <nocturnal> I'm learning about GNU Hurd and was speculating with a friend + who is also a computer enthusiast. I would like to know if Hurds + microkernel can recover services should they crash? and if it can, does + that recovery code exist in multiple services or just one core kernel + service? + <braunr> nocturnal: you should read about passive translators + <braunr> basically, there is no dedicated service to restore crashed + servers + <etenil> Hi everyone! + <braunr> services can crash and be restarted, but persistence support is + limited, and rather per serivce + <braunr> actually persistence is more a side effect than a designed thing + <braunr> etenil: hello + <etenil> braunr: translators can also be spawned on an ad-hoc basis, for + instance when accessing a particular file, no? + <braunr> that's what being passive, for a translator, means + <etenil> ah yeah I thought so :) + + +# IRC, freenode, #hurd, 2011-11-19 + + <chromaticwt> will hurd ever have the equivalent of a rs server?, is that + even possible with hurd? + <youpi> chromaticwt: what is an rs server ? + <chromaticwt> a reincarnation server + <youpi> ah, like minix. Well, the main ground issue is restoring existing + information, such as pids of processes, etc. + <youpi> I don't know how minix manages it + <antrik> chromaticwt: I have a vision of a session manager that could also + take care of reincarnation... but then, knowing myself, I'll probably + never imlement it + <youpi> we do get proc crashes from times to times + <youpi> it'd be cool to see the system heal itself :) + <braunr> i need a better description of reincarnation + <braunr> i didn't think it would make core servers like proc able to get + resurrected in a safe way + <antrik> depends on how it is implemented + <antrik> I don't know much about Minix, but I suspect they can recover most + core servers + <antrik> essentially, the condition is to make all precious state be + constantly serialised, and held by some third party, so the reincarnated + server could restore it + <braunr> should it work across reboots ? + <antrik> I haven't thought about the details of implementing it for each + core server; but proc should be doable I guess... it's not necessary for + the system to operate, just for various UNIX mechanisms + <antrik> well, I'm not aware of the Minix implementation working across + reboots. the one I have in mind based on a generic session management + infrastructure should though :-) diff --git a/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn new file mode 100644 index 00000000..9db92250 --- /dev/null +++ b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn @@ -0,0 +1,163 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +[RPC to self with rendez-vous leading to duplicate port +destroy](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00045.html) + +IRC, freenode, #hurd, 2011-03-14 + + <antrik> youpi: I wonder, why does the root FS call diskfs_S_dir_lookup() + at all?... + <youpi> errr, because a client asked for it? + <youpi> (problem with RPCs is you can't easily know where they come from :) + ) + <youpi> (especially when it's the root fs...) + <antrik> ah, it's about a client request... didn't see that + <youpi> well, I just said "is called", yes + <antrik> I do not really understand though why it tries to reauthenticate + against itself... + <antrik> I fear my memory of the lookup mechanism grew a bit dim + <youpi> see the source + <youpi> it's about a translated entry + <antrik> (and I never fully understood some aspects anyways...) + <youpi> it needs to start the translated entry as another user, possibly + <antrik> yes, but a translated entry normally would be served by *another* + process?... + <youpi> sure, but ext2fs has to prepare it + <youpi> thus reauthenticate to prepare the correct set of rights + <antrik> prepare what? + <youpi> rights + <youpi> so the process is not root, doesn't have / opened as root, etc. + <antrik> rights for what? + <youpi> err, about everything + <antrik> IIRC the reauthentication is done by the parent FS on the port to + the *translated* node + <antrik> and the translated node should be a different process?... + <youpi> that's not what I read in the source + <youpi> fshelp_fetch_root + <youpi> ports[INIT_PORT_CRDIR] = reauth (getcrdir ()); + <youpi> here, getcrdir() returns ext2fs itself + <antrik> well, perhaps the issue is that I have no idea what + fshelp_fetch_root() does, nor why it is called here... + <youpi> it notably starts the translator that dir_lookup is looking at, if + needed + <youpi> possibly as a different user, thus reauthentication of CRDIR + <antrik> so this is about a port that is passed to the translator being + started? + <youpi> no + <youpi> well, depends on what you mean by "port" + <youpi> it's about reauthenticating a port to be passed to the translator + being started + <youpi> and for that a rendez-vous port is needed for the reauthentication + <youpi> and that's the one at stake + <antrik> yeah, I meant the port that is reauthenticated + <antrik> what is CRDIR? + <youpi> current root dir ... + <antrik> so the parent translator passes it's own root dir to the child + translator; and the issue is that for the root FS the root dir points to + the root FS itself... + <youpi> yes + <antrik> OK, that makes sense + <youpi> (but that's only one example, rgrep mach_port_destroy hurd/ show + other potential issues) + <antrik> well, that's actually what I wanted to mention next... why is the + rendez-vous port destroyed, instead of just deallocating the port right + and letting reference counting to it's thing?... + <antrik> do its thing + <youpi> "just to make sure" I guess + <antrik> it's pretty obvious that this will cause trouble for any RPC + referencing itself... + <youpi> well, follow-up with that on the list + <youpi> with roland/tb in CC + <youpi> only they would know any real reason for destroy + <youpi> btw, if you knew how we could make _hurd_select()'s raw __mach_msg + call be interruptible by signals, that'll permit to fix sudo + <youpi> (damn, I need sleep, my tenses are all wrong) + <antrik> BTW, does this cause any actual trouble?... + <antrik> I don't know much about interruption... cfhammer might have a + better idea, he look into that stuff quite a bit AIUI + <antrik> looked + <antrik> (hehe, it's not only your tenses... guess there's something in the + ether ;-) ) + <youpi> it makes sudo, mailq, etc. fail sometimes + <antrik> I mean the rendez-vous thing + <youpi> that's it, yes + <youpi> sudo etc. fail at least due to this + <antrik> so these are two different problems that both affect sudo? + <antrik> (rendez-vous and interruption I mean) + <youpi> yes + <youpi> with my patch the buildds have much fewer issues, but still some + <youpi> (my interrupt-related patch) + <youpi> I'm installing a s/destroy/deallocate/ version of ext2fs on the + buildds, we'll see how it behaves + <youpi> (it fixes my testcase at least) + <antrik> interrupt-related patch? + <antrik> only thing interrupt-related I remember was the reauthentication + race... + <youpi> that's what I mean + <antrik> well, cfhammer investigated this is quite some depth, explaining + quite well why the race is only mitigated but still exists... problem is + that we didn't know how to fix it properly + <antrik> because nobody seems to understand the cancellation code, except + perhaps for Roland and Thomas + <antrik> (and I'm not even entirely sure about them :-) ) + <antrik> I think his findings and our conclusions are documented on the + ML... + <youpi> by "much fewer issues", I mean that some of the symptoms have + disappeared, others haven't + <antrik> BTW, couldn't the rendez-vous thing be worked around by simply + ignoring the errors from the failing deallocate?... + <youpi> no, failing deallocate are actually dangerous + <antrik> why? + <youpi> since the name might have been reused for something else in the + meanwhile + <youpi> that's the whole point of the warning I had added in the kernel + itself + <antrik> I see + <youpi> such things really deserve tracking, since they can have any kind + of consequence + <antrik> does Mach try to reuse names quickly, rather than only after + wrapping around?... + <youpi> it seems to + <antrik> OK, then this is a serious problem indeed + <youpi> (note: I rarely divine issues when there aren't actual frequent + symptoms :) ) + <antrik> well, the problem with the warning is that it only shows in the + cases that do *not* cause a problem... so it's hard to associate them + with any specific issues + <youpi> well, most of the time the port is not reused quickly enough + <youpi> so in most case it shows up more often than causing problem + +IRC, freenode, #hurd, 2011-03-14 + + <youpi> ok, mach_port_deallocate actually can't be used + <youpi> since mach_reply_port() returns a receive right, not a send right + * youpi guesses he will really have to manage to understand all that port + stuff completely + <antrik> oh, right + <antrik> youpi: hm... now I'm confused though. if one client holds a + receive right, the other client (or in this case the same process) should + have a send or send-once right -- these should *not* share the same name + in my understanding + <antrik> destroying the receive right should turn the send right into a + dead name + <antrik> so unless I'm missing something, the destroy shouldn't be a + problem, and there must be something else going wrong + <antrik> hm... actually I'm probably wrong + <antrik> yeah, definitely wrong. receive rights and "ordinary" send rights + share the name. only send-once rights are special + <antrik> I wonder whether the problem could be worked around by using a + send-once right... + <antrik> mach_port_mod_refs(mach_task_self(), name, + MACH_PORT_RIGHT_RECEIVE, -1) can be used to deallocate only the receive + right + <antrik> oh, you already figured that out :-) diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn index c7a0962c..659b81ea 100644 --- a/open_issues/runit.mdwn +++ b/open_issues/runit.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2011 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] @@ -17,3 +18,33 @@ report is just from his memory, and his memory is dim... The problem *might* either be a time stamping issue (which might be fixed by now) or it *might* be the `select` call failing issue we're seeing from time to time. Or something else. + +[[Harish Badrinath|harishbadrinath]] +Originally answered by Samuel Thibault: +> 120->proc_dostop_request ( 138) = 0 +> +> </snip> + +Usual issue with rpctrace: it does not support fork(). + + I've checked a backtrace in gdb, got this: + + 0x0105af6c in mach_msg_trap () + at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, + timeout=1000020, notify=0) at msg.c:110 + 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, + timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 + 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 + 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 + 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 + + and main() shows up as: + + sig_unblock(sig_term); + sig_unblock(sig_child); + -> iopause(x, 2 +haslog, &deadline, &now); + sig_block(sig_term); + sig_block(sig_child); + +So it simply looks like the known "signals don't interrupt select" bug. diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn new file mode 100644 index 00000000..4e1fa849 --- /dev/null +++ b/open_issues/sa_siginfo_sa_sigaction.mdwn @@ -0,0 +1,96 @@ +[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]] + +[[!meta title="SA_SIGINFO, SA_SIGACTION"]] + +[[!tag open_issue_glibc]] + +Note: SA_SIGINFO has now been implemented by Jérémie Koenig. It will be +uploaded in Debian eglibc 2.13-19. + +IRC, #hurd, August / September 2010: + + <giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void sighandler(int num) prototype but how do I add the sa_handler field? + <pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags + <giselher> SA_SIGINFO is not defined + <pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes + <giselher> K + <giselher> I am not sure if I fully understand this, there is the line "act.sa_flags = SA_SIGINFO" and how do I have to change that >_> + <pinotree> can you paste the source in a pastebin? + <giselher> k + <giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790 + <pinotree> something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G + <pinotree> note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined + <pinotree> (that code still won't compile, yet) + <giselher> btw: is there a reason why SA_SIGINFO is not implemented? + <giselher> the guildlines only say "It's not implemented" + <azeem> 09:43 < azeem> signal stuff is tricky :-/ + <azeem> basically it was pending on a complete rewrite by Roland, which never occured + <youpi> I have an almost complete implementation, just not finished yet + <youpi> (only the siginfo part) + <azeem> nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand + <azeem> ah, he's here + <azeem> :) + <giselher> oh, should I just wait ? + <youpi> no + <giselher> k + <youpi> there are OSes which don't have SA_SIGINFO + <youpi> just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO + <youpi> (i.e. replace with 0 in your example) + <giselher> ok + <youpi> when SA_SIGINFO becomes available, it'll just be used + +IRC, freenode, #hurd, 2011-08-20: + + < youpi> erf, tcpwrappers will need si_pid + < jkoenig> I could implement it not too far away in the future, we just + need a version of msg_sig_post() with a siginfo argument or something. + < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... + < youpi> (probably copy/pasty code) + < youpi> sa.sa_flags = SA_SIGINFO; + < youpi> sa.sa_handler = parse_config; + < youpi> void parse_config(int) + < youpi> yay + < youpi> if(siginf->si_signo == SIGXCPU) + < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); + < youpi> ... + < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO + they request... + < youpi> jkoenig: si_pid should get us almost all actually used coverage + < youpi> I've seen only one example using si_errno + < jkoenig> ok + < youpi> oh, it's actually supported by your patch + < youpi> (errno) + < jkoenig> but I guess since implementing si_pid will require a new RPC, we + might as well plan for the rest + < youpi> jkoenig: indeed + < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? + < youpi> ok, well, we'll see + < pinotree> jkoenig: if it can be of help, boost::unit_test queries various + fields of siginfo_t depending on the signal + < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting + memory on SIGBUS + < jkoenig> pinotree, oh ok good to know + < pinotree> *faulty + < youpi> jkoenig: well, I guess you had checked that the si_addr field is + correct in a few simple testcase :) + < jkoenig> hmm I think so, yes + < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC + < youpi> ok + < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV + depending on the upper bit, or something (I can't quite remember) + < jkoenig> but when sigsegv was generated si_addr was right. + < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost + sources) + < pinotree> maybe you can try the unit tests for boost::unit_tests, if any + :) + < pinotree> (while src/pulsecore/memtrap.c in PA) + * pinotree stops doing MrObvious™ diff --git a/open_issues/sbcl.mdwn b/open_issues/sbcl.mdwn new file mode 100644 index 00000000..4bbf92ef --- /dev/null +++ b/open_issues/sbcl.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011 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_porting]] + +IRC, freenode, #hurd, 2011-08-12 + + < zyg> did the segment registers had any purpose? I see fs is set equal to + others, but on linux fs is 0 (atleast on this x86 box). + < braunr> zyg: it can be used by special applications like wine, yes + < zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can + be used for TLS, fs in syscall to pass userspace. + < braunr> zyg: why are you interested in that ? + < zyg> a native compiler under linux places assumptions on fs register. So + I'm trying to find out what it should do under gnumach/hurd. + < braunr> what compiler ? + < zyg> braunr: it's sbcl + < braunr> ok + < youpi> zyg: the same, basically + < zyg> ok.. looking at the code, I've remarked where it sets up FS, because + /usr/include/asm/ldt.h:struct user_desc is missing. I must search for the + equiv. + < youpi> zyg: mach/i386/mach_i386.h + < youpi> the descriptor structure diff --git a/open_issues/screen.mdwn b/open_issues/screen.mdwn new file mode 100644 index 00000000..e0394f0d --- /dev/null +++ b/open_issues/screen.mdwn @@ -0,0 +1,120 @@ +[[!meta copyright="Copyright © 2009, 2010 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_porting]] + +Typing `C-c` (*SIGINT*) in a *screen* session (Debian package 4.0.3-14; -11 is +fine): + + * shell prompt: no reaction (nothing printed) + * `sleep 10` running: `^C` printed, but SIGINT is not sent. + +[[!debbug 522689#38]]. + +--- + +Revisit this issue: [[!debbug 97343]] -- special handling of `TIOCSCTTY` +depending on `__GNU__`. + +--- + +`#ifdef linux` and friends are used in quite a number of places. + +--- + +All diffs are GNU/Linux vs. GNU/Hurd. + + /* + * If your system supports BSD4.4's seteuid() and setegid(), define + * HAVE_SETEUID. + */ + -/* #undef HAVE_SETEUID */ + +#define HAVE_SETEUID 1 + +TODO: check. + +--- + + /* + * define HAVE_SVR4_PTYS if you have a /dev/ptmx character special + * device and support the ptsname(), grantpt(), unlockpt() functions. + */ + -#define HAVE_SVR4_PTYS 1 + +/* #undef HAVE_SVR4_PTYS */ + + /* + * define HAVE_GETPT if you have the getpt() function. + */ + #define HAVE_GETPT 1 + + /* + * define HAVE_OPENPTY if your system has the openpty() call. + */ + -/* #undef HAVE_OPENPTY */ + +#define HAVE_OPENPTY 1 + + /* + * define PTYRANGE0 and or PTYRANGE1 if you want to adapt screen + * to unusual environments. E.g. For SunOs the defaults are "qpr" and + * "0123456789abcdef". For SunOs 4.1.2 + * #define PTYRANGE0 "pqrstuvwxyzPQRST" + * is recommended by Dan Jacobson. + */ + -/* #undef PTYRANGE0 */ + -/* #undef PTYRANGE1 */ + +#define PTYRANGE0 "pq" + +#define PTYRANGE1 "0123456789abcdefghijklmnopqrstuv" + +TODO: check: `HAVE_SVR4_PTYS` is due to `configure.in` doing `test -c +/dev/ptmx`. But: even if we don't have that file, we still have `ptsname`, +`grantpt`, `unlockpt`. + +--- + + gcc -c -I. -I. -g -O2 -O2 -g -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers pty.c + +pty.c: In function 'OpenPTY': + +pty.c:323: warning: implicit declaration of function 'openpty' + +pty.c: At top level: + +pty.c:75: warning: 'PtyName' defined but not used + +pty.c:86: warning: 'PtyProto' defined but not used + +pty.c:87: warning: 'TtyProto' defined but not used + +TODO: check. + +--- + + --- linux/osdef.h 2009-10-06 18:43:53.000000000 +0200 + +++ screen-4.0.3/osdef.h 2009-10-06 18:49:49.000000000 +0200 + @@ -42,13 +42,19 @@ + #endif + + #ifdef SYSV + +extern char *strchr __P((char *, int)); + +extern char *strrchr __P((char *, int)); + +extern char *memset __P((char *, int, int)); + +extern int memcmp __P((char *, char *, int)); + #else + #endif + + #ifndef USEBCOPY + # ifdef USEMEMCPY + +extern void memcpy __P((char *, char *, int)); + # else + # ifdef USEMEMMOVE + +extern void memmove __P((char *, char *, int)); + # else + # endif + # endif + +TODO: check. + +--- + + * [[screen_dead_session]] diff --git a/open_issues/screen_dead_session.mdwn b/open_issues/screen_dead_session.mdwn new file mode 100644 index 00000000..fe51523b --- /dev/null +++ b/open_issues/screen_dead_session.mdwn @@ -0,0 +1,69 @@ +[[!meta copyright="Copyright © 2010, 2011 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_porting]] + +Comparing to GNU/Linux, on GNU/Hurd it happens much more often and easily for +*screen* sessions to become *dead*. This is annoying, as it defeats one of +*screen*'s main purposes. + +[[!toc]] + + +# One reproducible scenario goes like this + + * `ssh [somewhere]`, + + * start a *screen* session, and some long-running process *P* in there, + + * at some point the link is forcefully terminated (also known as disconnect + after 24 hours with consumer DSL), + + * *P* will continue to execute, + + * at some point, *P* will terminate / hang (after having received some kind + of signal?), and the *screen* session will be reported as *dead*. + + +# Another one, not as often reproduced + + * `ssh [somewhere]`, + + * start a *screen* session, and some long-running process *P* in there, + + * at some point the link is forcefully terminated (also known as disconnect + after 24 hours with consumer DSL), + + * `ssh [somewhere]`, + + * `screen -x`, and notice that *P* will *immediatelly* terminate / hang + (after having received some kind of signal?), and the *screen* session will + *immediatelly* be reported as *dead*. (Perhaps the other way round: upon + re-attaching, the *screen* session goes bonkers and takes *P* with it?) + + +# IRC, freenode, #hurd, 2011-10-19 + + <antrik> tschwinge: hm... haven't seen screen dying in a long time + <tschwinge> antrik: It's easy, and goes like this: have a session on one + system, log in from another, do screen -x and wait some time. + <antrik> I do this regularily. haven't had a crash in ages. + <antrik> (BTW, I'm not sure I ever had a crash on srceen -x... at that + time, I wasn't using -x. I often had crashes with screen -r. my + impression back then was that it works better when doing -rd -- in fact, + I always do that now, so I can't say whether crashes still happen with + only -r...) + +2011-10-26: + + <antrik> so I was saying the other day that I haven't had a screen crash in + a long time... well, here it was :-( + <antrik> this time it didn't crash on reconnect though, but already + before. probably when I killed the hanging ssh connection diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn new file mode 100644 index 00000000..45e983a7 --- /dev/null +++ b/open_issues/secure_file_descriptor_handling.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010, 2011 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]] + +`O_CLOEXEC`, `dup3` et al.; see +<http://udrepper.livejournal.com/20407.html>. [[tschwinge]] once worked +on this, posted patches to [[mailing_lists/libc-alpha]]. This works needs to +be resumed +and finished. + +--- + +In <http://lwn.net/Articles/417421/> an interesting point is made: *you [may] +want some [[unix/file_descriptor]] to still be open if 'exec' fails, but you +don't want it to be open after the exec succeeds*. [[I|tschwinge]]'m not sure +whether our current `O_CLOEXEC` implementation adheres to that. diff --git a/open_issues/security.mdwn b/open_issues/security.mdwn new file mode 100644 index 00000000..055c8bdc --- /dev/null +++ b/open_issues/security.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +There are [[several aspects to security|/security]] that are (mainly) relevant +to the design space. + +There are also security issues in the implemenation space, for example using +the correct coding paradigms. + +Large parts of our code base have not beed audited, either manually or in an +automated fashion. + +[[Unit testing]] is one aspect: testing for reliably failing for invalid input. + +[[Code analysis]] is another aspect. + +All publically usable interfaces provide attacking targets. This includes all +[[system call]]s and [[RPC]] interfaces. + +Fuzzing techniques can be use for locating possible issues. + + * <http://lwn.net/Articles/414273/> + + * Has already been used in the 70s / 80s (?) for testing [[UNIX]] command + line tools. + + * <http://www.ece.cmu.edu/~koopman/ballista/> diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn new file mode 100644 index 00000000..abec304d --- /dev/null +++ b/open_issues/select.mdwn @@ -0,0 +1,220 @@ +[[!meta copyright="Copyright © 2010, 2011, 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]] + +There are a lot of reports about this issue, but no thorough analysis. + + +# Short Timeouts + +## `elinks` + +IRC, unknown channel, unknown date: + + <paakku> This is related to ELinks... I've looked at the select() + implementation for the Hurd in glibc and it seems that giving it a short + timeout could cause it not to report that file descriptors are ready. + <paakku> It sends a request to the Mach port of each file descriptor and + then waits for responses from the servers. + <paakku> Even if the file descriptors have data for reading or are ready + for writing, the server processes might not respond immediately. + <paakku> So if I want ELinks to check which file descriptors are ready, how + long should the timeout be in order to ensure that all servers can + respond in time? + <paakku> Or do I just imagine this problem? + + +## [[dbus]] + + +## IRC + +### IRC, freenode, #hurd, 2012-01-31 + + <braunr> don't you find vim extremely slow lately ? + <braunr> (and not because of cpu usage but rather unnecessary sleeps) + <jkoenig> yes. + <braunr> wasn't there a discussion to add a minimum timeout to mach_msg for + select() or something like that during the past months ? + <youpi> there was, and it was added + <youpi> that could be it + <youpi> I don't want to drop it though, some app really need it + <braunr> as a debian patch only iirc ? + <youpi> yes + <braunr> ok + <braunr> if i'm right, the proper solution was to fix remote servers + instead of client calls + <youpi> (no drop, unless the actual bug gets fixed of course) + <braunr> so i'm guessing it's just a hack in between + <youpi> not only + <youpi> with a timeout of zero, mach will just give *no* time for the + servers to give an answer + <braunr> that's because the timeout is part of the client call + <youpi> so the protocol has to be rethought, both server/client side + <braunr> a suggested solution was to make it a parameter + <braunr> i mean, part of the message + <braunr> not a mach_msg parameter + <jkoenig> OTOH the servers should probably not be trusted to enforce the + timeout. + <braunr> why ? + <jkoenig> they're not necessarily trusted. (but then again, that's not the + only circumstances where that's a problem) + <braunr> there is a proposed solution for that too (trust root and self + servers only by default) + <jkoenig> I'm not sure they're particularily easy to identify in the + general case + <braunr> "they" ? the solutions you mean ? + <braunr> or the servers ? + <youpi> jkoenig: you can't trust the servers in general to provide an + answer, timeout or not + <jkoenig> yes the root/self servers. + <braunr> ah + <youpi> jkoenig: you can stat the actual node before dereferencing the + translator + <jkoenig> could they not report FD activity asynchronously to the message + port? libc would cache the state + <youpi> I don't understand what you mean + <youpi> anyway, really making the timeout part of the message is not a + problem + <braunr> 10:10 < youpi> jkoenig: you can't trust the servers in general to + provide an answer, timeout or not + <youpi> we already trust everything (e.g. read() ) into providing an answer + immediately + <braunr> i don't see why + <youpi> braunr: put sleep(1) in S_io_read() + <youpi> it'll not give you an immediate answer, O_NODELAY being set or not + <braunr> well sleep is evil, but let's just say the server thread blocks + <braunr> ok + <braunr> well fix the server + <youpi> so we agree + <braunr> ? + <youpi> in the current security model, we trust the server into achieve the + timeout + <braunr> yes + <youpi> and jkoenig's remark is more global than just select() + <braunr> taht's why we must make sure we're contacting trusted servers by + default + <youpi> it affects read() too + <braunr> sure + <youpi> so there's no reason not to fix select() + <youpi> that's the important point + <braunr> but this doesn't mean we shouldn't pass the timeout to the server + and expect it to handle it correctly + <youpi> we keep raising issues with things, and not achieve anything, in + the Hurd + <braunr> if it doesn't, then it's a bug, like in any other kernel type + <youpi> I'm not the one to convince :) + <braunr> eh, some would say it's one of the goals :) + <braunr> who's to be convinced then ? + <youpi> jkoenig: + <youpi> who raised the issue + <braunr> ah + <youpi> well, see the irc log :) + <jkoenig> not that I'm objecting to any patch, mind you :-) + <braunr> i didn't understand it that way + <braunr> if you can't trust the servers to act properly, it's similar to + not trusting linux fs code + <youpi> no, the difference is that servers can be non-root + <youpi> while on linux they can't + <braunr> again, trust root and self + <youpi> non-root fuse mounts are not followed by default + <braunr> as with fuse + <youpi> that's still to be written + <braunr> yes + <youpi> and as I said, you can stat the actual node and then dereference + the translator afterwards + <braunr> but before writing anything, we'd better agree on the solution :) + <youpi> which, again, "just" needs to be written + <antrik> err... adding a timeout to mach_msg()? that's just wrong + <antrik> (unless I completely misunderstood what this discussion was + about...) + + +#### IRC, freenode, #hurd, 2012-02-04 + + <youpi> this is confirmed: the select hack patch hurts vim performance a + lot + <youpi> I'll use program_invocation_short_name to make the patch even more + ugly + <youpi> (of course, we really need to fix select somehow) + <pinotree> could it (also) be that vim uses select() somehow "badly"? + <youpi> fsvo "badly", possibly, but still + <gnu_srs1> Could that the select() stuff be the reason for a ten times + slower ethernet too, e.g. scp and apt-get? + <pinotree> i didn't find myself neither scp nor apt-get slower, unlike vim + <youpi> see strace: scp does not use select + <youpi> (I haven't checked apt yet) + + +### IRC, freenode, #hurd, 2012-02-14 + + <braunr> on another subject, I'm wondering how to correctly implement + select/poll with a timeout on a multiserver system :/ + <braunr> i guess a timeout of 0 should imply a non blocking round-trip to + servers only + <braunr> oh good, the timeout is already part of the io_select call + + +### IRC, freenode, #hurdfr, 2012-02-22 + + <braunr> le gros souci de notre implé, c'est que le timeout de select est + un paramètre client + <braunr> un paramètre passé directement à mach_msg + <braunr> donc si tu mets un timeout à 0, y a de fortes chances que mach_msg + retourne avant même qu'un RPC puisse se faire entièrement (round-trip + client-serveur donc) + <braunr> et donc quand le timeout est à 0 pour du non bloquant, ben tu + bloques pas, mais t'as pas tes évènements .. + <abique|work> peut-être que passer le timeout de 10ms à 10 us améliorerait + la situation. + <abique|work> car 10ms c'est un peut beaucoup :) + <braunr> c'est l'interval timer système historique unix + <braunr> et mach n'est pas préemptible + <braunr> donc c'est pas envisageable en l'état + <braunr> ceci dit c'est pas complètement lié + <braunr> enfin si, il nous faudrait qqchose de similaire aux high res + timers de linux + <braunr> enfin soit des timer haute résolution, soit un timer programmable + facilement + <braunr> actuellement il n'y a que le 8254 qui est programmé, et pour + assurer un scheduling à peu près correct, il est programmé une fois, à + 10ms, et basta + <braunr> donc oui, préciser 1ms ou 1us, ça changera rien à l'interval + nécessaire pour déterminer que le timer a expiré + + +### IRC, freenode, #hurd, 2012-02-27 + + <youpi> braunr: extremely dirty hack + <youpi> I don't even want to detail :) + <braunr> oh + <braunr> does it affect vim only ? + <braunr> or all select users ? + <youpi> we've mostly seen it with vim + <youpi> but possibly fakeroot has some issues too + <youpi> it's very little probable that only vim has the issue :) + <braunr> i mean, is it that dirty to switch behaviour depending on the + calling program ? + <youpi> not all select users + <braunr> ew :) + <youpi> just those which do select({0,0}) + <braunr> well sure + <youpi> braunr: you guessed right :) + <braunr> thanks anyway + <braunr> it's probably a good thing to do currently + <braunr> vim was getting me so mad i was using sshfs lately + <youpi> it's better than nothing yes + + +# See Also + +See also [[select_bogus_fd]] and [[select_vs_signals]]. diff --git a/open_issues/select_bogus_fd.mdwn b/open_issues/select_bogus_fd.mdwn new file mode 100644 index 00000000..17aced4a --- /dev/null +++ b/open_issues/select_bogus_fd.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2011 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]] + + +# Python + +IRC, freenode, #hurd, 2011-04-13 + + <abeaumont> ok, cause of first python testsuite failure located, now the + hard part, how to best fix it :) + <abeaumont> how to redesign the code to avoid the problem... that's the + hard part, mostly cause i lack contextual info + <abeaumont> tschwinge: the problem is pretty much summarized by this + comment in _hurd_select (in glibc): /* If one descriptor is bogus, we + fail completely. */ + <pochu> does POSIX say anything about what to do if one fd is invalid? + <pochu> and the other question is why python is calling select() with an + invalid fd + <abeaumont> pochu: yep, it says it should not fail completelly + <pochu> then that's our bug :) + <pinotree> abeaumont: just note that (at least on debian) some tests may + hang forever or cause hurd/mach to die + <pinotree> abeaumont: see in the debian/rules of the packaging of each + pythonX.Y source + <pinotree> ... there's a list of the tests excluded from the test suite run + <abeaumont> well, to be precise, python has a configure check for + 'broken_poll' which hurd fails, and therefore python's select module is + not built, and anything depending on it fails + <abeaumont> broken_poll checks exactly for that posix requirement + <abeaumont> the reason for python using a non-existant + descriptor... unknown :D + <pochu> we should fix select to not fail miserably in that case + <pinotree> abeaumont: we have a patch to fix the broken poll check to + actually disable the poll module + <pochu> pinotree: but the proper fix is to fix select(), which is what + abeaumont is looking at + <abeaumont> pinotree: i'd say that's exactly what python's configure check + does itself -- disable building the select module + <pochu> abeaumont: what pinotree means is that the check is broken, see + http://patch-tracker.debian.org/patch/series/view/python2.6/2.6.6-8/hurd-broken-poll.diff + <pinotree> yes, the configure check for poll does the check, but not + everything of the poll module gets disabled (and you get a build failure) + +--- + +See also [[select]] and [[select_vs_signals]]. diff --git a/open_issues/select_vs_signals.mdwn b/open_issues/select_vs_signals.mdwn new file mode 100644 index 00000000..bbd69d00 --- /dev/null +++ b/open_issues/select_vs_signals.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 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]] + + +# `sudo` + +`sudo [task]` hands after finishing `[task]`. + +IRC, freenode, #hurd, 2011-04-02 + + <youpi> the sudo bug is select() not being able to get interrupted by + signals + +--- + +See also [[select]] and [[select_bogus_fd]]. diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn new file mode 100644 index 00000000..cf0103df --- /dev/null +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -0,0 +1,101 @@ +[[!meta copyright="Copyright © 2010, 2011, 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. + + <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722 + <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724 + <pinotree> \o/ + <youpi> \o/ + <pinotree> the patch is even short, after all: http://paste.debian.net/54795/ + --- a/sysdeps/mach/hurd/sendmsg.c + +++ b/sysdeps/mach/hurd/sendmsg.c + @@ -18,6 +18,7 @@ + + #include <errno.h> + #include <string.h> + +#include <unistd.h> + #include <sys/socket.h> + #include <sys/un.h> + + @@ -45,6 +46,7 @@ + mach_msg_type_number_t amount; + int dealloc = 0; + int i; + + struct sockaddr_storage sa; + + /* Find the total number of bytes to be written. */ + len = 0; + @@ -122,6 +124,34 @@ + err = EIEIO; + } + + + memset (&sa, 0, sizeof (struct sockaddr_storage)); + + if (addr) + + { + + memcpy (&sa, addr, addr_len); + + } + + else + + { + + getsockname (fd, (struct sockaddr *) &sa, &addr_len); + + } + + addr = (struct sockaddr_un *) &sa; + + if (message && (addr->sun_family == AF_LOCAL)) + + { + + struct cmsghdr *cm; + + struct msghdr *m = (struct msghdr *) message; + + for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm)) + + { + + if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS) + + { + + struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm); + + cred->cmcred_pid = __getpid (); + + cred->cmcred_uid = __getuid (); + + cred->cmcred_euid = __geteuid (); + + cred->cmcred_gid = __getgid (); + + cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups); + + } + + } + + } + + + err = HURD_DPORT_USE (fd, + ({ + if (err) + <youpi> what checks that the pid is correct? + <youpi> and uid, etc. + <pinotree> hm? + <youpi> credential is not only about one claiming to the other his uid & such + <youpi> it's about the kernel or whatever authority tell to an end the identity of the other end + <pinotree> yep + <pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side + <youpi> pflocal could as well just request the info from proc + <youpi> it will have to anyway, to check that it's true + <pinotree> hm + <pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive) + <youpi> well at least it shows we're able to transmit something :) + <pinotree> well it just manipulates the data which gets send nicely already ;) + <youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end + <youpi> the application sender part would be just the RPC authentication calls + <youpi> Mmm, just realizing: so receiver part already exists actually, right? + <youpi> (since it's just about letting the application reading from the message structure) + <pinotree> yep + <youpi> ok, good :) + +/!\ IRC, freenode, #hurd, 2011-08-11 + + < pinotree> (but that patch is lame) + +--- + +See also [[dbus]], [[pflocal_socket_credentials_for_local_sockets]] and +[[pflocal_reauth]]. diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn new file mode 100644 index 00000000..ed6358a2 --- /dev/null +++ b/open_issues/serial_console.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2010 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_documentation]] + +IRC, #hurdfr, 2010-09-20 + + <youpi> tu peux compiler ton gnumach pour qu'il utilise la console série, et tu + mets le port série sur la console qemu + <youpi> -AC_DEFINE([RCLINE], [-1], [com port for the remote console]) + <youpi> +AC_DEFINE([RCLINE], [0], [com port for the remote console]) + <youpi> dans i386/configfrag.ac + <manuel> grumpf, peu pratique :) + <youpi> ben après t'auras accès vraiment à ton gnumach + <youpi> messages de noyau etc. + <manuel> oui c'est sûr, mais j'ai aucune idée de comment je configure qemu & + co, ça va être sportif encore + <youpi> -serial vc + <manuel> je lance pas moi-même le qemu, donc j'imagine qqch comme -serial + tcp::qqch,server + <youpi> ben t'as pas accès à la console alors ? + <youpi> mais sinon via tcp ça devrait aller oui + <manuel> si, via telnet + <manuel> youpi: et après, tu fais comment pour envoyer le c-a-D toi ? + <manuel> (question sans doute bête) + <youpi> c'est un code différent via com1 iirc + <manuel> mmmmmmmmmhhhhhh + <youpi> (c'est pas bête: c-a-d c'est pas vraiment défini pour un port série) + <manuel> tu sais où je peux le trouver ? + <youpi> ah tiens non yena pas + <youpi> mais bon spa dur à ajouter + <manuel> bcp trop compliqué pour moi + <youpi> dans i386/i386at/com.c, à la première ligne ttyinput() + <youpi> tu compares c à ce que tu veux + <youpi> et dans ce cas tu appelles kdb_kintr + <youpi> (sans paramètre) + <youpi> mais sinon ya pas vraiment besoin d'appeller explicitement le + débuggueur hein + <manuel> ah ? + <youpi> dès que tu mets debug_all_traps à 1 dans traps.c, il sera invoqué lors + du segv + <manuel> ok + <youpi> pour xen j'ai mis £ comme raccourcis + <manuel> ça me paraît plus simple dans ce cas + <youpi> clin d'œil à la société anglaise :) diff --git a/open_issues/servers_default-pager_permissions.mdwn b/open_issues/servers_default-pager_permissions.mdwn new file mode 100644 index 00000000..58dba1cb --- /dev/null +++ b/open_issues/servers_default-pager_permissions.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="/servers/default-pager permissions"]] + +[[!tag open_issue_hurd]] + +IRC, freenode, #hurd, 2012-01-14: + + <youpi> antrik: what are the permissions that are supposed to be given to + /servers/default-pager ? + <antrik> olaf@alien:~$ ls -l /servers/default-pager + <antrik> crw-rw-rw- 1 root root 0, 0 Sep 17 2004 /servers/default-pager + <antrik> oh, interesting... in the other system it's different + <antrik> olaf@alien:~$ ls -l /sub/servers/default-pager + <antrik> crw-r--r-- 1 root root 0, 0 Jul 10 2006 + /sub/servers/default-pager + <antrik> both are Debian, the latter installed with crosshurd + <antrik> (and native-install run in a chroot or subhurd, don't remember + which...) diff --git a/open_issues/settrans_directory_symlink.mdwn b/open_issues/settrans_directory_symlink.mdwn new file mode 100644 index 00000000..86148a52 --- /dev/null +++ b/open_issues/settrans_directory_symlink.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 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_hurd]] + +This works: + + $ touch a && settrans a /hurd/symlink b + +This doesn't: + + $ mkdir a && settrans a /hurd/symlink b + settrans: a: Is a directory + +It's the same `file_set_translator` RPC both times, and it's [[translator +short-circuiting|hurd/translator/short-circuiting]] which makes the latter one +fail: + +`libdiskfs/file-set-trans.c`: + + [...] + /* Set passive translator */ + if (passive_flags & FS_TRANS_SET) + { + if (!(passive_flags & FS_TRANS_FORCE)) + { + /* Handle the short-circuited translators */ + mode_t newmode = 0; + + if (diskfs_shortcut_symlink && !strcmp (passive, _HURD_SYMLINK)) + newmode = S_IFLNK; + [...] + + if (newmode) + { + if (S_ISDIR (np->dn_stat.st_mode)) + { + /* We can't allow this, because if the mode of the directory + changes, the links will be lost. Perhaps it might be + allowed for empty directories, but that's too much of a + pain. */ + mutex_unlock (&np->lock); + return EISDIR; + } + [...] diff --git a/open_issues/sigpipe.mdwn b/open_issues/sigpipe.mdwn new file mode 100644 index 00000000..0df3560e --- /dev/null +++ b/open_issues/sigpipe.mdwn @@ -0,0 +1,345 @@ +[[!meta copyright="Copyright © 2011 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 open_issue_hurd]] + +[[!GNU_Savannah_bug 461]] + +IRC, freenode, #hurd, 2011-04-20 + + <svante_> I found a problem from 2002 by Marcus Brinkmann that I think is + related to my problems: http://savannah.gnu.org/bugs/?461. He has a test + file called pipetest.c that shows that SIGPIPE is not triggered reliably. + <svante_> Cited from the bug report: The attached test program does not + trigger SIGPIPE reliably, because closing the read end of the pipe + happens asynchronously. The write can succeed because the read end might + not have been closed yet. + <svante_> I have debugged this program on both Hurd and Linux, and the + problem in Hurd remains:-( + <svante_> Anybody looked into the almost ten year old + bug:http://savannah.gnu.org/bugs/?461 this one is definitely related to + the build problems of e.g. ghc6 and ruby1.9.1. Should I mention this on + the ML? + <youpi> that could be it indeed + <youpi> does th bug still happen? + <azeem> depends on: new interface io_close + <azeem> which depends on: POSIX record locking + <svante_> youpi: Yes it does, I've tested the pipetest.c file submitted by + Marcus B on both Linux and Hurd + <azeem> that would've maybe been a nice GSOC task + <youpi> azeem: err, the contrary for posix record locking, non ? + <azeem> argh + <azeem> why would POSIX record locking depend on this? + <azeem> well anyway, then have POSIX record locking be a GSOC task :) + <azeem> I wasn't aware that would also fix ruby and ghc building :) + <youpi> http://permalink.gmane.org/gmane.os.hurd.devel.readers/265 + <youpi> (for io_close stuff) + <youpi> http://comments.gmane.org/gmane.os.hurd.devel.readers/63 actually + <azeem> I guess if they didn't implement it/agreed on something back then + it'd be quite hard to do it now + <svante_> azeem: marcus recently showed up here. Maybe he can help out/has + ideas? + <azeem> well yeah + <azeem> but marcus was the junior guy back then + <azeem> <marcus> but it's a very hurdish solution (ie, complex, buggy, and + not implemented) + <azeem> maybe we can go for something simpler + <youpi> azeem: what is this quote about? + <azeem> don't remember + <azeem> not io_close I'd say + +2011-04-21 + + <antrik> svante_: why do you think the problem you see in ruby and ghc is + related to async close() ? + +2011-04-22 + + <svante_> Well: the test case I'm running on ruby is giving me an EBADF + after 8 successful loops, and tracing within eglibc points towards + __mutex_lock_solid or __spin_lock, __spin_lock_solid from + mach/lock-intern.h from cthreads. + +2011-04-23 + + <antrik> srs1: yeah, I saw it... but I still wonder what makes you think + this is related to async FD closing? + <srs1> antrik: Every test case showing the problems are related to fd.h and + the functions there, especially the ones used in the function: + _HURD_FD_H_EXTERN_INLINE struct hurd_fd *_hurd_fd_get (int fd) and so is + the pipetest from Marcus too. + <srs1> I have not yet been able to trace further with gdb since most + variables are optimized out and adding print statements does not work, at + least not yet. Now I'm trying to build eglibc with -O1 to see if the + optimized out variables are there or not. + <youpi> srs1: he means the ghc6 issue + <youpi> (and the ruby issue) + <srs1> youpi: Yes, the ghc6 and ruby ends at the functions I mentioned in + fd,h + <srs1> Both ghc6 and ruby programs are writing to a file when the error + happens. If they are using a pipeline or not I don't know yet, I think it + is a regular file write. + <srs1> I can send your the ruby program if you like: It is a c-file so + debugging is possible. ghc6 is worse, since that program cannot be + debugged directly with gdb. + <antrik> pipetest also results in the program hanging in locking stuff?... + <srs1> pipetest does not hang, but gives no output as it should. Running it + in gdb with single stepping shows the correct behavior, but then gdb + hangs if I try to single stepping further, continue at the right place + works! + <antrik> I haven't looked at the pipetest program. do you have the link + handy? + <antrik> never mind, got it + <antrik> srs1: that sounds like a GDB problem... + <youpi> most probably, yes + <youpi> (and I've always seen issues like this in gdb on hurd) + <antrik> actually I think it's expected... the RPC handling code has some + explicit GDB hooks AIUI; trying to single-step into this code is probably + expected to wreck havoc... + <youpi> well, it should have some sane behavior + <youpi> even if it's "skip to next point where it's debuggable" + <antrik> srs1: note that there is no BADF involved in the pipetest AIUI... + +2011-04-28 + + <antrik> what is the actual problem you are seeing BTW? + <gnu_srs1> antrik: in ruby the problem is: Exception `IOError' at + tool/mkconfig.rb:12 - closed stream + <gnu_srs1> Triggered by ruby:io.c:internal_read_func() calling + sysdeps/mach/hurd/read.c returning a negative number of bytes read. + <abeaumont> gnu_srs1: why do you think that error is locking related? + <gnu_srs1> This happens after 8 iterations of the read loop with 8192 bytes + read each time. + <abeaumont> but that doesn't involve locking at all, does it? + <gnu_srs1> I think it is, if there is a pipepline set up?? + <gnu_srs1> Also the ghc6 hang ends up in hangs in sysdeps/mach/hurd/read.c + traced into fd.h where all things happen (including setting locks and + mutexes) + <braunr> what locking ? + <braunr> stdio locking is different from file locking + <braunr> and a pipe doesn't imply file locking at all + <abeaumont> read may block on pipes, but it's unrelated to flock + <gnu_srs1> Look into the file fd.h, maybe you can describe things + better. I'm not fluent in this stuff. + <gnu_srs1> Has a pipe has a file descriptor associated to it? What about a + file read/write? + <abeaumont> a pipe provides 2 file descriptors, one for reading and another + one for writting + <abeaumont> i may give a look at that if i manage to build glibc + succesfully... + <gnu_srs1> Take a look at the realevant code from fd.h: + http://pastebin.com/kesBpjy4 + <abeaumont> the ruby error happens just trying to build ruby1.9? + <abeaumont> gnu_srs1: from what you said, the error occurs while reading, + so i don't see how it can be related to that code + <abeaumont> you already got a descriptor if you're reading from it + <gnu_srs1> I have not tried anything else than ruby1.9.1. I can send you + the ruby debug setup and files if you are interested. + <abeaumont> gnu_srs1: ok, i'll try to build ruby1.9.1 later... let's see if + i can build glibc first + <gnu_srs1> abeaumont: well, the read suddenly returns -1 bytes read, + resulting in a file descriptor of -1 (instead of +3). + <abeaumont> gnu_srs1: i see + <antrik> gnu_srs1: are you sure the hang really happens in _hurd_fd_get()? + could you give us a backtrace? + <antrik> gnu_srs1: there are many reasons why read() can return -1; errno + should indicate the reason. unfortunately, I can't make much out of + ruby's "translation" of the error :-) + <gnu_srs1> antrik: In the ruby case there is no hang: The steam is closed + by read() giving an error code !=0. This triggers things in the ruby + code: A negative number of bytes read and a negative fd results, and an + error error is triggered in the ruby code. + <gnu_srs1> antrik: See http://pastebin.com/eZmaZQJr + <antrik> gnu_srs1: yes, this all sounds perfectly right. the question is + *why* read() returns an error code. we'd need to know what error it is + exactly, and in what situation it occurs. tracing the libc code is not at + all useful here + <antrik> uhm... 1073741833 is errno?... + <gnu_srs1> BTW: I think the error code is EBADF (badfile descriptor?). The + integer version of it is 1073741833, see the pastebin i linked to. + <antrik> you could use perror() to get something more readable :-) + <antrik> or error() with the right arguments + <gnu_srs1> I used integer when printing, but looking into fd.h I think it + is EBADF (I did get this result once in gdb) + <antrik> fd.h won't tell you anything. most error codes are generated by + the server, not by libc + <antrik> BADF might be generated in libc when ruby tries to read on FD -1 + <antrik> (no idea why it tries to do that... perhaps there is actually + something wrong/stupid in ruby's error handling) + <gnu_srs1> Well I single-stepped in fd.h using gdb and printing err gave + EBADf. err is declared as: error_t err in read.c + <antrik> at which point did you single-step? while fd was still 3? + <gnu_srs1> I don't think the problem is in ruby, it is in mach/hurd! + Similar problems with ghc, python-apt, etc + <gnu_srs1> Yes, fd=3 was not changed. I cannot trace into fd.h from + read.c. That is the problem with all cases! Need to leave for a while + now. + <antrik> sorry, I don't see *anything* similar in the ghc failure. + <antrik> I don't know about python-apt + <antrik> for the ghc case, I'd like to see a GDB backtrace from the point + where it is hanging + <antrik> just to be clear: anything I/O-related will involve fd.h + somewhere. that doesn't in any way indicate the problems are related. in + fact the symptoms you described are very different, and I'm pretty + certain these are completely different issues + <gnu_srs1> antrik: Here is a backtrace, + http://pastebin.com/wvCiXFjB. Numbers 6,7,8 are from the calling Haskell + functions. They cannot be debugged by gdb. Nice to see that somebody is + showing interest at last:-/ + <antrik> hm... I wonder whether the _hurd_intr_rpc_msg_in_trap is a result + of the ^C? + <antrik> if so, it seems to be a "normal" bloking read() operation. so + again probably not related to libc code at all + <gnu_srs1> Where is this blocking read() code located mach/hurd? + <antrik> io_read() is implemented by whatever server handles the FD in + question + <antrik> I guess rpctrace will be more helpful here than GDB... to see what + the program is trying to do here + <gnu_srs1> Why don't I get there with gdb? + <antrik> err... the server is a different process + <antrik> you are only tracing the client code + <gnu_srs1> OK, here is a rpctrace for ruby: + http://pastebin.com/sdPiKGBW.Nice programs you have, no manual pages, and + the program hang + <gnu_srs1> s/http://pastebin.com/sdPiKGBW.Nice + /http://pastebin.com/sdPiKGBW. BTW: Nice/ + <gnu_srs1> antrik: Do you want the rpctrace of the ghc hang too? If that is + the case, do you need the whole file. From the ruby case the last part + looked most interesting: + libpthread/sysdeps/generic/pt-mutex-timedlock.c: assert (mutex->owner != + self); + <antrik> gnu_srs1: hm... you get that assertion only with rpctrace? guess + it doesn't work properly then :-( + <gnu_srs1> Is it visible on the client side? + <antrik> gnu_srs1: that assertion *is* from the client side. I'm just + surprised that apparently it's only triggered when you run it in rpctrace + <antrik> how did you invoke rpctrace? + <gnu_srs1> rpctrace "command with options" > rpctrace.out 2>&1 + <antrik> well, I'd like to know the "command with options" part :-) + <gnu_srs1> OK: for ruby: ./miniruby ./ tool/mkconfig.rb as before. + <antrik> OK, so it just runs the ruby interpreter and no other processes + <gnu_srs1> No other processes involved! + <abeaumont> gnu_srs1: i can reproduce the ruby error, no let's dig in it :D + <antrik> gnu_srs1: rpctrace for ghc could be useful too... but if it's too + long, pasting only the last bit might suffice + <gnu_srs1> antrik: OK, will do that. Do you find anything interesting? + <gnu_srs1> abeaumont: Using gdb: gdb ./miniruby; (gdb) break io.c:569; c8; + break fd.h:72 or break read.c:27 and you are there. Beware of gdb + hanging, so you need another terminal to kill -9 gdb (sometimes a reboot + is needed :-( + <antrik> gnu_srs1: no, the ruby rpctrace is useless; apparently rpctrace + makes it break before reaching the relevant part :-( + <abeaumont> thanks gnu_srs1 + <gnu_srs1> antrik: Hope for better luck with ghc: + http://pastebin.com/dgcrA05t + <antrik> hm... it hangs at proc_dostop() again... whatever that means + +2011-05-07 + + <gnu_srs> One question about ruby: I know where the problems occur in ruby + code. Can I switch to the kernel thread just before in gdb to single step + from there? + <youpi> you can put a breakpoint, can't you? + <antrik> gnu_srs: kernel thread? + <gnu_srs> Yes, but will single stepping from there lead me to the Hurd + code. I have not succeeded to do that yet! + <youpi> you mean the translator code? + <gnu_srs> Well, Roland did call it the signal thread, there are at least + two threads per process, a signal thread and a main (user) thread. + <youpi> then it's a thread in gdb + <youpi> just use the thread gdb commands to access it + <gnu_srs> I do find two threads in gdb, yes. But following only the user + thread does not lead me to the cause of the problems. + <gnu_srs> And following the other (signal thread) has not been successful + so far. + <youpi> multithreading debugging in gdb is painful yes + <youpi> single-step isn't really an option in it + <antrik> gnu_srs: well, as I said before, the cause is probably not in the + libc code anyways. it would be much more relevant to find out what the FD + in question is, and what "special" thing Ruby does to it to trigger the + problematic behaviour... + <youpi> it's simpler to put printfs etc. + <antrik> youpi: well, printf doesn't work in the FD code :-) + <youpi> you can make it work + <youpi> open /dev/mem, write to 0xb8000 + <youpi> I'm not even joking + <gnu_srs> I have printfs in the ruby code. And at some parts in eglibc (but + it is not possible to put them at all places I want, as mentioned before) + <antrik> sure, there are ways to debug this code too... but I don't think + it's useful. so far there is no indication that this will help finding + the actual issue + <gnu_srs> The problem is not file descriptors. It is that an ongoing read + suddenly returns -1 bytes read. And then the ruby code assigns a negative + file descriptor in the exception handling. + <youpi> a *read* ? + <youpi> with errno == 0 ? + <gnu_srs> Yes, a read! + <youpi> how ruby comes to assigning a negative fd from that? + <youpi> does it somehow close the fd? + <gnu_srs> The errno reported from the read is EBADF! + <youpi> did you try to rpctrace it? + <gnu_srs> I don't bother too much about ruby exception handling. The error + has already happened in the read operation. And that lead me to eglibc + code.... and so on... + <youpi> do you know what kind of file this fd was supposed to be on? + <youpi> sure, that's debugging + <gnu_srs> Yes I did rpctrace, but that was not successful. rpctrace just + hang! Buggy code? + <antrik> youpi: I assume that's Ruby's way to indicate that the FD is not + valid anymore, after the previous error + <youpi> does the program fork? + <youpi> antrik: possibly + <youpi> rpctrace has known issues, yes + <youpi> gnu_srs: did you trace close()s by hand with printfs? + <gnu_srs> Ho w to find out if it forks? + <youpi> what does rpctrace stop on ? + <gnu_srs> Well, I don't remember. Antrik? + <antrik> proc_dostop() IIRC + <antrik> or something like that + <gnu_srs> I did not find any close() statements in the code I debugged. + <youpi> ok, proc_dostop() is typically a sign of fork() + <youpi> gnu_srs: that doesn't necessarily mean it's not called + <antrik> gnu_srs: I think his point is that something else might close the + FD, causing the error you see + <youpi> anything can happen in the wild :) + <antrik> gnu_srs: as I said before, the next step is to find out what this + FD is, and what happens to it... + <gnu_srs> antrik: Any ideas how to find out? + <youpi> what is the backtrace? + <gnu_srs> Well I know the fd number, it is either 3 or 5 in my tests. Does + the number matter? + <youpi> yes, it's not std{in,out,err} + <gnu_srs> How to get a backtrace of a program that does not hang? + <youpi> make it hang at the point of failure + <youpi> when read returns -1 + <youpi> so you know who did the read + <gnu_srs> I have to run the loop several times before the number of bytes + read is -1. + <youpi> you mean running the program several times ? + <youpi> or just let the loop continue for some time? + <pinotree> if it's the latter, you can add breakpoints with conditions + <gnu_srs> No the read loop runs for 7 iterations, and fails the 8th time! + <youpi> then make it hang when read() returns -1 + <Mr_Spock> could you paste your code somewhere? + <youpi> when debugging, you're allowed to do all kinds of ugly things, you + know ;) + <gnu_srs> OK, I'll try that. + <gnu_srs> MR_Spock: The easiest way would be to try to build + ruby1.9.1. Then I can help you from where it fails. + <gnu_srs> pinotree: How to give a breakpoint with a condition? + <pinotree> break where if condition + <youpi> see help break + <youpi> oh, there's even a thread condition nowadays, good + <gnu_srs> Thanks for the discussion. I have to get into the real world for + a while now. To be continued. + <antrik> gnu_srs: well, if you already know that the loop runs several + times before the error occurs, you apparently already looked at the + higher-level code that is relevant here... + <youpi> but it may be generic code, and not tell what calls it diff --git a/open_issues/some_todo_list.mdwn b/open_issues/some_todo_list.mdwn index 5f8470b7..1f6f5002 100644 --- a/open_issues/some_todo_list.mdwn +++ b/open_issues/some_todo_list.mdwn @@ -51,7 +51,6 @@ From Marcus, 2002: * Are all inode numbers and link counts correct? * We also should have a "make check" test suite. We can add this once Jeff finished his automake patches * pick up the other things - * pthread, definitely. Now that we are so close * new console is basically done * needs integration of course * X switching support diff --git a/open_issues/strict_aliasing.mdwn b/open_issues/strict_aliasing.mdwn new file mode 100644 index 00000000..01019372 --- /dev/null +++ b/open_issues/strict_aliasing.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 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 open_issue_gnumach open_issue_hurd open_issue_mig]] + + +# IRC, freenode, #hurd, 2012-07-04 + + <braunr> we should perhaps build the hurd with -fno-strict-aliasing, + considering the number of warnings i can see during the build :/ + <pinotree> braunr: wouldn't be better to "just" fix the mig-generated stubs + instead? + <braunr> pinotree: if we can rely on gcc for the warnings, yes + <braunr> but i suspect there might be other silent issues in very old code diff --git a/open_issues/subhurd_error_messages.mdwn b/open_issues/subhurd_error_messages.mdwn new file mode 100644 index 00000000..46b58fa4 --- /dev/null +++ b/open_issues/subhurd_error_messages.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, unknown channel, unknown date: + + <antrik> BTW, many things in a subhurd print various error messages that are never visible on a normal Hurd... diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn new file mode 100644 index 00000000..c8a37169 --- /dev/null +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2010, 2011 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_gnumach open_issue_hurd]] + +Also filed as [[!GNU_Savannah_bug 29292]]. + +\#hurd, 2010, end of May / beginning of June + + [runnign sync, but sill unclean filesystem at next boot] + <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request + and waits (if the synchronous argument was specified) for a + m_o_lock_completed. But m_o_lock_completed only means that dirty pages + have been sent to the translator, and this one still needs to write them + to the backing storage + <slpz> guillem: there's no problem if sync() returns before actually + writting the changes to disk, but this also happens when shutting down + the translator + <slpz> guillem: in theory, locking mechanisms in libpager should prevent + this from happening by keeping track of write operations, but this seems + to fail in some situations + +It helps a lot to run [[`syncfs --synchronous /`|hurd/syncfs]] before issuing +the `halt` or `reboot` command. This will prevent most of the uncleanliness. +Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk +synchronization internally upon translator shutdown, but evidently it doesn't +in all cases. + +Apparently diskfs simply does not set filesystems as read-only: +<http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html>. diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn new file mode 100644 index 00000000..19cba82e --- /dev/null +++ b/open_issues/syslog.mdwn @@ -0,0 +1,107 @@ +[[!meta copyright="Copyright © 2010, 2011, 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_hurd]] + +[[!toc]] + +# IRC, unknown channel, unknown date + + <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 + I see that you intend(ed) to use syslog for logging debug messages. I + thought I'd point you to + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no + idea if that's still an issue or what went wrong at that time. Perhaps + you can have a look? + <scolobb> tschwinge: Thanks for information! Currently I'm logging some + debug messages to a simple file, but I'll now check whether the issue + you've pointed out is still present. + <scolobb> tschwinge: I am getting absolutely abnormal results: when I call + syslog() from a simple C program for the first time, the message goes to + the system log. However, any further calls to syslog() do just + nothing... I am able to send something to syslog only after reboot (it + doesn't help if I restart syslogd). + + +# IRC, freenode, #hurd, 2011-08-08 + + < pinotree> wow, `logger` + a simple C udp server can cause havoc + < pinotree> youpi: ever seen something like + http://paste.debian.net/hidden/72cf4b77/ ? + < pinotree> and then also other servers (like pflocal, pfinet, few more) + start becoming crazy (using 100% cpu) + < youpi> nope + < pinotree> iirc in one of the few tries i got the message "Resource lost." + from the closed ssh connection + < pinotree> i was trying to see why syslog doesn't work, but this basically + surprised me... + < pinotree> oh, i found an apparently working syslog daemon + < pinotree> dsyslog + < gg0> have you tried syslog-ng? IIRC it writes in /var/log/messages by + default. + < pinotree> yeah, it seems to stop receiving messages are few + < pinotree> gg0: are you using syslog-ng? + < gg0> pinotree: I should fire hurd vm up. I seem I kept dirty-patched + busybox syslog, I don't even know if it works, at least it starts + http://bugs.debian.org/636162 + < pinotree> maintainer said "not really" + < gg0> well, if all other syslogs use shm and sems, they won't work too, + right? + < youpi> shm should work with the latest libc + < youpi> what won't is sysv sem + < youpi> (i.e. semget) + + +IRC, OFTC, #debian-hurd, 2011-11-02: + + * pinotree sighs at #645790 :/ + <tschwinge> pinotree: W.r.t. 645790 -- yeah, ``someone'' should finally + figure out what's going on with syslog. + http://lists.gnu.org/archive/html/bug-hurd/2008-07/msg00152.html + <tschwinge> pinotree: And this... + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html + <pinotree> tschwinge: i did that 20 invocations tests recently, and + basically none of them has been logged + <pinotree> tschwinge: when i started playing with logger more, as result i + had some server that started taking all the cpu, followed by other + servers and in the end my ssh connection were dropped and i had nothing + to do (not even login from console) + <tschwinge> pinotree: Sounds like ``fun''. Hopefully we can manage to + understand (and fix the underlying issue) why a simple syslog() + invocation can make the whole system instable. + <pinotree> tschwinge: to be honest, i got havoc in the system when i told + syslog to manually look for /dev/log (-u /dev/log), possibly alao when + telling to use a datagram socket (-d) + <pinotree> but even if a normal syslog() invocation does not cause havoc, + there's still the "lost messages" issue + <tschwinge> Yep. What I've been doing ever since, is deinstall all + *syslog* packages. + <tschwinge> This ``fixed'' all syslog() hangs. + + +# IRC, freenode, #hurd, 2012-03-28 + + <braunr> i can see lots of CRON processes hanging around + <braunr> pinotree: crontab -l was hanging too when trying to quickly see + what went wrong + <braunr> so it may be an unreleased lock of some kind + <antrik> braunr: do you have syslog installed by any chance?... + <antrik> IIRC that bug has never been fixed :-( + <braunr> yes syslogd is running + <antrik> that's probably the culprit then + <braunr> ok + <braunr> i'll just disable it for now then + <antrik> the error has existed for years + <antrik> was similar for me though: for a long time I have been hearing + about this issue, and only suddenly I started experiencing it myself... + <antrik> it depends on how many things are actually logged. IIRC the hang + happens when some client sends 128 messages to syslog or something like + that diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn new file mode 100644 index 00000000..68418097 --- /dev/null +++ b/open_issues/system_call_mechanism.mdwn @@ -0,0 +1,56 @@ +[[!meta copyright="Copyright © 2011, 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_gnumach]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 + + <braunr> very simple examples: system calls use old call gates, which are + the slowest path to kernel space + <braunr> modern processors have dedicated instructions now + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> rah: basically, system calls are slower on mach because they use + call gates instead of newer sysenter/sysexit + <youpi> braunr: sysenter/exit is a x86_64 thing + <braunr> rah: apart from that, the code can't get much simpler, and *I* + know, for i have studied it, and wrote a compatible version in a clone + attempt + <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit + <braunr> youpi: no there are 32-bits instructions, i don't remember if + they're called sysenter, it's in my thesis though so i'm sure of it :) + <youpi> braunr: ah, the other part + <youpi> is linux-x86 using them? + <braunr> youpi: yes, glibc uses them + <youpi> and does it really change much nowadays? + <youpi> what is the actual difference between int 80 and sysenter? + <braunr> less checking + <youpi> checking what? + <youpi> the idt? + <braunr> ring levels for example + <youpi> well, checking a ring is fast :) + <braunr> depending on the original and requested levels, there are lookups + in tables + <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit + <youpi> ah, also it assumes things about segments + <youpi> so that indeed makes context things simpler + <braunr> right + <braunr> but mach doesn't uses int 0x80 + <braunr> it uses an lcall + <braunr> which is a bit slower from what I could read some time ago + <braunr> (not sure if it's still relevant) + <youpi> actually in 64bit mode I had to catch lcall from the invalid + instruction trap + <youpi> perhaps it got dropped in 64bit mode diff --git a/open_issues/system_crash_nmap.mdwn b/open_issues/system_crash_nmap.mdwn new file mode 100644 index 00000000..25d9a1c6 --- /dev/null +++ b/open_issues/system_crash_nmap.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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_gnumach]] + +IRC, unknown channel, unknown date: + + <Casper_> Hmm, `nmap hurd -p 1-` seems to reliably make a hurd machine reboot. diff --git a/open_issues/system_crash_pflocal_fifo.mdwn b/open_issues/system_crash_pflocal_fifo.mdwn new file mode 100644 index 00000000..1dddc44e --- /dev/null +++ b/open_issues/system_crash_pflocal_fifo.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2010 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_gnumach]] + +IRC, unknown channel, unknown date: + +`cat < /dev/zero | cat > /dev/null` will eventually make the system crash, +likewise when using a FIFO. + + <antrik> hm... VM activity seems much higher when running fifo than pfinet... may be the cause + <antrik> "zero filled" and "page faults" are serveral times higher with pipe than with pfinet + <antrik> (cow faults however are about the same...) + <antrik> pflocal is about the same as fifo + + <antrik> no, because it usually takes like 20 minutes until it crashes, sometimes much longer + + <antrik> not sure, but the longest so far was in the range of hours IIRC + + <antrik> I think I never tested what happens on "cat /dev/zero >/dev/null"... another thing yet to try + + <antrik> Linux BTW seems to employ some major VM trickery in this case -- dd shows a transfer rate of 10 GB/s... + + <antrik> no, no anomalies in vmstat + <antrik> the only observation I made is that number of page faults and some other number rise pretty quickly with pflocal and fifo, but not with pfinet + <antrik> I guess that's somehow related to the fact that pfinet doesn't crash -- though I guess the difference is simply that pfinet is way slower... + <antrik> (haven't checked that, though) + + <antrik> BTW, I'm not sure you got it right: the test case is "cat /dev/zero|cat >/dev/null", *not* "cat /dev/zero >/dev/null" + + <antrik> OK, "cat /dev/zero|tail -c 1" also crashes, so it's definitely not related to /dev/null + <antrik> "dd if=/dev/zero|tail -c 1" crashes as well + <antrik> but "tail -c 1 /dev/zero" doesn't seem to + <antrik> cool... running multiple instances of the pipe test also considerably speeds up the crash diff --git a/open_issues/system_initialization.mdwn b/open_issues/system_initialization.mdwn new file mode 100644 index 00000000..9048b615 --- /dev/null +++ b/open_issues/system_initialization.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +IRC, freenode, #hurd, 2011-03-30 + + <kilobug> init=/bin/sh hack doesn't work for GNU/Hurd ? + <antrik> kilobug: I don't think you can override init on Hurd. the init + server is actually involved in bootstrapping part of the system core + <antrik> at some point we discussed the possibility to reduce the Hurd init + server to *only* do that, and then pass on to standard sysv init... with + that it could actually work + +--- + + * [[systemd]], etc. diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn new file mode 100644 index 00000000..1d774307 --- /dev/null +++ b/open_issues/systemd.mdwn @@ -0,0 +1,150 @@ +[[!meta copyright="Copyright © 2010, 2011 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_porting]] + + * <http://www.freedesktop.org/wiki/Software/systemd> + + * <http://0pointer.de/blog/projects/systemd.html>, + <http://0pointer.de/blog/projects/systemd-update.html> + + * <http://lwn.net/Articles/389149/> + +Will need to have something like Linux' +[*cgroups*](http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/cgroups.txt;hb=HEAD). +Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)* +(german)](http://www.pro-linux.de/artikel/2/1464/ressourcen-verwaltung-mit-control-groups-cgroups.html), +Daniel Gollub, Stefan Seyfried, 2010-10-14. + +Likely there's also some other porting needed. + + +# IRC, OFTC, #debian-hurd, 2011-05-19 + + <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the + "systemd as dependency" and all the messages in it don't give me a bright + future for gnome on hurd... + <pochu> yeah, I've read the thread + <pochu> it's only a proposal so far... hopefully it'll be rejected, or they + will only accept the interfaces that other OSes can implement... + <pochu> we'll see + <pinotree> you can always help me with kde on hurd, would be nice ;) + <pochu> hehe + <pinotree> pochu: well, even if the depenency is rejected, the whole «don't + give a damn about non-linux and only bless linux for the "gnome os"» is a + bit... worrying attitude + <pochu> yeah... it doesn't come from all the community though + <pochu> I'm sure some people have always thought that way + <tschwinge> Or we could get systemd going? :-) + <pochu> good luck with that :p + <guillem> tschwinge: haha!? :) + <tschwinge> That bad? + <guillem> tschwinge: if you mean by that forking indefinitely then maybe + <guillem> tschwinge: upstream has expressely stated multiple times, no + interest whatsoever in any kind of portability to anything non-Linux + <guillem> or even older Linux versions! + <guillem> to the point of rejecting patches, because they "clutter" the + source code... + <tschwinge> Well, then let's ``just'' implement the Linux interfaces. :-) + <guillem> tschwinge: then you'll be always playing catch up + <guillem> tschwinge: for example several of the Linux-only things upstream + makes heavy use of, are pretty recent Linux-only additions to the kernel, + but equivalents have been present on FreeBSD for years + <tschwinge> Yeah. I'm half-serious, half-joking. + <tschwinge> I haven't looked at the systemd code at all. + <guillem> + https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html + for a list of its dependencies + <guillem> some are just glibc extensions though + <guillem> and some are IMO optional and should be conditionalized, but... + <guillem> pochu: I don't think that attitude is that old, there was a time + when Linux was not used widely, or even that functional, I think it has + been taking strength since the Linux Plumbers Cartel started :) + <guillem> as in one thing is not caring about anything non-Linux, the other + is outright rejecting portability fixes + <guillem> tschwinge: in any case, these "recent" events are "pissing me + off" to the point of having considered several times implementing + portable replacements for some of those Utopia projects, the problem as + always is time though :) + <guillem> tschwinge: and the issue is not only with systemd, upstart's + upstream has the same approach to portability, if you want to port it, + you'll have to maintain a fork + <pochu> let's create our own init system, make it better than anyone else, + and when people start switching to it, let's start using hurd-only APIs + :) + <tschwinge> We already had someone work on that. Like ten years ago. DMD. + Daemon Managing Daemons. <http://directory.fsf.org/project/DMD/> + <guillem> the real problem with that attitude is not the lack of care for + portabilty, the real problem is that these people are pushing for their + stuff all over the stack, and most of the time deprecating their own + stuff after a while when they have rewritten it from scratch, leaving the + burden of maintaining the old stuff to the other ports + <guillem> witness HAL, ConsoleKit, etc etc + <guillem> (anyway enough ranting I guess :) + <tschwinge> Yeah, it's true, though. + <pochu> agreed + + +# Requires Interfaces + +In the thread starting +[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a +[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) has been +posted that contains the following list (no claim for completeness) of +interfaces that are used in (two source code files of) systemd: + + * cgroups + * namespaces + * selinux + * autofs4 + * capabilities + * udev + * oom score adjust + * RLIMIT_RTTIME + * RLIMIT_RTPRIO + * ionice + * SCHED_RESET_ON_FORK + * /proc/$PID/stat + * fanotify + * inotify + * TIOCVHANGUP + * IP_TRANSPORT + * audit + * F_SETPIPE_SZ + * CLONE_xxx + * BTRFS_IOC_DEFRAG + * PR_SET_NAME + * PR_CAPBSET_DROP + * PR_SET_PDEATHSIG + * PR_GET_SECUREBITS + * /proc/$PID/comm + * /proc/$PID/cmdline + * /proc/cmdline + * numerous GNU APIs like asprintf + * SOCK_CLOEXEC, O_CLOEXEC + * /proc/$PID/fd + * /dev/tty0 + * TIOCLINUX + * VT_ACTIVATE + * TIOCNXCL + * KDSKBMODE + * /dev/random + * /dev/char/ + * openat() and friends + * /proc/$PID/root + * waitid() + * /dev/disk/by-label/ + * /dev/disk/by-uuid/ + * /sys/class/tty/console/active + * /sys/class/dmi/id + * /proc/$PID/cgroup + * \033[3J + * /dev/rtc + * settimeofday() and its semantics diff --git a/open_issues/term_blocking.mdwn b/open_issues/term_blocking.mdwn new file mode 100644 index 00000000..19d18d0e --- /dev/null +++ b/open_issues/term_blocking.mdwn @@ -0,0 +1,128 @@ +[[!meta copyright="Copyright © 2009, 2011 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_hurd]] + +There must be some blocking / dead-locking (?) problem in `term`. + +[[!toc]] + + +# Original Findings + + # w | grep [t]sch + tschwing p1 192.168.10.60: Tue 8PM 0:03 2172 /bin/bash + tschwing p2 192.168.10.60: Tue 4PM 40hrs 689 emacs + tschwing p3 192.168.10.60: 8:52PM 11:37 15307 /bin/bash + tschwing p0 192.168.10.60: 6:42PM 11:47 8104 /bin/bash + tschwing p8 192.168.10.60: 8:27AM 0:02 16510 /bin/bash + +Now open a new screen window, or login shell, or... + + # ps -Af | tail + [...] + tschwinge 16538 676 p6 0:00.08 /bin/bash + root 16554 128 co 0:00.09 ps -Af + root 16555 128 co 0:00.01 tail + +`bash` is started (on `p6`), but newer makes it to the shell promt; doesn't +even start to execute `.bash_profile` / `.bashrc`. The next shell started, on +the next available pseudoterminal, will work without problems. + +The `term` on `p6` has already been running before: + + # ps -Af | grep [t]typ6 + root 6871 3 - 5:45.86 /hurd/term /dev/ptyp6 pty-master /dev/ttyp6 + +In this situation, `w` will sometimes report erroneous values for *IDLE* +for the process using that terminal. + +Killed that `term` instance, and things were fine again. + + +All this reproducible happens while running the [[GDB testsuite|gdb]]. + +--- + +Have a freshly started shell blocking on such a `term` instance. + + $ ps -F hurd-long -p 1766 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 1766 0 3 1 1 6 131M 1.14M 0.0 0:28.85 5:40.91 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:05.76 1:08.48 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:06.40 1:11.52 + 3 0.0 0:05.76 1:09.89 + 4 0.0 0:05.42 1:06.74 + 5 0.0 0:05.50 1:04.25 + +... and after 5:45 h: + + $ ps -F hurd-long -p 21987 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 21987 1001 676 21987 21987 2 148M 2.03M 0.0 0:00.02 0:00.07 /bin/bash + 0 0.0 0:00.02 0:00.07 + 1 0.0 0:00.00 0:00.00 + + $ ps -F hurd-long -p 1766 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 1766 0 3 1 1 6 131M 1.14M 0.0 0:29.04 5:42.38 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:05.76 1:08.48 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:06.41 1:11.90 + 3 0.0 0:05.82 1:10.28 + 4 0.0 0:05.52 1:07.06 + 5 0.0 0:05.52 1:04.63 + + $ sudo gdb /hurd/term 1766 + [sudo] password for tschwinge: + GNU gdb (GDB) 7.0-debian + Copyright (C) 2009 Free Software Foundation, Inc. + License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> + This is free software: you are free to change and redistribute it. + There is NO WARRANTY, to the extent permitted by law. Type "show copying" + and "show warranty" for details. + This GDB was configured as "i486-gnu". + For bug reporting instructions, please see: + <http://www.gnu.org/software/gdb/bugs/>... + Reading symbols from /hurd/term...Reading symbols from /usr/lib/debug/hurd/term...done. + (no debugging symbols found)...done. + Attaching to program `/hurd/term', pid 1766 + [New Thread 1766.1] + [New Thread 1766.2] + [New Thread 1766.3] + [New Thread 1766.4] + [New Thread 1766.5] + [New Thread 1766.6] + Reading symbols from /lib/libhurdbugaddr.so.0.3...Reading symbols from /usr/lib/debug/lib/libhurdbugaddr.so.0.3... + [System doesn't respond anymore, but no kernel crash.] + +--- + +The very same behavior is still observable as of 2011-03-24. + +Next: rebooted; on console started root shell, screen, a few spare windows; as +user started GDB test suite, noticed the PTY it's using; in a root shell +started GDB (the system one, for `.debug` stuff) on `/hurd/term`, `set +noninvasive on`, attach to the *term* that GDB is using. + + +[[2011-07-04]]. + + +# Formal Verification + +This issue may be a simple programming error, or it may be more complicated. + +Methods of [[formal_verification]] should be applied to confirm that there is +no error in `/hurd/term`'s logic itself. There are tools for formal +verification/[[code_analysis]] that can likely help here. + +There is a [[!FF_project 277]][[!tag bounty]] on this task. diff --git a/open_issues/term_blocking/2011-07-04.mdwn b/open_issues/term_blocking/2011-07-04.mdwn new file mode 100644 index 00000000..0f302409 --- /dev/null +++ b/open_issues/term_blocking/2011-07-04.mdwn @@ -0,0 +1,246 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +GDB testsuite makes a term process go bonkers. The testsuite is terminated. +The term process remanins. Next, a new shell (bash) is started that connects +to this term process -- and hangs. + +Hung bash process (27834), term (22634). + + # portinfo -t 22634 27834 + 5 => 58: receive + 11 => 18: receive + 21 => 53: receive + 26 => 51: receive + 27 => 56: receive + 28 => 48: receive + 30 => 54: receive + +GDB on bash: + + #0 0x010ab12c in _hurd_intr_rpc_msg_in_trap (msg=0x102383c, option=3, send_size=44, rcv_size=2092, rcv_name=9, timeout=0, notify=0) at intr-msg.c:134 + err = <value optimized out> + err = <value optimized out> + user_option = 3 + user_timeout = 0 + m = 0x102383c + msgh_bits = 5395 + remote_port = 27 + msgid = 21001 + __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg" + #1 0x01235195 in __io_read (io_object=27, data=0x1024148, dataCnt=0x102414c, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:138 + Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, + msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, amount = 1}, Out = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, + msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, dataType = {msgtl_header = {msgt_name = 255, + msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1, msgt_deallocate = 1, msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 1}, + data = "# /etc/inputrc - global inputrc for libreadline\n# See readline(3readline) and `info rluserman' for more information.\n\n# Be 8 bit clean.\nset input-meta on\nset output-meta on\n\n# To allow the use of 8bit"...}} + msg_result = <value optimized out> + msgh_size = <value optimized out> + #2 0x010afbb1 in readfd (port=27) at fd-read.c:34 + nbytes = 0x9 + nread = 40 + data = 0x44 <Address 0x44 out of bounds> + offset = 12884901897 + #3 0x010b5de5 in _hurd_ctty_input (port=26, ctty=27, rpc=0x1024154) at ctty-input.c:36 + err = 19156808 + #4 0x010af53e in _hurd_fd_read (fd=0x1244f48, buf=0x102420f, offset=-1) at fd-read.c:39 + __ulink = {resource = {next = 0x0, prevp = 0x1244f4c}, thread = {next = 0x1024160, prevp = 0x1246c5c}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1a} + __ctty_ulink = {resource = {next = 0x0, prevp = 0x1244f5c}, thread = {next = 0x0, prevp = 0x1024180}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1b} + ctty = 27 + crit = 0x1246808 + __result = 16925048 + port = <value optimized out> + err = <value optimized out> + data = 0x102420f "" + nbytes = 0x10241f8 + nread = 1 + #5 0x0116c080 in __libc_read (fd=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece. + ) at ../sysdeps/mach/hurd/read.c:27 + descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.)> + err = <value optimized out> + #6 0x080cdaac in ?? () + No symbol table info available. + #7 0x080cdf88 in ?? () + No symbol table info available. + #8 0x080baff7 in ?? () + No symbol table info available. + #9 0x080bb435 in ?? () + No symbol table info available. + #10 0x080507e7 in ?? () + No symbol table info available. + #11 0x0804fc36 in ?? () + No symbol table info available. + #12 0x08052f22 in ?? () + No symbol table info available. + #13 0x08055dab in ?? () + No symbol table info available. + #14 0x0804d960 in ?? () + No symbol table info available. + #15 0x0804da1f in ?? () + No symbol table info available. + #16 0x0804dc65 in ?? () + No symbol table info available. + #17 0x0804d215 in ?? () + No symbol table info available. + #18 0x010b906b in __libc_start_main (main=0x804c450, argc=1, ubp_av=0x1024dd4, init=0x80d7ff0, fini=0x80d7fe0, rtld_fini=0xf330, stack_end=0x1024dcc) at libc-start.c:257 + result = <value optimized out> + #19 0x0804b281 in ?? () + No symbol table info available. + +GDB on term: + + 5 Thread 22634.5 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 4 Thread 22634.4 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 3 Thread 22634.3 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 2 Thread 22634.2 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + * 1 Thread 22634.1 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + + Thread 5 (Thread 22634.5): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x129bf10, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x129bf10 + reply = 0x129df20 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x8061460) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x80619a8 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 4 (Thread 22634.4): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x128df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x128df20 + reply = 0x128bf10 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x805f800) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805f788 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 3 (Thread 22634.3): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x127df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x127df20 + reply = 0x127bf10 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x805ec30) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805ebb8 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 2 (Thread 22634.2): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x126df20, option=3, send_size=32, rcv_size=4096, rcv_name=12, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae99 in __mach_msg_server_timeout (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12, option=0, timeout=0) at msgserver.c:151 + request = 0x126ef30 + reply = 0x126df20 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x0108af6b in __mach_msg_server (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12) at msgserver.c:196 + No locals. + #4 0x0109b99f in _hurd_msgport_receive () at msgportdemux.c:68 + No locals. + #5 0x01052b91 in cthread_body (self=0x805da48) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805d9d0 + #6 0x00000000 in ?? () + No symbol table info available. + + Thread 1 (Thread 22634.1): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x125ba2c, option=2, send_size=0, rcv_size=24, rcv_name=10, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x010516b8 in cproc_block () at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cprocs.c:638 + msg = {msgh_bits = 17345214, msgh_size = 18972660, msgh_remote_port = 17163428, msgh_local_port = 134764952, msgh_seqno = 19249824, msgh_id = 18935134} + waiter = 0x1240808 + new = <value optimized out> + p = 0x805d988 + #3 0x01053589 in hurd_condition_wait (m=0x805d89c) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cancel-cond.c:86 + p = 0x805d988 + cancel = <value optimized out> + __PRETTY_FUNCTION__ = "hurd_condition_wait" + c = 0x805e498 + #4 0x08052abf in trivfs_S_io_read (cred=0x8084b78, reply=32, replytype=18, data=0x125bb44, datalen=0x125bb40, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/users.c:695 + cancel = <value optimized out> + i = <value optimized out> + max = <value optimized out> + cp = <value optimized out> + avail = <value optimized out> + #5 0x0104053b in _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:234 + dataCnt = 2048 + msgh_simple = <value optimized out> + io_object = 0x8084b78 + dataP = 0x125bc8c "\350\003" + #6 _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:148 + In0P = 0x125dc70 + OutP = 0x125bc60 + offsetCheck = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0} + amountCheck = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0} + #7 0x0104065e in trivfs_io_server (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:2005 + InP = 0x125dc70 + OutP = 0x125bc60 + routine = <value optimized out> + #8 0x01038f17 in trivfs_demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libtrivfs/demuxer.c:32 + No locals. + #9 0x080537a8 in demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/main.c:68 + No locals. + #10 0x01059045 in internal_demuxer (inp=0x125dc70, outheadp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:101 + err = <value optimized out> + spawn = <value optimized out> + status = <value optimized out> + pi = <value optimized out> + link = {thread = 3, next = 0x0, prevp = 0x8084b94, notifies = 0x0, interrupted_next = 0x0} + outp = 0x125bc60 + __PRETTY_FUNCTION__ = "internal_demuxer" + [System crashed.] diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn new file mode 100644 index 00000000..72af3f35 --- /dev/null +++ b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)'"]] + +[[!tag open_issue_hurd]] + +<http://bugs.debian.org/46859>, <http://bugs.debian.org/195360> + +IRC, unknown channel, unknown date: + + <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed + <youpi> I actually don't understand this assertion + <youpi> it's just before __spin_lock (&ss->critical_section_lock); + <youpi> why should one check that a lock is free before taking it ? + <youpi> just the same in hurdexec.c + <youpi> (no, ss is not our own sigstate, so it's not safe to assume no other path can take it) + <youpi> there's another one in sysdeps/mach/hurd/spawni.c + <youpi> and jmp-unwind.c + <antrik> youpi: why do you think it's nonsense?... the fact that we take the lock (so we can't be interrupted) doesn't mean we are willing to wait for others to release the lock... maybe the code path should never be reached while others have a lock, or something + <youpi> then it's useless to take the lock + <youpi> "we take the lock (so we can't be interrupted)": no, it's not _our_ lock here, it's the lock of the thread we want to cancel + <antrik> what exactly is cancelling a thread?... (sorry, I don't really have experience with thread programming) + <youpi> ~= killing it + <antrik> well, we take the lock so nobody can mess with the thread while we are cancelling it, no?... + <youpi> yes + <youpi> that is fine + <youpi> but checking that the lock is free before taking it doesn't make sense + <youpi> why nobody should be able to take the lock ? + <youpi> and if nobody is, why do we take it ? (since nobody would be able to take it) + <antrik> well, maybe after taking the lock, we do some action that might result in others trying to take it... + <youpi> nope: look at the code :) + <youpi> or maybe the cancel_hook, but I really doubt it + diff --git a/open_issues/thread_numbering_of_ps_and_gdb.mdwn b/open_issues/thread_numbering_of_ps_and_gdb.mdwn new file mode 100644 index 00000000..7058cfe2 --- /dev/null +++ b/open_issues/thread_numbering_of_ps_and_gdb.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +It appears to [[me|tschwinge]] that `ps -T` enumerates thread IDs starting with +zero, and GDB starting with one. This should be unified. + +Or instead of manually allocating numbers, some other handle should be used, +that has a global meaning for the running GNU Mach kernel, or a process-wide +meaning, for example a port number. + +[[!tag open_issue_hurd open_issue_gdb]] + + +Also see [[GDB thread IDs]]. diff --git a/open_issues/threads_issues.mdwn b/open_issues/threads_issues.mdwn new file mode 100644 index 00000000..aec216e0 --- /dev/null +++ b/open_issues/threads_issues.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +List of issues w.r.t. the Hurd's many-threads paradigm. + +[[!tag open_issue_hurd]] + + * [[fsync]] diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn new file mode 100644 index 00000000..aa36e020 --- /dev/null +++ b/open_issues/ti-rpc_then_nfs.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2011 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_hurd open_issue_porting]] + +TI-RPC replaces glibc's Sun RPC implementation, [[!message-id +"4D0632C5.1040107@RedHat.com"]]. + +It needs some work on our side, [[!message-id +"20101214213212.GU1095@kepler.schwinge.homeip.net"]]. + +Then, the Hurd's [[hurd/translator/nfs]] translator and [[hurd/nfsd]] can be +re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]]. diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn new file mode 100644 index 00000000..ab239aef --- /dev/null +++ b/open_issues/time.mdwn @@ -0,0 +1,69 @@ +[[!meta copyright="Copyright © 2009, 2011 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_porting]] + +Neither the `time` executable from the GNU time package work completely +correctly, nor does the GNU Bash built-in one. + + tschwinge@flubber:~ $ \time sleep 2 + 0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ \time sleep 4 + 0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ \time sleep 6 + 0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ time sleep 2 + + real 0m2.093s + user 0m0.000s + sys 0m0.011s + tschwinge@flubber:~ $ time sleep 4 + + real 0m4.083s + user 0m0.000s + sys 0m0.010s + tschwinge@flubber:~ $ time sleep 6 + + real 0m6.164s + user 0m0.000s + sys 0m0.010s + +GNU time's *elapsed* value is off by some factor. + + $ \time factor 1111111111111111111 + 1111111111111111111: 1111111111111111111 + 0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + $ time factor 1111111111111111111 + 1111111111111111111: 1111111111111111111 + + real 0m11.424s + user 0m0.000s + sys 0m0.010s + +As above; also here all the running time should be attriuted to *user* time. +This is probably a [[!taglink open_issue_gnumach]]. + + +# 2011-09-02 + +Might want to revisit this, and take Xen [[!tag open_issue_xen]] into account +-- I believe flubber has already been Xenified at that time. + + +## IRC, freenode, #hurd, 2011-09-02 + +While testing some [[performance/IPC_virtual_copy]] performance issues: + + <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn new file mode 100644 index 00000000..bd9abcf9 --- /dev/null +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -0,0 +1,87 @@ +[[!meta copyright="Copyright © 2010, 2011 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 open_issue_hurd]] + +[[!toc]] + + +# IRC, freenode, #hurd, June (?) 2010 + + <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? + <marcusb> there is a way + <pochu> marcusb: which one would that be? + <marcusb> I forgot + <marcusb> there is an implementation in libc + <marcusb> realpath has a similar job + <marcusb> but that's not what I mean + <marcusb> pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for + <marcusb> maybe it works only for directories + <marcusb> yeah + <marcusb> pochu: check the getcwd() implementation of libc + <marcusb> sysdeps/mach/hurd/getcwd.c + <marcusb> _hurd_canonicalize_directory_name_internal + * pochu looks + <pochu> marcusb: interesting + <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file + <marcusb> right + <pochu> oh you already said that :) + <marcusb> actually, I am not sure that's correct + <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in + <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that + <marcusb> the hurd is strange + <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-) + <marcusb> yep + <pochu> ok. interesting + <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you? + <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip + <marcusb> there you go + <marcusb> or the other way round: would you be surprised if "cat somedir" would work? + <pochu> I think so. if it did, what would it do? + <marcusb> originally, cat dir would list the directory content! + <marcusb> in the old unix times + <pochu> I was surprised the first time I typed `vi somedir` by accident + <marcusb> and some early BSDs + * pochu feels young :-) + <marcusb> he don't worry, I didn't see those times either + <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface + <marcusb> which combines file and directory operations + <marcusb> of course, files and directories implement those functions differently + <antrik> marcusb: do you know why this behavior (cat on directories) was changed? + + +# IRC, freenode, #hurd, 2011-07-13 + +A related issue: + + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1039 + <braunr> any idea why a shell would consume more than 1039 map entries ? + <braunr> (well, not more actually) + <braunr> even the kernel and ext2fs have around 100 + <braunr> (the kernel has actually only 23, which is very good and expected) + <tschwinge> braunr: I agree that having some sort of debugging information + for memory objects et al. would be quite hand. To see where they're + coming from, etc. + <braunr> tschwinge: this would require naming objects at the mach level + <braunr> e.g. when creating an object + <braunr> giving it the path of a file for example + <tschwinge> braunr: I have recently seen something (due to youpi fixing a + bug) that bash is doing its own memory management. Perhaps all these are + such regions? + <tschwinge> braunr: For example, yes. + <braunr> what ? + <braunr> ?! + <tschwinge> braunr: + http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html + <braunr> i see + +Also see email thread starting at [[!message-id +"20110714082216.GA8335@sceen.net"]]. diff --git a/open_issues/translator_environment_variables.mdwn b/open_issues/translator_environment_variables.mdwn new file mode 100644 index 00000000..cae5a494 --- /dev/null +++ b/open_issues/translator_environment_variables.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> BTW, is settrans -a supposed to clear all env variables? + <cfhammar> or can I consider it a bug ;-) + <cfhammar> scolobb: yeah, seems the problem is in libfshelp + <scolobb> cfhammar: Are you talking about fshelp_start_translator_long? + <scolobb> (I can remember that it does something to the environment indeed) + <cfhammar> scolobb: yes, I think it's the culprit + <cfhammar> clearing the environment makes sense for passive translators I guess, but not active ones + <scolobb> Hm, searching ``env'' in hurd/libfshelp/start-translator-long.c gives me nothing :-( + <scolobb> I think the problem might be in the fact that fshelp_start_translator_long just doesn't copy the environment, but I may be wrong. + <cfhammar> scolobb: yeah, that's my guess also + <scolobb> Well, I don't know proc, but there might be a way to copy the environment to a task when you know its ID, what do you think? + <scolobb> I can see proc_set_arg_locations in process.defs, which sees to set something connected with environment, but I'm not sure whether it suits your needs. + <cfhammar> scolobb: it seems that the env isn't passed to file_exec in fshelp_start_translator_long + <scolobb> cfhammar: Yeah, that's right + <scolobb> I wonder what could the motivation for not passing the environment to a child process + <cfhammar> hmm... fshelp_start_translator_long parameterizes everything except env... + <cfhammar> perhaps there needs to be a fshelp_start_translator_longer ;-) diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn new file mode 100644 index 00000000..14ea1c6d --- /dev/null +++ b/open_issues/translator_stdout_stderr.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 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_hurd]] + +There have been several discussions and proposals already, about adding a +suitable logging mechanism to translators, for example. + + +Decide / implement / fix that (all?) running (passive?) translators' output +should show up on the (Mach / Hurd) console / syslog. + + +[[!taglink open_issue_documentation]]: [[!message-id +"87oepj1wql.fsf@becket.becket.net"]] + + +[[!taglink open_issue_documentation]]: Neal once had written an email on this +topic. + + +IRC, freenode, #hurd, 2011-11-06 + + <youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) { + fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); } + <tschwinge> Isn't stderr in auto-flush mode by default? + <tschwinge> man setbuf: The standard error stream stderr is always + unbuffered by default. + <youpi> tschwinge: "by default" is the important thing here + <youpi> in the case of translators iirc stderr is buffered + <tschwinge> youpi: Oh! + <tschwinge> That sounds wrong. + + +IRC, freenode, #hurd, 2011-11-23 + + <braunr> we'd need a special logging task for hurd servers + <pinotree> if syslog would work, that could be used optionally + <braunr> no, it relies on services provided by the hurd + <braunr> i'm thinking of something using merely the mach interface + <braunr> e.g. using mach_msg to send log messages to a special port used to + reference the logging service + <braunr> which would then store the messages in a circular buffer in ram + <braunr> maybe sending to syslog if the service is available + <braunr> the hurd system buffer if you want diff --git a/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn new file mode 100644 index 00000000..5d3c3aab --- /dev/null +++ b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn @@ -0,0 +1,148 @@ +[[!meta copyright="Copyright © 2010 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_hurd open_issue_glibc]] + +bug-hurd email from 2010-07-28: *O_NOTRANS & O_NOFOLLOW* + +2010-07-29, #hurd + + <antrik> cfhammar: I think that touches on a rather fundamental problem... it's always hard to decide how to handle translators, as the most useful approach depends a lot on context + <antrik> this was actually part of the idea behind namespace-based translator selection + <cfhammar> or perhaps we should just drop the whole O_NOFOLLOW == O_NOTRANS and only apply it for link like translators + <pochu> cfhammar: from what I read in [glibc]/hurd/lookup-retry.c, the problem is that some translators can lie about that + <antrik> cfhammar: at some point I considered the possibility of adding a couple of special flags describing translators ("link" and "device" being some, but also introducing a few new ones) to decide standard behaviour in various situations + <pochu> so you can't really know whether they are links without O_NOTRANS + <cfhammar> pochu: yeah, this would have to be considered carefully + <pochu> antrik: care to explain what namespace based translator selection means? :) + <antrik> pochu: the basic idea is that you add special suffixes to the file name during a lookup, which change the behaviour of lookups + <antrik> the most basic use would be adding a suffix that automatically runs an annonymous translator on the file + <cfhammar> antrik: doesn't stat cover most of those flags (except for firmlink i guess) + <antrik> (scolobb mostly implemented that part) + <antrik> but the idea was also to selectively activate/deactivate static translators based on patterns + <antrik> (this is implemented partially, but recursion is completely missing so far) + <antrik> cfhammar: some of them, yes. but I think there are some cases where the standard stat information is not enough to decide on useful handling + <antrik> let's take the example of a translator that mangles the underlying file -- like xmlfs, mboxfs etc. + <antrik> these aren't device file nor links, but should not really be handled like "normal" (store) filesystems either + <antrik> hm... is there any information in the stat that indicates mount points? + <antrik> I guess that would be good enough to flag "normal" filesystems + <pochu> I'm not sure I understand. you add a suffix during a lookup, based on what? whatever, including e.g. flags? + <antrik> pochu: well, an exmple would be "cat foo.gz,,u" + <antrik> where "u" would be a shorthand for "unzip" + <antrik> and it would launch a translator that uncompresses the underlying file + <pochu> what if there are a foo.gz and a foo.gz,,u files? + <antrik> (I think storeio with gzip store can do that... though some more generic translator might be useful, to cover other compression/archieve types as well) + <antrik> pochu: than you are SOL ;-) + <antrik> pochu: I chose ",," as the suffix after some careful examination that this is *extremely* unlikely to occur in normal use + <antrik> pochu: actually, we introduced an escaping scheme too, so it is still possible to access files with ",," in the name... but that's of limited use, as programs not aware of this will still break + <cfhammar> hmm i wonder why glibc handles O_NOFOLLOW to begin with, since the test it does presumes trust in the containing directory the fs could do it just as securely + <antrik> cfhammar: the FS could do what? + <pochu> another problem I've found is that an open(symlink, O_RDONLY | O_NOFOLLOW, 0) should fail with ELOOP according to POSIX, but it doesn't fail on Hurd + <antrik> pochu: yeah, saw that + <antrik> shouldn't be too hard to fix I hope?... + <cfhammar> antrik: libc test whether the node is a symlink or a (trusted) root owned translator, which it would follow + <pochu> antrik: probably not, though I haven't looked at it closely + <antrik> cfhammar: in what situation would the filesystem do the test? + <antrik> cfhammar: and what advantage would it have over the current approach? + <antrik> pochu: OK + <cfhammar> antrik: the point of the test is to approximate symlink vs. mount point but the fs seems to be in a better position to answer this + <antrik> cfhammar: why? I think this information should be fully available to glibc... if it's not, I'd consider this a bug, or at least a major omission + <cfhammar> antrik: well take fifos for instance, they should be considered part of the containing filesystem but would not by glibc + <cfhammar> antrik: we could make an exception in glibc for fifos but not for other future situations in new translators + <cfhammar> antrik: i mean, we could but this leaves control at the translators hand and let different translators handle things their own way + <cfhammar> generally, it seems more flexible to leave policy to servers rather than to bake it into the (implicit) protocol (which glibc implements) + <antrik> cfhammar: I don't see though why handling it in the filesystem would help here... if the filesystem has the information about how the translator should be handled, it can pass it to the clients + <antrik> hm... that's actually a tricky point. we have many situations where we have to choose between handling things in the client library or server-side... I'm haven't really formed an opinion yet which is preferable in general + <pochu> with cfhammar's proposal, you wouldn't need O_NOTRANS when you specify O_NOFOLLOW, right? + <cfhammar> pochu: i don't think my proposal would even work with O_NOTRANS + <antrik> cfhammar: hm, perhaps we are talking past each other. do you want the handling to be in the filesystem containing the underlying node, or in the actual translator implementing the node? + <antrik> hrm + <cfhammar> antrik: the containing filesystem + <cfhammar> (since this is a security issue) + <pochu> yeah, otherwise the trust issue would still be there + <antrik> then why wouldn't it work with O_NOTRANS? + <antrik> BTW, what security issue are you talking about? do you mean the fact that a translator can redirect the lookups to another file, but hide the fact that it's a link? + <pochu> antrik: I mean the O_NOTRANS & O_NOFOLLOW comment in [glibc]/hurd/lookup-retry.c + <cfhammar> antrik: because O_NOTRANS means don't follow translators (including symlinks) and O_NOFOLLOW means don't follow (any) link but do follow translators + <antrik> pochu: I must admit that I never fully understood what that one is about :-) + <cfhammar> antrik: i imagine O_NOTRANS|O_NOFOLLOW == O_NOTRANS + <antrik> cfhammar: I see + <antrik> cfhammar: but I guess that's totally orthogonal from handling in glibc vs. handling in the FS?... + <pochu> AFAIU, it's that if you do an open(translator, O_NOFOLLOW, 0), the translator can lie about it being a symlink. So you need to do an O_NOTRANS lookup + <pochu> hence hurd/hurdlookup.c adds O_NOTRANS if O_NOFOLLOW is present in flags + <antrik> ah, OK + <antrik> so the idea here is that instead of doing that, glibc would only pass on O_NOFOLLOW, and the filesystem would handle the O_NOTRANS part itself + <cfhammar> antrik: if you have O_NOTRANS the filesystem will never follow any translators including non-link ones, so it can't really handle O_NOFOLLOW to exclude link translators + <cfhammar> antrik: yeah + <antrik> AIUI the problem is that with the current scheme, using O_NOFOLLOW will also ignore non-link translators? + <cfhammar> antrik: exactly, including fifos + <cfhammar> antrik: of course, there's still the problem of determining that it is a non-link translator + <antrik> cfhammar: but why can't this be fixed keeping the current scheme? wouldn't it suffice for glibc to ask the filesystem whether there is a link (with O_NOTRANS), and if not, do the actual lookup without O_NOTRANS?... + <pochu> antrik: there's still the problem of translators lying about them being symlinks or not, right? so instead of a blacklist (is it a symlink?) you would need a whitelist + <antrik> pochu: sure. I just don't see how an implementation in the filesystem would do any better on that score than one in glibc + <cfhammar> antrik: the fs is better at maintaining the whitelist, e.g. you could have different whitelist for different translators + <cfhammar> antrik: the fs also knows who own the fs, so it could make exeptions for the owner's translators + <cfhammar> like glibc does for the root user, currently + <antrik> I'm not really convinced so far that having these policies in the filesystem is really preferable to having them in the client-side library... + <cfhammar> antrik: we want to put /hurd/fifo in the whitelist for all users but we can't determine whether an active translator on the underlying node is /hurd/fifo or not, but the FS can if it started the translator itself + <cfhammar> antrik: of course, this can also be done by hiding the /hurd/fifo translator so that glibc doesn't do the test in the first place + <cfhammar> antrik: but this isn't pretty, you'd have to proxy it afaics :-/ + <antrik> cfhammar: TBH, I don't like the whole whilelisting idea + <antrik> seems to me this is really just another manifestation of the infamous firmlink problem + <antrik> as I said in past discussions, I tend to think that the only way to fix it *properly* is changing the way authentification is handled + <antrik> we actually discussed this at some point... when crossing translator boundries, the client shouldn't use it's full permissions on the new translator, but rather the intersection of it's own permissions and that of the parent translator + <antrik> this way, "secret" links should cease to be dangerous... + <cfhammar> yeah, but that'll take way too long for poor pochu ;-) + <antrik> cfhammar: true... but I'm not convinced that a whitelisting hack in the meantime is really worthwhile + <cfhammar> antrik: we already have a whitelisting hack (root user's translators), we're just moving it to the filesystem and adding /hurd/fifo + <antrik> cfhammar: nope, allowing all root translators is a general policy, not a whitelisting hack + <antrik> not elegant either, but a very different class + <cfhammar> antrik: i don't remember the details but fixing firmlink problem seemed to require some fundamental changes, it might even turn out to be unfeasible + <antrik> BTW, it's still not clear to my why the filesystem is supposed to have a better idea which translators to whitelist than glibc?... + <cfhammar> antrik: huh, i don't think i've seen that policy elsewhere, only for root clients not servers + <cfhammar> antrik: for one it can keep track of if the current active translator is the current passive one, and thus know which program it runs + <antrik> do I get it right that in the case of fifo, the client can't generally trust the user running the translator, and thus the idea is instead to trust the translator program?... + <cfhammar> O_NOFOLLOW implies that the client does not trust the file not to redirect it anywhere and we know /hurd/fifo will not do this + <antrik> cfhammar: was that a "yes"?... + <cfhammar> antrik: yes + <antrik> hm... I think I already said it in the context of object migration: I really don't like the idea of trust based on the program being executed... + <antrik> this workaround also has other shortcomings: what if the transaltor is started actively? + <cfhammar> hmm the owner of the translator could hijack it and the fs wouldn't know + <antrik> I must admit though that I don't see another short-term solution either :-( + <antrik> oh, right, that's another problem + <cfhammar> seems like the fs must implement the fifo itself (or atleast hide the /hurd/fifo translator behind a proxy) + <antrik> BTW, what is the specific manifestation of the problem with fifos being ignored on NOFOLLOW? + <pochu> there are two problems + <pochu> one is that with O_NOFOLLOW, it's ext2fs who checks the file permissions, and denies it (dunno the reason for that) + <pochu> the other one is that if you stat the fifo with O_NOFOLLOW and without it, the device will look different (and thus cp believes the file has changed and fails) + <pochu> that's because an stat on the fifo will return the fifo translator's PID as the device + <antrik> ah + <pochu> while one with O_NOFOLLOW will return the partition device + <antrik> so the specific problem here is that the stat info is differenet with the fifo translator than without + <pochu> I'm not sure whether it would be correct & possible to return the device of the parent translator in libtrivfs, instead of the PID + <pochu> yes + <pochu> that, and the permission one (they are different) + <pochu> though both would be solved if O_NOFOLLOW didn't imply O_NOTRANS :) + <antrik> what exactly do you mean by "device" here? + <pochu> I mean st_dev in struct stat + <antrik> well, I wonder whether the permission problem shouldn't actually be considered a bug in fifo. i sthere a good reason why the permissions are not propagated to the underlying node, as with most other translators? + <pochu> I don't think that's the problem + <antrik> what else? + <pochu> it's rather that if you open the fifo with O_NOTRANS, you don't get the underlying node, and then it's ext2fs (and so libdiskfs) who checks the permissions, and it denies them for whatever reason + <pochu> antrik: libdiskfs/dir-lookup.c has this: + <pochu> if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR) + <pochu> >------- && (flags & (O_READ|O_WRITE|O_EXEC))) + <pochu> >------- || (type == S_IFLNK && (flags & (O_WRITE|O_EXEC)))) + <pochu> >-------error = EACCES; + <pochu> so it returns EACCES for the fifo + <pochu> I wonder whether there's a good reason (that I'm missing) for that + <cfhammar> pochu: i think the reason might be that ext2fs denies access because it does not implement those file types itself + <cfhammar> i.e. ext2fs expects them to be opened without O_NOTRANS + <cfhammar> (or opened exclusively for non rwx reasons such as stat or settrans) diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn new file mode 100644 index 00000000..1dac130c --- /dev/null +++ b/open_issues/translators_set_up_by_untrusted_users.mdwn @@ -0,0 +1,352 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + + +# IRC, freenode, #hurd, 2011-07-17 + + <antrik> Reventlov: this is the so-called "firmlink issue" -- though AFAIK + it doesn't actually apply to firmlinks ;-) + <antrik> the problem is that any user can in theory create and set up a + special translator, which will redirect to another directory, without any + indication that it's a link + <braunr> but this doesn't supersede the file system permissions, does it ? + <antrik> as a result, if someone runs rm -r on the directory containing + that translator (which could be a world-writable one such as tmp), the rm + -r will descend into the directory, and thus remove it with the + permissions of the user who ran the rm -- not the one who set up the + translator + <braunr> oh i see, when tmp gets cleared by a script run as root, your home + is deleted ? + <antrik> right + <antrik> of course, the workaround is trivial: just don't follow + translators set up by untrusted users + <antrik> (which is precisely the default policy for FUSE BTW) + <braunr> which is the general policy around memory managers in general + <antrik> it's just nobody cared to implement this change + <youpi> antrik: does rm use O_NOTRANS ? + <antrik> youpi: I'm pretty sure it doesn't + <youpi> so it's still an issue for now + <antrik> yes, it's still an issue. it's just not a really fundamental + problem as macrus claimed it to be... [sigh] + <youpi> well, fix rm and then you can say it's not an issue any more + <braunr> does it only concern rm ? + <antrik> youpi: rm is just an example. the problem is much more generic: a + malicious translator can do all kinds of harm + <youpi> sure + <youpi> it's just about tools not blindly following things + <antrik> the only simple and effective answer is not to follow translators + from untrusted users by default + <youpi> antrik: but then /dev/null can't be non-root + <braunr> depends how "untrusted users" are identified + <antrik> we discussed a more sophisticated solution with cfhammer, that + would change the way reauthentication works in lookups, and should + prevent these kinds of permission escalation without preventing desirable + uses... but it still wouldn't address DOS issues, so it would be only a + partial solution + <antrik> youpi: why should it? + <manuel> (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html + for the most sophisticated solution) + <antrik> braunr: well, currently the permission system generally trusts + root and the own user. implementing something else might be tricky... not + sure + <antrik> manuel: yes, that's precisely the discussion I was referring + to... thanks for the link :-) + <youpi> antrik: depends what you mean by "follow" + <youpi> what DOS are you thinking of? + <antrik> youpi: a translator can generate endless amounts of "data"; a + translator can generate endless recursive directory tress; or it can just + never return from RPCs... all things that can do pretty much harm + depending on the situation + <antrik> filesystem clients generally trust filesystem operations to be + safe -- and that's just not true anymore with filesystems run by + untrusted users + <antrik> (be it Hurd translators or FUSE modules) + <antrik> this is a fundamental problem as marcus and neal rightly observed + <antrik> I just don't agree about the seriousness of the consequences + <antrik> I don't think not following untrusted translators really looses us + much + <youpi> EDOOMANYNEGATIONS + <youpi> s/D/T + <youpi> again, what do you mean by "following" ? + <youpi> always use O_NOTRANS ? + <tschwinge> Yes, I think. + <youpi> or never accept a REAUTH ? + <youpi> O_NOTRANS would mean ftpfs running as root, brrr + <youpi> it's not really true that clients always trust filesystem + operations + <youpi> the "not returning" case for instance, also appears with nfs mounts + <antrik> no, not always use O_NOTRANS. just be more selective about what + translators to follow. specifically, don't follow translators set up by + untrusted users. (unless explicitly requested) + <antrik> you can think of it as O_NO_UNTRUSTED_TRANS + <antrik> note that if you run ftpfs under a special user, who is not root + but trusted by root, this would still be fine. I hope it shouldn't be too + hard to implement that... + <antrik> as for NFS: clients generally do *not* try to catch possible + failures. if the NFS server doesn't return, the clients hang forever. but + the NFS server is generally trusted, so this is not much of a problem + <antrik> BTW, I guess not accepting reauth from untrusted translators would + also fix the privilege escalations (similar to the proposed modified + reauth mechanism, only more invasive); but it wouldn't fix the DoS issues + <ArneBab> antrik: would that also be an issue for a run translator, which + runs a command on read? + <ArneBab> youpi: couldn’t ftpfs have root drop priviledges? + <ArneBab> like a runas trans + <ArneBab> essertially su for translators to drop privs + <antrik> ArneBab: hm... if we can make sure that the translator was started + as root, and dropped privileges later, I guess that would be fine... not + sure how hard that is + <antrik> ArneBab: but I think it would be more elegant to start the + translators as trusted non-root users in the first place + <ArneBab> then i ph.avme to trust them + <ArneBab> deper hierarchy + <ArneBab> deeper + <ArneBab> but essertially the same + <ArneBab> if then someone mounted his home himself, would I be able to read + it? + <ArneBab> /home/user + <ArneBab> antrik: if not, that would be really non-nice + <antrik> ArneBab: sorry, but we simply *can't* trust a translator set up by + an untrusted user. if he controls it, he can make it behave maliciously + <antrik> we could in theory try to come up with a proxy that catches + problematic semantics, and presents a "safe" variant to the actual + clients... but that would be not-trivial, and I'm not sure how safe it + can be made + <antrik> ArneBab: of course you should always have the option to explicitly + say that you want to trust the translator, if you think the user doesn't + have malicious intentions :-) + <antrik> (I think nsmux would be a good way to achieve this...) + <braunr> unless it's really really necessary (and i don't see why it would + be), no design should force a process to start with privileges and drop + them + <braunr> having a set of trusted users (e.g. uid < 100) is a nice solution + to the problem imho + <braunr> or part of a group, 100 is a non-hurdish static limit + <ArneBab> What user is running a passive translator? + <braunr> passive translators are a pain for such things :/ + <braunr> a command line and attach point are not enough to persistently + encode the execution context of the tranlator + <ArneBab> What user is running a passive translator? + <ArneBab> sorry + <braunr> the one owning the inode if i'm right + <ArneBab> so actually the orly problem are recursive commands, which also + are a problem with plain symlinks? + <braunr> i'm not sure + <ArneBab> Is thene any havoc a translator can wreak that a symlink can’t? + <braunr> well, as symlinks are translators, if a translator can damage + something, a symlink may too + <ArneBab> but not in Linux? + <braunr> err + <braunr> there are no translator in linux + <ArneBab> → commands could just treat translators as symlinks + <ArneBab> jepp, but it has symlinks + <braunr> no, this would defeat the purpose of translators :p + <braunr> and it's just no doable + <braunr> you would have recursion everywhere + <ArneBab> why? + <braunr> because every file access is sent to a translator + <ArneBab> hm, yes + <braunr> and we don't want to change commands + <braunr> we want to fix the design + <ArneBab> → only untrusted trans + <braunr> rather than considering them as symlinks, just consider them as + untrusted translators + <braunr> this doesn't change the semantics, only the action of accessing a + node or not + <braunr> but as antrik said, this has to be done :) + <braunr> the real problem would simplify to "how do you know if a + translator can be trusted", which is a matter of selecting the righ + identification strategy + <braunr> one strong strategy would be to have a port right copied to each + trusted task + <braunr> i wonder if one of the special ports could be used for that + <braunr> or if we have to add a new one + <ArneBab> so when I login, I would give port rights to trusted uids? + <braunr> no + <braunr> when a trusted translator starts a passive translator attached on + a node owned by root, it would copy its trusted right to the new task + <braunr> much like the device master port is passed to root tasks + <braunr> but i'm not sure this mechanism can be safely used to know if the + translator can be trusted + <braunr> the translator would be able to actively call services requiring + this capability + <braunr> but i guess client tasks would have to ask for the translator to + prove it's trusted + <braunr> which is a problem because the issue is to know if it can be + trusted before asking it anything + <braunr> another way is to register trusted tasks in another server, and + ask this server if the target translator is trusted + <braunr> i"m pretty sure these strategies already exist in some form on the + hurd + <ArneBab> hm + <braunr> does someone here have an idea why BSD-derived VMs account wiring + information at the high level vm_map instead of storing it in lower level + vm_page ? + <ArneBab> braunr: a translator anywhene in the FS can only be there, if the + creator had sufficient rights to the node, right? + <ArneBab> so wouldn’t it suffice to check the access rights? + <braunr> no + <braunr> ismple example: /dev/null is owned by root, but you have read + access to it + <braunr> hm that may not answer your question actually + <braunr> what access right would you check ? + <braunr> if someone creates a node with rights 777, do you still want to + access it ? + <ArneBab> no + <braunr> simple enough i hope :) + <ArneBab> arg… + <ArneBab> if I can write to it, I can give it a translaton + <ArneBab> translator + <braunr> but this doesn't tell you it can be trusted + <ArneBab> well, actually: yes, access, but not recurse + <braunr> the owner sets his own rights, and you can't trust the owner + <braunr> unless it's root, but you don't want all your translators to run + as root + <ArneBab> it can act as its owner? + <ArneBab> yes + <braunr> well, as i told you, a passive translator is started by its parent + translator (the one managing the file systeme node it's attached to) + <braunr> the new translator runs as the user owning the node + <braunr> (if i'm right) + <ArneBab> …and so on, till noot starts the first + <ArneBab> root + <braunr> ? + <ArneBab> root starts /, right? + <braunr> no + <braunr> gnumach starts / + <ArneBab> ah, right + <braunr> gnumach starts somefs.static + <braunr> which attaches at / + <braunr> and runs with root privileges + <braunr> keep in mind that unix permissions are implemented as capabilities + on the hurd + <ArneBab> → root has it / it’s root + <braunr> the rights you have aren't limited to those permissions + <ArneBab> jepp + <braunr> and it's not "until" + <ArneBab> so why should I not access a translator run by someone else? I + just don’t want to do any active command (recurse)… hm… can a translator + turn a read request into a write? + <braunr> that's the only problem + <ArneBab> program with my rights wants to read, but the translator makes it + write instead? + <braunr> no + <braunr> a translator can do pretty much anything with your request + <ArneBab> with my rights? + <braunr> no + <braunr> the most obvious example of DoS is simply not answering + <braunr> your process hangs + <braunr> considering some file system accesses, a translator could return + inconsistent data + <ArneBab> so if the translator tries to make me write instead of read, it + can do so only when the owner of the translaton can write to the file in + question? + <braunr> a well written application shouldn't have too much trouble dealing + with it but some aren't that well written + <braunr> this has *nothing* to do with read/write permissions + <braunr> you should read the critique :p + +[[hurd/critique]] + + <ArneBab> ln -s /home/you /home/me → “why don’t you look into my home?” + <ArneBab> read it again, that is :) + <ArneBab> (has been some time since I read it) + <antrik> braunr: you just described the auth mechanism ;-) + <antrik> ArneBab: symlinks can do considerably less than translators; and + even these caused a lot of trouble when introduced (and still cause + sometimes) + <antrik> we can't make every application aware of translators + <antrik> indeed I believe we can a avoid many problems by presenting + various translators as symlinks -- but this is not approriate for all + translators + <antrik> it is something the translator itself decides, so it's not helpful + to solve security issues at all + <antrik> and as braunr already pointed out, this wouldn't help with DoS + problems + + +# Linux kernel, Symlink/Hardlink Attack + +Even though not directly comparable, the issues described at [Symlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection) +and [Hardlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection) +do bear some similarity with the issue we're discussing here. + +Likewise, Kees Cook, [fs: symlink restrictions on sticky +directories](http://lwn.net/Articles/468215/), 2011-11-18. [2011-12-06 +update](http://lwn.net/Articles/470891/). Jake Edge, [Fixing the symlink race +problem](http://lwn.net/Articles/472071/), 2011-12-14. + + +# IRC, freenode, #hurd, 2011-08-31 + + <antrik> I don't see any problems with following only translators of + trusted users + <youpi> where to store the list of trusted users? + <youpi> is there a way to access the underlying node, which for /dev + entries belongs to root? + <ArneBab> youpi: why a list of trusted users? Does it not suffice to + require /hurd/trust set by root or ourselves? + <youpi> ArneBab: just because that's what antrik suggests, so I ask him for + more details + <ArneBab> ah, ok + <antrik> youpi: probably make them members of a group + <antrik> of course that doesn't allow normal users to add their own trusted + users... but that's not the only limitation of the user-based + authentication mechanism, so I wouldn't consider that an extra problem + <antrik> ArneBab: we can't set a translator on top of another user's + translator in general + <antrik> root could, but that's not very flexible... + <antrik> the group-based solution seems more useful to me + <ArneBab> antrik: why can’t we? + <antrik> also note that you can't set passive translators on top of other + translators + <antrik> ArneBab: because we can only set translators on our own nodes + <ArneBab> active ones, too? + <antrik> yes + <ArneBab> antrik: I always thought I could… + <ArneBab> but did not test it + <ArneBab> antrik: so I need a subhurd to change nodes which do not belong + to me? + * ArneBab in that case finally understands why you like subhurds so much: + That should be my normal right + <antrik> it should be your normal right to change stuff not belonging to + you? that's an odd world view :-) + <antrik> subhurds don't really have anything to do with it + <ArneBab> change it in a way that only I see the changes + <antrik> you need local namespaces to allow making local modifications to + global resources + <youpi> it should be one's normal right to change the view one has of it + <antrik> we discussed that once actually I believe... + <antrik> err... private namespaces I mean + +IRC, freenode, #hurd, 2011-09-10: + + <cjuner_> I am rereading Neal Walfield's and Marcus Brinkman's critique of + the hurd on mach. One of the arguments is that a file system may be + malicious (by DoS its clients with infinitely deep directory + hierarchies). Is there an answer to that that does not require programs + to be programmed defensively against such possibilities? + +IRC, freenode, #hurd, 2011-09-14: + + <antrik> cjuner: regarding malicious filesystems: the answer is to do + exactly the same as FUSE on Linux: don't follow translators set up by + untrusted users by default + <cjuner> antrik, but are legacy programs somehow protected? What about + executing `find`? Or is GNU's find somehow protected from that? + <antrik> cjuner: I'm talking about a global policy + <cjuner> antrik, and who would implement that policy? + <antrik> cjuner: either glibc or the parent translators + +Continued discussion about [[resource_management_problems/pagers]]. diff --git a/open_issues/trust_the_behavior_of_translators.mdwn b/open_issues/trust_the_behavior_of_translators.mdwn new file mode 100644 index 00000000..454c638b --- /dev/null +++ b/open_issues/trust_the_behavior_of_translators.mdwn @@ -0,0 +1,181 @@ +[[!meta copyright="Copyright © 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_hurd]] + +Apart from the issue of [[translators_set_up_by_untrusted_users]], here is +another problem described. + + +# IRC, freenode, #hurd, 2012-02-17 + +(Preceded by the [[memory_object_model_vs_block-level_cache]] discussion.) + + <slpz> what should do Mach with a translator that doesn't clean pages in a + reasonable amount of time? + <slpz> (I'm talking about pages flushed to a pager by the pageout daemon) + <braunr> slpz: i don't know what it should do, but currently, it uses the + default pager + +[[default_pager]]. + + <slpz> braunr: I know, but I was thinking about an alternative, for the + case in which a translator in not behaving properly + <slpz> perhaps freeing the page, removing the map, and letting it die in a + segmentation fault could be an option + <braunr> slpz: what if the translator can't do it properly because of + system resource exhaustion ? + <braunr> (i.e. it doesn't have enough cpu time) + <slpz> braunr: that's the biggest question + <slpz> let's suppose that Mach selects a page, sends it to the pager for + cleaning it up, reinjects the page into the active queue, and later it + founds the page again and it's still dirty + <slpz> but it needs to free some pages because memory it's really, really + scarce + <slpz> Linux just sits there waiting for I/O completion for that page + (trusts its own drivers) + <slpz> but we could be dealing with rogue translator... + <braunr> yes + <braunr> we may need some sort of "authentication" mechanism for pagers + <braunr> so that "system pagers" are trusted and others not + <braunr> using something like the device master port but for pagers + <braunr> a special port passed to trusted pagers only + <slpz> hum... that could be used to workaround the untrusted translator + crossing problem while walking a directory tree + +[[translators_set_up_by_untrusted_users]]. + + <slpz> but I think differentiating between trusted and untrusted + translators was rejected for philosophical reasons + <slpz> (but I'm not sure) + <mcsim> slpz: probably there should be something like oom killer? + <mcsim> braunr: even if translator is trusted it could have a bug which + make it ask more and more memory, so system have something to do with + it. Also, this way TCB is increased, so providing port for trusted + translators may hurt security. + <mcsim> I've read that Genode has "guarded allocators" which help resource + accounting by limiting of memory that could be used. Probably something + like this could be used in Hurd to limit translators. + <antrik> I don't remember how Viengoos deals with this :-( + +[[microkernel/Viengoos]]. + + <braunr> mcsim: the main feature lacking in mach is resource accounting :p + +[[resource_management_problems]]. + + <slpz> mcsim: yes, I think there should be a Hurdish oom killer, paying + special attention to external pagers + +[[microkernel/mach/external_pager_mechanism]]. + + <braunr> the oom killer selects untrusted processes by definition (since + pagers are in kernel) + <mcsim> slpz: and what is better: oom killer or resource accounting? + <mcsim> Under resource accounting I mean mechanism when process can't get + more resources than it is allowed. + <braunr> resource accounting of course + <braunr> but it's not just about that + <braunr> really, how does the kernel deal when a pager refuses to honor a + paging request ? + <braunr> whether it is buggy or malicious + <braunr> is it really possible to keep all pagers out of the TCB ? + <antrik> mcsim: we definitely want proper resource accounting in the long + run. the question is how to deal with the situation that resources are + reallocated to other tasks, so some pages have to be freed + <antrik> I really don't remember how Neal proposed to deal with this + <slpz> mcsim: Better: resource accounting (in which resources are accounted + to the user tasks which are requesting them, as in the Viengoos + model). Good enough an realistic: oom killer + <antrik> I'm not sure an OOM killer for non-system pagers is terribly + helpful. in typical use, the vast majority of paging is done by trusted + pagers... + <antrik> and without proper client resource accounting, there are enough + other ways a rogue/broken process can eat system resources -- I'm not + convinced that untrusted pagers have a major impact on the overall + situation + <mcsim> If pager can't free resources because of lack, for example, of cpu + time it's priority could be increased to give it second chance to free + the page. But if it doesn't manage to free resources it could be killed. + <antrik> I think the current approach with default pager taking over is + good enough for dealing with untrusted pagers. the real problem are even + trusted pager frequently failing to deal with the requests + <braunr> i agree with antrik + <braunr> and i'm opposed to an oom killer + <braunr> it's really not a proper fix for our problems + <braunr> mcsim: what if needs 3 attempts before succeeding ? + <braunr> +it + <braunr> and increasing priority without a good reason (e.g. no priority + inversion) leads to unfairness + <braunr> we don't want to deal with tricky problems like malicious pagers + using that to starve other tasks + <mcsim> braunr: this is just temporary decision (for example for half of + second of user time), to increase probability that task was killed not + because of it lacked resources. + <braunr> mcsim: tunables should only affect the efficiency of an operation, + not its success + + +## IRC, freenode, #hurd, 2012-02-19 + + <antrik> neal: the specific question is how to ensure processes free memory + fast enough when their allocation becomes lower due to resource pressure + <neal> antrik: you can't really. + <neal> antrik: the memory manager can act on the application's behalf if + the application marks pages as discardable or pagable. + <neal> antrik: if the memory manager makes an upcall to the application to + free some memory and it doesn't, you have to penalize it. + <neal> antrik: You shouldn't the process like exokernel + <neal> antrik: It's the developers fault, not the user's + <neal> antrik: What you need are controls that ensure that the user stays + in control + <neal> ...shouldn't *kill* the process... + <antrik> neal: well, how can I penalize a process that eats to much + physical memory? + <neal> in the future, you don't give it as much slack memory + <antrik> marking as pagable means a system pager will push them to the swap + partition? + <antrik> ah, OK + <neal> yes + <neal> and you page it more aggressively, i.e., you don't give it a chance + to free memory + <neal> The situation is: + <neal> you have memory pressure + <neal> you choose a victim process and ask it to free memory + <neal> now, you need to wait + <neal> if you wait and it doesn't free memory, you give it bad karma + <neal> if you wait and it frees memory, you're good + <neal> but during that window, a bad process can delay recovery + <neal> so, in the future, we give bad processes less time + <neal> but, we still send a message asking it to free memory + <neal> we just hope it was a bug + <antrik> so the major difference to the approach we have in Mach is that + instead of just redeclaring some pages as anonymous memory that will be + paged to swap by the default pager eventually if the pager in question + fails to handle them properly, we wait some time for the process to free + (any) memory, and only then start paging out some of it's pages to swap + <neal> there's also discardable memory + <antrik> hm... there is some notion of "precious" pages in Mach... I wonder + whether that is also used to decide about discarding pages instead of + pushing them to swap? + <neal> antrik: A precious page is ro data that shouldn't be dropped + <antrik> ah + <antrik> but I guess that means non-precious RO data (such as a cache) can + be dropped without asking the pager, right? + <neal> yes + <antrik> I wonder whether such a karma system can be introduced in Mach as + well to deal with problematic pagers + + +## IRC, freenode, #hurd, 2012-02-21 + + <neal> antrik: One of the main differences between Mach and Viengoos is + that in Mach servers are responsible for managing memory whereas in + Viengoos applications are primarily responsible for managing memory. diff --git a/open_issues/tty_activitiy_vs_disk_io.mdwn b/open_issues/tty_activitiy_vs_disk_io.mdwn new file mode 100644 index 00000000..26382d56 --- /dev/null +++ b/open_issues/tty_activitiy_vs_disk_io.mdwn @@ -0,0 +1,81 @@ +[[!meta copyright="Copyright © 2011 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_hurd]] + +IRC, freenode, #hurd, 2011-07-25 + + < youpi> Mmm, typing something on the mach console triggers a write on the + disk + < youpi> because the /dev/console node gets updated + < youpi> I don't really see why + < youpi> (yes, just typing at the bash prompt, not even running something) + < youpi> typing during the sleep command (i.e. mere tty echo) doesn't + trigger it, however + < youpi> running bash's echo does trigger it + < braunr> during sleep, the glibc stream functions handle I/O, while with + bash, its readline takes care of it, right ? + < youpi> /bin/echo too + < youpi> during sleep it's the tty process which handles I/O + < braunr> the write may be due to a write time update on the inode + < braunr> modification* time + < youpi> probably yes, but how so? + < youpi> ext2fs is only supposed to pass the thing to the console + translator + < braunr> not sure + < youpi> actually, ext2fs even isn't supposed to come into play when it's + about typing at the bash prompt + < youpi> once it's opened, isn't the port for /dev/console supposed to be + directly to the translator there? + < braunr> i think so + < youpi> (s/tty/term/ in what I said) + < braunr> well, it's certain + < youpi> so I don't see how ext2fs can be triggered to write an atime or + mtime + < braunr> what does rpctrace say ? + < youpi> io_read_request and io_write_request + < youpi> braunr: it doesn't happen at the login prompt + < youpi> interestingly, atime is always 3-4 secs earlier than ctime & mtime + < youpi> doesn't happen with dash + < braunr> we should implement relatime and experiment with it + < braunr> it shouldn't be hard + < youpi> well, there's noatime already + < youpi> but my point is that this update shouldn't happen + < youpi> and I believe it's the source of the i_file_acl e2fsck warning + < braunr> i wasn't saying that concerning this problem, it was just a + separate idea (noatime is more problematic than relatime) + < braunr> and i agree, it shouldn't happen :) + < youpi> ok, it's set_node_times which gets called + +IRC, freenode, #hurd, 2011-07-27 + + < antrik> BTW, I'm not sure it's still relevant; but the reason accessing + translators such as the console modifies the underlying node is that most + stat information is generally passed through + < antrik> (in some cases it might be unintentional though, simply using the + default implementation from trivfs carelessly...) + < youpi> I know + < youpi> I've seen that in the code + < antrik> OK + < youpi> it is still relevant: I still find it useless to write it on the + disk + < youpi> though w uses it to show idle time over reboot + < braunr> is it useful to keep the information across reboots ? + < youpi> for some value of "useful" for w + < braunr> i wonder what would break if this was entierly kept in memory + < youpi> nothing, probably + < youpi> note that it doesn't overload ext2fs so much, it just adds a write + every ~5s + < youpi> (at worse, i.e. when keeping showing text, for instance) + < braunr> indeed, the behaviour seems the same on linux + < antrik> ah... that explains why the disk doesn't spin down while IRC is + active... always wondered about that :-) + < youpi> that's not very power-saving, yes + < youpi> well, we might want to put /dev on ram someday diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn new file mode 100644 index 00000000..dd1e465c --- /dev/null +++ b/open_issues/unit_testing.mdwn @@ -0,0 +1,94 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +This task may be suitable for [[community/GSoC]]: +[[community/gsoc/project_ideas/testing_framework]] + +--- + +A collection of thoughts with respect to unit testing. + +We definitely want to add unit test suites to our code base. + +We should select a tool that we like to use, and that is supported (not +abandoned). + + * [SC + Test](http://web.archive.org/web/20021204193607/sc-archive.codesourcery.com/sc_test) + + * [DejaGnu](http://www.gnu.org/software/dejagnu/) / + [Expect](http://expect.nist.gov/) + + * used by the [[GCC testsuite|gcc]], [[GDB testsuite|gdb]], + [[binutils testsuite|binutils]], etc. + + * The [[glibc testsuite|glibc]] has a home-grown system (Makefile-based), + likewise does the [[Open_POSIX_Test_Suite]]. + + * [Kyua](http://code.google.com/p/kyua/) (and its predecessor [ATF](http://www.NetBSD.org/~jmmv/atf/)). + + * Primarily used by NetBSD as its testing framework; FreeBSD is in the process of adopting it. + + * Provides bindings to write tests in C, C++ and POSIX shell. Lua is planned. + + * Builds and runs on many different Unix-based operating systems. + + * [check](http://check.sourceforge.net/) + + * used by some GNU packages, for example GNU PDF (Jose E. Marchesi) + + * CodeSourcery's [QMTest](http://www.codesourcery.com/qmtest) + + * useb by? + + * documentation: + + * <http://www.codesourcery.com/public/qmtest/whitepaper.pdf> + + * <http://www.python.org/workshops/2002-02/papers/01/index.htm> + + * <http://gcc.gnu.org/ml/gcc/2002-05/msg01978.html> + + * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/tutorial/index.html> + + * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/manual/index.html> + + * [Git](http://git-scm.com/) has an elaborate unit testsuite, which is also + used in [Notmuch](http://notmuchmail.org/). + + * [*[ANNOUNCE] ktest.pl: Easy and flexible testing script for Linux Kernel + Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt, + 2010-10-28. [v2](http://lwn.net/Articles/414064/), 2010-11-08. + + * <http://autotest.kernel.org/wiki/WhitePaper> + + +# Related + + * [[nightly_builds]] + + * [[nightly_builds_deb_packages]] + + * <http://www.phoronix-test-suite.com/> -- ``comprehensive testing and + benchmarking platform''. This one might be useful for [[performance]] + testing, too? + + * <http://ltp.sourceforge.net/> + + * [LaBrea](https://github.com/dustin/labrea/wiki), or similar tools can be + used for modelling certain aspects of system behavior (long response times, + for example). + + +# Discussion + +See the [[GSoC project idea|community/gsoc/project_ideas/testing_framework]]'s +[[discussion +subpage|community/gsoc/project_ideas/testing_framework/discussion]]. diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn new file mode 100644 index 00000000..25168fce --- /dev/null +++ b/open_issues/user-space_device_drivers.mdwn @@ -0,0 +1,208 @@ +[[!meta copyright="Copyright © 2009, 2011, 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_gnumach open_issue_hurd]] + +This is a collection of resources concerning *user-space device drivers*. + +Also see [[device drivers and IO systems]]. +[[community/gsoc/project ideas/driver glue code]]. + +[[!toc levels=2]] + + +# Issues + +## IRQs + + * Can be modeled using [[RPC]]s. + + * Security considerations: IRQ sharing. + + * *Omega0* paper defines an interface. + + * As is can be read in the *Mach 3 Kernel Principles*, there is an *event + object* facility in Mach that can be used for having user-space tasks react + to IRQs. However, at least in GNU Mach, that code (`kern/eventcount.c`) + doesn't seem functional at all and isn't integrated properly in the kernel. + + * IRC, freenode, #hurd, 2011-07-29 + + < antrik> regarding performance of userspace drivers, there is one + thing that really adds considerable overhead: interrupt + handling. whether this is relevant very much depends on the hardware + in question. when sending many small packets over gigabit ethernet, + it might be noticable; in most other cases it's irrelevant + < youpi> some cards support interrupt coalescin + < youpi> could be supported by DDE too + +## DMA + + * Security considerations. + + * I/O MMU. + +## I/O Ports + + * Security considerations. + +## PCI and other buses + + * Security considerations: sharing. + +## Latency of doing RPCs + + * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when + doing RPC calls. + +## System Boot + +### IRC, freenode, #hurd, 2011-07-27 + + < braunr> btw, was there any formulation of the modifications required to + have disk drivers in userspace ? + < braunr> (which would obviously need something like + initrd/initramfs/whatever and may also need the root file system not to + be the first task started) + < braunr> hm actually, we may not need initrd + < braunr> the boot loader could just load more modules + < antrik> braunr: I have described all that in my thesis report... in + German :-( + < braunr> and the boot scripts could be adjusted to pass around the right + ports + < Tekk_> braunr: yeah, we could probably load a module that kciks us into + userspace and starts the disk driver + < braunr> modules are actualy userspace executables + < Tekk_> ah + < Tekk_> so what's the issue? + < Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce + < braunr> change the file systems to tell them which underlying disk driver + to use + < Tekk_> mhm + < braunr> s/disk/storage/ + +### IRC, freenode, #hurd, 2012-04-25 + + <youpi> btw, remember the initrd thing? + <youpi> I just came across task.c in libstore/ :) + + +# Plan + + * Examine what other systems are doing. + + * L4 + + * Hurd on L4: deva, fabrica + + * [[/DDE]] + + * Minix 3 + + * Start with a simple driver and implement the needed infrastructure (see + *Issues* above) as needed. + + * <http://savannah.nongnu.org/projects/user-drivers/> + + Some (unfinished?) code written by Robert Millan in 2003: PC keyboard + and parallel port drivers, using `libtrivfs`. + + +# Documentation + + * [An Architecture for Device Drivers Executing as User-Level + Tasks](http://portal.acm.org/citation.cfm?id=665603), 1993, David B. Golub, + Guy G. Sotomayor, Freeman L. Rawson, III + + * [Performance Measurements of the Multimedia Testbed on Mach 3.0: Experience + Writing Real-Time Device Drivers, Servers, and + Applications](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8685), + 1993, Roger B. Dannenberg, David B. Anderson, Tom Neuendorffer, Dean + Rubine, Jim Zelenka + + * [User Level IPC and Device Management in the Raven + Kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.3733), + 1993, D. Stuart Ritchie, Gerald W. Neufeld + + * [Creating User-Mode Device Drivers with a + Proxy](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.3055), + 1997, Galen C. Hunt + + * [The APIC Approach to High Performance Network Interface Design: Protected + DMA and Other + Techniques](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1198), + 1997, Zubin D. Dittia, Guru M. Parulkar, Jerome R. Cox, Jr. + + * [The Fluke Device Driver + Framework](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.7927), + 1999, Kevin Thomas Van Maren + + * [Omega0: A portable interface to interrupt hardware for L4 + system](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.5958), + 2000, Jork Löser, Michael Hohmuth + + * [Userdev: A Framework For User Level Device Drivers In + Linux](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4461), + 2000, Hari Krishna Vemuri + + * [User Mode Drivers](http://www.linuxjournal.com/article/5442), 2002, Bryce + Nakatani + + * [Towards Untrusted Device + Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.1725), + 2003, Ben Leslie, Gernot Heiser + + * [Encapsulated User-Level Device Drivers in the Mungi Operating + System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.1531), + 2004, Ben Leslie Nicholas, Nicholas FitzRoy-Dale, Gernot Heiser + + * [Linux Kernel Infrastructure for User-Level Device + Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.1408), + 2004, Peter Chubb + + * [Get More Device Drivers out of the + Kernel!](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6333), + 2004, Peter Chubb + + * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers> + + * [Initial Evaluation of a User-Level Device + Driver](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.4531), + 2004, Kevin Elphinstone, Stefan Götz + + * [User-level Device Drivers: Achieved + Performance](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6766), + 2005, Ben Leslie, Peter Chubb, Nicholas FitzRoy-Dale, Stefan Götz, Charles + Gray, Luke Macpherson, Daniel Potts, Yueting Shen, Kevin Elphinstone, + Gernot Heiser + + * [Virtualising + PCI](http://www.ice.gelato.org/about/oct06_presentations.php#pres14), 2006, + Myrto Zehnder, Peter Chubb + + * [Microdrivers: A New Architecture for Device + Drivers](http://www.cs.rutgers.edu/~vinodg/papers/hotos2007/), 2007, Vinod + Ganapathy, Arini Balakrishnan, Michael M. Swift, Somesh Jha + + * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.2623> + [[!tag open_issue_documentation]] + + * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.2170> + [[!tag open_issue_documentation]] + + +# External Projects + + * [[/DDE]] + + * <http://ertos.nicta.com.au/research/drivers/uldd/> + + * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers> diff --git a/open_issues/viengoos_make_clean.mdwn b/open_issues/viengoos_make_clean.mdwn new file mode 100644 index 00000000..af2920e7 --- /dev/null +++ b/open_issues/viengoos_make_clean.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 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_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge: If I do a make clean n the root directory, follow that with a configure, configure fails with: configure: error: C compiler cannot create executables + <neal> this is in config.log: /home/neal/src/hurd-l4/build/lib/gcc/i686-pc-viengoos-gnu/4.2.2/../../../../i686-pc-viengoos-gnu/bin/ld: cannot find -lc + <neal> rt + <tschwinge> neal: Should make clean also remove srcdir/gcc/gcc and binutils, as you do it with newlib? + <neal> I'd prefer it not to + <neal> as I use make clean to prep the tree for new configure changes + <neal> and build gcc takes a long time + <neal> (as does newlib, but newlib in this case needs to be rebuilt) diff --git a/open_issues/viengoos_tls_gcc.mdwn b/open_issues/viengoos_tls_gcc.mdwn new file mode 100644 index 00000000..92499903 --- /dev/null +++ b/open_issues/viengoos_tls_gcc.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 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_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge : I'm trying to enable tls for viengoos. This requires compiling gcc with --enable-tls, which enables threading, which pulls in libpthread, which requires newlib headers. + <neal> tschwinge : Unfortunately, I don't see how to install the newlib headers without having gcc + <neal> tschwinge : Have you got any ideas? diff --git a/open_issues/virtual_square_view-os.mdwn b/open_issues/virtual_square_view-os.mdwn new file mode 100644 index 00000000..dcc98785 --- /dev/null +++ b/open_issues/virtual_square_view-os.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +All the following is based only on a first, and quick glance only. + +We may want to have a look at Virtual Square / View-OS, and evaluate in which +ways this is related / implemented / implementable / usable / useful in a Hurd +environment, and even ;-) strive to collaborate with them. + +[[I|tschwinge]] found this project very much by chance: on LinkedIn, they +posted a proposal for [DevRoom on Virtualization +Technologies](http://www.linkedin.com/groupItem?view=&gid=27213&type=member&item=31720076) +for [[community/meetings/FOSDEM_2011]]. LinkedIn sends out such posts in very +opaque emails from time to time (probably they'd look less opaque with a HTML +mail user agent), and I even bothered to have a look at it, and follow the link +to the web page, and not delete it straightway. + +So, I had a quick look at the project: + +This seems to be an amalgamation / combination of various virtualization +mechanisms / projects / ideas. Virtualization is here meant in a broad sense, +including file system namespaces: our `chroot` / `settrans --chroot`; +networking configurations: our pfinet override stuff; system configuration: +subhurds?; current time, devices: likewise?; executable interpreter: our exec +server override stuff; "stat" virtualization: fakeroot; etc. -- They seem to +do a lot of stuff that we also try to do / could do / can do. + +In fact, this looks a bit like they're trying to bring some more of the Hurd's +[[hurd/concepts]] over to Unix / Linux, more than only the *usual VFS stuff* +(translators / FUSE). + +Perhaps start reading with the *slides* linked below. + + * <http://virtualsquare.org/> + + * <http://wiki.virtualsquare.org/> + + * <http://sourceforge.net/projects/view-os/> + + * Renzo Davoli, [*Virtual + Square*](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.9106), + 2005 + + * Renzo Davoli, Michael Goldweber, [*View-OS: Change your View on + Virtualization*](http://www.cs.unibo.it/~renzo/view-os-lk2009.pdf), + Proc. of Linux Kongress, 2009 + + * [slides](http://www.cs.unibo.it/~renzo/view-os-lk2009-slides.pdf) diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn new file mode 100644 index 00000000..9440284f --- /dev/null +++ b/open_issues/virtualbox.mdwn @@ -0,0 +1,99 @@ +[[!meta copyright="Copyright © 2011 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_gnumach]] + +Running GNU Mach in VirtualBox crashes during initialization. + +IRC, freenode, #hurd, 2011-08-15 + + <BlueT_> HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once + you see the Grub menu, turn off the debian hurd box. 3) Let the box boot + normally, and wait for the error/crash/reboot. 4) The error/crash will + happen twice and it's reboot automatically. The 3rd boot will success. + + <BlueT_> root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54 + <BlueT_> copyoutmsg + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:1289 + <BlueT_> exec_load + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/elf-load.c:80 + <BlueT_> user_bootstrap + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:756 + + i386/i386/locore.S:1289 is + + movl $USER_DS,%eax /* use user data segment for accesses */ + => mov %ax,%es + + State is + + cs: 0x8 + ds: 0x10 + es: 0x10 + fs: 0 + gs: 0 + ss: 0x10 + eax: 0x1f + ecx: 0x8048000 + edx: 0x15fb7f + ebx: 0x1001000 + esp: 0x75e47e08 + ebp: 0x75e47e6c + esi: 0x1002000 + edi: 0x8048000 + eip: 0x106c93 + efl: 0x10206 + + <youpi> oh, wait, it's not even the data access which poses problem + <youpi> but the use of $USER_DS + <youpi> ew + <youpi> looks like a gdt initialization emulation issue in virtualbox... + + + <BlueT_> just found that at the second crash, the address is different + <BlueT_> 2nd time: + <BlueT_> addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x1068bd 0x152c74 + <BlueT_> _kret_popl_es + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:527 + <BlueT_> user_bootstrap + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:765 + + i386/i386/locore.S:527 is: + + _return_from_kernel: + _kret_popl_gs: + popl %gs /* restore segment registers */ + _kret_popl_fs: + popl %fs + _kret_popl_es: + => popl %es + _kret_popl_ds: + + cs: 0x8 + ds: 0x10 + es: 0x10 + fs: 0 + gs: 0 + ss: 0x10 + eax: 0x106c95 + ecx: 0x6aab096c + edx: 0x106cec + ebx: 0x75e47f04 + esp: 0x75e47f0c + ebp: 0x75e47fac + esi: 0x75e47f8c + edi: 0x7fffff3c + eip: 0x1068bd + efl: 0x10216 + + <youpi> looks again like a $USER_DS issue + <youpi> what's interesting is that that one means that $USER_DS did load in + %es fine at least once + <youpi> and it's the reload that fails diff --git a/open_issues/virtualization.mdwn b/open_issues/virtualization.mdwn new file mode 100644 index 00000000..343f624a --- /dev/null +++ b/open_issues/virtualization.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +An index of things to work on w.r.t. virtualization. + + * [[/virtualization]] + + * [[hurd/virtualization|hurd/virtualization]] + + * [[GSoC project proposal|community/gsoc/project_ideas/virtualization]] + + * [[hurd/subhurd]] / [[hurd/neighborhurd]] + +<!-- + + * There's talking about *collectives* in the Hurd RM, on [[/advantages]] and + [[unsorted/hurd-migr]] ([[!taglink open_issue_documentation]]). + +--> + + * [[Implementing_Hurd_On_Top_of_Another_System]] + + * Unix / Linux + + * [[Capsicum]] + + * [[Virtual_Square_View-OS]] + + * [Namespace file descriptors](http://lwn.net/Articles/407495/), + 2010-09-29 + + * [Divorcing namespaces from + processes](http://lwn.net/Articles/377109/), 2010-03-03 + + * [[File_Systems]] + + * [[Networking]] diff --git a/open_issues/virtualization/capsicum.mdwn b/open_issues/virtualization/capsicum.mdwn new file mode 100644 index 00000000..44503e34 --- /dev/null +++ b/open_issues/virtualization/capsicum.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +*Capsicum - practical capabilities for UNIX* + +<http://www.cl.cam.ac.uk/research/security/capsicum/> + +<http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/> +(server disappeared; [Google +cache](http://webcache.googleusercontent.com/search?q=cache:cCAqjWOhhksJ:www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/)) + +<http://lackingrhoticity.blogspot.com/2010/10/process-descriptors-in-freebsd-capsicum.html> + +<http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811-usenix-capsicum.pdf> +/ <http://www.youtube.com/watch?v=raNx9L4VH2k> diff --git a/open_issues/virtualization/file_systems.mdwn b/open_issues/virtualization/file_systems.mdwn new file mode 100644 index 00000000..a12ea10d --- /dev/null +++ b/open_issues/virtualization/file_systems.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +Of course, it is possible to use commodity file systems on [[virtualized +systems|virtualization]], like [[hurd/translator/ext2fs]] or +[[hurd/translator/nfs]], but there are also other possibilities which ought to +be explored. + + * [[network_file_system_by_just_forwarding_RPCs]] + + * Linux saw a patch for [*generic name to handle and open by handle + syscalls*](http://thread.gmane.org/gmane.linux.file-systems/46648) posted, + which in turn can be beneficial for a [[QEMU]] emulation of a 9P file + system. LWN's Jonathan Corbet covered this [*open by + handle*](http://lwn.net/Articles/375888/) functionality on 2010-02-23. diff --git a/open_issues/virtualization/networking.mdwn b/open_issues/virtualization/networking.mdwn new file mode 100644 index 00000000..7a6474a1 --- /dev/null +++ b/open_issues/virtualization/networking.mdwn @@ -0,0 +1,30 @@ +[[!meta copyright="Copyright © 2010 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_hurd]] + +Collection about stuff that is relevant for *virtualization* and *networking*. + + * [[Virtual_Square_View-OS]] + + * [*Virtual Networks*](http://virtualsquare.org/vn.html) + + * [User Level Networking](http://uln.sourceforge.net/) + + * [Virtual Distributed Ethernet](http://vde.sourceforge.net/) + + * [Application Level + Environment4Networking](http://sourceforge.net/projects/ale4net/) + + *Ale4NET used dyn library call diversion to define networking at process + level.* -- what we're doing with our approach for overriding the default + [[hurd/translator/pfinet]] by setting environment variables. + + Project is now part of [[Virtual_Square_View-OS]]. diff --git a/open_issues/wayland.mdwn b/open_issues/wayland.mdwn new file mode 100644 index 00000000..67f78b1d --- /dev/null +++ b/open_issues/wayland.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 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_porting]] + +IRC, freenode, #hurd, 2012-03-18: + + <antrik> Wayland should be very portable. all the system dependencies are + in the infrastructure, such as DRI + <antrik> we have had a DRI task (for X.Org) for years + <antrik> (in fact I would be the right person to implement this, + considering my background -- by quite frankly, I doubt I'll ever do it) + <tschwinge> http://xorg.freedesktop.org/wiki/Hurd_Porting + +IRC, freenode, #hurd, 2012-03-20: + + <youlysses> Is wayland something that will be semi-easy to port to the + hurd? I saw GNOME is heading in this direction. + <pinotree> wayland at the moment is linux only + <tschwinge> youlysses: A DRI implementation will be needed. + <pinotree> that, and libdrm compiling + <youlysses> So it will take some work ... but theres no *HUGE* design + decison that would inhibit it? + <pinotree> i know it uses epoll, for instance + <tschwinge> youlysses: I cannot judge how complex a DRI system is, and how + much needs to be designed vs. implemented. diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn new file mode 100644 index 00000000..65e6c584 --- /dev/null +++ b/open_issues/wine.mdwn @@ -0,0 +1,69 @@ +[[!meta copyright="Copyright © 2010, 2011 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_porting]] + +On 2010-11-28, Austin English contacted us, stating that he's working on +porting [Wine](http://winehq.org/) to the GNU/Hurd. + +It is not yet clear how difficult this is going to be, what sort of +requirements Wine has: only libc / POSIX / etc., or if there are +*advanced* things like [[system_call]] trapping involved, too. + +[[Samuel|samuelthibault]] suspects that *there's some need for LDT table +allocation. There is kernel support for this,* however. + + +IRC, freenode, #hurd, 2011-08-11 + + < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM, + and to that end, I've successfully compiled the latest sources from Git + after installing the libc (devel) packages from experimental and + personally patching Wine with http://pastebin.com/rg6dx09G + +[[rg6dx09G.patch]] + + < arethusa> my question is, when trying to launch Wine, I'm seeing "wine + client error:0: sendmsg: (os/kern) invalid address" from the client side, + whereas the wineserver seems to be starting and running correctly, how + could I debug this issue further? using rpctrace doesn't seem to help, as + the trace just hangs when run on the Wine loader instead of yielding + insight + < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when + wine encounters an error or something like that ? + < arethusa> it's too early for that + < kilobug> or least give you a full traceback of the wine code where the + error occur ? + < arethusa> the error is happening during initial connect to the + wineserver, in dlls/ntdll/server.c + < arethusa> but that doesn't help me figure out why sendmsg would error out + in this way + < arethusa> + http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361 + < azeem_> arethusa: probably some of the msghdr entries are not supported + by the Hurd's glib + < azeem_> c + < pinotree> haha, socket credentials, which we don't support yet + < azeem_> yep + < pinotree> youpi: ↑ another case ;) + < azeem_> arethusa: just implement those and it should work + < kilobug> in pflocal ? or glibc ? + < pinotree> pflocal + < arethusa> azeem_: hmm, okay, thanks + < pinotree> arethusa: their lack is a known issue, and makes things like + dbus and gamin not work + < arethusa> it's + https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and + related links I assume? + +[[sendmsg_scm_creds]] + + < youpi> yes + < pinotree> (but that patch is lame) diff --git a/open_issues/wine/rg6dx09G.patch b/open_issues/wine/rg6dx09G.patch new file mode 100644 index 00000000..510ff23f --- /dev/null +++ b/open_issues/wine/rg6dx09G.patch @@ -0,0 +1,116 @@ +diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c
+index 42b3639..7484608 100644
+--- a/dlls/ntdll/directory.c
++++ b/dlls/ntdll/directory.c
+@@ -3145,14 +3145,14 @@ static void WINAPI read_changes_user_apc( void *arg, IO_STATUS_BLOCK *io, ULONG
+ static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc )
+ {
+ struct read_changes_info *info = user;
+- char data[PATH_MAX];
++ char data[4096];
+ NTSTATUS ret;
+ int size;
+
+ SERVER_START_REQ( read_change )
+ {
+ req->handle = wine_server_obj_handle( info->FileHandle );
+- wine_server_set_reply( req, data, PATH_MAX );
++ wine_server_set_reply( req, data, 4096 );
+ ret = wine_server_call( req );
+ size = wine_server_reply_size( reply );
+ }
+diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c
+index 6c8e8e2..e949227 100644
+--- a/dlls/ntdll/signal_i386.c
++++ b/dlls/ntdll/signal_i386.c
+@@ -180,6 +180,36 @@ __ASM_GLOBAL_FUNC(vm86_enter,
+
+ #endif /* linux */
+
++#ifdef __GNU__
++
++typedef ucontext_t SIGCONTEXT;
++
++#define EAX_sig(context) ((context)->uc_mcontext.gregs[REG_EAX])
++#define EBX_sig(context) ((context)->uc_mcontext.gregs[REG_EBX])
++#define ECX_sig(context) ((context)->uc_mcontext.gregs[REG_ECX])
++#define EDX_sig(context) ((context)->uc_mcontext.gregs[REG_EDX])
++#define ESI_sig(context) ((context)->uc_mcontext.gregs[REG_ESI])
++#define EDI_sig(context) ((context)->uc_mcontext.gregs[REG_EDI])
++#define EBP_sig(context) ((context)->uc_mcontext.gregs[REG_EBP])
++#define ESP_sig(context) ((context)->uc_mcontext.gregs[REG_ESP])
++
++#define CS_sig(context) ((context)->uc_mcontext.gregs[REG_CS])
++#define DS_sig(context) ((context)->uc_mcontext.gregs[REG_DS])
++#define ES_sig(context) ((context)->uc_mcontext.gregs[REG_ES])
++#define SS_sig(context) ((context)->uc_mcontext.gregs[REG_SS])
++#define FS_sig(context) ((context)->uc_mcontext.gregs[REG_FS])
++#define GS_sig(context) ((context)->uc_mcontext.gregs[REG_GS])
++
++#define EFL_sig(context) ((context)->uc_mcontext.gregs[REG_EFL])
++#define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP])
++#define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO])
++#define ERROR_sig(context) ((context)->uc_mcontext.gregs[REG_ERR])
++
++#define FPU_sig(context) ((FLOATING_SAVE_AREA *)&(context)->uc_mcontext.fpregs.fp_reg_set.fpchip_state)
++#define FPUX_sig(context) NULL
++
++#endif /* __GNU__ */
++
+ #ifdef BSDI
+
+ #include <machine/frame.h>
+diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c
+index 9649df8..cdd1798 100644
+--- a/dlls/shell32/shfldr_unixfs.c
++++ b/dlls/shell32/shfldr_unixfs.c
+@@ -369,7 +369,7 @@ static inline BOOL UNIXFS_is_pidl_of_type(LPCITEMIDLIST pIDL, SHCONTF fFilter) {
+ static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, char *pszCanonicalPath)
+ {
+ char *pPathTail, *pElement, *pCanonicalTail, szPath[FILENAME_MAX], *pszUnixPath, has_failed = 0, mb_path[FILENAME_MAX];
+- WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[PATH_MAX], *dospath_end;
++ WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[MAX_PATH], *dospath_end;
+ int cDriveSymlinkLen;
+ void *redir;
+
+diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c
+index ad8e08b..a8d6329 100644
+--- a/dlls/winex11.drv/xrender.c
++++ b/dlls/winex11.drv/xrender.c
+@@ -2440,8 +2440,8 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE *physDev)
+ return;
+ }
+
+-BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, X11DRV_PDEVICE *devSrc,
+- struct bitblt_coords *dst, struct bitblt_coords *src, BLENDFUNCTION blendfn )
++BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, struct bitblt_coords *dst,
++ X11DRV_PDEVICE *devSrc, struct bitblt_coords *src, BLENDFUNCTION blendfn )
+ {
+ FIXME("not supported - XRENDER headers were missing at compile time\n");
+ return FALSE;
+diff --git a/libs/wine/ldt.c b/libs/wine/ldt.c
+index 3098061..b3fee13 100644
+--- a/libs/wine/ldt.c
++++ b/libs/wine/ldt.c
+@@ -96,6 +96,11 @@ static inline int set_thread_area( struct modify_ldt_s *ptr )
+ #include <i386/user_ldt.h>
+ #endif
+
++#ifdef __GNU__
++#include <mach/i386/mach_i386.h>
++#include <mach/mach_traps.h>
++#endif
++
+ /* local copy of the LDT */
+ #ifdef __APPLE__
+ struct __wine_ldt_copy wine_ldt_copy = { { 0, 0, 0 } };
+@@ -203,6 +208,9 @@ static int internal_set_entry( unsigned short sel, const LDT_ENTRY *entry )
+ #elif defined(__APPLE__)
+ if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) < 0)
+ perror("i386_set_ldt");
++#elif defined(__GNU__)
++ if ((ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry, 1)) != KERN_SUCCESS)
++ perror("i386_set_ldt");
+ #else
+ fprintf( stderr, "No LDT support on this platform\n" );
+ exit(1);
\ No newline at end of file diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn new file mode 100644 index 00000000..558c93b7 --- /dev/null +++ b/open_issues/xattr.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2011, 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]]."]]"""]] + +[[!meta title="xattr: extended attributes"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +This task is listed as a [[Google Summer of Code project +idea|community/gsoc/project_ideas/xattr]]. + +IRC, freenode, #hurd, 2011-06-01: + + <gnu_srs> Another thing: the lsattr and chattr programs seems to be bogus + on Hurd. Are they present since they are part of e2fsprogs? + <youpi> I don't think the Hurd has an interface for it + <tschwinge> gnu_srs, youpi: lsattr/chattr are extended attributes, right? + We do have some patches from years ago for adding some support in glibc, + but they're not yet integrated. And also we do have a plan for using + these instead of our Hurd-specific passive translator information in + inodes. + +If interested in working on this, talk to [[tschwinge]], and see these resources: + + * [[!GNU_Savannah_task 5503]], [[!GNU_Savannah_patch 5126]] + + * <http://lists.gnu.org/archive/html/bug-hurd/2006-02/threads.html#00115>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-01/threads.html#00180>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-05/threads.html#00042> + + * <http://www.spinics.net/lists/linux-ext4/msg07260.html>, + <http://www.spinics.net/lists/linux-ext4/msg07259.html>, + <http://www.spinics.net/lists/linux-ext4/msg07261.html> + + +IRC, OFTC, #debian-hurd, 2012-03-18: + + <pinotree> notes to self: it seems our ext2 driver comes from linux 2.3.42 + or so, and in linux 2.5.46 ext2/ext3 get xattr and acl support diff --git a/open_issues/xen_crash_copy-size_le_page_size.mdwn b/open_issues/xen_crash_copy-size_le_page_size.mdwn new file mode 100644 index 00000000..f2d8081e --- /dev/null +++ b/open_issues/xen_crash_copy-size_le_page_size.mdwn @@ -0,0 +1,104 @@ +[[!meta copyright="Copyright © 2009 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_xen]] + +`/dev/hd2` is 2 GiB in size (backed by LVM), unformatted. + + # mkfs.ext2 -o hurd /dev/hd2 + mke2fs 1.41.7 (29-June-2009) + hd2 count 1 + re-open, hd2 count 2 + ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/hd2 is mounted. + re-open, hd2 count 3 + re-open, hd2 count 4 + re-open, hd2 count 5 + Filesystem label= + OS type: Hurd + Block size=4096 (log=2) + Fragment size=4096 (log=2) + 131072 inodes, 524288 blocks + 26214 blocks (5.00%) reserved for the super user + First data block=0 + Maximum filesystem blocks=536870912 + 16 block groups + 32768 blocks per group, 32768 fragments per group + 8192 inodes per group + Superblock backups stored on blocks: + 32768, 98304, 163840, 229376, 294912 + + Assertion `copy->size <= PAGE_SIZE' failed in file "../gnumach-1-branch-Xen-branch/xen/block.c", line 536 + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006abc1,2006ba03,2006782c,218,2e2be8d4) + 0x20020ace(2006ba03,2006782c,218,2e3629a0,32000) + 0x2003e9d5(2de04764,2e2be0b8,12,0,3fff80) + 0x200476e6(2de5ad54,2e2db010,2e30a9a0,2de3a854,2de5ad44) + 0x20021ed4(2de5ad44,2e2bb2e0,2e2bb2a0,0,0) + 0x2005309d(129b8f0,3,38,28,e) + 0x20006838(129b8f0,3,38,28,e) + >>>>> user space <<<<< + + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x2003e9d5 0x200476e6 0x20021ed4 0x2005309d 0x20006838 + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + Assert + ??:0 + device_write + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/xen/block.c:537 + _Xdevice_write + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/device/device.server.c:253 + ipc_kobject_server + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:201 + mach_msg_trap + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367 + mach_call_call + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083 + +GDB on `mkfs.ext2`: + + raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272 + 272 actual = write(data->dev, buf, size); + (gdb) print size + $4 = 32768 + (gdb) bt + #0 raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272 + #1 0x080635fc in unix_write_blk64 (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:673 + #2 0x0806373c in unix_write_blk (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:705 + #3 0x0805e87d in ext2fs_zero_blocks (fs=0x8082940, blk=524272, num=16, ret_blk=0x15ffb1c, ret_count=0x0) + at ../../../git/lib/ext2fs/mkjournal.c:182 + #4 0x0804ec56 in main (argc=131072, argv=0x80000) at ../../git/misc/mke2fs.c:2032 + +Discussion: + + <tschwinge> I had a look at the code, but unfortunately don't really know + how this data transfers between Xen and the domU work. + <tschwinge> Well, I know how it roughly works, but not the implementation + deatils. + <youpi> well here it's not about the xen/domU transfers + <youpi> it's about copying data to align it + <youpi> i.e. when offset is not aligned, I need to copy it + <tschwinge> Yes- + <youpi> I was lazy, just implemented it for things smaller than a page + <youpi> it just needs to be extended into copying several pages + <tschwinge> youpi: Hmm, do we need to copy all the data to shift away the + offset or is there a better way? + <youpi> the blkbackend needs data to be sector-aligned + <youpi> just aligning on a page makes offset computation simpler + <youpi> as it's rare that's not a problem + <tschwinge> And a sector is the usual 512 bytes there, I assume? + <tschwinge> But then we do need to copy all of it? + <youpi> let me check + <youpi> the sector is the granularity you can't go below + <youpi> sector is the sector_size reported by the backend + <youpi> but for sector_number and first/last_sect it's 512 + <youpi> yes, that's weird diff --git a/open_issues/xen_domu_with_ro_hd.mdwn b/open_issues/xen_domu_with_ro_hd.mdwn new file mode 100644 index 00000000..efbd2d18 --- /dev/null +++ b/open_issues/xen_domu_with_ro_hd.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="Xen domU with a read-only HD"]] + +[[!tag open_issue_xen]] + +read-only hd3 + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 5 + re-open, hd3 count 6 + /dev/hd3 was not cleanly unmounted, check forced. + Pass 1: Checking inodes, blocks, and sizes + Pass 2: Checking directory structure + Pass 3: Checking directory connectivity + Pass 4: Checking reference counts + Pass 5: Checking group summary information + /dev/hd3: 2729/262144 files (0.2% non-contiguous), 34116/524288 blocks + Error writing block 1 (Attempt to write block from filesystem resulted in short write). Ignore error<y>? yes + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 7 + re-open, hd3 count 8 + e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hd3 + Could this be a zero-length partition? diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn new file mode 100644 index 00000000..756abf5e --- /dev/null +++ b/open_issues/xen_lseek.mdwn @@ -0,0 +1,57 @@ +[[!meta copyright="Copyright © 2011 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_xen]] + +IRC, freenode, #hurd, 2011-09-01: + + <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + <youpi> no wonder it's slow + <youpi> unfortunately that's also what it does on linux, the system call is + just less costly + <youpi> apparently gfortran calls io_seek for, like, every token of the + sourced file + <youpi> (fgetpos actually, but that's the same) + <youpi> and it is indeed about 10 times slower under Xen for some reason + +IRC, freenode, #hurd, 2011-11-02: + + <youpi> btw, we have a performance issue with xen + <youpi> an lseek() call costs a huge lot + <youpi> like 1ms + <youpi> while the same costs just a few dozens µs with kvm + <youpi> there's of course the cost of switching between ring3, ring0, + ring1, ring0, ring3, but still + <gianluca> oh, nice. + <youpi> lseek is supposed to perform only a back&forth + <youpi> and I don't observe disk activity, so it's not waiting for the disk + to complete whatever atime change & such :) + <youpi> it was mentioned that perhaps xen in hvm mode with pv drivers would + be faster + <youpi> thanks to the ring3/"1" switching being done by the processor + <youpi> (and assuming npt) + <gianluca> hm + <gianluca> i'll look into that, sounds fun. + <gianluca> :) + <tschwinge> Here is a testcase: + http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html + +[[performance/io_system/binutils_ld_64ksec]]. + +Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]]. + +IRC, freenode, #hurd, 2011-11-05: + + <youpi> [test-mach.c is] mostly as a reference for the trap overhead + <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach + <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek + <youpi> that might simply be an issue in the RPC mechanism, which behaves + badly with the xen memory management + <youpi> yes, about 0.5ms for an lseek, that's quite high :) diff --git a/open_issues/xen_lseek/test-lseek.c b/open_issues/xen_lseek/test-lseek.c new file mode 100644 index 00000000..667dce66 --- /dev/null +++ b/open_issues/xen_lseek/test-lseek.c @@ -0,0 +1,17 @@ +#include <stdio.h> +#include <math.h> +#include <fcntl.h> +#include <unistd.h> +#include <sys/time.h> +#define N 100000 +int main(void) { + int fd = open("test.c", O_RDONLY); + struct timeval tv1, tv2; + int i; + gettimeofday(&tv1, NULL); + for (i = 0; i < N; i++) + lseek(fd, 0, SEEK_CUR); + gettimeofday(&tv2, NULL); + printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); + return 0; +} diff --git a/open_issues/xen_lseek/test-mach.c b/open_issues/xen_lseek/test-mach.c new file mode 100644 index 00000000..90337346 --- /dev/null +++ b/open_issues/xen_lseek/test-mach.c @@ -0,0 +1,19 @@ +#define _GNU_SOURCE +#include <stdio.h> +#include <fcntl.h> +#include <mach/mach.h> +#define N 1000000 +int main(void) { + struct timeval tv1, tv2; + int i; + task_t task; + task = mach_task_self(); + mach_port_urefs_t refs; + gettimeofday(&tv1, NULL); + for (i = 0; i < N; i++) { + mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs); + } + gettimeofday(&tv2, NULL); + printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); + return 0; +} diff --git a/open_issues/xorg_porting.mdwn b/open_issues/xorg_porting.mdwn new file mode 100644 index 00000000..5f540e44 --- /dev/null +++ b/open_issues/xorg_porting.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="X.Org Porting"]] + +[[!tag open_issue_porting]] + +See the list of [Hurd-related X.Org project +ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting). |