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.

Add a new item titled:

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.

Posted 2018-11-01 02:18:59 CET Tags:

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.

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)

Posted 2016-11-01 15:57:30 CET Tags:

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
<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 :)
Posted 2013-09-25 21:59:24 CEST Tags:

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.

Posted 2013-07-03 09:16:51 CEST Tags:

IRC, OFTC, #debian-hurd, 2012-12-16

<pinotree> or
<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
Posted 2013-01-08 21:31:31 CET Tags:

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,
<pinotree> (possibly i'm forgetting some already there features to know
<braunr> the socket state is centralized in pfinet
<braunr> netstat polls it
<braunr> (or asks it once)
Posted 2012-12-11 11:54:54 CET Tags:

IRC, freenode, #hurd, 2012-12-05

<braunr> rbraun   18813 R        2hrs ln -sf ../af_ZA/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:
<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
<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 ?
<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
<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
<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
<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
<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 :)
Posted 2012-12-11 11:54:54 CET Tags:

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)

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.
Posted 2012-03-20 22:45:31 CET Tags:
Posted 2012-03-18 15:20:18 CET Tags:

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.

Posted 2012-03-17 12:21:08 CET Tags:


ImpulseTracker clone aiming at providing the same look&feel.
Home page:


  • Started: -
  • Discussed: -
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


Fix gphoto2-settings.c:gp_setting_get() to accept NULL pointer and do the allocation.
This is a requirement for gphoto2 patch.


Not yet started.

Posted 2012-02-07 17:03:42 CET Tags:


ImpulseTracker clone aiming at providing the same look&feel.
Home page:


  • Started: -
  • Discussed: -
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


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) {


Not yet started.

Looks like a lot, but most of them, if not all, are trivial.

Posted 2012-02-07 17:03:42 CET Tags:


Microblogging plugins for Pidgin.
Home page:


  • Started: -
  • Discussed: -
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


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.


Not yet started.

Posted 2012-02-07 17:03:42 CET Tags:


Runs a command and optionally reports its output by mail.
Home page:


  • Started: -
  • Discussed: -
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


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));


Not yet started.

Posted 2012-02-07 17:03:42 CET Tags:


The gphoto2 digital camera command-line client.
Home page:


  • Started: -
  • Discussed: -
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


Only one file relies on PATH_MAX: gphoto2/main.c
First need to patch libgphoto2 package.


Not yet started.

Posted 2012-02-07 17:03:42 CET Tags:


A program for managing a WWW site via FTP, DAV or HTTP.
Home page:


  • Started: -
  • Discussed: -
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


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];


Not yet started.

One of the PATH_MAX if used in debian patch.

Posted 2012-02-07 17:03:42 CET Tags:


Simple but powerful libvte-based terminal emulator.
Home page:


  • Started: 2012-02-03
  • Discussed: 2012-02-03
  • Draft Submitted: -
  • Submitted: 2012-02-07, Bug#659018
  • Accepted: 2012-02-12, by Andrew Starr-Bochicchio


