More than half of the Debian archive has been compiled successfully on the Hurd, however, many programs fail to build for various reasons.
A list of build failures including error messages can be found, as well as a preliminary analysis of them and solutions, and some more details in guidelines. Graphs and statistics about the consequence in terms of build dependencies are available.
There is a mailing list, debian-hurd-build-logs, where builds logs from the Debian GNU/Hurd autobuilders are posted. It is a high-traffic and high-volume list, and for that reason not archived, so you have to subscribe to see the messages.
It might be a good idea to record your intention to port something either in the list below or in the Alioth task tracker so other people do not do duplicated work.
Also, the ?HurdFr guys maintain their own liste des travaux de packaging.
Aside from the Alioth task tracker, here is a list of some packages (the important ones, as they're, e.g., blocking other packages from being built) that need someone to work on them.
When you have a patch to submit, please adhere to the patch submission guidelines.
There is also further information available about porting.
IRC, OFTC, #debian-hurd, 2012-12-16
<pinotree> http://lists.debian.org/<50CE505F.3040106@pyro.eu.org>
<pinotree> or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679198#123
too
<youpi> ouch, there are quite a few!
<pinotree> most are "duplicated", like the source in webkit2 copies (so
fixing it once upstream will make it fixed progressively once the copies
are upgraded)
<youpi> ah, ok
<pinotree> similar for ruby 1.8/1.9/jruby
IRC, freenode, #hurd, 2012-12-05
<braunr> rbraun 18813 R 2hrs ln -sf ../af_ZA/LC_NUMERIC
debian/locales-all/usr/lib/locale/en_BW/LC_NUMERIC
<braunr> when building glibc
<braunr> is this a known issue ?
<tschwinge> braunr: No. Can you get a backtrace?
<braunr> tschwinge: with gdb you mean ?
<tschwinge> Yes. If you have any debugging symbols (glibc?).
<braunr> or the build log leading to that ?
<braunr> ok, i will next time i have it
<tschwinge> OK.
<braunr> (i regularly had it when working on the pthreads port)
<braunr> tschwinge:
http://www.sceen.net/~rbraun/hurd_glibc_build_deadlock_trace
<braunr> youpi: ^
<youpi> Mmm, there's not so much we can do about this one
<braunr> youpi: what do you mean ?
<youpi> the problem is that it's really a reentrency issue of the libc
locale
<youpi> it would happen just the same on linux
<braunr> sure
<braunr> but hat doesn't mean we can't report and/or fix it :)
<youpi> (the _nl_state_lock)
<braunr> do you have any workaround in mind ?
<youpi> no
<youpi> actually that's what I meant by "there's not so much we can do
about this"
<braunr> ok
<youpi> because it's a bad interaction between libfakeroot and glibc
<youpi> glibc believe fxtstat64 would never call locale functions
<youpi> but with libfakeroot it does
<braunr> i see
<youpi> only because we get an EAGAIN here
<braunr> but hm, doesn't it happen on linux ?
<youpi> EAGAIN doesn't happen on linux for fxstat64, no :)
<braunr> why does it happen on the hurd ?
<youpi> I mean for fakeroot stuff
<youpi> probably because fakeroot uses socket functions
<youpi> for which we probably don't properly handleEAGAIN
<youpi> I've already seen such kind of issue
<youpi> in buildd failures
<braunr> ok
<youpi> (so the actual bug here is EAGAIN
<youpi> )
<braunr> yes, so we can do something about it
<braunr> worth a look
<pinotree> (implement sysv semaphores)
<youpi> pinotree: if we could also solve all these buildd EAGAIN issues
that'd be nice :)
<braunr> that EAGAIN error might also be what makes exim behave badly and
loop forever
<youpi> possibly
<braunr> i've updated the trace with debugging symbols
<braunr> it fails on connect
<pinotree> like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563342 ?
<braunr> it's EAGAIN, not ECONNREFUSED
<pinotree> ah ok
<braunr> might be an error in tcp_v4_get_port
IRC, freenode, #hurd, 2012-12-06
<braunr> hmm, tcp_v4_get_port sometimes fails indeed
<gnu_srs> braunr: may I ask how you found out, adding print statements in
pfinet, or?
<braunr> yes
<gnu_srs> OK, so that's the only (easy) way to debug.
<braunr> that's the last resort
<braunr> gdb is easy too
<braunr> i could have added a breakpoint too
<braunr> but i didn't want to block pfinet while i was away
<braunr> is it possible to force the use of fakeroot-tcp on linux ?
<braunr> the problem seems to be that fakeroot doesn't close the sockets
that it connected to faked-tcp
<braunr> which, at some point, exhauts the port space
<pinotree> braunr: sure
<pinotree> change the fakeroot dpkg alternative
<braunr> ok
<pinotree> calling it explicitly `fakeroot-tcp command` or
`dpkg-buildpackage -rfakeroot-tcp ...` should work too
<braunr> fakeroot-tcp looks really evil :p
<braunr> hum, i don't see any faked-tcp process on linux :/
<pinotree> not even with `fakeroot-tcp bash -c "sleep 10"`?
<braunr> pinotree: now yes
<braunr> but, does it mean faked-tcp is started for *each* process loading
fakeroot-tcp ?
<braunr> (the lib i mean)
<pinotree> i think so
<braunr> well the hurd doesn't seem to do that at all
<braunr> or maybe it does and i don't see it
<braunr> the stale faked-tcp processes could be those that failed something
only
<pinotree> yes, there's also that issue: sometimes there are stake
faked-tcp processes
<braunr> hum no, i see one faked-tcp that consumes cpu when building glibc
<pinotree> *stale
<braunr> it's the same process for all commands
<pinotree> <braunr> but, does it mean faked-tcp is started for *each*
process loading fakeroot-tcp ?
<pinotree> → everytime you start fakeroot, there's a new faked-xxx for it
<braunr> it doesn't look that way
<braunr> again, on the hurd, i see one faked-tcp, consuming cpu while
building so i assume it services libfakeroot-tcp requests
<pinotree> yes
<braunr> which means i probably won't reproduce the problem on linux
<pinotree> it serves that fakeroot under which the binary(-arch) target is
run
<braunr> or perhaps it's the normal fakeroot-tcp behaviour on sid
<braunr> pinotree: a faked-tcp that is started for each command invocation
will implicitely make the network stack close all its sockets when
exiting
<braunr> pinotree: as our fakeroot-tcp uses the same instance of faked-tcp,
it's a lot more likely to exhaust the port space
<pinotree> i see
<braunr> i'll try on sid and see how it behaves
<braunr> pinotree: on the other hand, forking so many processes at each
command invocation may make exec leak a lot :p
<braunr> or rather, a lot more
<braunr> (or maybe not, since it leaks only in some cases)
<braunr> pinotree: actually, the behaviour under linux is the same with the
alternative correctly set, whereas faked-tcp is restarted (if used at
all) with -rfakeroot-tcp
<braunr> hm no, even that isn't true
<braunr> grr
<braunr> pinotree: i think i found a handy workaround for fakeroot
<braunr> pinotree: the range of local ports in our networking stack is a
lot more limited than what is configured in current systems
<braunr> by extending it, i can now build glibc \o/
<pinotree> braunr: what are the current ours and the usual one?
<braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c
<braunr> the modern ones are the ones suggested in the comment
<braunr> sysctl_local_port_range is the symbol storing the range
<pinotree> i see
<pinotree> what's the current range on linux?
<braunr> 20:44 < braunr> the modern ones are the ones suggested in the
comment
<pinotree> i see
<braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range
<braunr> 32768 61000
<braunr> so, i'm not sure why we have the problem, since even on linux,
netstat doesn't show open bound ports, but it does help
<braunr> the fact faked-tcp can remain after its use is more problematic
<pinotree> (maybe pfinet could grow a (startup-only?) option to change it,
similar to that sysctl)
<braunr> but it can also stems from the same issue gnu_srs found about
closed sockets that haven't been shut down
<braunr> perhaps
<braunr> but i don't see the point actually
<braunr> we could simply change the values in the code
<braunr> youpi: first, in pfinet, i increased the range of local ports to
reduce the likeliness of port space exhaustion
<braunr> so we should get a lot less EAGAIN after that
<braunr> (i've not committed any of those changes)
<youpi> range of local ports?
<braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c, tcp_v4_get_port function
and sysctl_local_port_range array
<youpi> oh
<braunr> EAGAIN is caused by tcp_v4_get_port failing at
<braunr> /* Exhausted local port range during search? */
<braunr> if (remaining <= 0)
<braunr> goto fail;
<youpi> interesting
<youpi> so it's not a hurd bug after all
<youpi> just a problem in fakeroot eating a lot of ports
<braunr> maybe because of the same issue gnu_srs worked on (bad socket
close when no clean shutdown)
<braunr> maybe, maybe not
<braunr> but increasing the range is effective
<braunr> and i compared with what linux does today, which is exactly what
is in the comment above sysctl_local_port_range
<braunr> so it looks safe
<youpi> so that means that the pfinet just uses ports 1024- 4999 for
auto-allocated ports?
<braunr> i guess so
<youpi> the linux pfinet I meant
<braunr> i haven't checked the whole code but it looks that way
<youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_min[] = { 1, 1
};
<youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_max[] = { 65535,
65535 };
<youpi> looks like they have increased it since then :)
<braunr> hum :)
<braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range
<braunr> 32768 61000
<youpi> yep, same here
<youpi> ./inet_connection_sock.c: .range = { 32768, 61000 },
<youpi> so there are two things apparently
<youpi> but linux now defaults to 32k-61k
<youpi> braunr: please just push the port range upgrade to 32Ki-61K
<braunr> ok, will do
<youpi> there's not reason not to do it
IRC, freenode, #hurd, 2012-12-11
<braunr> youpi: at least, i haven't had any failure building eglibc since
the port range patch
<youpi> good :)
IRC, freenode, #hurd, 2012-12-06
<braunr> we need a netstat command
<pinotree> wouldn't that require rpcs and notifications in pfinet to get
info on the known sockets?
<braunr> depends on the interface
<braunr> netstat currently uses /proc/net/* so that's out of the question
<braunr> but a bsd netstat using ioctls could do the job
<braunr> i'm not sure if it's done that way
<braunr> i don't see why it would require notifications though
<pinotree> if add such rpcs to pfinet, you could show the sockets in procfs
<braunr> yes
<braunr> that's the clean way :p
<braunr> but why notifications ?
<pinotree> to get changes on data of sockets (status change, i/o activity,
etc)
<pinotree> (possibly i'm forgetting some already there features to know
that)
<braunr> the socket state is centralized in pfinet
<braunr> netstat polls it
<braunr> (or asks it once)
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.
See the list of Hurd-related X.Org project ideas.
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.
gphoto2
The gphoto2 digital camera command-line client.
Home page: http://www.gphoto.org/proj/libgphoto2
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Only one file relies on PATH_MAX: gphoto2/main.c
First need to patch libgphoto2 package.
Comments
Not yet started.
libgphoto2
ImpulseTracker clone aiming at providing the same look&feel.
Home page: http://www.gphoto.org/proj/libgphoto2
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Fix gphoto2-settings.c:gp_setting_get() to accept NULL pointer and do the allocation.
This is a requirement for gphoto2 patch.
Comments
Not yet started.
shush
Runs a command and optionally reports its output by mail.
Home page: http://web.taranis.org/shush
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX shush-1.2.3/*:
src/shush.c: char cfdir[PATH_MAX+1], *slfac, *to[3];
src/shush.c: strlcpy(cfdir+1, optarg, PATH_MAX);
src/shush.c: snprintf(cfdir+1, PATH_MAX, "%s/.shush", getenv("HOME"));
src/crontab.c: static char cfname[PATH_MAX];
src/crontab.c: snprintf(cfname, PATH_MAX, "%s/schedule", cfdname);
src/crontab.c: snprintf(cfname, PATH_MAX, "%s/%s", cfdname, token);
src/crontab.c: snprintf(cfname, PATH_MAX, "%s/%s", cfdname, entry->d_name);
src/crontab.c: char tag[PATH_MAX+80], *oldtab, *mytab, newtab[PATH_MAX];
src/crontab.c: snprintf(newtab, PATH_MAX, "%s/%s-crontab.XXXXXX",
src/state.c:static char statepath[PATH_MAX];
src/state.c: snprintf(statepath, PATH_MAX, "%s/.state/shtate-%lu-%s-%s-%u",
src/state.c: snprintf(statepath, PATH_MAX, "%s/shtate-%lu-%s-%s-%u",
src/run.c: char fname[PATH_MAX], outlog[PATH_MAX], errlog[PATH_MAX], *outstr, *errstr;
src/run.c: snprintf(fname, PATH_MAX, "%s/%s", cfdir, job);
src/run.c: snprintf(outlog, PATH_MAX, "%s.stdout", cf_getstr(CF_CONFIG));
src/run.c: snprintf(errlog, PATH_MAX, "%s.stderr", cf_getstr(CF_CONFIG));
src/run.c: snprintf(fname, PATH_MAX, "%s/.%s-%s", cfdir, jid, get_hostname(0));
src/run.c: snprintf(outlog, PATH_MAX, "%s/%s-%s.stdout.XXXXXX",
src/run.c: snprintf(errlog, PATH_MAX, "%s/%s-%s.stderr.XXXXXX",
src/check.c: char fname[PATH_MAX], outre[PATH_MAX], errre[PATH_MAX], *outstr, *errstr;
src/check.c: snprintf(fname, PATH_MAX, "%s/%s", cfdir, job);
src/check.c: snprintf(outre, PATH_MAX, "%s.stdout", cf_getstr(CF_CONFIG));
src/check.c: snprintf(errre, PATH_MAX, "%s.stderr", cf_getstr(CF_CONFIG));
Comments
Not yet started.
pidgin-microblog
Microblogging plugins for Pidgin.
Home page: http://code.google.com/p/microblog-purple/
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX pidgin-microblog-0.3.0/*:
pidgin-microblog-0.3.0/microblog/mb_cache.c:static char cache_base_dir[PATH_MAX] = "";
pidgin-microblog-0.3.0/microblog/mb_cache.c:snprintf(cache_base_dir, PATH_MAX, "%s/mbpurple", user_dir);
The cache_base_dir is static but should only be called through a getter.
If it has not been initialized, return "" from the getter.
Comments
Not yet started.
schism
ImpulseTracker clone aiming at providing the same look&feel.
Home page: http://nimh.org/schismtracker
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX schism-0+20110101/*:
include/disko.h: char tempname[PATH_MAX];
include/disko.h: char filename[PATH_MAX];
include/headers.h:# undef PATH_MAX
schism/disko.c: if (len + 6 >= PATH_MAX) {
schism/audio_loadsave.c:char song_filename[PATH_MAX + 1];
schism/audio_loadsave.c: strncpy(song_filename, file, PATH_MAX);
schism/audio_loadsave.c: song_filename[PATH_MAX] = '\0';
schism/page_loadmodule.c:static char filename_entry[PATH_MAX + 1] = "";
schism/page_loadmodule.c:static char dirname_entry[PATH_MAX + 1] = "";
schism/page_loadmodule.c:char cfg_module_pattern[PATH_MAX + 1] = GLOB_DEFAULT;
schism/page_loadmodule.c:static char glob_list_src[PATH_MAX + 1] = ""; // the pattern used to make glob_list (this is an icky hack)
schism/page_loadmodule.c: strncpy(glob_list_src, globspec, PATH_MAX);
schism/page_loadmodule.c: glob_list_src[PATH_MAX] = '\0';
schism/page_loadmodule.c: strncpy(cfg_dir_modules, ptr, PATH_MAX);
schism/page_loadmodule.c: cfg_dir_modules[PATH_MAX] = 0;
schism/page_loadmodule.c: create_textentry(widgets_loadmodule + 2, 13, 46, 64, 0, 3, 3, NULL, filename_entry, PATH_MAX);
schism/page_loadmodule.c: create_textentry(widgets_loadmodule + 3, 13, 47, 64, 2, 3, 0, NULL, dirname_entry, PATH_MAX);
schism/page_loadmodule.c: create_textentry(widgets_exportsave + 2, 13, 46, 64, 0, 3, 3, NULL, filename_entry, PATH_MAX);
schism/page_loadmodule.c: create_textentry(widgets_exportsave + 3, 13, 47, 64, 2, 0, 0, NULL, dirname_entry, PATH_MAX);
schism/util.c: char buf[PATH_MAX];
schism/util.c: if (strlen(filename) > PATH_MAX - 16) {
schism/util.c: char buf[PATH_MAX + 1];
schism/util.c: if (getcwd(buf, PATH_MAX))
schism/util.c: char buf[PATH_MAX + 1];
schism/util.c: if (getcwd(buf, PATH_MAX))
schism/util.c: char buf[PATH_MAX + 1];
schism/util.c: char buf[PATH_MAX];
schism/util.c: char buf2[PATH_MAX];
schism/util.c: if (!GetCurrentDirectory(PATH_MAX-1,buf)) return 0;
schism/util.c: snprintf(buf2, PATH_MAX-2, "%s.bat", name);
schism/main.c: strncpy(cfg_dir_modules, initial_dir, PATH_MAX);
schism/main.c: cfg_dir_modules[PATH_MAX] = 0;
schism/main.c: strncpy(cfg_dir_samples, initial_dir, PATH_MAX);
schism/main.c: cfg_dir_samples[PATH_MAX] = 0;
schism/main.c: strncpy(cfg_dir_instruments, initial_dir, PATH_MAX);
schism/main.c: cfg_dir_instruments[PATH_MAX] = 0;
schism/page_loadinst.c:static char inst_cwd[PATH_MAX+1] = "";
schism/page_loadinst.c:static char slash_search_str[PATH_MAX];
schism/page_loadinst.c: strncpy(cfg_dir_instruments, ptr, PATH_MAX);
schism/page_loadinst.c: cfg_dir_instruments[PATH_MAX] = 0;
schism/page_loadinst.c: strncpy(inst_cwd, ptr, PATH_MAX);
schism/page_loadinst.c: inst_cwd[PATH_MAX] = 0;
schism/page_loadinst.c: if (slash_search_mode < PATH_MAX) {
schism/config.c:char cfg_dir_modules[PATH_MAX + 1], cfg_dir_samples[PATH_MAX + 1], cfg_dir_instruments[PATH_MAX + 1],
schism/config.c: cfg_dir_dotschism[PATH_MAX + 1], cfg_font[NAME_MAX + 1];
schism/config.c: strncpy(cfg_dir_dotschism, ptr, PATH_MAX);
schism/config.c: cfg_dir_dotschism[PATH_MAX] = 0;
schism/config.c: cfg_get_string(&cfg, "Directories", "modules", cfg_dir_modules, PATH_MAX, tmp);
schism/config.c: cfg_get_string(&cfg, "Directories", "samples", cfg_dir_samples, PATH_MAX, tmp);
schism/config.c: cfg_get_string(&cfg, "Directories", "instruments", cfg_dir_instruments, PATH_MAX, tmp);
schism/config.c: strncpy(cfg_module_pattern, ptr, PATH_MAX);
schism/config.c: cfg_module_pattern[PATH_MAX] = 0;
schism/page_vars.c: cfg_dir_modules, PATH_MAX);
schism/page_vars.c: cfg_dir_samples, PATH_MAX);
schism/page_vars.c: cfg_dir_instruments, PATH_MAX);
schism/page_loadsample.c:static char current_filename[PATH_MAX];
schism/page_loadsample.c:static char search_str[PATH_MAX];
schism/page_loadsample.c: PATH_MAX-1);
schism/page_loadsample.c: PATH_MAX-1);
schism/page_loadsample.c: strncpy(cfg_dir_samples, ptr, PATH_MAX);
schism/page_loadsample.c: cfg_dir_samples[PATH_MAX] = 0;
schism/page_loadsample.c: if (search_pos < PATH_MAX) {
Comments
Not yet started.
Looks like a lot, but most of them, if not all, are trivial.
sitecopy
A program for managing a WWW site via FTP, DAV or HTTP.
Home page: http://www.manyfish.co.uk/sitecopy
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX sitecopy-0.16.6/*:
intl/dcigettext.c: PATH_MAX but might cause redefinition warnings when sys/param.h is
intl/dcigettext.c:#ifndef _POSIX_PATH_MAX
intl/dcigettext.c:# define _POSIX_PATH_MAX 255
intl/dcigettext.c:#if !defined PATH_MAX && defined _PC_PATH_MAX
intl/dcigettext.c:# define PATH_MAX (pathconf ("/", _PC_PATH_MAX) < 1 ? 1024 : pathconf ("/", _PC_PATH_MAX))
intl/dcigettext.c:#if defined HAVE_SYS_PARAM_H && !defined PATH_MAX && !defined MAXPATHLEN
intl/dcigettext.c:#if !defined PATH_MAX && defined MAXPATHLEN
intl/dcigettext.c:# define PATH_MAX MAXPATHLEN
intl/dcigettext.c:#ifndef PATH_MAX
intl/dcigettext.c:# define PATH_MAX _POSIX_PATH_MAX
intl/dcigettext.c: path_max = (unsigned int) PATH_MAX;
src/ftp.c:#include <limits.h> /* for PATH_MAX */
src/ftp.c:#ifndef PATH_MAX
src/ftp.c:#define PATH_MAX 2048
src/ftp.c: char cwd[PATH_MAX];
src/ftp.c: char dir[PATH_MAX];
src/ftp.c: if (!sess->use_cwd || fn[0] != '/' || strlen(fn) > PATH_MAX)
debian/patches/10_bts410703_preserve_storage_files_sigint.dpatch:+ char filebuf[PATH_MAX];
debian/patches/10_bts410703_preserve_storage_files_sigint.dpatch:+ char filebuf[PATH_MAX];
Comments
Not yet started.
One of the PATH_MAX if used in debian patch.
sakura
Simple but powerful libvte-based terminal emulator.
Home page: http://www.pleyades.net/david/sakura.php
Log
- Started: 2012-02-03
- Discussed: 2012-02-03
- Draft Submitted: -
- Submitted: 2012-02-07, Bug#659018
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX sakura-2.4.2/*:
src/sakura.c: char buf[PATH_MAX+1];
Comments
+ char *buf = NULL;
+ struct stat sb;
Will dynamically allocate the buffer according to information provided by lstat().
+ if (lstat(file, &sb) == -1) {
+ return cwd;
+ }
+ buf = malloc(sb.st_size + 1);
Do the allocation. Don't bother to check for return value as g_strdup_printf() doesn't do it.
+ len = readlink (file, buf, sb.st_size + 1);
+ if (len < 0 || len > sb.st_size) {
+ g_free(buf);
+ return cwd;
+ }
Check realink() return value.
+ g_free(buf);
Free the dynamically allocated buffer.
auto-apt
When you want to build a program from source and it fails due to missing headers. Auto-apt can search what package would provide the header files.
(from https://help.ubuntu.com/community/AutoApt)
Log
- Started: 2012-01-24
- Discussed: 2012-01-26
- Draft Submitted: -
- Submitted: 2012-02-07, Bug#659025
- Accepted: -
ToDo
The output of grep -R PATH_MAX auto-apt-0.3.22/* is a bit long. It contains files that have been patched using #define PATH_MAX XYZ.
Here is the only file of interest:
pkgcdb/pkgtab.c: char buf[PATH_MAX];
pkgcdb/pkgtab.c: assert(p - pkg < PATH_MAX);
pkgcdb/pkgtab.c: static char buf[PATH_MAX];
pkgcdb/pkgtab.c: assert(len < PATH_MAX);
Comments
+++ auto-apt-0.3.22/auto-apt-pkgcdb.c 2012-02-03 09:25:54.045858173 +0100
+ unsigned char *buf = NULL;
+ while (!feof(stdin)) {
unsigned char *fname, *pkg;
unsigned char *p;
int nslash = 0;
+ buf = get_line(stdin);
+ if (buf == NULL)
+ break;
Reading from stdin using the get_line() function as explained in the porting guide.
+ free(buf);
+++ auto-apt-0.3.22/pkgcdb/pkgtab.c 2012-01-30 09:05:07.883096049 +0100
+ char *buf = NULL;
+ buf = (char *)malloc(p - pkg + 1);
+ if (buf == NULL) {
+ abort();
+ }
+ free(buf);
- static char buf[PATH_MAX];
+ static char *buf;
+ if (buf != NULL) {
+ free(buf);
+ }
+ buf = (char *)malloc(len + 1);
+ if (buf == NULL) {
+ abort();
+ }
up-imapproxy
SquirrelMail's IMAP Proxy is a caching IMAP proxy server intended for use with webmail clients that cannot maintain persistent connections to an IMAP server.
Home page: http://www.imapproxy.org
Log
- Started: 2012-01-31
- Discussed: 2012-02-03
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX up-imapproxy-1.2.7/*:
src/main.c: char f_randfile[ PATH_MAX ];
Comments
Work in progress...
Only the function that fills the buffer knows how long it can be.
This function is RAND_file_name() and is part of OpenSSL.
Probably OpenSSL function has to be fixed first to accept NULL buffer.
Then fix the up-imapproxy code to use the new version of the function.
rng-tools
Daemon to use a Hardware TRNG. The rngd daemon acts as a bridge between a Hardware TRNG (true random number generator) such as the ones in some Intel/AMD/VIA chipsets, and the kernel's PRNG (pseudo-random number generator).
(from http://packages.debian.org/lenny/rng-tools)
Log
- Started: 2012-01-28
- Discussed: 2012-01-30
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX rng-tools-2-unofficial-mt.14/*:
viapadlock_engine.c:static char cpudev_path[PATH_MAX+1];
viapadlock_engine.c:char devpath[PATH_MAX+1];
Comments
Work in progress, see related thread.
Even if the PATH_MAX can be easily fixed, some problems remain.
The code uses linux/types.h, that has to be replaced by sys/types.h, but also uses linux/random.h which has no equivalent I know of.
At least one source file is named after the OS: rngd_linux.c.
TI-RPC replaces glibc's Sun RPC implementation, id:"4D0632C5.1040107@RedHat.com".
It needs some work on our side, id:"20101214213212.GU1095@kepler.schwinge.homeip.net".
Then, the Hurd's nfs translator and ?nfsd can be
re-enabled, id:"87hb2j7ha7.fsf@gnu.org".
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
Debian's openjdk-7-jre package depends on libaccess-bridge-java-jni (source package: java-access-bridge).
The latter one has openjdk-6-jdk as a build dependency, but that can be hacked around:
# ln -s java-7-openjdk /usr/lib/jvm/java-6-openjdk
Trying to build it:
$ LD_LIBRARY_PATH=/usr/lib/jvm/java-7-openjdk/jre/lib/i386/jli dpkg-buildpackage -b -uc -d
[...]
make[3]: Entering directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen'
/usr/lib/jvm/java-6-openjdk/bin/idlj \
-pkgPrefix Bonobo org.GNOME \
-pkgPrefix Accessibility org.GNOME \
-emitAll -i /usr/share/idl/bonobo-activation-2.0 -i /usr/share/idl/at-spi-1.0 -i /usr/share/idl/bonobo-2.0 \
-fallTie /usr/share/idl/at-spi-1.0/Accessibility.idl
/usr/share/idl/at-spi-1.0/Accessibility_Collection.idl (line 66): WARNING: Identifier `object' collides with a keyword; use an escaped identifier to ensure future compatibility.
boolean isAncestorOf (in Accessible object);
^
/usr/share/idl/at-spi-1.0/Accessibility_Component.idl (line 83): WARNING: Identifier `Component' collides with a keyword; use an escaped identifier to ensure future compatibility.
interface Component : Bonobo::Unknown {
^
Exception in thread "main" java.lang.AssertionError: Platform not recognized
at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:71)
at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:108)
at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(FileSystems.java:89)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:98)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:96)
at java.security.AccessController.doPrivileged(Native Method)
at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:95)
at java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:90)
at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:489)
at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:480)
at java.security.AccessController.doPrivileged(Native Method)
at sun.util.calendar.ZoneInfoFile.<clinit>(ZoneInfoFile.java:479)
at sun.util.calendar.ZoneInfo.getTimeZone(ZoneInfo.java:658)
at java.util.TimeZone.getTimeZone(TimeZone.java:559)
at java.util.TimeZone.setDefaultZone(TimeZone.java:656)
at java.util.TimeZone.getDefaultRef(TimeZone.java:623)
at java.util.TimeZone.getDefault(TimeZone.java:610)
at java.text.SimpleDateFormat.initializeCalendar(SimpleDateFormat.java:682)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:619)
at java.text.DateFormat.get(DateFormat.java:772)
at java.text.DateFormat.getDateTimeInstance(DateFormat.java:547)
at com.sun.tools.corba.se.idl.toJavaPortable.Util.writeProlog(Util.java:1139)
at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.writeHeading(Skeleton.java:145)
at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.generate(Skeleton.java:102)
at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generateSkeleton(InterfaceGen.java:159)
at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generate(InterfaceGen.java:108)
at com.sun.tools.corba.se.idl.InterfaceEntry.generate(InterfaceEntry.java:110)
at com.sun.tools.corba.se.idl.toJavaPortable.ModuleGen.generate(ModuleGen.java:75)
at com.sun.tools.corba.se.idl.ModuleEntry.generate(ModuleEntry.java:83)
at com.sun.tools.corba.se.idl.Compile.generate(Compile.java:324)
at com.sun.tools.corba.se.idl.toJavaPortable.Compile.start(Compile.java:169)
at com.sun.tools.corba.se.idl.toJavaPortable.Compile.main(Compile.java:146)
make[3]: *** [org/GNOME/Accessibility/Accessible.java] Error 1
make[3]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
IRC, freenode, #hurd, 2011-08-10:
< jkoenig> and with my latest fix (hardwire os.name as "Linux"),
java-access-bridge actually built \o/
< youpi> I wouldn't call it a "fix" :)
< jkoenig> true, but pretty much everything assumes we're either solaris,
linux or windows :-/
< jkoenig> also we're actually using the Linux code which it is used to
select throughout the JDK
< jkoenig> if it's any consolation, os.version stays "GNU-Mach
1.3.99/Hurd-0.3" :-)
< youpi> ideally it should simply be changed to "GNU"
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?
$ 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 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
$ 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 rpctrace), git
tries to mmap a file via the 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 issue.
There is a NO_MMAP conditional in Git's source code, but it is a compile-time
conditional. The fallback code in compat/mmap.c:git_mmap only supports
MAP_PRIVATE, and simply preads in the requested portion of a file. This
could be made a runtime fallback, too.
In order to use DHCP, you need to install the ifupdown and isc-dhcp-client
packages, and manually create the following symbolic link:
# ln -s ../rcS.d/S10networking /etc/rc.boot/
During execution at boot time, the S10networking script will emit some error
messages while trying to configure the loopback interface. These are not
fatal.
Debian GNU/Hurd doesn't currently execute Debian standard /etc/rcS.d/* boot
scripts, but has its own /libexec/rc script -- which integrates scripts from
/etc/rc.boot/ instead.
Open Issues
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.
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
On 2010-11-28, Austin English contacted us, stating that he's working on porting Wine 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 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
< 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?
< youpi> yes
< pinotree> (but that patch is lame)
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.
General information
Configuration
Last reviewed up to the 5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08)
sources, and for libatomic_ops to the
6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) sources.
configure.acPARALLEL_MARKis not enabled; doesn't make sense so far.*-*-kfreebsd*-gnudefinesUSE_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.hostNothing.
Makefile.am,include/include.am,cord/cord.am,doc/doc.am,tests/tests.amNothing.
include/gc_config_macros.hShould be OK.
include/private/gcconfig.hHairy. But should be OK. Search for HURD, compare to LINUX, I386 case.
See
doc/porting.htmlanddoc/README.macros(and others) for documentation.LINUX has:
#define LINUX_STACKBOTTOMDefined instead of
STACKBOTTOMto have the value read from/proc/.#define HEAP_START (ptr_t)0x1000May 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 #endifTODO
#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 #endifTODO
# 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 # endifTODO
# 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 # endifCAN_SAVE_CALL_ARGSvs. -fomit-frame-pointer now being on by default for Linux x86 IIRC? (Which is an 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 HEURISTIC2Defined instead of
STACKBOTTOMto 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 ... */ #endifBeing on glibc, we could perhaps do similar as
USE_LIBC_PRIVATESinstead ofHEURISTIC2. Pro: avoidSIGSEGV(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/(can even use the same as Linux?), or use some other interface.#define SIG_SUSPEND SIGUSR1,#define SIG_THR_RESTART SIGUSR2We don't
#define MPROTECT_VDB(WIP comment); but Linux neither.Where does our
GETPAGESIZEcome from? Should we#include <unistd.h>like it is done for LINUX?
include/gc_pthread_redirects.hTODO
Cancellation stuff is Linux-only. In other places, too.
mach_dep.c#define NO_GETCONTEXTopen 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_pushedThe
HAVE_BUILTIN_UNWIND_INITcase is ours.
os_dep.creadSure that it doesn't internally (in glibc) use
malloc. Probably only / mostly
a problem for --enable-redirect-mallocconfigurations? Linux with threads usesreadv.TODO.
dyn_load.cFor
DYNAMIC_LOADING. TODO.pthread_support.c,pthread_stop_world.cTODO.
TODO.
Other files also contain LINUX and other conditionals.
libatomic_ops/configure.acNothing.
Makefile,src/Makefile,src/atomic_ops/Makefile,src/atomic_ops/sysdeps/Makefile,doc/Makefile,tests/MakefileNothing.
src/atomic_ops/sysdeps/gcc/x86.hNothing.
b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all correct.
mmap, b64dd3bc1e5a23e677c96b478d55648a0730ab75parallel mark, 07c2b8e455c9e70d1f173475bbf1196320812154, pass--disable-parallel-markor enable for us, too?HANDLE_FORK, e9b11b6655c45ad3ab3326707aa31567a767134b, 806d656802a1e3c2b55cd9e4530c6420340886c9, 1e882b98c2cf9479a9cd08a67439dab7f9622924Check
include/private/thread_local_alloc.hreUSE_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.
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
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).
IRC, OFTC, #debian-hurd, 2012-02-05
<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
There is a FOSS Factory bounty (p274) 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.
Will need to have something like Linux' cgroups. Introduction: Ressourcen-Verwaltung mit Control Groups (cgroups) (german), 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
IRC, freenode, #hurd, 2013-01-18
<braunr> systemd relies on linux specific stuff that is difficult to
implement
<braunr> notably cgroups to isolate the deamons it starts so it knows when
they stopped regardless of their pid
<braunr> just assume you can't use systemd on anything else than linux
Required Interfaces
In the thread starting here, a message 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
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?
<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)
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.
IRC, freenode, #hurd, 2013-01-13
Perhaps completely unrelated to the issue above, perhaps not.
<tschwinge> bash: xmalloc: ../../../bash/lib/sh/strtrans.c:60: cannot
allocate 261 bytes (323584 bytes allocated)
<tschwinge> 1.5 GiB RAM were free.
<tschwinge> This happened when I did a rever history search (C-r [...]),
and then pressed C-c.
Typing C-c (SIGINT) in a screen session (Debian package 4.0.3-14; -11 is
fine):
- shell prompt: no reaction (nothing printed)
sleep 10running:^Cprinted, but SIGINT is not sent.
Revisit this issue: Debian bug #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.
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
GNU Emacs mostly does work, however there are a few issues.
diredon a directory hangs. (UseC-g C-gto break the unresponsive operation.)Configuration in
src/s/:gnu.husesbsd-common.h.gnu-kfreebsd.husesgnu-linux.h-- we probably should too.gnu-linux.hmakes a few things depend on/proc(also seeHAVE_PROCFS) -- either resort to our own ways, or enhance our procfs accordingly.sysdep.c
Got a hang when compiling GNU Emacs 23, when it was compiling
.elto.elcfiles. Looked like busy-looping inside glibc. This was not reproducible so far.Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in
ext2fson/media/datawhen resuming emacs23 build in~/tmp/emacs/emacs23-*/(dpkg-buildpackage -B -uc -nc 2>&1 | tee L). No modifications toemacs23-*so far, I think. Hangs always in the same place, it seems, and reproducible. Tarred toemacs23-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;syncfsinvolving/media/datahangs). Plan: GDB on that ext2fs, and see what's hanging / locked.
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.
syncfs is a tiny wrapper around the file syncfs
RPC.
Its functionality should me merged into GNU coreutils' sync program, see
GNU Savannah task #6614.
There is a FOSS Factory bounty (p270) on this task.
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 attributed to user time. This is probably a open issue gnumach.
2011-09-02
Might want to revisit this, and take Xen into account -- I believe flubber has already been Xenified at that time.
IRC, freenode, #hurd, 2011-09-02
While testing some 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).
2013-03-30/31
Investigating time's configure, a difference of the output between Linux and
Hurd shows:
-checking for wait3 that fills in rusage... yes
+checking for wait3 that fills in rusage... no
This causes a different code path in resuse.c to be used; such code path does
not get a define for HZ, which is then defined with a fallback value of 60.
Debian bug #704283 has been filed with a fix for this no-wait3 case.
socat needs porting. Some work has already been done in 2007, see
http://www.dest-unreach.org/socat/contrib/socat-hurd.html or contact
Thomas Schwinge.
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)
2008-12
On the otherwise-idle flubber:
$ git clone git://sources.redhat.com/git/glibc.git
Initialized empty Git repository in /media/data/home/tschwinge/tmp/glibc/glibc/.git/
remote: Generating pack...
remote: Done counting 380933 objects.
remote: Deltifying 380933 objects...
remote: 100% (380933/380933) done
remote: Total 380933 (delta 294166), reused 380686 (delta 294002)
Receiving objects: 100% (380933/380933), 70.31 MiB | 27 KiB/s, done.
Resolving deltas: 100% (294166/294166), done.
error: git-checkout-index: unable to create file iconvdata/ibm1122.c (Interrupted system call)
error: git-checkout-index: unable to create file localedata/charmaps/IBM862 (Interrupted system call)
Checking out files: 100% (10676/10676), done.
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: iconvdata/ibm1122.c
# modified: localedata/charmaps/IBM862
#
no changes added to commit (use "git add" and/or "git commit -a")
$ ls -l iconvdata/ibm1122.c localedata/charmaps/IBM862
-rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 iconvdata/ibm1122.c
-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?
Fixing this situation is easy enough:
$ git checkout -- iconvdata/ibm1122.c localedata/charmaps/IBM862
$ git status
# On branch master
nothing to commit (working directory clean)
2010-03-16
Still seen.
2010-11-17
A very similar issue. 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 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?
IRC, freenode, #hurd, 2013-01-30
<braunr> hm, let's try to clone a huge repository
<braunr> hm, cloning a whole linux repo, and still no problem :)
<pinotree> weren't most/all the issues at unpack time?
<braunr> i don't remember
<braunr> we'll see when it gets there
<braunr> the longest part is "resolving deltas", for which ext2fs is
clearly the big bottleneck (no I/O, page-cache only, but still)
<braunr> pinotree: well, slow, but no error
IRC, freenode, #hurd, 2013-01-31
<braunr> fyi, i've tried several checkouts of big repositories, and never
got a single error
<braunr> youpi: looks like the recent fixes also solved some git issues we
had
<braunr> i could clone big repositories without any problem
<youpi> cool :)
The runit package doesn't work, even its test suite doesn't finish.
Thomas Schwinge once was having a look at that, but this very
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 Originally answered by Samuel Thibault:
120->proc_dostop_request ( 138) = 0
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.
adduser does work as expected, the following warnings are spurious, they just
appear when one doesn't have the nscd package. They do not appear on Linux boxes
because there posix_spawn doesn't report ENOENT for exec(). POSIX indeed says
that `if the error occurs after the calling process successfully returns, the
child process shall exit with exit status 127'. The Hurd however reports all
errors, thus the warning.
$ sudo adduser foo
Adding user `foo' ...
Adding new group `foo' (1002) ...
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
Adding new user `foo' (1002) with group `foo' ...
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
Creating home directory `/home/foo' ...
Copying files from `/etc/skel' ...
[...]
Reported at Debian bug #623199.
Single-threaded use appears to work:
$ echo 'int main(void) { int *a; a[10]=0; return a[5]; }' | ↩
gcc -o a -fmudflap -x c - -lmudflap
$ ./a
*******
mudflap violation 1 (check/write): time=1227208721.922064 ptr=0x1023de0 size=4
pc=0x1037a33 location=`<stdin>:1:26 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x33) [0x1037a33]
./a(main+0x7c) [0x80486c4]
/usr/lib/libmudflap.so.0(__wrap_main+0x49) [0x1037239]
Nearby object 1: checked region begins 68B before and ends 65B before
mudflap object 0x80ca268: name=`argv[]'
bounds=[0x1023e24,0x1023e2b] size=8 area=static check=0r/0w liveness=0
alloc time=1227208721.922064 pc=0x10371d3
Nearby object 2: checked region begins 76B before and ends 73B before
mudflap object 0x80cb448: name=`environ[]'
bounds=[0x1023e2c,0x1023ed7] size=172 area=static check=0r/0w liveness=0
alloc time=1227208721.922064 pc=0x10371d3
number of nearby objects: 2
*******
mudflap violation 2 (check/read): time=1227208721.942109 ptr=0x1023dcc size=4
pc=0x1037a33 location=`<stdin>:1:35 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x33) [0x1037a33]
./a(main+0xf3) [0x804873b]
/usr/lib/libmudflap.so.0(__wrap_main+0x49) [0x1037239]
Nearby object 1: checked region begins 88B before and ends 85B before
mudflap object 0x80ca268: name=`argv[]'
Nearby object 2: checked region begins 96B before and ends 93B before
mudflap object 0x80cb448: name=`environ[]'
number of nearby objects: 2
Multi-threaded use doesn't:
$ echo 'int main(void) { int *a; a[10]=0; return a[5]; }' | ↩
gcc -include pthread.h -o a -fmudflapth -x c - -lmudflapth -lpthread
$ ./a
Killed
$ gdb a
[...]
Starting program: /media/data/home/tschwinge/a
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x01180653 in getenv () from /lib/libc.so.0.3
(gdb) bt
#0 0x01180653 in getenv () from /lib/libc.so.0.3
#1 0x01177a02 in __dcigettext () from /lib/libc.so.0.3
#2 0x01176a57 in dcgettext () from /lib/libc.so.0.3
#3 0x011c03b5 in strerror_r () from /lib/libc.so.0.3
#4 0x01175b57 in __assert_perror_fail () from /lib/libc.so.0.3
#5 0x0111f1ad in cthread_fork (func=0x114f630 <_hurd_msgport_receive>, arg=0x0)
at /build/buildd/hurd-20080607/build-tree/hurd/libpthread/pthread/cthreads-compat.c:41
#6 0x0115713e in _hurdsig_init () from /lib/libc.so.0.3
#7 0x01140852 in _hurd_proc_init@@GLIBC_2.2.6 () from /lib/libc.so.0.3
#8 0x01140e86 in _hurd_init () from /lib/libc.so.0.3
#9 0x011690ce in init1 () from /lib/libc.so.0.3
#10 0x00001e96 in _dl_start_user () from /lib/ld.so
#11 0x00000001 in ?? ()
#12 0x01024000 in ?? ()
#13 0x00000000 in ?? ()
Also libmudflap is pthread-only.
