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.
- hurd
-
open issues
- bash
- boehm gc
- elinks
- GNU Emacs
- fakeroot eagain
- fcntl.*F_SETFL.*FD_.*
- Hiccups of Git
- git duplicated content
- git nfs mmap
- increasing bogus port at boot
- libc variant selection
- libtool
- m4 vs stack
- netstat
- prelink
- runit
- sbcl
- screen
- screen dead session
- shepherd
- socat
- ssh
- ti-rpc then nfs
- time
- tmux
- wayland
- wine
- X.Org Porting
- user
GNU Shepherd is the service manager that is used by GuixSD. It is intended for use on the GNU/Hurd, and perhaps one day it will.
When the ntpdate package is installed, one gets at boot something like:
Debian GNU/Hurd stretch/sid debian console
task ext2fs increasing a bogus port 947 by 1, most probably a bug.
task ext2fs increasing a bogus port 947 by 1, most probably a bug.
task ext2fs deallocating a bogus port 947, most probably a bug.
task ext2fs deallocating a bogus port 947, most probably a bug.
login:
This is coming from the execution of the shell script /etc/network/if-up.d/ntpdate, whose stdout/stderr is on the Mach console, but part of which gets executed after getty starts on it. It happens that getty uses revoke() to revoke access to it from other programs, and thus the ntpdate shell scripts gets its stdout/stderr in a bogus state, which libc doesn't really cope with correctly.
Commenting c:23:respawn:/sbin/getty 38400 console from /etc/inittab works
around the issue (but removes the getty from the Mach console)
IRC, freenode, #hurd, 2013-08-01
<braunr> teythoon: can you stop tmux on darnassus please ?
<braunr> i'd like to check something
<teythoon> done
<braunr> tmux makes load average grow to 5 without any visible activity :/
<braunr> can't reproduce it with my instances though
<braunr> anyway, that's minor
<teythoon> I used tmux before and never encountered that
<teythoon> sometimes tmux would hang on attaching or detaching though, but
overall I had less problems with tmux than with screen
<teythoon> ah, I tried to start tmux on darnassus and now it hangs
IRC, freenode, #hurd, 2014-02-04
<teythoon> braunr: whoa, i can reproduce gnu_srs' hanging ssh sessions on
darnassus
<teythoon> here goes
<teythoon> run tmux, exit the shell so that tmux quits, start tmux again
(tmux hangs now on some socket stuff), log in with ssh again, pkill tmux,
rm /tmp/tmux*/default => both ssh sessions hang and time out eventually
<braunr> why start tmux twice ?
<teythoon> dunno
<teythoon> that's what i just did, twice in a row
<teythoon> there's a bug somewhere that makes tmux hang if the socket
exists but no tmux server is running
<teythoon> maybe that contributes to to the other issuse, i don't know
<braunr> looks like an infinite loop somewhere
<gnu_srs> teythoon: Nice to set that I'm not alone having this problem:P
<braunr> teythoon: what's happening ? :)
<teythoon> ?
<braunr> on darnassus
<teythoon> not sure
<teythoon> uh, something is very wrong o_O
<teythoon> help ?
<braunr> :)
<braunr> the msg thread of a process is blocked somewhere
<braunr> preventing ps/top from completing
<braunr> looks like proc is blocked now ..
<braunr> restarting the vm
<braunr> apparently, removing buggy tmux sockets make pflocal crash
<braunr> thanks for the report :)
<teythoon> you are welcome :)
Ssh compression does not work at the server level for some reason:
Jul 2 18:06:08 debian sshd[405]: fatal: buffer_uncompress: inflate returned -3
One has to disable compression in /etc/sshd_config:
Compression no
The error returned by inflate is Z_DATA_ERROR.
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)
?exec memory leaks.
<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.
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.
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.
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: 2012-02-12, by Andrew Starr-Bochicchio
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: 2013-05-13, by Barry deFreese
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();
+ }
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.
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.
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, 2014-02-19
<pere> hi. I'm trying to port libtirpc to get rcpbind on hurd, and am
unable to find IPV6_PORTRANGE and IPV6_PORTRANGE_LOW. is this a known
problem with a known fix?
<braunr> what are they supposed to be ?
<pere> braunr: found them described in <URL:
http://www.daemon-systems.org/man/ip6.4.html >.
<braunr> "The IPV6_PORTRANGE socket option and the conflict resolution rule
are not defined in the RFCs and should be considered implementation
dependent
<braunr> "
<braunr> hm
<braunr> if we have that, they're very probably not accessible from outside
our network stack
<pere> needed feature on hurd, in other words...
<braunr> why ?
<pere> If I remember correctly, SO_PEERCRED is also missing?
<braunr> yes ..
<braunr> that one is important
<pere> braunr: you wonder why the IPV6_PORTRANGE socket option was created?
<braunr> i wonder why it's needed
<braunr> does linux have it ?
<pere> yes, linux got it.
<braunr> same name ?
<pere> it make it possible for some services to work with some
firewalls. :)
<pere> yes, same name, as far I can tell.
<braunr> they could merely bind ports explicitely, couldn't they ?
<pere> not always.
<braunr> or is it for servers on creation of a client socket ?
<pere> see <URL:
http://www.stacken.kth.se/lists/heimdal-discuss/2000-11/msg00002.html >
for an example I came across.
<braunr> i don't find these macros on linux :/
<pere> how strange. libtirpc build on linux.
<braunr> is there a gitweb or so somewhere ?
<braunr> i can't find it on sf :/
<pere> for <URL: http://sourceforge.net/projects/libtirpc >, you mean?
<braunr> yes
<pere> no idea.
<braunr> are you looking at upstream 0.2.4 or a particular debian package ?
<pere> I'm looking at the debian package.
<braunr> let me take a look
<pere> http://paste.debian.net/82971/ is my first draft patch to get the
source building.
<braunr> ok so
<braunr> in src/bindresvport.c
<braunr> if you look carefully, you'll see that these _PORTRANGE macros are
used in non linux code
<braunr> not very portable but it explains why you hit the problem
<braunr> try using #if defined (__linux__) || defined(__GNU__)
<braunr> also, i think we intend to implement SCM_CREDS, not SO_PEERCRED
<braunr> but consider we have neither for now
<pere> ah, definitely a simpler fix.
<braunr> pere: btw, see
https://lists.debian.org/debian-hurd/2010/12/msg00014.html
<pere> <URL: https://bugs.debian.org/739557 > with patch reporte.d
IRC, freenode, #hurd, 2014-02-20
<pere> new libtirpc with hurd fixes just uploaded to debian. should fix
the rpcbind build too.
IRC, OFTC, #debian-hurd, 2014-02-20
<pere> hm, rpcbind built with freshly patched libtirpc fail to work on
hurd. no idea why.
<pere> running 'rpcinfo -p' show 'rpcinfo: can't contact portmapper: RPC:
Success'
<teythoon> o_O
<pere> I have no idea how to debug it. :(
<pere> anyway, I've found that rpcinfo is the broken part. rpcbind work,
when I test it from a remote machine.
IRC, OFTC, #debian-hurd, 2014-02-21
<pere> failing rpcinfo -p on hurd reported as <URL:
http://bugs.debian.org/739674 >. Anyone got a clue how to debug it?
IRC, OFTC, #debian-hurd, 2014-03-03
<pere> I was just tipped by sesse that the hurd fix for libtirpc probably
caused RC bug in nfs-common, <URL: https://bugs.debian.org/740491 >.
Have not had time to check it out more closely.
IRC, OFTC, #debian-hurd, 2014-03-04
<youpi> pere: I don't really see how debian/patches/05-hurd-port.diff could
break Linux' libtirpc
<youpi> AIUI, the patch has zero effect on non-hurd builds
<youpi> oh wait
<youpi> it's simply missing a reautoconf to get HAVE_SYS_USER_H undefined
in config.h.in
<pere> youpi: I am quite sure I did add the required dh_autoreconf call.
did you see a build log where it was missing?
<youpi> pere: ah, ok. Then 02-rerun-bootstrap.diff can be dropped
<youpi> and I don't have any further idea
<youpi> pere: maybe it's the autoreconf itself which broke something?
<pere> could be. not quite sure how to find out.
<gnu_srs> pere: what about running autoreconf on the previous (working
version)?
<pere> gnu_srs: sound like a good idea. perhaps a good idea to just
disable the two patches as a start.
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.
Open Issues
dhclient aborting with a stack smashing error
IRC, freenode, #hurd, 2013-08-21:
<teythoon> yay, I fixed the path of the dhcp leases file... <teythoon> ... and now dhclient dies of a buffer overflow <teythoon> fortunately the fix is rather simple, anyone who cares about the security of his box just has to stop using isc software <teythoon> the code is full of stuff like char foo[100]; /* surely that's enough */ <pinotree> note that our version of isc-dchp (the one in ports) is older than the latest one available in unstable (which is still older than the latest upstream releases) <teythoon> so? <pinotree> dunno, might have been fixed or not <teythoon> ^^ yeah sure <gnu_srs> A lot of software has these limitations and PATH_MAX, MAXPATHLEN issues :( <pinotree> having a limitation is not a problem per-se <teythoon> no, only software written in c has these kind of problems <pinotree> the problem is not checking whether the limits are hit <teythoon> well, looking at the source of isc-dhcp my time is better spent making another dhcp client work on hurd <teythoon> also reading up on bug #616290 does make me want to avoid touching it ever <braunr> hehe <gnu_srs> teythoon: somebody was offering an alternative to the isc dhcpclient, but I think it was rejected by Samuel? <teythoon> why would he do that? <braunr> probably for compliance <gnu_srs> He probably thought they would release a new version soon, is 4.3.0 out yet? <teythoon> well, as soon as my fixes for ifupdown go in, dhclient will start crashing <teythoon> no, there is no new version released <teythoon> no major one that is <teythoon> 4.2.5 is out <gnu_srs> can't you just increase the buffer size, where is the problem exactly? <teythoon> I have no idea <gnu_srs> The Hurd patches are not in 4.2.5, they were promised for 4.3.0a1. <gnu_srs> Still the buffer overflow problem might be present in 4.2.5 if patched to build on Hurd. <braunr> there, darnassus now has a fully featured git/gitweb service <teythoon> :) <teythoon> btw, I managed to reproduce the crash reliably <teythoon> rm /var/lib/dhcp/*; dhclient -v /dev/eth0 ... *boom* <teythoon> ditch the -v, everything works, and now that there is a lease file, you can add the -v again and it works <braunr> ew :) <teythoon> and what has dhclient.c to say for its defense? <teythoon> log_info("%s", ""); <teythoon> hm, not much :/IRC, freenode, #hurd, 2013-08-22:
<teythoon> uh, the isc-dhcp situation is a huge pita, the source on -ports does not compile anymore :/IRC, freenode, #hurd, 2013-08-23:
<gnu_srs> teythoon: Was it the slash in the network interface names that caused the buffer overflow in dhclient? <teythoon> gnu_srs: no, previously no dhcp leases file was written and everything was fine <pinotree> teythoon: did you really develop your patch against that old version of ifupdown? <teythoon> gnu_srs: now it is written, and for some reason dhclient crashes *iff* -v is given *and* there is no previous lease file <teythoon> pinotree: no, I did not. that was only reportbug including information from my desktop machine without asking me <teythoon> but when I first looked at ifupdown it was still a 6000 lines noweb file >,< <teythoon> that was fun <pinotree> which version is it against? <teythoon> hg tipIRC, freenode, #hurd, 2013-08-30:
<tschwinge> teythoon: I understand correctly that you found that id:"874ngfvwn4.fsf@kepler.schwinge.homeip.net" in fact was really "just" a buffer overflow in the dhclient code? <teythoon> tschwinge: ah, most interesting, I didn't realize that you stumbled across this as well <teythoon> to be honest I don't know what's going on there, I only observed what I wrote in my report <teythoon> for me it started crashing once the lease file was actually a valid path (i.e. not to a non-existing directory b/c of the slashes in /dev/eth0) <teythoon> I tried to rebuild the package served on debian-ports, but that failedIRC, freenode, #hurd, 2014-01-03:
<congzhang> dhcp 4.3 alpha released <congzhang> and PATH_MAX issue was fixedIRC, freenode, #hurd, 2014-01-21:
<gnu_srs> teythoon: what about this? *** stack smashing detected ***: dhclient terminated <teythoon> gnu_srs: well, dhclient dies <teythoon> i've seen this, it comes and goes <teythoon> not sure what happens, but i tend to blame it on our custom-built dhcp package <teythoon> from debian-ports, and it's outdated <teythoon> it's most likely not your fault <gnu_srs> i thought there was a new upstream by now <teythoon> and the network configuration can be done with passive translators as it was always done <teythoon> there was ? <gnu_srs> there is one recently released, haven't checked yet <gnu_srs> in experimental: 4.3.0a1-2, does still not build out of the box <teythoon> there was, but it does not seem to build on the hurd <teythoon> https://buildd.debian.org/status/logs.php?pkg=isc-dhcp&arch=hurd-i386 <teythoon> the most recent version is from debian-portsIRC, freenode, #hurd, 2014-01-24:
<braunr> stack smashing detected ***: dhclient terminated <braunr> how nice <tschwinge> braunr: dhclient: http://news.gmane.org/find-root.php?message_id=%3C874ngfvwn4.fsf%40kepler.schwinge.homeip.net%3E <tschwinge> braunr: And I thought, teythoon had found this to be a buffer overflow; something like char dev[10], and for us the path to the dev (/dev/eth0) was longer (but I may be misremebering). <braunr> tschwinge: sounds reasonable <tschwinge> braunr: By the way: I'm seeing this segfault all the time during boot, but when I again run it manually (root login), it works fine. <braunr> tschwinge: you mean the dhclient one µ? <tschwinge> Yes. <braunr> mhm <teythoon> braunr, tschwinge: i never found the cause of the dhclient issue <teythoon> i blame the (outdated) build on debian-portsIRC, freenode, #hurd, 2014-01-30:
<youpi> err, still nobody found the dhclient bug? <gnu_srs> youpi: You found the dh-client bug, right? <youpi> gnu_srs: yes, the dhclient bug was in libc, as tschwinge guessed <youpi> I'll probably upload a fixed glibc on debian-ports <gnu_srs> youpi: dhclient starts OK with libc 2.17-98~0 <youpi> btw, the experimental version of isc-dhcp has a newer occurrence of PATH_MAX <gnu_srs> :-( <youpi> (aside from not including the needed debian files for hurd-i386)IPv6
IRC, freenode, #hurd, 2014-02-23:
<gg0> seems dhclient can't also set ipv6 translator <gg0> cheated by setting it manually, i had probably screwed it up somehow <gg0> exim was complaining 2014-02-23 22:26:41 IPv6 socket creation failed: Address family not supported by protocol
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
IRC, freenode, #hurd, 2015-02-09
<Andre_H> since Wine 1.7.28 it runs quite well on Gnu/Hurd - wiki.winehq.org/Hurd
<Andre_H> ( https://source.winehq.org/git/wine.git/commitdiff/6d50cfcac28f84e07777fc10874887356832102e )
IRC, freenode, #hurd, 2014-01-11
<gnu_srs1> Andre_H: Looks like the two committed patches did not go into
wine-1.6.2:-(
<gnu_srs1> Additionally, your PATH_MAX fixes was not accepted?
<Andre_H> gnu_srs1: well, the stable branch is called stable because not
everything get's there :)7
<Andre_H> gnu_srs1: the PATH_MAX patch needs more thinking...
IRC, freenode, #hurd, 2014-01-06
<Andre_H> Wanted to note that
http://www.gnu.org/software/hurd/open_issues/wine.html is wrong about
socket credentials, afaik they are still not implemented but that doesn't
block Wine anymore
<Andre_H> In fact all you need to run Wine are the patches followed by
https://source.winehq.org/patches/data/101439 (not yet upstream) or see
http://wiki.winehq.org/Hurd
<braunr> Andre_H: thanks for your report
<Andre_H> np :)
<Andre_H> braunr: can someone update
http://www.gnu.org/software/hurd/open_issues/wine.html please?
<braunr> Andre_H: well, you can :)
<Andre_H> log in with google -> check guidelines of your wiki -> try out
your wiki syntax -> laziness alarm :)
<gnu_srs> Andre_H: The reason why wine runs now is a bug in SCM_CREDS was
fixed, see the wine-devel ML.
<gnu_srs> Andre_H: s/SCM_CREDS/SCM_RIGHTS/
<Andre_H> gnu_srs: already updated our wiki :)
<Andre_H> gnu_srs: would you mind updating yours:
http://www.gnu.org/software/hurd/open_issues/wine.html :)
<Andre_H> gnu_srs: two commits for wine are in now :)
IRC, freenode, #hurd, 2013-12-31
<Andre_H> gnu_srs: i didn't need the patches for
dlls/mountmgr.sys/diskarb.c, maybe due to missing headers
IRC, freenode, #hurd, 2013-12-30
<gnu_srs> wine runs:)
<gnu_srs> It's just extremely slow.,..
<gnu_srs> gg0: please don't reopen #733604 , I've filed an updated one:
#7336045
<gnu_srs> #733605
<gg0> gnu_srs: i've reassigned it from wine-1.6 (nonexistent) to wine
(correct), then to src:wine (more correct), but between such
reassignments you closed it so found command in the latter made it
reopening
<gg0> then i realized you could mess up bugs on your own, without help :)
<gnu_srs> gg0: tks anyway, now it is src:wine and the title is right. Maybe
you should have noted me on IRC?
<Andre_H> gnu_srs: what's your status about wine? i'm still about to get
things upstream...
<gnu_srs> Andre_H: see debian bug #733605
IRC, freenode, #hurd, 2013-12-29
<Andre_H> Hi,
http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html seems
fixed in Debian GNU/Hurd 2013, do you know which patch they used? i
already asked in their channel, but well, there are only 18 people :)
<youpi> Andre_H: it hasn't been fixed in Debian GNU/Hurd. Work is discussed
on the bug-hurd mailing list
<Andre_H> youpi: thx for the info, i wonder why wine now works with some
hacks, but didn't in the past
<youpi> I guess some circumvention patch was added to wine
<youpi> does it actually really work, as in running applications for real?
<youpi> (I've nevere tried)
<Andre_H> youpi: i'm a wine developer and haven't seen circumventions for
hurd... i also just tried winelib apps last night, will try... let's say
powerpoint viewer today
<gnu_srs> Andre_H: How did you make wine run? I have patches for wine-1.4.1
and 1.6.1 to build (so far unpublished), but it does not yet run
properly.
<gnu_srs> test case: wine notepad
<Andre_H> gnu_srs: what's happening when you try that?
<gnu_srs> Andre_H: Currently it hangs at connect() (after creating the
/tmp/.wine1000/.../socket, etc, and starting again)
<gnu_srs> seems to be some problem with the HURD_DPORT_USE macro in eglibc,
investigation ongoing
<Andre_H> gnu_srs: well, i'm using the debian distro, maybe you're on
something else? you could also pastebin your hacks, so i could have a
look. i'm about to clean mine up to send them upstream... ntdll will be
quite hard...
IRC, freenode, #hurd, 2013-10-02
<gnu_srs> youpi: I've come a little further with wine, see debian bug
#724681 (same problem).
<gnu_srs> Now the problem is probably due to the specific address space
and stack issues to be
<gnu_srs> fixed for wine to run as braunr pointed out some months ago
(IRC?) when we discussed wine.
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)
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.
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 Git commit d6c34577eeaba37ff08998d18676531082c040b6
(2016-03-18), and for libatomic_ops to Git commit
01d2509c13f3aa7e03cb4cbf50fda08f98725ce4 (2016-03-24).
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 #endif[Hurd] Use mmap instead of sbrk, https://github.com/ivmai/bdwgc/pull/95.
TODO
#if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) /* Nptl allocates thread stacks with mmap, which is fine. But it */ /* keeps a cache of thread stacks. Thread stacks contain the */ /* thread control blocks. These in turn contain a pointer to */ /* (sizeof (void *) from the beginning of) the dtv for thread-local */ /* storage, which is calloc allocated. If we don't scan the cached */ /* thread stacks, we appear to lose the dtv. This tends to */ /* result in something that looks like a bogus dtv count, which */ /* tends to result in a memset call on a block that is way too */ /* large. Sometimes we're lucky and the process just dies ... */ /* There seems to be a similar issue with some other memory */ /* allocated by the dynamic loader. */ /* This should be avoidable by either: */ /* - Defining USE_PROC_FOR_LIBRARIES here. */ /* That performs very poorly, precisely because we end up */ /* scanning cached stacks. */ /* - Have calloc look at its callers. */ /* In spite of the fact that it is gross and disgusting. */ /* In fact neither seems to suffice, probably in part because */ /* even with USE_PROC_FOR_LIBRARIES, we don't scan parts of stack */ /* segments that appear to be out of bounds. Thus we actually */ /* do both, which seems to yield the best results. */ # define USE_PROC_FOR_LIBRARIES #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." # endifTODO
#if ((defined(UNIX_LIKE) && (defined(DARWIN) || defined(HURD) \ || defined(OPENBSD) || defined(ARM32) \ || defined(MIPS) || defined(AVR32) \ || defined(OR1K) || defined(NIOS2))) \ || (defined(LINUX) && !defined(__gnu_linux__)) \ || (defined(RTEMS) && defined(I386)) || defined(PLATFORM_ANDROID)) \ && !defined(NO_GETCONTEXT) # define NO_GETCONTEXT #endifAlso see comment below, regarding
mach_dep.c.
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.
This is also likely the issue causing the GDBGC_find_limit_with_boundSIGSEGV startup confusion described in binutils.#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?[Hurd] Use mmap instead of sbrk, https://github.com/ivmai/bdwgc/pull/95.
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: [TODO]
Also see comment above, regarding
include/private/gcconfig.h.GC_with_callee_saves_pushedThe
HAVE_BUILTIN_UNWIND_INITcase is ours.
os_dep.c- 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, b64dd3bc1e5a23e677c96b478d55648a0730ab75This is (still) stale/redundant/unused, as far as I can tell.
parallel 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.TODO:
diff --git ./include/private/gcconfig.h ./include/private/gcconfig.h{+#if defined(LINUX) || defined(FREEBSD) || defined(SOLARIS) || defined(IRIX5) \+} {+ || ((defined(USE_MMAP) || defined(USE_MUNMAP)) && !defined(USE_WINALLOC))+} {+# define MMAP_SUPPORTED+} {+#endif+}diff --git ./include/private/gcconfig.h ./include/private/gcconfig.h#if !defined(CAN_HANDLE_FORK) && !defined(NO_HANDLE_FORK) \ && [-((defined(GC_PTHREADS)-]{+!defined(HAVE_NO_FORK) \+} && [-!defined(HURD)-]{+((defined(GC_PTHREADS)+} && !defined(NACL) \ &&[-!defined(PLATFORM_ANDROID) &&-] !defined(GC_WIN32_PTHREADS)[-\-] && !defined(USE_WINALLOC)) \ || (defined(DARWIN) && defined(MPROTECT_VDB)) || defined(HANDLE_FORK)) /* Attempts (where supported and requested) to make GC_malloc work in */ /* a child process fork'ed from a multi-threaded parent. */ # define CAN_HANDLE_FORK #endif {+#if defined(CAN_HANDLE_FORK) && !defined(CAN_CALL_ATFORK) \+} {+ && !defined(HURD) && !defined(PLATFORM_ANDROID)+} {+ /* Have working pthread_atfork(). */+} {+# define CAN_CALL_ATFORK+} {+#endif+}diff --git ./include/private/gcconfig.h ./include/private/gcconfig.h{+#if (defined(FREEBSD) || (defined(DARWIN) && !defined(_POSIX_C_SOURCE)) \+} {+ || (defined(SOLARIS) && (!defined(_XOPEN_SOURCE) \+} {+ || defined(__EXTENSIONS__))) \+} {+ || defined(LINUX)) && !defined(HAVE_DLADDR)+} {+# define HAVE_DLADDR+} {+#endif+}diff --git ./os_dep.c ./os_dep.c@@ -3038,9 +3005,11 @@ GC_API GC_push_other_roots_proc GC_CALL GC_get_push_other_roots(void) /* Also old MSWIN32 ACCESS_VIOLATION filter */ # if !defined(MSWIN32) && !defined(MSWINCE) STATIC SIG_HNDLR_PTR GC_old_bus_handler = 0; {+# if defined(FREEBSD) || defined(HURD) || defined(HPUX)+} STATIC GC_bool GC_old_bus_handler_used_si = FALSE; {+# endif+} STATIC GC_bool GC_old_segv_handler_used_si = FALSE;diff --git ./os_dep.c ./os_dep.c@@ -3192,20 +3169,22 @@ GC_API GC_push_other_roots_proc GC_CALL GC_get_push_other_roots(void) # else GC_bool used_si; {+# if defined(FREEBSD) || defined(HURD) || defined(HPUX)+} if (sig == [-SIGSEGV) {-] [- old_handler = GC_old_segv_handler;-] [- used_si = GC_old_segv_handler_used_si;-] [- } else-]{+SIGBUS)+} { old_handler = GC_old_bus_handler; used_si = GC_old_bus_handler_used_si; {+} else+} {+# endif+} {+ /* else */ {+} {+ old_handler = GC_old_segv_handler;+} {+ used_si = GC_old_segv_handler_used_si;+} } # endifdiff --git ./os_dep.c ./os_dep.c# if defined(HPUX) || defined(LINUX) || defined(HURD) \ || (defined(FREEBSD) && defined(SUNOS5SIGS)) sigaction(SIGBUS, &act, &oldact); if [-(oldact.sa_flags-]{+((oldact.sa_flags+} & SA_SIGINFO) {+!= 0)+} { GC_old_bus_handler = oldact.sa_sigaction; {+# if !defined(LINUX)+} GC_old_bus_handler_used_si = TRUE; {+# endif+} } else { GC_old_bus_handler = (SIG_HNDLR_PTR)oldact.sa_handler; {+# if !defined(LINUX)+} GC_old_bus_handler_used_si = FALSE; {+# endif+} } if (GC_old_bus_handler == (SIG_HNDLR_PTR)SIG_IGN) { [-if (GC_print_stats)-] [- GC_err_printf("Previously-]{+WARN("Previously+} ignored bus [-error!?\n");-]{+error!?\n", 0);+} {+# if !defined(LINUX)+} GC_old_bus_handler = (SIG_HNDLR_PTR)SIG_DFL; {+# else+} {+ /* GC_old_bus_handler is not used by GC_write_fault_handler. */+} {+# endif+} } {+else+} if (GC_old_bus_handler != (SIG_HNDLR_PTR)SIG_DFL) { [-if (GC_print_stats == VERBOSE)-] [- GC_log_printf("Replaced-]{+GC_VERBOSE_LOG_PRINTF("Replaced+} other SIGBUS handler\n"); } # endif /* HPUX || LINUX || HURD || (FREEBSD && SUNOS5SIGS) */
Build
Here's a log of a boehm-gc build run; this is from Git commit
d6c34577eeaba37ff08998d18676531082c040b6 (2016-03-18), and for libatomic_ops
Git commit 01d2509c13f3aa7e03cb4cbf50fda08f98725ce4 (2016-03-24), run on
kepler.SCHWINGE and laplace.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.9 CXX=g++-4.9 --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.
Analysis
$ toolchain/logs/process boehm-gc build
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
[...]
Analysis
$ toolchain/logs/process boehm-gc install
Testsuite
$ make -k check 2>&1 | tee log_test
[...]
$ (cd libatomic_ops/ && make -k check) 2>&1 | tee log_test_
[...]
Analysis
$ toolchain/logs/process boehm-gc test
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
IRC, freenode, #hurd, 2013-09-03
<congzhang> braunr: when will libc malloc say memory corruption?
<braunr> congzhang: usually on free
<braunr> sometimes on alloc
<congzhang> and after one thread be created
<congzhang> I want to know why and how to find the source
<congzhang> does libgc work well on hurd?
<braunr> i don't think it does
<congzhang> so , why it can't?
<braunr> congzhang: what ?
<congzhang> libgc was not work on hurd
<pinotree> why?
<congzhang> I try porting dotgnu
<braunr> ah
<braunr> nested signal handling
<congzhang> one program always receive Abort signal
<pinotree> and why it should be a problem in libgc?
<congzhang> for malloc memory corruption
<braunr> libgc relies on this
<congzhang> yes
<congzhang> so, is there a workaround to make it work?
<braunr> show the error please
<congzhang> http://paste.debian.net/34416/
<pinotree> where's libgc?
<congzhang> i compile dotgnu with enable-gc
<pinotree> so?
<congzhang> I am not sure about it
<pinotree> so why did you say earlier that libgc doesn't work?
<congzhang> because after I see one thread was created notice by gdb, it
memory corruption
<pinotree> so what?
<congzhang> maybe gabage collection happen, and gc thread start
<pinotree> that's speculation
<pinotree> you cannot debug things speculating on code you don't know
<pinotree> less speculation and more in-deep debugging, please
* congzhang I try again, to check weather thread list changing
<congzhang> sorry for this
<braunr> it simply looks like a real memory corruption (an overflow)
<congzhang> maybe PATH related problem
<pinotree> PATH?
<congzhang> yes
<braunr> PATH_MAX
<braunr> but unlikely
<congzhang> csant do path traverse
<congzhang> I fond the macro
<congzhang> found
<congzhang> #if defined(__sun__) || defined(__BEOS__)
<congzhang> #define BROKEN_DIRENT 1
<congzhang> #endif
<congzhang> and so for hurd?
<pinotree> BROKEN_DIRENT doesn't say much about what it does
<WhiteKIBA> nope
<WhiteKIBA> whoops
<congzhang> it seems other port meet the trouble too
<pinotree> which trouble?
<congzhang> http://comments.gmane.org/gmane.comp.gnu.dotgnu.developer/3642
<congzhang> (gdb) ptype struct dirent
<congzhang> type = struct dirent {
<congzhang> __ino_t d_ino;
<congzhang> unsigned short d_reclen;
<congzhang> unsigned char d_type;
<congzhang> unsigned char d_namlen;
<congzhang> char d_name[1];
<congzhang> }
<congzhang>
<congzhang> d_name should be char[PATH_MAX]?
<congzhang> and
http://libjit-linear-scan-register-allocator.googlecode.com/svn/trunk/pnet/support/dir.c
<pinotree> no
<braunr> stop pasting that much
<_d3f> uhm PATH_MAX on the hurd?
<braunr> and stop saying nonsense
<congzhang> sorry, i think four line was not worth to pastbin
<pinotree> they are 8
<congzhang> never again
<braunr> just try by defining BROKEN_DIRENT to 1 in all cases and see how
it goes
* congzhang read dir.c again
<congzhang> braunr: it does not crash this time, I do more test
IRC, freenode, #hurd, 2013-09-04
<congzhang> hi, I am dotgnu work on hurd, and even winforms app
<congzhang> s/am/make
<congzhang> and maybe c# hello world translate another day :)
IRC, freenode, #hurd, 2013-12-16
<braunr> gnu_srs: ah, libgc
<braunr> there are signal-related problems with libgc
Leak Detection
IRC, freenode, #hurd, 2013-10-17
<teythoon> I spent the last two days integrating libgc - the boehm
conservative garbage collector - into hurd
<teythoon> it can be used in leak detection mode
<azeem> whoa, cool
<teythoon> and it actually kind of works, finds malloc leaks in translators
<braunr> i think there were problems with signal handling in libgc
<braunr> i'm not sure we support nested signal handling well
<teythoon> yes, I read about them
<teythoon> libgc uses SIGUSR1/2, so any program installing handlers on them
will break
<azeem> (which is not a problem on Linux, cause there some RT-signals or so
are used)
<teythoon> yes
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.
IRC, freenode, #hurd, 2013-06-30
<pinotree> other than that, the hwcap system is not working for us yet,
right?
<youpi> no but we'd like to use e.g. cpuid for that
<youpi> like kfreebsd does
<pinotree> do they use cpuid for that?
<pinotree> i kind of lost myself in glibc's loading internals, trying to
find out where the hwcap bits come from
<youpi> on linux it comes from the kernel
<youpi> on kfreebsd aiui they use cpuid to figure it out from the process
itself
<pinotree> do you have any pointer to the kfreebsd way? iirc i had a look
in their sysdeps, but found nothing related to that
<youpi> it's in local-sysdeps.diff aiui
<youpi> +dl_platform_kfreebsd_i386_init
<youpi> which fills dl_hwcap
<youpi> called at _dl_sysdep_start
<pinotree> interesting
Having working CPUID code inside glibc is also a prerequisite for proper IFUNC support.
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.
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 works pretty well. It works beautifully in X.
2024-01-14
Emacs version 29.1 runs on Debian GNU/Hurd. Joshua Branson uses it in
X without issue. He use org-mode, gnus, erc, calc, markdown-mode, etc.
In fact he, edits this wiki via Debian GNU/Hurd (running on a T43)
using Emacs. He is able to make changes to the wiki, render the wiki,
look at the resulting webpage with the
netsurf web browser, commit the
changes, and send a patch to bug-hurd@gnu.org, all while using the
Hurd. 
Also since the Hurd ported rust, you can now use treesitter with Emacs! Joshua got html-ts-mode working.
Emacs also has a packaged eglot, which is a client for language server protocol, into core. Joshua was able to get eglot working for C mode with clandg, but it was a bit slow. Joshua is running Emacs on a T43, with 1.5 GB of RAM, so perhaps his hardware is just super slow.
You can easily install many Emacs packages with apt:
# apt install elpa-zenburn-theme
Or you can use use-package.
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.
time
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.
times
guile
IRC, freenode, #hurd, 2013-08-21
<nalaginrut> does guile2 on hurd fixed? times issue
<teythoon> nalaginrut: does not look good
<teythoon> scheme@(guile-user)> (times)
<teythoon> $1 = #(0 0 0 0 0)
<nalaginrut> well, seems not a fixed version, if there's fixed version
<nalaginrut> since it's not Guile's bug, I can do nothing for it
<teythoon> ah
<nalaginrut> in spite of this, Guile2 works I think
<nalaginrut> all tests passed but 2 fail
<nalaginrut> one of the failure is version shows "UNKNOWN" which is
trivials
<teythoon> well, did you try to fix the times issue in Hurd?
<nalaginrut> I didn't , I have to get more familiar with hurd first
<nalaginrut> I'm playing hurd these days
<teythoon> :)
<nalaginrut> anyway, I think times issue is beyond my ability at present
<nalaginrut> ;-P
<teythoon> times is implemented in the glibc, in sysdeps/mach/hurd/times.c
<teythoon> don't say that before you had a look
<nalaginrut> yes, you're right
<nalaginrut> but I think times has something to do with the kernel time
mechanism, dunno if it's related to the issue
<nalaginrut> how did you get the times.c under hurd?
<nalaginrut> apt-get source glibc?
<teythoon> well, I'd clone git://sourceware.org/git/glibc.git
<teythoon> and yes, the kernel is involved
<teythoon> task_info is used to obtain the actual values
<teythoon>
http://www.gnu.org/software/hurd/gnumach-doc/Task-Information.html
<teythoon> I'd guess that something fails, but the times(2) interface is
not able to communicate the exact failure
<nalaginrut> maybe it's not proper to get src from upstream git? since it's
OK under Linux which uses it too
<nalaginrut> but apt-get source glibc has nothing
<teythoon> so I would copy the times(2) implementation from the libc so
that you can modify it and run it as a standalone program
<teythoon> well, the libc has system dependent stuff, times(2) on Linux is
different from the Hurd version
<teythoon> it has to be
<nalaginrut> alright, I got what you mean ;-)
<teythoon> and the debian libc is built from the eglibc sources, so the
source package is called eglibc iirc
<nalaginrut> ah~I'll try
<teythoon> have you tried to rpctrace your times test program? the small c
snippet you posted the other day?
<nalaginrut> I haven't build all the tools & debug environment on my hurd
;-(
<teythoon> what tools?
<nalaginrut> well, I don't even have git on it, and I'm installing but
speed is slow, I'm looking for a new mirror
<teythoon> ah well, no need to do all this on the Hurd directly
<teythoon> building the libc takes like ages anyway
<nalaginrut> oops ;-)
<nalaginrut> I'll take your advice to concentrate on times.c only
<teythoon> oh well, it might be difficult after all, not sure though
<teythoon> times sends two task_info messages, once with TASK_BASIC_INFO,
once with TASK_THREAD_TIMES_INFO
<teythoon> here is the relevant rpctrace of your test program:
<teythoon> task131(pid14726)->task_info (1 10) = 0 {0 25 153427968 643072 0
0 0 0 1377065590 570000}
<teythoon> task131(pid14726)->task_info (3 4) = 0 {0 0 0 10000}
<teythoon> ok, I don't know enough about that to be honest, but
TASK_THREAD_TIMES_INFO behaves funny
<teythoon> I put a sleep(1) into your test program, and if I rpctrace it,
it behaves differently o_O
* nalaginrut is reading task-information page to get what it could be
<nalaginrut> maybe I have to do the same steps under Linux to find some
clue
<teythoon> no, this is Mach specific, there is no such thing on Linux
<teythoon> on Linux, times(2) is a system call
<teythoon> on Hurd, times is a function implemented in the libc that
behaves roughly the same way
<nalaginrut> OK~so different
<teythoon> look at struct task_basic_info and struct task_thread_times_info
in the task-information page for the meaning of the values in the
rpctrace
<teythoon> yes, very
<braunr> nalaginrut: you may want to try a patch i did but which is still
waiting to be merged in glibc
<nalaginrut> braunr: ah~thanks for did it ;-)
<nalaginrut> can I have the link?
<braunr> i'm getting it
<braunr> teythoon: funny things happen with rpctrace, that's expected
<braunr> keep in mind rpctrace doesn't behave like ptrace at all
<braunr> it acts as a proxy
<braunr> nalaginrut:
https://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508
<braunr> nalaginrut: you need to add it to the debian eglibc patch list,
rebuild the packages, and install the resulting .debs
<braunr> if you have trouble doing it, i'll make packages when i have time
<nalaginrut> braunr: I think your test result is expected? ;-)
<braunr> what test result ?
<nalaginrut> times test under that patch
<braunr> yes
<braunr> but i have no idea if it will work
<braunr> my patch fixes a mismatch between glibc and the procfs server
<braunr> nothing more
<braunr> it may help, it may not, that's what i'd like to know
<nalaginrut> hah~thanks for that
<nalaginrut> I get source from apt-get, then manually modified the files,
no much code ;-)
<nalaginrut> compiling
<nalaginrut> there is no cpuinfo in /proc?
<teythoon> no
<nalaginrut> a feature need to be done? or there's another way for that?
<teythoon> well, it hasn't been implemented
<teythoon> do you need that? what for?
<nalaginrut> compiling error, I realized I should use gcc-4.7
<pinotree> how are you building?
<nalaginrut> I just happened to play proc while compiling, and found
there's no
<nalaginrut> cxa_finalize.c:48:1: error: tcbhead_t has no member
named multiple_threads
<nalaginrut> I changed to gcc-4.7
<pinotree> just edit the sources, and then dpkg-buildpackage -nc -us -uc
<pinotree> that will rebuild the debian package as it would be in a debian
build, making sure all the build dependencies are there, etc
<pinotree> doing it different than that is just wrong™
<nalaginrut> ok, doing
<pinotree> were you really doing ./configure etc yourself?
<nalaginrut> well, I can't wait till it's done, I'll let it compile and
check it out tomorrow
<nalaginrut> I used configure, yes ;-P
<pinotree> not good
<nalaginrut> I have to go, thanks for help guys
IRC, freenode, #hurd, 2013-08-22
< nalaginrut> eglibc was done by dpkg-buildpackage, then how to install it?
(sorry I'm a brand new debian users)
< nalaginrut> oh~I found it
< nalaginrut> yes, (times) returns reasonable result ;-)
* nalaginrut is trying 'make check'
< nalaginrut> unfortunately, it can't pass the test though, I'm researching
it, anyway, we made first step
< nalaginrut> for Hurd internal-time-units-per-second will be 1000
< nalaginrut> , but the elapsed time is far larger than (* 2
internal-time-units-per-second)
< nalaginrut> I think the different of two returned clocks after 1 second
should be the TIME_UNITS_PER_SECOND, in principle
< nalaginrut> but I'm not sure if it's elibc or Guile bug
< nalaginrut> dunno, maybe clock tick should be 1000?
< nalaginrut> well, I'll try clock per second as 1000
< braunr> nalaginrut: clock tick (or actually, the obsolete notion of a
clock tick in userspace) should be 100
< braunr> nalaginrut: how did you come with 1000 ?
< nalaginrut> braunr: Guile set TIME_UNITS_PER_SECOND to 1000 when there's
no 8bytes size and doesn't define HAVE_CLOCK_GETTIME
< nalaginrut> #if SCM_SIZEOF_LONG >= 8 && defined HAVE_CLOCK_GETTIME
< nalaginrut> #define TIME_UNITS_PER_SECOND 1000000000
< nalaginrut> #else
< nalaginrut> #define TIME_UNITS_PER_SECOND 1000
< nalaginrut> #endif
< nalaginrut> and the test for 'times' used time-units-per-second
< pinotree> what has sizeof(long) have to do with time units per second?
< nalaginrut> dunno, maybe the representation of time?
< nalaginrut> the test failed since the difference between two clocks after
1sec is too large
< nalaginrut> and for the test context, it should small than 2 times of
units-per-second
< nalaginrut> should be smaller
< nalaginrut> sorry for bad English
< pinotree> aren't you basically looking for clock_getres?
< nalaginrut> pinotree: I don't understand what you mean
< pinotree>
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html
< nalaginrut> I wonder if there's a standard CLK_PER_SEC for Hurd
< nalaginrut> or it can be modified as wish
< pinotree> why do you need it?
< nalaginrut> the difference is 10,000,000, which can never less than
2*clock_per_second
< nalaginrut> pinotree: I don't need it, but I want to know if there's a
standard value
< braunr> nalaginrut: ok so, this is entirely a guile thing
< braunr> nalaginrut: did you test with my patch ?
< nalaginrut> braunr: yes, 'times' works fine
< braunr> but even with that, a tets fails ?
< braunr> test*
< nalaginrut> well, I can't say works fine, the proper description is "now
it has reasonable result"
< braunr> youpi: could you bring
http://git.sceen.net/hurd/glibc.git/commit/?id=90404d6d1aa01f6ce1557841f5a675bb6a30f508
into debian glibc btw ?
< nalaginrut> braunr: it failed the test since the clock run too fast, but
it should be smaller than 2*clk-per-sec
< braunr> i don't get that
< braunr> can you show the code that checks the condition ?
< nalaginrut> braunr: http://pastebin.com/sG3QxnPt
< braunr> * 0.5 internal-time-units-per-second ?
< nalaginrut> for C users, it's just like
a=times(...);sleep(1);b=times(...); then time-units-per-sec/2 <= (b-a) <=
time-units-per-sec*2
< braunr> ah ok
< nalaginrut> the test passes when it's true
< braunr> so basically, it says sleep(1) sleeps for more than 2 seconds
< braunr> can you check the actual value ?
< braunr> b-a
< nalaginrut> hold on for minutes
< nalaginrut> it's 10,000,000
< nalaginrut> for clk-per-sec=1000,000,000, it's OK
< nalaginrut> but for 100 or 1000, it's too small
< braunr> let's forget 100
< braunr> guile uses 1000
< nalaginrut> OK
< braunr> but i still don't get why
< nalaginrut> so I asked if there's standard value, or it can be ajustified
< nalaginrut> adjusted
< braunr> ok so, times are expressed in clock ticks
< braunr> are you sure you're using a patched glibc ?
< nalaginrut> yes I used your patch, and the 'times' get reasonable result
< braunr> then
< braunr> 11:28 < nalaginrut> it's 10,000,000
< braunr> doesn't make sense
< nalaginrut> hmm
< braunr> anhd i don't understand the test
< braunr> what's tms:clock new ?
< nalaginrut> it's actually the return value of 'times'
< nalaginrut> Guile wrap the clock_t and tms to a vector, then we can get
all the thing in a row
< nalaginrut> 'new' is a variable which was gotten after 1 sec
< braunr> let's see what this does exactly
< nalaginrut> equal to "new = times(...)"
< nalaginrut> 'tms' equal to (clock_t (struct tms))
< nalaginrut> we have to pass in the struct pointer to get the struct
values filled, but for Guile we don't use pointer, times actually returns
two things: clock_t and struct tms
< nalaginrut> and Guile returns them as a vector in a row, that's it
< braunr> nalaginrut: test this please:
http://darnassus.sceen.net/~rbraun/test.c
< braunr> i don't have a patched libc here
< braunr> i'll build one right now
< nalaginrut> clock ticks: 1000000
< braunr> and this seems reasonable to you ?
< braunr> anyway, i think the guile test is bugged
< nalaginrut> no, the reasonable is not for this
< braunr> does it ever get the clock tick value from sysconf() ?
< nalaginrut> I say reasonable since it's always 0 both for clock and tms,
before apply your patch
< braunr> uh no
< braunr> i have the same value, without my patch
< nalaginrut> so I said "I can't say it works fine"
< braunr> either the test is wrong because it doesn't use sysconf()
< nalaginrut> anyway, I don't think times should return "all zero"
< braunr> or the clock values have already been ocnverted
< braunr> but it doesn't
< braunr> you did something wrong
< nalaginrut> with your patch it doesn't
< braunr> without neither
< braunr> 11:43 < braunr> i have the same value, without my patch
< nalaginrut> well, it's too strange
< braunr> check how the test actually gets the clock values
< braunr> also, are your running in vbox ?
< braunr> you*
< nalaginrut> no ,it's physical machine
< braunr> oh
< braunr> nice
< braunr> note that vbox has timing issues
< nalaginrut> I thought I should give you some info of CPU, but there's no
/proc/cpuinfo
< braunr> shouldn't be needed
< nalaginrut> OK
< braunr> run my test again with an unpatched glibc
< braunr> just to make sure it produces the same result
< braunr> and
< nalaginrut> so the clock-per-sec is machine independent for Hurd I think
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< nalaginrut> since it's implemented in userland
< braunr> clock-per-sec is always system dependent
< braunr> All times reported are in clock ticks.
< braunr> The number of clock ticks per second can be obtained
using:
< braunr> sysconf(_SC_CLK_TCK);
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< braunr> to see if they're converted before reaching the test code or not
* nalaginrut is building eglibc
< braunr> building ?
< braunr> what for ?
< nalaginrut> I modified it to 1000, now it's useless
< braunr> we want it to 100 either way
< nalaginrut> and how to reinstall eglibc under debian?
< braunr> it's obsolete, procfs already uses 100, and 100 is low enough to
avoid overflows in practically all cases
< braunr> aptitude install libc0.3=<version>
< nalaginrut> OK
< braunr> aptitude show -v libc0.3
< braunr> for the list of available versions
< nalaginrut> out of topic, what's the meaning of the code in
quantize_timeval ?
< nalaginrut> tv->tv_usec = ((tv->tv_usec + (quantum - 1)) / quantum) *
quantum;
< nalaginrut> I can't understand this line
< braunr> scaling and rounding i guess
< nalaginrut> hmm...but quantum seems always set to 1?
< nalaginrut> 100/__getclktck()
< braunr> ah right
< braunr> old crap from the past
< nalaginrut> and clk-tck is 100
< braunr> the author probably anticipated clk_ticks could vary
< braunr> in practice it doesn't, and that's why it's been made obsolete
< nalaginrut> I wonder if it could be vary
< braunr> no
< nalaginrut> alright
< nalaginrut> why not just assign it to 1?
< braunr> 11:55 < braunr> old crap from the past
< braunr> the hurd is 20 years old
< braunr> like linux
< nalaginrut> oh~
< braunr> but with a lot less maintenance
< nalaginrut> braunr: well, I tried the original eglibc, your test was
clock ticks: 1000000
< nalaginrut> but in Guile, (times) ==> (0 0 0 0 0)
< nalaginrut> the reasonable result maybe: #(4491527510000000 80000000 0 0
0)
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< braunr> ah, he left
IRC, freenode, #hurd, 2013-08-23
< braunr> nalaginrut: times() doesn't seem to be affected by my patch at
all
< nalaginrut> braunr: but it did in my machine
< nalaginrut> well, I think you mean it doesn't affect your C test code
< braunr> i'm almost sure something was wrong in your test
< braunr> keep using the official debian glibc package
< nalaginrut> I don't think it's test issue, since every time (times)
return zero, the test can never get correct result
< braunr> times doesn't return 0
< braunr> for sleep(1), i always have the right result, except in
microseconds
< nalaginrut> times in Guile always return #(0 0 0 0 0)
< braunr> (microseconds is the native mach time unit)
< braunr> well, guile does something wrong
< nalaginrut> after sleep 1, it's 0 again, so it's none sense
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< braunr> not on my system
< nalaginrut> but (times) returns reasonable result after applied your
patch
< braunr> that's not normal, since times isn't affected by my patch
< nalaginrut> oops
< braunr> you need to look for what happens in guile between the times()
call and the #(0 0 0 0 0) values
< nalaginrut> well, I tried many times between patch or non-patch, I think
there's no mistake
< nalaginrut> I read the 'times' code in Guile, there's nothing strange,
just call 'times' and put all the result to a vector
< braunr> which means there is no conversion
< braunr> in which case the test is plain wrong since there MUST also be a
call to sysconf()
< braunr> to obtain the right clock ticks value
< braunr> is your box reachable with ssh ?
< nalaginrut> oh~wait, seems there's a quotient operation, I'm checking
< nalaginrut> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
< nalaginrut> scm_from_long (ticks_per_second));
< braunr> iirc, TIME_UNITS_PER_SECOND is hardcoded
< nalaginrut> unless factor is zero
< nalaginrut> yes, it's hardcoded
< braunr> that's completely non portable and wrong
< nalaginrut> you suggest to call sysconf?
< braunr> yes
< braunr> but i don't have the code in mind
< braunr> what is ticks_per_second ?
< nalaginrut> OK, that's one issue, we have to find why times return 0
< braunr> 14:14 < braunr> is your box reachable with ssh ?
< braunr> i'd like to make sure times returns 0 at your side
< braunr> because it doesn't at mine
< nalaginrut> no
< braunr> until i can reproduce, i can't consider there is a problem
< nalaginrut> I think it's unreachable for outer space
< nalaginrut> well, if you want to reproduce, just get guile src of debian
< braunr> guile 2.0 ?
< nalaginrut> yes, apt-get source guile-2.0
< nalaginrut> I'm checking ticks_per_second
< braunr> got the source, how do i test
< braunr> ?
< nalaginrut> you have to build it, and run ./meta/guile, then you don't
have to install it
< nalaginrut> and try (times)
< braunr> aw libgc
< nalaginrut> the reasonable result should be #(4313401920000000 110000000
20000000 0 0) or something alike
< nalaginrut> but #(0 0 0 0 0) in each time is not reasonable apparently
< nalaginrut> maybe you need apt-get build-dep guile-2.0?
< braunr> already done
< nalaginrut> building Guile2 may take very long time
< nalaginrut> about 30 minutes in my old machine
< braunr> then it should take just a few minutes on mine
< nalaginrut> alright it's not very long, I've spent 8 hours for gcc in LFS
< braunr> 8 hours ?
< braunr> takes 5-10 minutes on a common machine ..
< nalaginrut> but it's Celeron566 at that time...
< braunr> ah, that old
< nalaginrut> include bootstrap, so very long
< braunr> nalaginrut: i got the test failure from the build procedure, how
do i run it manually ?
< nalaginrut> braunr: ./meta/guile -L test-suite
test-suite/tests/time.test
< nalaginrut> braunr: or make check for all
< braunr> put a print after the schedule() and before the return nil; in
runtime_mstart, since that's the body of new threads
< nlightnfotis> unfortunately, I can't confirm this with goroutines
running; the assertion failure aborts before I can get anything useful
< braunr> you can
< braunr> make sure there is a \n in the message, since stdout is line
buffered by default
< braunr> if you don't reach that code, it means threads don't exit
< braunr> at least goroutine threads
< braunr> btw, where is the main thread running ?
< nlightnfotis> I just checked there is a \n at the end.
< nlightnfotis> "<braunr> btw, where is the main thread running " could you
elaborate a little bit on this?
< braunr> what does main() after initializing the runtime ?
< braunr> +do
< nlightnfotis> the runtime main or the process's main?
< braunr> the process
< braunr> nlightnfotis: what we're interested in is knowing whether main()
exits or not
< nlightnfotis> braunr: I can see there are about 4 functions of interest:
runtime_main (the main goroutine, and I can imagine 1st thread)
< nlightnfotis> main_init (I don't know what it does, will check this out
now)
< nlightnfotis> main_main (not sure about this one either)
< nlightnfotis> and runtime_exit (0)
< braunr> i can see that too
< braunr> i'm asking about main()
< nlightnfotis> which seems to be the function that terminates the main
thread
< nlightnfotis> <braunr> nlightnfotis: what we're interested in is knowing
whether main() exits or not --> my theory is runtime_exit (0) exits the
process' main. Seeing as at various times go programs echo $? == 0.
< nlightnfotis> let me research that a little bit
< nlightnfotis> braunr: that will require a bit more studying. main_main()
and main_init() are both expanded to assembly tags if I understand it
correctly.
< nlightnfotis> main.main and __go_init_main respectively.
< braunr> why are you looking from there instead of looking from main() ?
< nlightnfotis> are we not looking out if main exits?
< braunr> we are
< braunr> so why look at main_main ?
< braunr> or anything else than main ?
< nlightnfotis> these are called inside runtime_main and I figured out they
might have a clue
< braunr> runtime_main != main
< braunr> (except if there is aliasing)
< nlightnfotis> there is still the possibility that runtime_main is the
main function and that runtime_exit(0) exits it.
< braunr> there is no doubt that main is main
< braunr> (almost)
< nlightnfotis> and I just found out that there is no main in assembly
produced from go. Only main.main
< braunr> check the elf headers for the entry point then
< nlightnfotis> braunr: I went through the headers, and found the process'
main. You can find it in <gcc_root>/libgo/runtime/go-main.c
< nlightnfotis> it seems very strange though: It creates a new thread, then
aborts?
< braunr> nlightnfotis: see :)
< braunr> nlightnfotis: add traces there
< nlightnfotis> braunr: can you look into that piece of code to check out
something I don't understand?
< nlightnfotis> braunr: I can not seem able to find __go_go 's definition
< nlightnfotis> only a declaration in runtime.h
< braunr>
https://github.com/NlightNFotis/gcc/blob/master/libgo/runtime/proc.c,
line 1552
< nlightnfotis> gee thanx. For a strange kind of fashion, I was looking for
it in runtime.c
< braunr> use git grep
< braunr> or tags/cscope
< nlightnfotis> braunr: yep! runtime_exit does seem to terminate a go
process that was not otherwise abnormally terminated.
< braunr> ?
< braunr> is it called or not ?
< braunr> runtime_exit is a macro on exit()
< braunr> so we already know what it does
< nlightnfotis> it is called
< braunr> ok
< braunr> that's not normal :)
< nlightnfotis> for a simple program
< braunr> uh ?
< nlightnfotis> for one that has a go routine
< braunr> but
< nlightnfotis> it doesn't
< nlightnfotis> it's expected
< braunr> ok
< braunr> that makes sense
< braunr> well, trace
< braunr> keep tracing
< braunr> for example in main()
< braunr> is runtime_mstart() actually reached ?
< nlightnfotis> yeah main and runtime_main were my next two targets
< braunr> good
< nlightnfotis> and now I followed your advice and it does compiler much
faster
< braunr> so, it looks like the main thread just becomes a mere kernel
thread
< braunr> running runtime_mstart() and fetching goroutines as needed
< braunr> after your traces, i'd suggest running a small go test program,
with one simple goroutine (doesn't crash right ?)
< braunr> and trace context switching
< braunr> but after the traces
< braunr> one important trace is to understand why runtime_exit gets called
< nlightnfotis> it does crash even with 1 goroutine
< braunr> oh
< braunr> when doesn't it crash ?
< nlightnfotis> when it has 0 goroutines
< nlightnfotis> it works as expected
< nlightnfotis> but anything involving goroutines crashes
< nlightnfotis> and goroutines are very important; everything in the
standard library involves goroutines
< braunr> ok
< braunr> doesn't change what i suggested, good
< braunr> 1/ find out why runtime_exit gets called
< braunr> 2/ trace context switching with 1 goroutine
< nlightnfotis> on it.
< braunr> in all cases, make all your goroutines (including the main one)
*not* return
< braunr> so that you don't deal with goroutine destruction yet
< nlightnfotis> runtime_mstart in main doesn't to be run at all. So the
path is __go_go and then return from it.
< nlightnfotis> *doesn't seem
IRC, freenode, #hurd, 2013-08-26
< braunr> youpi: my glibc clock patch looks incomplete btw
< youpi> which one?
< youpi> ah, the ticks one?
< braunr> yes
< braunr> it doesn't change the values returned by times
< braunr> as a side effect, the load average bumps to 2+ on an idle machine
IRC, freenode, #hurd, 2013-08-27
< nalaginrut> braunr: have you tried Guile2 on your machine? ;-)
< braunr> nalaginrut: no
< braunr> nalaginrut: but i saw the code actually does use sysconf()
< nalaginrut> braunr: yes, for ticks_per_second
< braunr> i had to look myself to find it out, you didn't say it, despite
me asking multiple times
< braunr> it won't make debugging easier ;p
< braunr> nalaginrut: also, the return value of times is actually *never*
used
< braunr> i don't know why you've been talking about it so much
< nalaginrut> braunr: I'm sorry, it's first time to look stime.c for me
< braunr> the interesting function is get_internal_run_time_times()
< nalaginrut> what do you mean about "the return value of times is actually
*never* used"? in which context?
< braunr> see get_internal_run_time_times
< braunr> struct tms time_buffer;
< braunr> times(&time_buffer);
< braunr> return ...
< braunr> and yes, the user and system time reported in struct tms are 0
< braunr> let's see what posix has to say about it
< pinotree> it says it will return (clock_t)-1 for errors, but no standard
errors are defined yet
< nalaginrut> but I don't think get_internal_run_time_times has something
to do with scm_times
< braunr> well, i don't see any other call to times()
< braunr> i've asked you repeatedly to look for how guile fetches the data
< braunr> i think it's done in get_internal_run_time_times
< braunr> what makes you think otherwise ?
< braunr> our times() seems to behave fine, other than the units of the
return value
< nalaginrut> I don't understand what do you mean?
get_internal_run_time_times is unrelated to scm_times which is actually
"times" in Scheme code
< braunr> ok
< nalaginrut> I think we're talking about "times" activity, right?
< braunr> ok so result is a vector
< braunr> with the return value and the four values in struct tms
< nalaginrut> yes
< braunr> and what looks interesting is
< braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
scm_from_long (ticks_per_second));
< braunr> SCM_SIMPLE_VECTOR_SET (result, 0, scm_product (scm_from_long
(rv), factor));
< braunr> TIME_UNITS_PER_SECOND is 1000
< nalaginrut> yes, it means (clock_t *
(TIME_UNITS_PER_SECOND/ticks_per_second)), though I've no idea why it
does this
< braunr> normalizing values i guess
< nalaginrut> I wonder if the factor should be 1, just guessing
< braunr> let's see what our clock tick really is
< braunr> 1000000 on an unmodified libc
< braunr> 100 with my patch
< nalaginrut> so what's the problem?
< nalaginrut> all the values were multiplied by ticks, it's fair for the
subtraction
< nalaginrut> I think the problem is clock is too large for the difference
between utime and utime(sleep 1)
< nalaginrut> oops, is too small
< nalaginrut> sorry, I confused,
< nalaginrut> the problem is the difference of clock is too large for
2*internal-time-units-per-second
< nalaginrut> and actually, internal-time-units-per-second is
SCM_TIME_UNITS_PER_SECOND
< nalaginrut> but without your patch, 'times' would return zeros all the
time, which is never meet the condition: SCM_TIME_UNITS_PER_SECOND/2 <=
(clock2 - clock1)
< nalaginrut> well, maybe your point is
TIME_UNITS_PER_SECOND/ticks_per_second is too small without your patch,
which causes the scm_to_long cast give a 0 value
< nalaginrut> s/cast/casting
< nalaginrut> when ticks_per_second is 100, the factor would be 10, which
seems to be reasonable
< nalaginrut> s/scm_to_long/scm_from_long
< nalaginrut> well, I have to checkout this
< nalaginrut> OK, let me reconstruct the point: ticks_per_second so too
large that makes the factor becomes zero
< nalaginrut> but decrease ticks_per_second to 100 causes the clock become
too large than TIME_UNITS_PER_SECOND
< braunr> 10:59 < nalaginrut> but without your patch, 'times' would return
zeros all the time, which is never meet the condition:
SCM_TIME_UNITS_PER_SECOND/2 <= (clock2 - clock1)
< braunr> until you prove me otherwise, this is plain wrong
< braunr> times() never returned me 0
< braunr> so let's see, this gives us a factor of 1000 / 1000000
< braunr> so the problem is factor being 0
< braunr> that's why *guile* times returns 0
< braunr> with my patch it should return 10
< nalaginrut> braunr: I'm sorry I mean "stime" in Scheme returns zeros
< nalaginrut> yes, I think the problem is factor
< nalaginrut> the factor
< braunr> now why doesn't my patch fix it all ?
< braunr> ah yes, rv is still in microseconds
< braunr> that's what i've been telling youpi recently, my patch is
incomplete
< braunr> i'll cook a quick fix, give me a few minutes please
< nalaginrut> but it fixed something ;-)
< braunr> well, guile makes a stupid assumption here
< braunr> so it's not really a fix
< nalaginrut> braunr: should I ask some info about TIME_UNITS_PER_SECOND
from Guile community?
< nalaginrut> or it doesn't help
< braunr> what do you want to ask them ?
< nalaginrut> since I don't know how this value was chosen
< nalaginrut> dunno, I'll ask if you need it
< nalaginrut> I just think maybe you need this info
< braunr> well
< braunr> my plan is to align the hurd on what other archs do
< braunr> i.e. set clk_tck to 100
< braunr> in which case this won't be a problem any more
< braunr> now you could warn them about the protability issue
< braunr> i'm not sure if they would care though
< nalaginrut> the warning is useful for the future
< nalaginrut> and it's not hard to make a change I think, for a constant,
but it depends on the maintainers
< braunr> it's not that simple
< braunr> time related things can easily overflow in the future
< nalaginrut> alright
< braunr> refer to the 2038 end-of-the-world bug
< nalaginrut> so how can I describe the warning/suggestion to them?
< braunr> i'm not sure
< braunr> tell them the TIME_UNITS_PER_SECOND isn't appropriate for larger
values of clk_tck
< braunr> dammit, microseconds are hardcoded everywhere in
sysdeps/mach/hurd ... >(
< braunr> nalaginrut: my new patch seems to fix the problem
< braunr> nalaginrut: i've built debian packages with which you can
directly test
< braunr> nalaginrut: deb http://ftp.sceen.net/debian-hurd-i386
experimental/
< braunr> Totals for this test run:
< braunr> passes: 38605
< braunr> failures: 0
< braunr> unexpected passes: 0
< braunr> expected failures: 7
< braunr> unresolved test cases: 578
< braunr> untested test cases: 1
< braunr> unsupported test cases: 10
< braunr> errors: 0
< braunr> PASS: check-guile
< braunr> =============
< braunr> 1 test passed
< braunr> =============
< braunr> :)
< braunr> youpi: the branch i added to glibc contains a working patch for
clock_t in centiseconds
< youpi> k
IRC, freenode, #hurd, 2013-08-28
<nalaginrut> braunr: well, looks great! I'll try it soon~
<nalaginrut> braunr: BTW, where is the patch/
<mark_weaver> braunr: what was needed to get guile working on the hurd?
<mark_weaver> well, if the fix wasn't to guile, I don't need the details.
<braunr> 04:53 < nalaginrut> braunr: BTW, where is the patch/
<braunr> there is hardly anyone here at 5am
<braunr> nalaginrut:
https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds
<nalaginrut> braunr: thanks for that, but why not use a constant for 100?
<braunr> nalaginrut: i don't know where to define it
<braunr> it's glibc, you don't define new stuff mindlessly
<youpi> braunr: about your centiseconds patch, did you run the libc
testsuite with it?
<mark_weaver> it does seem a shame to reduce the resolution of the timers
from microseconds to centiseconds. I wonder if that could be avoided.
<youpi> by fixing all applications which assume centiseconds
<mark_weaver> *nod* well, if there's such a problem in Guile, I'd be glad
to fix that.
<braunr> youpi: no
<mark_weaver> I see that there's a macro CLOCKS_PER_SEC that programs
should consult.
<youpi> braunr: ok, I'll do then
<braunr> mark_weaver: why is it a shame ?
<braunr> it's not clock or timer resolution
<youpi> it's clock_t resolution
<braunr> it's an obsolete api to measure average cpu usage
<braunr> having such a big value on the other hand reduces the cpu usage
durations
<mark_weaver> braunr: good point :) I confess to being mostly ignorant of
these APIs.
<mark_weaver> Though Guile should still consult CLOCKS_PER_SEC instead of
assuming centiseconds. If it's making an improper assumption, I'd like
to know so I can fix it.
<braunr> the improper assumption is that there are less than 1000 clock
ticks per second
<mark_weaver> do you know off-hand of some code in Guile that is making
improper assumptions?
<braunr> yes
<braunr> let me find it
<mark_weaver> thanks
<braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
<braunr> scm_from_long (ticks_per_second));
<braunr> it seems guile attempts to normalize all times values to
TIME_UNITS_PER_SECOND
<braunr> while i think it would be better off using ticks_per_second (clock
ticks as provided by sysconf())
<braunr> attempting to normalize here causes factor to become 0 if
TIME_UNITS_PER_SECOND < ticks_per_second
<mark_weaver> ah, I see.
<mark_weaver> I'll take care of it. thanks for the pointer!
<youpi> braunr: I've commited the centisecond patch to debian's glibc
IRC, freenode, #hurd, 2013-08-29
<nalaginrut> braunr: Guile2 works smoothly now, let me try something cool
with it
<braunr> nalaginrut: nice
IRC, OFTC, #debian-hurd, 2013-09-29
<pinotree> youpi: is the latest glibc carrying the changes related to
timing? what about gb guile-2.0 with it?
<youpi> it does
<youpi> so that was the only issue with guile?
<youpi> well at least we'll see
<pinotree> iirc yes
<pinotree> according to nalaginrut and the latest build log, it'd seem so
<youpi> started
<youpi> yay, guile-2.0 :)
<pinotree> yay
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.
IRC, freenode, #hurd, 2013-10-10
<sea`> Huh? I've cloned the 'hurd' repository and I'm attempting to compile
it, but the 'rtnetlink.h' header in
'hurd/pfinet/linux-src/include/linux/' is just blank. (Which leads to an
error later down when a macro that's supposed to be defined in there is
first used)
<sea`> So I'm just wondering, is that file really blank? Or is this some
unexpected error of decompression?
<braunr> clone again and see
<braunr> the file is definitely not empty
<sea`> I cloned it twice, both have that file blank. BUT, I want to point
out that both clones do have some decompression errors. (Some files are
missing chunks in /both/ cloned repositories).
<braunr> where did you clone it from ?
<sea`> git.sv.gnu.org/hurd/hurd.git
<braunr> hum decompression errors ?
<braunr> can you paste them please ?
<sea`> Hmm, I can clone again and show you an example if I find one
<sea`> This was on the hurd. When I run: git clone $repo;, it seems to fail
almost randomly with "incorrect header check", but when it does succeed,
occasionally some files are missing chunks
<sea`> and apparently entire files can be blank
<braunr> http or git ?
<sea`> git.
<braunr> that's really weird
<braunr> actually i don't even have problems with http any more nowadays ..
<sea`> This is using the hurd image from sthibault
<sea`> So once I get it recompiled and shuffle in the new binaries, the
problem should probably go away
<braunr> no
<braunr> well maybe but
<braunr> don't recompile
<braunr> upgrade packages instead
<sea`> Alright, I'll do an upgrade instead. Why that path specifically?
<braunr> rebuilding is long
<braunr> i wonder if the image you got is corrupted
<braunr> compute the checksum
<braunr> we've had weird reports in the past about the images he provides
<braunr> well not the images themselves, but differences after dowloading
..
<braunr> downloading*
<sea`> The MD5SUMS file on his site isn't including the values for the most
recent images.
<sea`> It stops at 2012-12-28
<braunr> hummm
<sea`> Anyway, let's see. git clone failed again:
<sea`> Receiving objects: 100% (50955/50955), 15.48 MiB | 42 KiB/s, done.
<sea`> error: inflate: date stream error (incorrect header check) <- This
is the interesting part
<sea`> fatal: serious inflate inconsistency
<sea`> fatal: index-pack failed
<braunr> not intereseting enough unfortunately
<braunr> but it might come from savannah too
<sea`> Ehm. The whole thing locked up badly. I'll reboot it and try again.
<braunr> are you sure it locked oO ?
<braunr> the hurd can easily become unresponsive when performing io
operations
<braunr> but you need more than such a git repository to reach that state
<sea`> Yeah, that happens occasionally. It's not related to git, but rather
it happens when I cancel some command.
<braunr> your image must be corrupted
<braunr> have you enabled host io caching btw ?
<sea`> By now it's corrupted for sure..everytime it crashes the filesystem
gets into a weird state.
<sea`> I'll unpack a fresh image, then update the packages, and then try
cloning this git repository.
<braunr> i'll get the image too so we can compare sums
<sea`> 957bb0768c9558564f0c3e0adb9b317e ./debian-hurd.img.tar.gz
<sea`> Which unpacks to: debian-hurd-20130504.img
<azeem_> the NSA might backdoor the Hurd, in anticipation of our scheduled
world-dominance
<braunr> for now they're doing it passively :
<braunr> :p
<braunr> sea`: same thing here
<braunr> sea`: if you still have problems, the image itself might be wrong
<braunr> in which case you should try with the debian network installer
<sea`> Ah, so if problems persist, try with the network installer. Okay
<sea`> Is there some recipe for constructing a hurd/mach minimal
environment?
<sea`> A system with only just enough tools and libraries to compile and
poke at things.
<braunr> not currently
<braunr> we all work in debian environments
<braunr> the reason being that a lot of patches are queued for integration
upstream
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->procdostoprequest ( 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.
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.