Here is the output of grep -R PATH_MAX sakura-2.4.2/*:

src/sakura.c:                char buf[PATH_MAX+1];


+                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.

Posted 2012-02-03 16:26:45 CET Tags:


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).


  • Started: 2012-01-28
  • Discussed: 2012-01-30
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


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];


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.

Posted 2012-02-02 15:05:38 CET Tags:


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:


  • Started: 2012-01-31
  • Discussed: 2012-02-03
  • Draft Submitted: -
  • Submitted: -
  • Accepted: -


Here is the output of grep -R PATH_MAX up-imapproxy-1.2.7/*:

src/main.c:    char f_randfile[ PATH_MAX ];


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.

Posted 2012-02-02 15:05:38 CET Tags:


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.


  • Started: 2012-01-24
  • Discussed: 2012-01-26
  • Draft Submitted: -
  • Submitted: 2012-02-07, Bug#659025
  • Accepted: 2013-05-13, by Barry deFreese


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);


+++ 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();
+    }
Posted 2012-02-02 15:05:38 CET Tags:

TI-RPC replaces glibc's Sun RPC implementation, id:"".

It needs some work on our side, id:"".

Then, the Hurd's nfs translator and ?nfsd can be re-enabled, id:"".

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: >.
<braunr> "The IPV6_PORTRANGE socket option and the conflict resolution rule
  are not defined in the RFCs and should be considered implementation
<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: >
  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: >, 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> 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

<pere> <URL: > 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:
<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: >.  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: >.
  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
<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
<pere> gnu_srs: sound like a good idea.  perhaps a good idea to just
  disable the two patches as a start.
Posted 2011-11-04 22:53:40 CET Tags:

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
< youpi> zyg: mach/i386/mach_i386.h
< youpi> the descriptor structure
Posted 2011-09-01 09:27:33 CEST Tags:

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(
        at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(
        at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(
        at java.nio.file.FileSystems$DefaultFileSystemHolder$
        at java.nio.file.FileSystems$DefaultFileSystemHolder$
        at Method)
        at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(
        at java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(
        at java.nio.file.FileSystems.getDefault(
        at sun.util.calendar.ZoneInfoFile$
        at sun.util.calendar.ZoneInfoFile$
        at Method)
        at sun.util.calendar.ZoneInfoFile.<clinit>(
        at sun.util.calendar.ZoneInfo.getTimeZone(
        at java.util.TimeZone.getTimeZone(
        at java.util.TimeZone.setDefaultZone(
        at java.util.TimeZone.getDefaultRef(
        at java.util.TimeZone.getDefault(
        at java.text.SimpleDateFormat.initializeCalendar(
        at java.text.SimpleDateFormat.<init>(
        at java.text.DateFormat.get(
        at java.text.DateFormat.getDateTimeInstance(
make[3]: *** [org/GNOME/Accessibility/] 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 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"
Posted 2011-07-08 22:35:03 CEST Tags:

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 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 case (and what about 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?

Posted 2011-07-06 00:50:43 CEST Tags:
$ 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 $?

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 $?

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


-> git-core-2

Posted 2011-06-13 16:44:12 CEST Tags:
$ git-new-workdir /media/kepler-data/home/thomas/tmp/source/binutils/git master master
fatal: Out of memory? mmap failed: No such device
$ echo $?
$ showtrans /media/kepler-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.

Posted 2011-06-10 18:47:19 CEST Tags:

Open Issues

  • Debian bug #616290

  • Proper Hurdy DHCP support

  • 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
    <teythoon> I have no idea
    <gnu_srs> The Hurd patches are not in 4.2.5, they were promised for
    <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 tip

    IRC, freenode, #hurd, 2013-08-30:

    <tschwinge> teythoon: I understand correctly that you found that
      id:"" 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 failed

    IRC, freenode, #hurd, 2014-01-03:

    <congzhang> dhcp 4.3 alpha released
    <congzhang> and PATH_MAX issue was fixed

    IRC, 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
    <teythoon> there was, but it does not seem to build on the hurd
    <teythoon> the most recent version is from debian-ports

    IRC, freenode, #hurd, 2014-01-24:

    <braunr> stack smashing detected ***: dhclient terminated
    <braunr> how nice
    <tschwinge> braunr: dhclient:
    <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
    <braunr> tschwinge: you mean the dhclient one µ?
    <tschwinge> Yes.
    <braunr> mhm
    <teythoon> braunr, tschwinge: i never found the cause of the dhclient
    <teythoon> i blame the (outdated) build on debian-ports

    IRC, 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
    <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
  • 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
    <gg0> exim was complaining 2014-02-23 22:26:41 IPv6 socket creation
      failed: Address family not supported by protocol
Posted 2011-05-20 20:14:58 CEST Tags:

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...)


<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
Posted 2010-12-01 20:00:58 CET Tags:

IRC, freenode, #hurd, 2015-02-09

<Andre_H> since Wine 1.7.28 it runs quite well on Gnu/Hurd -
<Andre_H> ( )

IRC, freenode, #hurd, 2014-01-11

<gnu_srs1> Andre_H: Looks like the two committed patches did not go into
<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 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 (not yet upstream) or see

<braunr> Andre_H: thanks for your report
<Andre_H> np :)
<Andre_H> braunr: can someone update 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: :)

<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:
<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
<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, 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
<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


< 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
< 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>
< 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 and
  related links I assume?

sendmsg scm creds

< 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.

Posted 2010-11-29 17:08:30 CET Tags:

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


Last reviewed up to Git commit d6c34577eeaba37ff08998d18676531082c040b6 (2016-03-18), and for libatomic_ops to Git commit 01d2509c13f3aa7e03cb4cbf50fda08f98725ce4 (2016-03-24).


    • PARALLEL_MARK is not enabled; doesn't make sense so far.

    • *-*-kfreebsd*-gnu defines USE_COMPILER_TLS. What's this, and why does not other config?

    • TODO

      [ if test "$enable_gc_debug" = "yes"; then
          AC_MSG_WARN("Should define GC_DEBUG and use debug alloc. in clients.")
          AC_DEFINE([KEEP_BACK_PTRS], 1,
                    [Define to save back-pointers in debugging headers.])
          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_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])


  •, include/, cord/, doc/, tests/


  • include/gc_config_macros.h

    Should be OK.

  • include/private/gcconfig.h

    Hairy. But should be OK. Search for HURD, compare to LINUX, I386 case.

    See doc/porting.html and doc/README.macros (and others) for documentation.

    LINUX has:


      Defined instead of STACKBOTTOM to have the value read from /proc/.

    • #define HEAP_START (ptr_t)0x1000

      May want to define it for us, too?

    • #ifdef USE_I686_PREFETCH, USE_3DNOW_PREFETCH --- [...]

      Apparently these are optimization that we also could use. Have a look at LINUX for X86_64, which uses __builtin_prefetch (which Linux x86 could use, too?).

    • TODO

      #if defined(LINUX) && defined(USE_MMAP)
          /* The kernel may do a somewhat better job merging mappings etc.    */
          /* with anonymous mappings.                                         */
      #   define USE_MMAP_ANON
    • 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
    • TODO

      # if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) \
           && !defined(INCLUDE_LINUX_THREAD_DESCR)
          /* Will not work, since libc and the dynamic loader use thread      */
          /* locals, sometimes as the only reference.                         */
      # endif
    • TODO

      # if defined(UNIX_LIKE) && defined(THREADS) && !defined(NO_CANCEL_SAFE) \
           && !defined(PLATFORM_ANDROID)
          /* Make the code cancellation-safe.  This basically means that we   */
          /* ensure that cancellation requests are ignored while we are in    */
          /* the collector.  This applies only to Posix deferred cancellation;*/
          /* we don't handle Posix asynchronous cancellation.                 */
          /* Note that this only works if pthread_setcancelstate is           */
          /* async-signal-safe, at least in the absence of asynchronous       */
          /* cancellation.  This appears to be true for the glibc version,    */
          /* though it is not documented.  Without that assumption, there     */
          /* seems to be no way to safely wait in a signal handler, which     */
          /* we need to do for thread suspension.                             */
          /* Also note that little other code appears to be cancellation-safe.*/
          /* Hence it may make sense to turn this off for performance.        */
      #   define CANCEL_SAFE
      # endif
    • CAN_SAVE_CALL_ARGS vs. -fomit-frame-pointer now being on by default for Linux x86 IIRC? (Which is an open issue gcc for not including us.)

    • TODO

      # if defined(REDIRECT_MALLOC) && defined(THREADS) && !defined(LINUX)
      #   error "REDIRECT_MALLOC with THREADS works at most on Linux."
      # endif
    • TODO

      #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

      Also see comment below, regarding mach_dep.c.

    HURD has:

    • #define STACK_GROWS_DOWN

    • #define HEURISTIC2

      Defined instead of STACKBOTTOM to have the value probed.

      Linux also has this:

      #if defined(LINUX_STACKBOTTOM) && defined(NO_PROC_STAT) \
          && !defined(USE_LIBC_PRIVATES)
          /* This combination will fail, since we have no way to get  */
          /* the stack base.  Use HEURISTIC2 instead.                 */
      #   undef LINUX_STACKBOTTOM
      #   define HEURISTIC2
          /* This may still fail on some architectures like IA64.     */
          /* We tried ...                                             */

      Being on glibc, we could perhaps do similar as USE_LIBC_PRIVATES instead of HEURISTIC2. Pro: avoid SIGSEGV (and general fragility) during probing at startup (if I'm understanding this correctly). Con: rely on glibc internals. Or we instead add support to parse /proc/ (can even use the same as Linux?), or use some other interface.
      This is also likely the issue causing the GDB GC_find_limit_with_bound SIGSEGV startup confusion described in binutils.


    • We don't #define MPROTECT_VDB (WIP comment); but Linux neither.

    • Where does our GETPAGESIZE come from? Should we #include <unistd.h> like it is done for LINUX?

    • [Hurd] Use mmap instead of sbrk,

  • include/gc_pthread_redirects.h

    • TODO

      Cancellation stuff is Linux-only. In other places, too.

  • mach_dep.c

    • #define NO_GETCONTEXT

      open 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_pushed

      The HAVE_BUILTIN_UNWIND_INIT case is ours.

  • os_dep.c

    • TODO.
  • dyn_load.c


  • pthread_support.c, pthread_stop_world.c


  • TODO.

    Other files also contain LINUX and other conditionals.

  • libatomic_ops/



    • Makefile, src/Makefile, src/atomic_ops/Makefile, src/atomic_ops/sysdeps/Makefile, doc/Makefile, tests/Makefile


    • src/atomic_ops/sysdeps/gcc/x86.h


  • b8b65e8a5c2c4896728cd00d008168a6293f55b1 probably not all correct.

  • mmap, b64dd3bc1e5a23e677c96b478d55648a0730ab75

    This is (still) stale/redundant/unused, as far as I can tell.

  • parallel mark, 07c2b8e455c9e70d1f173475bbf1196320812154, pass --disable-parallel-mark or enable for us, too?

  • HANDLE_FORK, e9b11b6655c45ad3ab3326707aa31567a767134b, 806d656802a1e3c2b55cd9e4530c6420340886c9, 1e882b98c2cf9479a9cd08a67439dab7f9622924

  • Check include/private/thread_local_alloc.h re USE_COMPILER_TLS/USE_PTHREAD_SPECIFIC.

  • 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+}
    • 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
      {+#if defined(CAN_HANDLE_FORK) && !defined(CAN_CALL_ATFORK) \+}
      {+    && !defined(HURD) && !defined(PLATFORM_ANDROID)+}
      {+  /* Have working pthread_atfork().     */+}
      {+# define CAN_CALL_ATFORK+}
    • 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+}
    • 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;+}
      #           endif
    • diff --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) */


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.


$ 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."


$ make install 2>&1 | tee log_install


$ toolchain/logs/process boehm-gc install


$ make -k check 2>&1 | tee log_test
$ (cd libatomic_ops/ && make -k check) 2>&1 | tee log_test_


$ 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.



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
<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,
<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
<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> (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> d_name should be char[PATH_MAX]?
<congzhang> and
<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
Posted 2010-11-17 21:29:41 CET Tags:

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,
<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
<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.

Posted 2010-10-07 11:33:17 CEST Tags:

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:
<kahmalo> or to one of our mailing lists.
<kahmalo> I guess the pflocal select() bug is the primary hindrance to running ELinks on the Hurd.  Has any decision been made on how that will be fixed?
Posted 2010-07-24 12:23:41 CEST Tags:
<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)
Posted 2009-10-23 08:49:26 CEST Tags:

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"';;

... 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.

Posted 2009-10-08 14:50:56 CEST Tags:

Typing C-c (SIGINT) in a screen session (Debian package 4.0.3-14; -11 is fine):

  • shell prompt: no reaction (nothing printed)
  • sleep 10 running: ^C printed, but SIGINT is not sent.

Debian bug #522689#38.

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
-/* #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 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 @@

 #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));

 #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.

Posted 2009-10-06 23:37:48 CEST Tags:
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 <>  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
Posted 2009-10-01 23:27:18 CEST Tags:

GNU Emacs mostly does work, however there are a few issues.


Emacs version 27.1 runs on Debian GNU/Hurd, but it does not run super smoothly on the Hurd console. Emacs will run in the Hurd console, but not as well. These three commands kill emacs in the Hurd console pretty reliably:

 (use-package magit :ensure t)
 M-x package-list-packages
 M-x find-file ~/.authinfo.gpg

Emacs does runs much better under X. Most things work well: org-mode, gnus, erc, etc.

You can easily install many Emacs packages with apt:

 # apt install elpa-zenburn-theme
Posted 2009-08-18 12:36:14 CEST Tags:

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.

Posted 2009-08-18 12:33:11 CEST Tags:


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.


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).


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.



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
<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://
<teythoon> and yes, the kernel is involved
<teythoon> task_info is used to obtain the actual values
<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,
<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
<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
<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:
<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
< 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
< 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>
< 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
< 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
  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:
< 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) <=
< 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:
< 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
< 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
< 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) *
< 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
< 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
< 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
< 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
< 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
< 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
< 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
< 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
< 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
< 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>,
  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
< braunr> so, it looks like the main thread just becomes a mere kernel
< 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*
< 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
< 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
< nalaginrut> and actually, internal-time-units-per-second is
< 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
< 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
< 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:
<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
<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
<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
Posted 2009-07-07 22:48:47 CEST Tags:


On the otherwise-idle flubber:

$ git clone 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)


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 ?
<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
<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
<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
<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


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/' (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/ gcc/config/lm32/lm32.c
ls: cannot access gcc/config/iq2000/ 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



$ 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


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)



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


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
<braunr> i could clone big repositories without any problem
<youpi> cool :)
Posted 2009-05-19 12:01:42 CEST Tags:

The runit package doesn't work, even its test suite doesn't finish.

Thomas Schwinge once was having a look at that, but this very report is just from his memory, and his memory is dim... The problem might either be a time stamping issue (which might be fixed by now) or it might be the select call failing issue we're seeing from time to time. Or something else.

?Harish Badrinath Originally answered by Samuel Thibault:

120->proc_dostop_request ( 138) = 0

Usual issue with rpctrace: it does not support fork().

I've checked a backtrace in gdb, got this:

 0x0105af6c in mach_msg_trap ()
   at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
1  0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140,
   timeout=1000020, notify=0) at msg.c:110
2  0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0,
   timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324
3  0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48
4  0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29
5  0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543

and main() shows up as:

 ->  iopause(x, 2 +haslog, &deadline, &now);

So it simply looks like the known "signals don't interrupt select" bug.

Posted 2009-05-19 12:01:42 CEST Tags:

socat needs porting. Some work has already been done in 2007, see or contact Thomas Schwinge.

Posted 2009-05-19 12:01:42 CEST Tags:

GFDL 1.2+

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.