From 0a12a6b7404b6d861b44372632f3b302c404d05e Mon Sep 17 00:00:00 2001 From: Ahsan Date: Tue, 19 Feb 2019 03:28:44 +0100 Subject: --- open_issues/glibc.mdwn | 3453 ------------------------------------------------ 1 file changed, 3453 deletions(-) (limited to 'open_issues') diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 55bf9031..8b137891 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -1,3454 +1 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2014, 2015, -2016 Free Software Foundation, Inc."]] -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc]] - -Here's what's to be done for maintaining glibc. - -[[!toc levels=2]] - - -# [[General information|/glibc]] - - * [[Versioning]] - - -# [[Sources|source_repositories/glibc]] - - -# [[Debian Cheat Sheet|debian]] - - -# Configuration - - - -Last reviewed up to the [[Git mirror's 9a869d822025be8e43b78234997b10bf0cf9d859 -(2014-02-07) sources|source_repositories/glibc]]. - - * `t/hurdsig-fixes` - - hurdsig.c: In function '_hurd_internal_post_signal': - hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] - hurdsig.c:1168:12: note: 'pending' was declared here - - * `t/host-independency` - - [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id - "20120525202732.GA31088@intel.com"]], commit - 918b56067a444572f1c71b02f18255ae4540b043. [[!GCC_PR 53183]], GCC commit - c05436a7e361b8040ee899266e15bea817212c37. - - * `t/pie-sbrk` - - [[gcc/PIE]]. - - * `t/sysvshm` - - ../sysdeps/mach/hurd/shmat.c: In function '__shmat': - ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] - ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive': - ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable] - ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized] - ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized] - - * [[`t/tls`|t/tls]] - - * [[`t/tls-threadvar`|t/tls-threadvar]] - - * `t/verify.h` - - People didn't like this too much. - - Other examples: - - * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert` - - * [[toolchain/cross-gnu]], without `--disable-multi-arch` - - i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...] - ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages: - ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined - make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1 - make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string' - - Might simply be a missing patch(es) from master. - - * `--disable-multi-arch` - - IRC, freenode, #hurd, 2012-11-22 - - tschwinge: is your glibc build w/ or w/o multiarch? - pinotree: See open_issues/glibc: --disable-multi-arch - ah, because you do cross-compilation? - No, that's natively. - There is also a not of what happened in cross-gnu when I - enabled multi-arch. - No idea whether that's still relevant, though. - EPARSE - s%not%note - Better? - yes :) - As for native builds: I guess I just didn't (want to) play - with it yet. - it is enabled in debian since quite some time, maybe other - i386/i686 patches (done for linux) help us too - I though we first needed some CPU identification - infrastructe before it can really work? - I thought [...]. - as in use the i686 variant as runtime automatically? i guess - so - I thought I had some notes about that, but can't currently - find them. - Ah, I probably have been thinking about open_issues/ifunc - and open_issues/libc_variant_selection. - - * --build=X - - `long double` test: due to `cross_compiling = maybe` wants to execute a - file, which fails. Thus `--build=X` has to be set. - - * Check what all these are: - - running configure fragment for sysdeps/mach/hurd - checking Hurd header version... ok - running configure fragment for sysdeps/mach - checking for i586-pc-gnu-mig... i586-pc-gnu-mig - checking for mach/mach_types.h... yes - checking for mach/mach_types.defs... yes - checking for task_t in mach/mach_types.h... task_t - checking for thread_t in mach/mach_types.h... thread_t - checking for creation_time in task_basic_info... yes - checking for mach/mach.defs... yes - checking for mach/mach4.defs... yes - checking for mach/clock.defs... no - checking for mach/clock_priv.defs... no - checking for mach/host_priv.defs... no - checking for mach/host_security.defs... no - checking for mach/ledger.defs... no - checking for mach/lock_set.defs... no - checking for mach/processor.defs... no - checking for mach/processor_set.defs... no - checking for mach/task.defs... no - checking for mach/thread_act.defs... no - checking for mach/vm_map.defs... no - checking for mach/memory_object.defs... yes - checking for mach/memory_object_default.defs... yes - checking for mach/default_pager.defs... yes - checking for mach/i386/mach_i386.defs... yes - checking for egrep... grep -E - checking for host_page_size in mach_host.defs... no - checking for mach/machine/ndr_def.h... no - checking for machine/ndr_def.h... no - checking for i386_io_perm_modify in mach_i386.defs... yes - checking for i386_set_gdt in mach_i386.defs... yes - checking whether i586-pc-gnu-mig supports the retcode keyword... yes - - * `sysdeps/i386/stackguard-macros.h` - - See [[t/tls|t/tls]]. - - * Verify 77c84aeb81808c3109665949448dba59965c391e against - `~/shared/glibc/make_TAGS.patch`. - - * `HP_SMALL_TIMING_AVAIL` not defined anywhere. - - * Unify `CPUCLOCK_WHICH` stuff in `clock_*` files. - - * Not all tests are re-run in a `make -k tests; make tests-clean; make -k - tests` cycle. For example, after `make tests-clean`: - - $ find ./ -name \*.out - ./localedata/tst-locale.out - ./localedata/sort-test.out - ./localedata/de_DE.out - ./localedata/en_US.out - ./localedata/da_DK.out - ./localedata/hr_HR.out - ./localedata/sv_SE.out - ./localedata/tr_TR.out - ./localedata/fr_FR.out - ./localedata/si_LK.out - ./localedata/tst-mbswcs.out - ./iconvdata/iconv-test.out - ./iconvdata/tst-tables.out - ./stdlib/isomac.out - ./posix/wordexp-tst.out - ./posix/annexc.out - ./posix/tst-getconf.out - ./elf/check-textrel.out - ./elf/check-execstack.out - ./elf/check-localplt.out - ./c++-types-check.out - ./check-local-headers.out - ./begin-end-check.out - - * `CPUCLOCK_WHICH`, `t/cpuclock` - - /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime': - /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH' - /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH' - collect2: error: ld returned 1 exit status - make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1 - make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt' - make[1]: *** [rt/others] Error 2 - make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' - make: *** [all] Error 2 - - * Missing Interfaces - - We have posted a [[Google Summer of Code project proposal|community/gsoc]]: - - [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no - actions=yes]] - - Many are missing for GNU Hurd, some of which have been announced in - [`NEWS`](https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS), others - typically haven't (like new flags to existing functions). Typically, - porters will notice missing functionaly. But in case you're looking for - something to work on, here's a bit of a commented list, otherwise go - looking in `/usr/include/i386-gnu/gnu/stubs.h` on a Debian GNU/Hurd system, - or the respective file from a fresh glibc build. - - `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`, - `CLOCK_REALTIME_ALARM`, `O_PATH`, `O_TMPFILE` - (ffdd31816a67f48697ea4d6b852e58d2886d42ca), - `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27, - b1b2aaf8eb9eed301ea8f65b96844568ca017f8b, - 521c6785e1fc94d1f501743e9a40af9e02797df3), - `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) - `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, - `open_by_handle_at`, - `posix_openpt`, `process_vm_readv`, `process_vm_writev`, - `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several - `MAP_*`|glibc/mmap]] - - Check also the content of `gnu/stubs.h`, which lists all the functions - marked as stub which only return `ENOSYS`. - - * `chflags` - - Patch sent, [[!message-id "20120427012130.GZ19431@type.famille.thibault.fr"]]. - - IRC, OFTC, #debian-hurd, 2012-04-27: - - Does anyone have any idea why int main(void) { return - chflags(); } will compile with gcc but not with g++ ? It says - that "chflags" was not declared in this scope. - I get the same error on FreeBSD, but including sys/stat.h - makes it work - Can't find a solution on Hurd though :/ - the Hurd doesn't have chflags - apparently linux neither - what does it do? - change flags :) - Are you sure the Hurd does not have chflags ? Because gcc - does not complain - there is no chflags function in /usr/include - but what flags does it change? - According to the FreeBSD manpage, it can set flags such as - UF_NODUMP, UF_IMMUTABLE etc. - Hum, there is actually a chflags() definition - but no declaration - so actually chflags is supported, but the declaration was - forgotten - probably because since linux doens't have it, it has never - been a problem up to now - so I'd say ignore the error for now, we'll add the - declaration - - * [[t/tls-threadvar]] - - * `futimesat` - - If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`. - - * `futimens` - - IRC, freenode, #hurd, 2014-02-09: - - it seems apt 0.9.15.1 has troubles downloading packages - etc., as opposed to apt 0.9.15 - ah, that version uses futimens unconditionally - and we haven't implemented that yet - did somebody file a bug for that apt-get issue? - I haven't - I'll commit the fix in eglibc - but perhaps a bug report would be good for the kfreebsd - case - - * `bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT` - - * `io/fcntl.h [__USE_ATFILE]` - - Do we support `AT_FDCWD` et al.? - (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.) - - * `t/opendirat`: `opendirat` (`scandirat`, `scandirat64`) - - Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 + - 14d96785125abee5e9a49a1c3037f35a581750bd. - - * `madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP` - - [[glibc_madvise_vs_static_linking]]. - - IRC, OFTC, #debian-hurd, 2013-09-09: - - does hurd MADV_DONTNEED or MADV_FREE or none? - http://sources.debian.net/src/jemalloc/3.4.0-1/include/jemalloc/jemalloc_defs.h.in#L239 - seems it builds by defining JEMALLOC_PURGE_MADVISE_DONTNEED - but i don't know what i'm talking about, so it could build with - JEMALLOC_PURGE_MADVISE_FREE as well - - IRC, OFTC, #debian-hurd, 2013-09-10: - - gg0: it implements none, even if it defines DONTNEED (but - not FREE) - - See also: - - gnash (0.8.11~git20130903-1) unstable; urgency=low - - * Git snapshot. - + Embedded jemalloc copy has been replaced by system one. - [...] - - Disable jemalloc on hurd and kfreebsd-*. No longer disabled upstream. - - * `msync` - - Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`. - - * `epoll`, `sys/epoll.h` - - Used by [[wayland]], for example. - - IRC, freenode, #hurd, 2013-08-08: - - is there any possible to have kquque/epoll alike - things in hurd? or there is one? - nalaginrut: use select/poll - is it possible to implement epoll? - it is - we don't care enough about it to do it - (for now) - well, since I wrote a server with Guile, and it could - take advantage of epoll, never mind, if there's no, it'll use - select automatically - but if someday someone care about it, I'll be - interested on it - epoll is a scalability improvement over poll - the hurd being full of scalability issues, this one is - clearly not a priority - ok - - IRC, freenode, #hurd, 2013-09-26: - - if I want to have epoll/kqueue like things, where - should it dwell? kernel or some libs? - libs - userland - that would be a good project to work on, something i - intended to do (so i can help) but it requires a lot of work - you basically need to add a way to explicitely install and - remove polling requests (instead of the currently way that - implicitely remove polling requests when select/poll returns) - while keeping the existing way working for some time - glibc implements select - the hurd io interface shows the select interface - servers such as pfinet/pflocal implement it - glibc implements the client-side of the call - where's poll? since epoll just added edge-trigger in - poll - both select and poll are implemented on top of the hurd io - select call (which isn't exactly select) - - http://git.sceen.net/hurd/hurd.git/plain/hurd/io.defs - this is the io interface - - http://git.sceen.net/hurd/glibc.git/tree/hurd/hurdselect.c?h=tschwinge/Roger_Whittaker - this is the client side implementation - - IRC, freenode, #hurd, 2014-02-14: - - also: do you know if hurd has a modern-day poll() - replacement? ala epoll, kqueue, iocp, port_create(), etc? - last thing I remember was that there was no epoll - equivalent, but that was a few years ago :) - braunr: ^ - * desrt is about to replace gmaincontext in glib with something - more modern - * desrt really very much wants not to have to write a poll() - backend.... - it seems that absolutely every system that i care about, - except for hurd, has a new approach here :/ - even illumos has solaris-style ports - desrt: I suggest you bring up the question on bug-hurd - the poll() system call there to satisfy POSIX, but there - might be a better Hurd-specific thing you could use - is there* - that would be ideal - i have to assume that a system that passes to many messages - has some other facilities :) - *so many - the question is if they work with fds.... - bug-hurd doesn't seem like a good place to ask open-ended - questions.... - it's the main development lists, it's just old GNU naming - list* - k. thanks. - bug-hurd@gnu.org is the address - * desrt goes to bug... hurd - written. thanks. - desrt: the hurd has only select/poll - it suffers from so many scalability issues there isn't - much point providing one currently - we focus more on bug fixing and posix compliance right now - fair answer - you should want a poll-based backend - it's the most portable one, and doesn't suck as much as - select - very easy to write - although, internally, our select/poll works just like a - bare epoll - i.e. select requests are installed, the client waits for - one or more messages, then uninstalls the requests - - IRC, freenode, #hurd, 2014-02-23: - - brings me to another question i asked here recently that - nobody had a great answer for: any plan to do kqueue? - not for now - i remember answering you about that - ah. on IRC or the list? - that internally, our select/poll implementation works just - like epoll - on irc - well "just like" is a bit far from the truth - well... poll() doesn't really work like epoll :p - internally, it does - even on linux - since both of us have to do the linear scan on the list - which is really the entire difference - that's the user interface part - i'm talking about the implementation - ya -- but it's the interface that makes it unscalable - i know - what i mean is - since the implementation already works like a more modern - poll - we could in theory add such an interface - but epoll adds some complicated detail - you'll have to forgive me a bit -- i wasn't around from a - time that i could imagine what a non-modern poll would look like - inside of a kernel :) - what i mean with a modern poll is a scalable poll-like - interface - epoll being the reference - * desrt is not super-crazy about the epoll interface.... - me neither - kevent() is amazing -- one syscall for everything you need - i don't know kqueue enough to talk about it - no need to do 100 epollctls when you have a whole batch of - updates to do - there's two main differences - first is that instead of having a bunch of separate fds for - things like inotify, timerfd, eventfd, signalfd, etc -- they're - all built in as different 'filter' types - second is that instead of a separate epoll_ctl() call to - update the list of monitored things, the kevent() call - (epoll_wait() equivalent) takes two lists: one is the list of - updates to make and the other is the list of events to - return.... so you only do one syscall - well, again, that's the interface - internally, there still are updates and waits - and on a multiserver system like the hurd, this would mean - one system call per update per fd - and then one per wait - on the implementation side, i think kqueue also has a nice - feature: the kernel somehow has some magic that lets it post - events to a userspace queue.... so if you're not making updates - and you do a kevent() that would not block, you don't even enter - the kernel - ok - hm. that's an interesting point - "unix" as such is just another server for you guys, right? - no - that's a major difference between the hurd and other - microkernel based systems - even multiserver ones like minix - we don't have a unix server - we don't have a vfs server or even an "fd server" - so mach knows about things like fds? - no - only glibc - oh. weird! - yes - that's the hurd's magic :) - being so posix compliant despite how exotic it is - this starts to feel like msvcrt :p - maybe, i wouldn't know - windows is a hybrid after all - with multiple servers for its file system - so why not - anyway - so windows doesn't have fds in the kernel either... the C - library runtime emulates them - mach has something close to file descriptors - which is fun when you get into dll hell -- sometimes you - have multiple copies of the C library runtime in the same program - -- and you have to take care not to use fds from one of them with - th o ther one - yes .. - that, i knew :) - but back to the hurd - since fds are a glibc thing here, and because "files" can - be implemented by multiple servers - (sockets actually most of the time with select/poll) - we have to make per fd requests - the implementation uses the "port set" kernel abstraction - right -- we could have different "fd" coming from different - places - do you know what a mach port is ? - not even a little bit - hm - i think it's what a plane does when it goes really fast, - right? - let's say it's a kernel message queue - no it's not a sonic boom - :) - ;p - so - ports are queues - (aside: i did briefly run into mach ports recently on macos - where they modified their kqueue to support them...) - queues of RPC requests usually - (but i didn't use them or look into them at all) - they can be referenced through mach port names, which are - integers much like file descriptors - they're also used for replies but, except for weird calls - like select/poll, you don't need to know that :) - a port set is one object containing multiple ports - sounds like dbus :) - the point of a port set is to provide the ability to - perform a single operation (wait for a message) on multiple ports - sounds like an epoll fd.... - is the port set itself a port? - so, when a client calls select, it translates the list of - fds into port names, creates reply ports for each of them, puts - them into a port set, send one select request for each, and does - one blocking wait on the port set - no, but you can wait for a message on a port set the same - way you do on a port - and that's all it does - does that mean that you can you put a port set inside of - another port set? - hm maybe - i guess in some way that doesn't actually make sense - i guess - because i assume that the message you sent to each port in - your example is "tell me when you have some stuff" - yes - and you'd have to send an equivalent message to the port - set.... and that just doesn't make sense - since it's not really a thing, per se - it would - insteaf of port -> port set, it would just be port -> port - set -> port set - but we don't have any interface where an fd stands for a - port set - what i'm trying to tell here is that - considering how it's done, you can easily see that there - has to be non trivial communication - each with the cost of a system call - and not just any system call, a messaging one - mach is clearly not as good as l4 when it comes to that - hrmph - and the fact that most pollable fds are either unix or - inet/inet6 sockets mean that there will be contention in the - socket servers anyway - i've seen some of the crazy things you guys can do as a - result of the way mach works and way that hurd uses it, in - particular - normal users setting up little tcp/ip universes for - themselves, and so on - yes :) - but i guess this all has a cost - the cost here comes more from the implementation than the - added abstractions - mach provides async ipc, which can partially succeed - if i spin up a subhurd, it's using the same mach, right? - yes - that's neat - we tend to call them neighbour hurds because of that - i'm not sure it is - it puts it half way between linux containers and outright - VMs - because you have a new kernel.... ish... - well, it is for the same reasons hypervisors are neat - but the kernel exists within this construct.... - a new kernel ? - a new hurd - yes - but not a new mach - exactly - ya -- that's very cool - it's halfway between hypervisors and containers/jails - what matters is that we didn't need to write much code to - make it work - and that the design naturally guarantees strong isolation - right. that's what i'm getting at - unlike containers - it shows that the interaction between mach and these set of - crazy things collectively referred to as the hurd is really - proper - usually - sometimes i think it's not - but that's another story :) - don't worry -- you can fix it when you port to L4 ;) - eh, no :) - btw: is this fundamentally the same mach as darwin? - yes - so i guess there are multiple separate implementations of a - standard set of interfaces? - ? - * desrt has to assume that apple wouldn't be using GNU mach, for - example... - no it's the same code base - they couldn't - but only because the forks have diverged a bit - ah - and they probably changed a lot of things in their virtual - memory implementation - so i guess original mach was under some BSDish type thing - and GNU mach forked from that and started adding GPL code? - something like that - makes sense - we have very few "non-standard" mach interfaces - but we now rely on them so we couldn't use another mach - either - back to the select/poll stuff - * desrt gets a lesson tonight :) - it costs, it's not scalable - but - we have scalability problems in our servers - they're old code, they use global locks - right. this is the story i heard last time. - probably from me - poll works good enough for us right now - we're more interested in bug fixes than scalability - currently - the reason this negative impacts me is because now i need - to write a bunch more code ;p - i hope this changes but we still get weird errors that - many applications don't expect and they react badly to those - well, poll really is the posix fallback - every other OS that we want to support has some sort of new - scalable epoll-type interface or is Windows (which needs separate - code anyway) - a very large number of them have kqueue... linux has - epoll... solaris/illumos is the odd one out with this weird thing - that's sort of like epoll - i would think you want a posix fallback for such a - commonly used interface - hm - braunr: hurd is pretty much the only one that doesn't - already have something better.... - linux can be built without epoll - and the nice thing about all of these things is that every - single one of them gives me an fd that can be polled when any - event is ready - i don't see why anyone would do that, but it's a compile - time option ;p - yes ... - we don't have xxxfd() :) - and we want to expose that fd on our API... so people can - chain gmaincontext into other mainloops - that's expected - so for hurd this means that i will need to spin up a - separate thread doing poll() and communicating back to the main - thread when anything becomes ready - i was looking forward to not having to do that :) - it matches the unix "everything is a file" idea, and - windows concept of "events" - i understand but again, it's a posix fallback - you probably want it anyway - probably - it could help new systems trying to be posix like - i honestly thought i'd get away with it, though - this is true... - CLOCK_MONOTONIC is an easy enough requirement to implement - or fake.... "modern event polling framework" is another story... - - [[clock_gettime]]. - - yes, but again, we do have the underlying machinery to add - it - i appreciate if your priorities are elsewhere ;) - it's just not worth the effort right now - although we do have performance and latency improvements - in our patch queues currently - if our network stack gets replaced, it would become - interesting - we need to improve posix compliance first - make more applications not choke on unecpected errors - and then we can think of improving scalability - +1 vote from me for implementing monotonic time :) - (and also pthread_condattr_setclock()) - and we probably won't implement the epoll interface ;p - yes - it's worth noting that there is also a semi-widely - available non-standard extension called - pthread_cond_timedwait_relative_np that you could implement - instead - it takes a (relative) timeout instead of an absolute one -- - we can use that if it's available - desrt: why would you want relative timeouts ? - braunr: if you're willing to take the calculations into - your own hands and you don't have another way to base it on - monotonic time it starts to look like a good alternative - and indeed, this is the case on android and macos at least - hm - not great as a user-facing API of course.... due to the - spurious wakeup possibility and need to retry - so it's non standard alternative to a monotonic clock ? - no -- these systems have monotonic clocks - what they lack is pthread_condattr_setclock() - oh right - which is documented in POSIX but labelled as 'optional' - so relative is implicitely monotonic - yes - i imagine it would be the same 'relative' you get as the - timeout you pass to poll() - since basing anything like this on wallclock time is - absolutely insane - (which is exactly why we refuse to use wallclock time on - our timed waits) - sure - i'm surprised clock_monotonic is even optional in posix - 2008 - but i guess that's to give some transition margin for - small embedded systems - when you think about it, CLOCK_REALTIME really ought to - have been the optional feature - monotonic time is so utterly basic - yes - and that's how it's normally implemented - kernels provide a monotonic clock, and realtime is merely - shifted from it - - * `sys/eventfd.h` - - * `sys/inotify.h` - - * `sys/signalfd.h` - - * `sys/timerfd.h` - - * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51, - 87f51853ce3671f4ba9a9953de1fff952c5f7e52) - - * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`) - - IRC, freenode, #hurd, 2012-04-20: - - in glibc, we use the generic waitflags.h which, unlike - linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, - WCONTINUED - should the generic bits/waitflags.h define them anyway, - since they are posix? - well, we'd have to implement them anyway - but otherwise, I'd say yes - sure, but since glibc headers should expose at least - everything declared by posix, i thought they should be defined - anyway - that might bring bugs - some applications might be #ifdefing them - and break when they are defined but not working - i guess they would define them to 0, andd having them to - non-zero values shouldn't break them (since those values don't do - anything, so they would act as if they were 0.. or not?) - no, I mean they would do something else, not define them to - 0 - like posix/tst-waitid.c, you mean? - yes - - See `posix/tst-waitid.out` failure below. - - * `getconf` things (see below the results of `tst-getconf.out`) - - * `getsockopt`, `setsockopt` - - IRC, freenode, #hurd, 2013-02-14 - - Hi, {get,set}sockopt is not supported on Hurd. This shows - e.g. in the gnulib's test-{poll,select} code. - Reading - http://hea-www.harvard.edu/~fine/Tech/addrinuse.html there might - be reasons _not_ to implement them, comments? - uh? they are supported on hurd - not SO_REUSEPORT for setsockopt() - that isn't the same as claiming "get/setsockopt is not - supported on hurd" - most probably that option is not implemented by the - socket family you are using - OK, some options like SO_REUSEPORT then, more info in - the link. - note also SO_REUSEPORT is not posix - and i don't see SO_REUSEPORT mentioned in the page you - linked - No, but SO_REUSEADDR - - IRC, freenode, #hurd, 2013-02-23 - - as an example, the poll test code from gnulib fails due - to that problem (and I've told you before) - gnu_srs: what's the actual failure? - can you provide a minimal test case showing the issue? - pinotree: A smaller test program: - http://paste.debian.net/237495/ - gnu_srs: setting SO_REUSEADDR before binding the socket - works... - and it seems it was a bug in the gnulib tests, see - http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6ed6dffbe79bcf95e2ed5593eee94ab32fcde3f4 - pinotree: You are right, still the code I pasted pass on - Linux, not on Hurd. - so? - the code is wrong - you cannot change what bind does after you have called - it - * pinotree → out - so linux is buggy? - no, linux is more permissive - (at least, on this matter) - - * `getcontext`/`makecontext`/`setcontext`/`swapcontext` - - Support for these functions within the Hurd threadvar environment has - been added, but for multi-threaded applications ([[libpthread]]), it is - a bit clunky: as a practical requirement, a thread's stack size always - has to be equal to `PTHREAD_STACK_DEFAULT`, 2 MiB, and also has to be - naturally aligned. The idea is still to [[get rid of Hurd threadvars - and replace them with TLS|t/tls-threadvar]]. - - Aside from [[gccgo]], the following packages might make use of these - functions, searching on for - `\b(get|set|make|swap)context\s*\(` on 2013-05-18: boost1.49, - chromium-browser, gtk-vnc, guile-1.8, iceape, icedove, iceweasel, - libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim, - and more. - - IRC, OFTC, #debian-hurd, 2013-09-08: - - oh, and even ruby2.0 suffers because of fixed-stack - threads - yes, we definitely need to finish fixing it - my current work is in our glibc repo, youpi/tls-threadvar - | *** makecontext: a stack at 0xbc000 with size 0x40000 - is not usable with threadvars - all 8 failing tests with that - maybe we can hand-disable the use of contexts in ruby for - now? - gg0: ↑ :) - after the pseudo-patch i RFCed, i don't deserve to say - anything else about that :) - i mean, feel free to investigate and "fix" ruby2.0 as - above :) - eh maybe i'd just be able to hand-disable failing - thread-related _tests_ :) - i'm still hoping some real developer picks and actually fixes - it, seems it's not enough interesting though - 21:37 < youpi> yes, we definitely need to finish fixing it - afaiu youpi is working on threadvars-tls migration, which - would mean fixing them all. i just meant fixing ruby, which would - mean having puppet btw - gg0: "actually fixing" means fixing threadvars-tls - migration - "just fixing" ruby can be done by simply disabling context - use in ruby - - IRC, OFTC, #debian-hurd, 2013-09-10: - - this one fixes make test by disabling context and giving more - time to timing related tests http://paste.debian.net/plain/37977/ - make test-all is another story - gg0: AIUI, the sleep part should get fixed by the next - glibc upload, which will include the getclk patch - but the disabling context part could be good to submit to - the debian ruby package, mentioning that this is a workaround for - now - unfortunately still not enough, test-all still fails - does it make the package not build? - test-all is the second part of what we call tests - they build and package (they produce all ruby packages), - after that they run debian/run-test-suites.bash which is make - test + make test-all - well after or during the build doesn't matter, it's their - testsuite - ok just failed: - TestBug4409#test_bug4409 = Illegal instruction - make: *** [yes-test-all] Error 132 - what to do with Illegal instruction? - just found 2 words that make everybody shut up :p - same as above: debug it - gg0: have you confirmed that this is reproducible? I've - once had a process die with SIGILL and it was not and I figured - it might have been a (qemu?) glitch - seems i'm running tests which are disabled on _all_ archs, - better so - well, this should be reproducible. i just got it on a qemu, i - could try to reproduce it on real hardware but as just said, i - was testing tests disabled by maintainer so completely useless - gg0: yeah, I'm running all my hurd instances on qemu/kvm - as well, I meant did you get this twice in a row? - to be honest i got another illegal instruction months ago but - don't recall doing what - nope not twice, i've commented it out. then run the remaining - and then found out i should not have done what i was doing - but i could try to reproduce it - ok now i recall i got it another one few hours ago on real - hardware, from logs: - TestIO#test_copy_stream_socket = Illegal instruction - teythoon: on real hardware though - and this is the one i should debug once it finishes, still - running - - IRC, freenode, #hurd, 2013-09-11: - - ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: - Assertion `! __spin_lock_locked (&ss->critical_section_lock)' - failed. - and - ../libpthread/sysdeps/mach/pt-thread-halt.c:51: - __pthread_thread_halt: Unexpected error: (ipc/send) invalid - destination port. - gg0_: Which libpthread source are these? Stock Debian - package? - tschwinge: everything debian, ruby rebuilt with - http://paste.debian.net/plain/38519/ which should disable - *context - - IRC, OFTC, #debian-hurd, 2013-09-11: - - wrt ruby, i'd propose a patch that disables *context and - comments out failed tests (a dozen). most of them are timing - related, don't always fail - if they failed gracefully, we could leave them enabled and - just ignoring testsuite result, but most of them block testsuite - run when fail - anyone against? any better idea (and intention to implement - it? :p)? - youpi: is disabling some tests acceptable? ^ - it'd be good to at least know what is failing - so as to know what impact hiding these failures will have - remember that hiding bugs usually means getting bitten by - them even harder later :) - many of them use pipes - here the final list, see commented out ones - http://paste.debian.net/plain/38426 - and as said some don't always fails - test_copy_stream_socket uses a socket - note that we can still at least build packages with notest - at least to get the binaries uploaded - disabling *context should however really be done - and the pipe issues are concerning - I don't remember other pipe issues - so maybe it's a but in the ruby bindings - i just remember they didn't die, then something unknown - fixed it - I see something frightening in io.c - #if BSD_STDIO - preserving_errno(fseeko(f, lseek(fileno(f), - (off_t)0, SEEK_CUR), SEEK_SET)); - #endif - this looks very much like a workaround for an odd thing in - BSD - it happens that that gets enabled on hurd too, since - __MACH__ is defined - you could try to drop these three lines, just to see - this is very probably very worth investigating, at any rate - even just test_gets_limit_extra_arg is a very simple test, - that I fail to see why it should ever fail on hurd-i386 - starting debugging it would be a matter of putting printfs - in io.c, to check what gets called, with what parameters, etc. - just a matter of taking the time to do it, it's not very - complex - youpi: are you looking at 1.8? no BSD_STDIO here - yes, 1.8 - 1.9.3.448 - landed to sid few days ago - ah, I have 1.87 - +. - my favourites are TestIO#test_copy_stream_socket and - TestIO#test_cross_thread_close_fd -> Illegal instruction - TestIO#test_io_select_with_many_files sometimes Illegal - instruction, sometimes ruby1.9.1: - ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: Assertion - `! __spin_lock_locked (&ss->critical_section_lock)' failed. - - [[thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock]]? - - trying to debug illegal instruction - http://paste.debian.net/plain/38585/ - (yes, i'm not even good at gdbing) - any hint? - oh found out there's an intree .gdbinit, that might - complicate things - - IRC, OFTC, #debian-hurd, 2013-09-13: - - where should it be implemented MAP_STACK? plus, is it worth - doing it considering migration to tls, wouldn't it be useless? - sysdeps/mach/hurd/mmap.c i should reduce stupid questions - frequency from daily to weekly basis - - IRC, OFTC, #debian-hurd, 2013-09-14: - - say i managed to mmap 0x200000-aligned memory - now i get almost the same failed tests i get disabling - *context - that would mean they don't depend on threading - - IRC, freenode, #hurd, 2013-09-16: - - i get many ../sysdeps/mach/hurd/jmp-unwind.c:53: - _longjmp_unwind: Assertion `! __spin_lock_locked - (&ss->critical_section_lock)' failed. - by running ruby testsuite, especially during test_read* tests - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L972 - read/write operations with pipes - gg0: that's weird - gg0: debian glibc ? - braunr: yep, debian 2.17-92 - sometimes assertion above, sometimes tests in question get - stuck reading - it would be nice reproducing it w/o ruby - probably massive io on pipes could do the job - also more nice finding someone who finds it interesting to - fix :p - ruby is rebuilt with http://paste.debian.net/plain/40755/, no - *context - pipe function in tests above creates one thread for write, - one for read - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26 - gg0: About the jmp-unwind assertion failure: is it be - chance this issue: - ? - I didn't look in detail. - tschwinge: that's what i thought too about the assertion, - which is why i find it strange - asserting it's not locked then locking it doesn't exclude - race conditions - - IRC, OFTC, #debian-hurd, 2013-09-17: - - youpi: i guess no one saw it anymore since - tg-thread-cancel.diff patch - it = - http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html - this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though - another assertion to remove? - gg0: it's not exactly the same: in hurd_thread_cancel we - hold no lock at all at the assertion point - in jmp-unwind.c, we do hold a lock - and the assertion might be actually true because all other - threads are supposed to hold the first lock before taking the - other one - you could check for that in other places - and maybe it's the other place which wouldhave to be fixed - also look for documentation which would say that - - IRC, freenode, #hurd, 2013-09-17: - - gg0: is that what we do ?? - braunr: well, i was looking at - http://sources.debian.net/src/eglibc/2.17-92/debian/patches/hurd-i386/tg-thread-cancel.diff - which afaics fixes - http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html - the one i get now is - http://sources.debian.net/src/eglibc/2.17-92/sysdeps/mach/hurd/jmp-unwind.c#L53 - 09:12 < youpi> gg0: it's not exactly the same: in - hurd_thread_cancel we hold no lock at all at the assertion point - 09:13 < youpi> in jmp-unwind.c, we do hold a lock - 09:13 < youpi> and the assertion might be actually true - because all other threads are supposed to hold the first lock - before taking the other one - gg0: that assertion is normal - it says there is a deadlock - ss->critical_section_lock must be taken before ss->lock - you mean ss->lock before ss->critical_section_lock - no - ah ok got it - that's a bug - longjmp - ugh - you could make a pass through the various uses of those - locks and check what the intended locking protocol should be - i inferred ss->critical_section_lock before ss->lock from - hurd_thread_cancel - this might be wrong too but considering this function is - used a lot, i doubt it - (no, i hadn't got it, i was looking at jmp-unwind.c where - lock is before critical_section_lock) - could we get useful info from gdb'ing the assertion? - gg0: Only if you first get an understanding why it is - happening, what you expect to happen instead/why it shall not - happen/etc. Then you can perhaps use GDB to verify that. - i can offer an irc interface if anyone is interested, it's - ready, just to attach :) - this is the test - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L937 - pipe function creates two threads - http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26 - Attaching to pid 15552 - [New Thread 15552.1] - [New Thread 15552.2] - (gdb) - - IRC, freenode, #hurd, 2013-09-21: - - gg0: it seems the assert (! __spin_lock_locked - (&ss->critical_section_lock)); is bogus - but it'd be good to catch a call trace - well, it may not be bogus, in case that lock is only ever - taken by the thread itself - in that case, inside longjmp_unwind we're not supposed to - have it already - ok, that's what we had tried to discuss with Roland - it can happen when playing with thread cancelation - youpi: the assertion isn't exactly bogus - the lock ordering is - braunr: which one are you talking about? - the one in hurd_thread_cancel looks really wrong - and some parts of the code keep the critical section lock - without ss->lock held, so I don't see how lock ordering can help - - IRC, OFTC, #debian-hurd, 2013-09-22: - - how much does this patch suck on a scale from 1 to 10? - http://paste.debian.net/plain/44810/ - well, the stack allocation issue will go away once I get - the threadvars away - I'm working on it right now - about the lib paths, it makes sense to add the gnu case, - but i386-gnu shouldn't be put in the path - that's great - so seems the wrong moment for what i've already done - ie. asking terceiro what he thinks about patch above :/ - any distro-independent way to get libc.so and libm.so path? - ruby as last resource takes them from "ldd ruby" - gg0: should work fine then - well it does. but gnu doesn't have a case so it hits default - which is broken - http://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/40235/entry/test/dl/test_base.rb - btw even linux and kfreebsd with debian multipath have broken - cases but they don't hit default and get fixed by ldd later - why it is broken? are arguments passed to that script? - i'm not sure about what propose. a broken case so it doesn't - hit default like linux and kfbsd - yes they are :/ - and which ones are? who executes that script and which - arguments does it pass to it? - other ruby scripts which have nothing to do with libc/libm - well, if they pass arguments which should be the paths - to libc and libm, they must be getting such paths, aren't they? - they don't. arguments are other ruby scripts, don't know why, - maybe something else broken before - but that would mean that before there's a smarter path - detection way, i doubt - then add the case for hurd, but setting both libc and - libm as nil - so they will be fetched again - yep and would really ugly - +be - "please commit this one which wrongly sets paths." - an alternative would be removing default case - or pointing it out by proposing ldd in hurd case might make - them review the whole detection - by setting correct paths like in patch above it wouldn't - break a possible hurd-amd64, it would work due to ldd - gg0: that's why I said the patch is fine, but without the - i386-gnu part of the path - just like it happens to be on linux & kfreebsd - i might take ldconfig -p output - to make it uselessly correct from start - http://bugs.ruby-lang.org/issues/8937 - note thar ruby 1.8 is EOL - *that - -- If you're reporting a bug in both Ruby 1.9/2.0 and Ruby - 1.8: ruby-trunk, and write like "this bug can be reproduced in - Ruby 1.8 as well." -- - i suspect this one won't be the only one i'll file. unless - upcoming youpi's tls and braunr's thread destruction patches fix - all ruby tests - did you check ruby2.0 too, btw? - switched to ruby2 few hours ago. i pointed out 2nd part of - testsuite is not enabled, probably terceiro will enable it soon - by applying my patch above we'd completely fix current - ruby2.0 build (yes because tests are not completely enabled) - what you run those extra tests? - - http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/run-test-suites.bash - make test + make test-all - (test-all is 2nd part) - many are problematic. i didn't finish yet to suppress them - one-by-one. one i suppress, another one pops up - either get stuck or well known assertion - check those that get stuck :) - which kind of check? - "check" as in "debug" - btw i tested puppet few days ago (with ruby1.8), it seems to - be working, at least at trasferring files from master - don't know about any advanced usage - ruby 1.8 is going to die soon, so testing things against - it is not totally useful - so you assume 1.8 is less broken than 1.9/2.0, right? - no - i just can see it's been built without tests itself too - erm no - well ok, if i can be wrong, i'll be wrong - i say that after a quick check time ago, might be wrong - `getbuildlogs ruby1.8 last hurd-i386`, see the last - build log - ah from pkg-kde-tools - i hate kde :) - no? - no what? - devscripts: /usr/bin/getbuildlog - pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs - which is not what i said - wait that's what apt-file found - maybe i should update it - is it so recent? - no - i just added an 's' more at the end of the command, but - typing getbu could have been helpful anyway... - yeah just got it - my fault not to have tried to run it before looking for it - and btw, i don't see what hating kde has to do with - tools developed by qt/kde debian packagers - j/k i simply don't use kde, never used and apt-file search - told me it was from pkg-kde-tools - btw build log says "make test" fails, doesn't even start. and - its failure doesn't block the build - exactly - s/make test/make test-all/ - "make test" (aka "1st part" above) doesn't run. i guess it's - missing in packaging - - IRC, freenode, #hurd, 2013-09-22: - - youpi: i mean the lock order where the assertion occurs is - reserved compared to the one in hurd_thread_cancel - (and the one in hurd_thread_cancel is the same used in - hurd condition-related functions) - "reserved" ? - reversed - :) - by "the assertion occurs", you mean gg0's spot? - yes - well , the assertion also happens in hurd_thread_cancel - it does oO - i didn't see that - but otherwise yes, it's completely bogus that we have both - locking in different orders - could you submit the fix for jmp-unwind.c to upstream? - what fix ? - reversing the lock order - ah, simply that - (well, provided that hurd_thread_cancel is right) - that's what i suggested to gg0 - to check where those locks are held and determine the - right order - - IRC, OFTC, #debian-hurd, 2013-09-28: - - now we'd just need tls - http://bugs.ruby-lang.org/issues/8937 - well, it would pass makecheck at least. makecheckall would - keep hanging on threads/pipes tests i guess, unless tls/thread - destruction patches fix them - - IRC, OFTC, #debian-hurd, 2013-10-05: - - so what is missing for ruby2.0, only disabling use of - context for now, no? - i'm not tracking it closely, gg0_ is - maybe terceiro would accept a patch which only disables - *context, "maybe" because he rightly said changes must go - upstream - anyway with or without *context, many many tests in - makecheckall fail by making it hang, first with and without - assertion you removed, now they all simply hang - youpi: what do we want to do? if you're about finishing tls - migration (as i thought a couple of weeks ago), i won't propose - anything upstream. otherwise i could but that will have to be - reverted upstream once you finish - about tests, current ruby2.0 doesn't run makecheckall, only - makecheck which succeeds on hurd (w/o context) - if anyone wants to give it a try: - http://paste.debian.net/plain/51089 - first hunk makes makecheck (not makecheckall) succeed and - has been upstreamed, not packaged yet - what about makecheckall for ruby2.0? - 16:58 < gg0_> anyway with or without *context, many many - tests in makecheckall fail by making it hang, first with and - without assertion you removed, now they all simply hang - i for a moment thought it as for 1.9.1, ok - these hangs should be debugged, yes - nope, tests behavior doesn't change between 1.9 and 2.0. i - started suppressing tests onebyone on 2.0 as well and as happened - on 1.9, i gave up cause there were too many - yep a smart mind could start debugging them, starting from - patch above pasted by a lazy one owner - one problem is that one can't reproduce them by isolate - them, they don't fail. start makecheckall then wait for one fail - now after my stupid report, someone like pinotree could take - it over, play with it for half an hour/an hour (which equals to - half a gg0's year/a gg0's year - ) - and fix them all - - 17:05 < gg0_> youpi: what do we want to do? if you're about - finishing tls migration (as i thought a couple of weeks ago), i - won't propose anything upstream. otherwise i could but that will - have to be reverted upstream once you finish - gg0_: I don't really know what to answer - that's why I didn't answer :) - youpi: well then we could upstream context disable and keep - it disabled even if you fix tls. ruby won't be as fast as it - would be with context but i don't think anyone will complain - about that. then once packaged, if terceiro doesn't enable - makecheckall, we will have ruby2.0 in main - that can be a plan yes - btw reverting it upstream should not be a problem eventually - sure, the thing is remembering to do it - filed http://bugs.ruby-lang.org/issues/8990 - please don't fix tls too soon :) - s/makecheck/maketest/g - - IRC, OFTC, #debian-hurd, 2013-10-08: - - ok. *context disabled http://bugs.ruby-lang.org/issues/8990 - - bt full of an attached stuck ruby test - http://paste.debian.net/plain/53788/ - anything useful? - uh, is that really all? - there's not much interesting unfortunately - did you run thread apply all bt full ? - (not just bt full) - no just bt full - http://paste.debian.net/plain/53790/ - wait, there's a child - damn ctrl-c'ing while it was loading symbols made it crash :/ - restarted testsuite - isn't it interesting that failed tests fail only if testsuite - runs from beginning, whereas if run singularly, they succeed? - as it got out of whatever resources - youpi: http://paste.debian.net/plain/53798/ - the interesting part is actually right at the top - it's indeed stuck in the critical section spinlock - question being what is keeping it - iirc I had already checked in the whole glibc code that all - paths which lock critical_section_lock actually release it in - all cases, but maybe I have missed some - (I did find some missing paths, which I fixed) - i guess the same check you and braunr talk about in - discussion just before this anchor - http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg - yes, but the issue we were discussing there is not what - happens here - we would see another thread stuck in the other way roudn, - otherwise - no way to get what is locking? - no, that's not recorded - and what about writing it somewhere right after getting the - lock? - one will have to do that in all spots taking that lock - but yes, that's the usual approach - i would give it try but eglibc rebuild takes too much time, - that conflicts with my laziness - i read even making locks timed would help - - IRC, OFTC, #debian-hurd, 2013-10-09: - - so correct order would be: - __spin_lock (&ss->lock); // locks sigstate - __spin_lock (&ss->critical_section_lock); - [do critical stuff] - __spin_unlock (&ss->critical_section_lock); - __spin_unlock (&ss->lock); // unlocks sigstate - ? - - 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is - waiting) https://bugs.ruby-lang.org/issues/9000 - 21:46 < gg0> that means that if you take a 2.0 snapshot, - it'll build fine on hurd (unless you introduce maketestall as in - 1.9, that would make it get stuck like 1.9) - 21:48 < terceiro> gg0: nice - 21:48 < terceiro> I will try to upload a snapshot as soon as - I can - 21:52 < gg0> no problem. you might break my "conditional - satisfaction" by adding maketestall. better if you do that on - next+1 upload so we'll have at least one 2.0 built :) - - would it be a problem granting me access to a porter box to - rebuild eglibc+ruby2.0? - i'm already doing it on another vm but host often loses power - you cannot install random stuff on a porterbox though - i know i'd just need build-deps of eglibc+ruby2.0 i guess - (already accessed to porter machines in the past, account - lele, mips iirc) - ldap should remember that - don't want to disturb anyone else work btw. if it's not a - problem, nice. otherwise no problem - please send a request to admin@exodar.debian.net so it - is not forgotten - following this one would be too "official"? - http://dsa.debian.org/doc/guest-account/ - hurd is not a release architecture, so hurd machines are - not managed by DSA - ok - the general procedure outlines is ok though, just need - to be sent to the address above - sent - (1st signed mail with mutt, in the worst case i've attached - passphrase :)) - gg0: could you send me an ssh key? - no alioth account? - yes, but EPERM - youpi: sent to youpi@ - youpi@ ? - (... which doesn't exist :/) - sthibault@ - please test gg0-guest@exodar.debian.net ? - (I'd rather not adduser the ldap name, who knows what might - happen when you get your DD account) - i'm in. thanks - you're welcome - ldap users need to be adduser'ed? - I'm not getting your ldap user account from ud-replicate, - at least - (btw i never planned to apply nm, i'd be honoured but i - simply think not to deserve it) - never say never ;) - bah i like failing. that would be a success. i can't :) - gg0-guest@exodar:~$ dchroot - E: Access not authorised - I: You do not have permission to access the schroot service. - I: This failure will be reported. - ah, right, iirc I need to add you somewhere - gg0: please retry? - works - good - are there already eglibc+ruby2.0 build-deps? - yes - oh that means i should do something myself now :) - yep, that had to happen at some point :) - my laziness thanks: "at some point" is better than "now" :) - - IRC, freenode, #hurd, 2013-10-10: - - ok just reproduced the - former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits - 20:37 < braunr> gg0: does ruby create and destroy threads - ? - no idea - braunr: days ago you and youpi talked about locking order - (just before this anchor - http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg) - oh right - could you submit the fix for jmp-unwind.c to - upstream? - it didn't made it in the todo list - so correct order is in hurd_thread_cancel, right? - sorry about that - we need to make a pass to make sure it is - that means locking first ss->critical_section_lock _then_ - ss->lock - correct? - but considering how critical hurd_thread_cancel is, i - expect so - - i get the same deadlock by swapping locks - braunr: youpi: fyi ^ - 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and - destroy threads ? - how could i check it? - gg0: ps -eflw - gg0: that's not surprising, since in the b acktrace you - posted there isn't another thread locked in the other order - so it's really that somehow the thread is already in - critical sesction - youpi: you mean there is ? - ah, it's not the same bug - no, in what he posted, no other thread is stuck - so it's not a locking order - just that the critical section is actually busy - youpi: ack - braunr: what's the other bug? ext2fs one? - gg0: idk - braunr: thanks. doesn't show threads (found -T for that) but - at least doesn't limit columns number if piped (thanks to -w) - it does - there is a TH column - ok thread count. -T gives more info - - IRC, freenode, #hurd, 2013-10-24: - - ruby2.0 builds fine with the to-be-uploaded libc btw - youpi: without d-ports patches? surprise me :) - gg0: plain main archive source - you did it. surprised - ah ok you just pushed your tls. great! - tls will fix a lot of things - - IRC, OFTC, #debian-hurd, 2013-11-03: - - gg0: - #252 test_fork.rb:30:in `': core dumped - [ruby-core:28924] - FAIL 1/949 tests failed - with the to-be-uploaded glibc - why does it coredump? - that's the test i had workarounded by increasing sleep from 1 - to 3 but i don't recall it coredump'ed - *recall if - "sleep 1" at bootstraptest/test_fork.rb:33 - how can I run the test alone? - - IRC, OFTC, #debian-hurd, 2013-11-04: - - gg0: ^ - it should not take much - run $ make OPTS=-v test - found out how to minimize - mkdir _youpi && cp bootstraptest/{runner,test_fork}.rb _youpi - then run $ ./miniruby -I./lib -I. -I.ext/common - ./tool/runruby.rb --extout=.ext -- --disable-gems - "./_youpi/runner.rb" --ruby="ruby2.0 -I./lib" -q -v - youpi: that should work - #1 test_fork.rb:1:in `': No such file or - directory - /usr/src/ruby1.9.1-1.9.3.448/ruby2.0 - -I/usr/src/ruby1.9.1-1.9.3.448/lib -W0 bootstraptest.tmp.rb - [ruby-dev:32404] - seems it can't find /usr/src/ruby1.9.1-1.9.3.448/ruby2.0 - well it's ruby1.9.1 indeed :) - ok, got core - replace 2.0 with 1.9, check what you have in rootdir - k - Mmm, no, there's no core file - does stupidly increasing sleep time work? - nope - without *context it runs "make test" fine. real problems come - later with "make test-all" - wrt test_fork, is correspondence between signals correct? i - recall i read something about USR1 not implemented - USR1 is implemented, it's SIGRT which is not implemented - my next wild guess is that that has something to do with - atfork, whatever that means - it makes 2 forks: one sleeps for 1 sec then kills -USR1 - itself, the second traps USR1 in getting current time. in the - meanwhile parent sleeps for 2 secs - - IRC, OFTC, #debian-hurd, 2013-11-07: - - ruby2.0 just built on unstable - - IRC, OFTC, #debian-hurd, 2013-11-09: - - youpi: just found out a more "official" way to run one test - only - http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/README.porters;h=94aff7dd3ecd9f748498f2e285b4a4313b4b8f36;hb=HEAD - btw still getting coredumps? - - IRC, OFTC, #debian-hurd, 2013-11-13: - - wrt the other test test_fork i suppose you made it not to - segfault anymore, it simply does fail - I haven't taken any particular care - didn't have any time to deal with it - - IRC, OFTC, #debian-hurd, 2013-11-14: - - btw patches to disable *context have been backported to 1.9 - as well so next 1.9 point release should have *context disabled - as 2.0 have - *has - i guess you'd like to get them reverted now - youpi: ^ - after testing that *context work, yes - - * `sigaltstack` - - IRC, freenode, #hurd, 2013-10-09: - - Hi, is sigaltstack() really supported, even if it is - defined as well as SA_ONSTACK? - probably not - well, - i don't know actually, mistaking with something else - it may be supported - iirc no - pinotree: are you sure? - this is what i remember - if you want to be sure that $foo works, just do the - usual way: test it yourself - found it: hurd/TODO: *** does sigaltstack/sigstack - really work? -- NO - well TODO is old and there were signal-related patches - by jk in the meanwhile, although i don't think they would have - changed this lack - in any case, test it - anybody fluent in assembly? Looks like this code - destroys the stack: http://paste.debian.net/54331/ - gnu_srs1: why would it ? - it does something special with the stack pointer but it - just looks like it aligns it to 16 bytes, maybe because of sse2 - restrictions (recent gcc align the stack already anyway) - Well, in that case it is the called function: - http://paste.debian.net/54341/ - how do you know there is a problem with the stack in the - first place ? - tracing up to here, everything is OK. then esp and ebp - are destroyed. - and single stepping goes backward until it segfaults - "destroyed" ? - zero if I remember correctly now. the x86 version built - for is i586, should that be changed to i486? - this shouldn't change anything - and they shouldn't get to 0 - use gdb to determine exactly which instruction resets the - stack pointer - how to step into the assembly part? using 's' steps - through the function since no line information: - Single stepping until exit from function - wine_call_on_stack, - which has no line number information. - gnu_srs1: use break on the address - how do i get the address of where the assembly starts? - - * `recvmmsg`/`sendmmsg` (`t/sendmmsg`) - - From [[!message-id "20120625233206.C000A2C06F@topped-with-meat.com"]], - Roland McGrath: *They are generally useful interfaces and there is - nothing intrinsically Linuxoid about them. At least when not given a - timeout, they could be implemented in terms of sendmsg/recvmsg. So - perhaps we ought to have a sysdeps/posix implementation that the Hurd - would use instead of stubs (and folks can consider adding new RPCs). - Then perhaps the Linux fallback case should be that instead of stubs, - too.* - - * `SOCK_CLOEXEC` - - IRC, freenode, #hurd, 2013-09-02: - - Do we support accept4 with the SOCK_CLOEXEC flag? - According to the code in sysdeps/mach/hurd/accept4.c - that case is not covered - (only O_NONBLOCK, not SOCK_NONBLOCK??)) - gnu_srs1: we do - but only for accept4, not for socket and socketpair - pinotree: cannot find the case for O_CLOEXEC covered in - __libc_accept4() - gnu_srs1: no, you need SOCK_* - The only code for accept4() is in sysdeps/mach/hurd/ and - it uses O_* for flags ? - flags = sock_to_o_flags (flags); - tried checking it? - Aha, tks:-D - and you don't need an explicit case of O_CLOEXEC, since - it is handled in other ways - - [[!message-id "1378154151.21738.15.camel@G3620.my.own.domain"]]. - - IRC, freenode, #hurd, 2013-09-03: - - any ideas about the SOCK_CLOEXEC issue? - didn't i tell already about it? - I did not find any hurd related code in tschwinges - branches. - you didn't check deep then... - so why does socket/socketpair not return ENOSYS then? - why should it, since they are implemented? - ... - for socket/socketpair? - gnu_srs: enosys means no system call - s/ENOSYS/EINVAL/ - see the mail to the bug-hurd/debian-hurd ML for more info - and tschwinges reply - which is what i knew already? - pinotree: please reply on the mailing list on the EINVAL - vs EPROTOTYPE issue to clarify things - gnu_srs: - https://sourceware.org/ml/libc-alpha/2013-02/msg00092.html - gnu_srs: things were clear already... - pinotree: I've read that patch and still pflocal/pf.c - returns EPROTOTYPE not changed by the __socket wrapper in eglibc - gnu_srs: what about realizing SOCK_CLOEXEC and friends - are NOT posix? - since socket/socketpair does not return EINVAL the dbus - code has to be patched then? - pflocal should never ever get such flags mixed to the - protocol, so any invalid value of protocol correctly returns - EPROTOTYPE - this is the question I need answered: Which way to go? - all of them - ? - - applications should not assume that because you have - accept4 (which is not posix) then SOCK_CLOEXEC and SOCK_NONBLOCK - (flags for it) are usable to socket and socketpair - - glibc should (as the idea of my patch) handle - implementations providing SOCK_* but not supporting them for - socket/socketpair - - finally the hurd part of glibc could implement them - to conclude: should I send a bug report for dbus then? - pinotree: yes or no? - gnu_srs: *shrug* i wrote it above, so an *upstream* - report (not a debian one) - - IRC, freenode, #hurd, 2013-09-06: - - I've found another error code issue, now in glib2.0 (and - dbus). Are you really sure the error code - for protocol of pflocal/pf.c should be - EPROTONOSUPPORT. The code expects EINVAL for a protocol with - SOCK_CLOEXEC, which is a flag. Maybe pf.c should add - this case and return EINVAL instead of - submitting bug reports upstream. Yes, I know this is not - POSIX, but it is defined for Hurd too, - currently only supported for accept4, not socket or - socketpair. - gnu_srs: no, and i explained already why it is wrong - this way - pflocal shouldn't even get such flags - (pflocal or any other server implementing socket_create) - (20:19:35) pinotree: pflocal shouldn't even get such - flags - then the glibc wrapper code is missing to catch this - flag:( - youpi: ? - gnu_srs: because, as told many times, socket and - socketpair do not support such flags - given they don't do, they filter nothing - and no, you need to file bugs upstream, since having - SOCK_* and accept4 does not imply at all that socket and - socketpair support them - - IRC, freenode, #hurd, 2013-09-07: - - A correction from yesterdays discussion: - s/EPROTONOSUPPORT/EPROTOTYPE - - IRC, freenode, #hurd, 2013-09-10: - - for dbus2.0 I found out that the third SOCK_CLOEXEC case - needs a patch too (more working tests), - the updated patch is at http://paste.debian.net/37948/ if - you have the time, otherwise I'll do it. - gnu_srs: which is what i wrote in my bug report... - Yes you wrote that, but the patch is not updated yet? - it refers to a different socket access, recently added, - which is not used by default - I got two more tests running when adding that patch:-/ - tests of what? - run-test.sh and run-test-systemserver.sh:P - tests of what? - i don't have the universal knowledge of the files in all - the sources - dbus-1.6.14/test/name-test/* - - [[!message-id "523A3D6C.2030200@gmx.de"]]. - - IRC, OFTC, #debian-hurd, 2013-09-19: - - tschwinge: ehm, regarding the SOCK_* patches for - socket/socketpair, didn't we talk about them when i worked on - eglibc 2.17? - - * `mlock`, `munlock`, `mlockall`, `munlockall` - - IRC, freenode, #hurd, 2014-01-09: - - Hi, is mlock, mlockall et al implemented? - i doubt it - mlock could be, but mlockall only partially - - * [[glibc_IOCTLs]] - - * Support for `$ORIGIN` in the dynamic linker, `ld.so` - - IRC, freenode, #hurd, 2014-02-23: - - - https://www.gnu.org/software/hurd/user/jkoenig/java/report.html - says $ORIGIN patches have been added to Hurd. Have those hit the - mainline codebase? - - [[user/jkoenig/java]], [[user/jkoenig/java/report]]. - - It doesn't seem to work here, but perhaps I'm missing - something (I'm using the prebuilt Debian/Hurd 2014-02-11 VM - image) - objdump -x says the value of RPATH is $ORIGIN - But it doesn't load a library I placed in the same dir as - the binary - sjamaan: i'm not sure - sjamaan: what are you trying to do ? - - IRC, freenode, #hurd, 2014-02-24: - - braunr: I am working on a release of the CHICKEN Scheme - compiler. Its test suite is currently failing on the stand-alone - deployment tests. Either it should work and use $ORIGIN, or the - test should be disabled, saying Hurd is not supported for - stand-alone deployment-directories - braunr: The basic idea is to be able to create "appdirs" - like on OS X or PC-BSD, containing all the dependencies a program - needs, which can then simply be untarred - sjamaan: ok so you do need $ORIGIN - yeah - iiuc, so does Java. Does Java work on Hurd? - we had packages at the time jkoenig worked on it - integration of patches may have been incomplete, i wasn't - there at the time and i'm not sure - So it's safest to claim it's unsupported, for now? - yes - Thank you, I'll do that and revisit it later - - * `mig_reply_setup` - - IRC, freenode, #hurd, 2014-02-24: - - braunr: neither hurd, gnu mach or glibc provides - mig_reply_setup - i want to provide this function, where should i put it ? - i found some mach source that put it in libmach afaic - - ftp://ftp.sra.co.jp/.a/pub/os/mach/extracted/mach3/mk/user/libmach/mig_reply_setup.c - teythoon: what does it do ? - braunr: not much, it just initializes the reply message - libports does this as well, in the - ports_manage_port_operations* functions - teythoon: is it a new function you're adding ? - braunr: yes - braunr: glibc has a declaration for it, but no - implementation - teythoon: i think it should be in glibc - maybe in mach/ - - * [[POSIX file record locking|file_locking]] - - * `execve` with relative paths - - [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id - "4BFA500A.7030502@gmail.com"]]. - - IRC, freenode, #hurd, 2014-03-05: - - youpi: what about the exec_filename patch series? [...] - Roland was disagreeing with it - - * `mount`/`umount` - - IRC, freenode, #hurd, 2014-03-01: - - Hi, how to handle packages depending on mount.h, et al? - On Hurd mount/umount is supplied by hurd is not in libc? - gnu_srs1: mount or mount.h? - mount.h et al - man 2 mount - what is the question then? - some packages expect the mount 2 functionality - available, not by the external command mount/umonut - umount* - azeem: one example is fuse - gnu_srs1: that is correct - gnu_srs1: i put a small hacks entry in the list about - moving the mount/umount functionality from our utilities to the - libc - - * POSIX Timers - - `timer_create`, `timer_delete`, [[`clock_gettime`|clock_gettime]], and - so on. - - * `fd_to_filename` - - See [[translate_FD_or_port_to_file_name]]. - - For specific packages: - - * [[octave]] - - * Create `t/cleanup_kernel-features.h`. - - * [[Secure_file_descriptor_handling]]. - - * In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of - `-DHAVE_SENDFILE` -- but we do have `sendfile`, too. - - Define `__ASSUME_SENDFILE` to 1 in `kernel-features.h`, if `sendfile` - works. - - * `/usr/include/pthread.h` overwrite issue - - `make`, after editing `nss/nss_db/db-initgroups.c`: - - [...] - make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv' - make subdir=nss -C nss ..=../ others - make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' - /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h - /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied - make[2]: *** [/usr/include/pthread.h] Error 1 - make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' - make[1]: *** [nss/others] Error 2 - make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker' - make: *** [all] Error 2 - - See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]]. Passing - `install_root=/INVALID` to `make`/`make check` is a cheap cure. For `make - install`, prepending an additional slash to `install_root` (that is, - `install_root=//[...]`) is enough to obfuscate the Makefile rules. - - * `sysdeps/unix/sysv/linux/syslog.c` - - * `fsync` on a pipe - - IRC, freenode, #hurd, 2012-08-21: - - pinotree: i think gnu_srs spotted a conformance problem in - glibc - (only one?) - pinotree: namely, fsync on a pipe (which is actually a - socketpair) doesn't return EINVAL when the "operation not supported" - error is returned as a "bad request message ID" - pinotree: what do you think of this case ? - i'm far from an expert on such stuff, but seems a proper E* - should be returned - (there also is a problem in clisp falling in an infinite loop - when trying to handle this, since it uses fsync inside the error - handling code, eww, but we don't care :p) - basically, here is what clisp does - if fsync fails, and the error isn't EINVAL, let's report the - error - and reporting the error in turn writes something on the - output/error stream, which in turn calls fsync again - smart - after the stack is exhausted, clisp happily crashes - gnu_srs: i'll alter the clisp code a bit so it knows about our - mig specific error - if that's the problem (which i strongly suspect), the solution - will be to add an error conversion for fsync so that it returns - EINVAL - if pinotree is willing to do that, he'll be the only one - suffering from the dangers of sending stuff to the glibc maintainers - :p - that shouldn't be an issue i think, there are other glibc - hurd implementations that do such checks - does fsync return EINVAL for other OSes? - EROFS, EINVAL - fd is bound to a special file which does not - support synchronization. - obviously, pipes and sockets don't - - http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html - so yes, other OSes do just that - now that you speak about it, it could be the failure that - the gnulib fsync+fdatasync testcase have when being run with `make - check` (although not when running as ./test-foo) - hm we may not need change glibc - clisp has a part where it defines a macro IS_EINVAL which is - system specific - (but we should change it in glibc for conformance anyway) - #elif defined(UNIX_DARWIN) || defined(UNIX_FREEBSD) || - defined(UNIX_NETBSD) || defined(UNIX_OPENBSD) #define IS_EINVAL_EXTRA - ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV)) - i'd rather add nothing to clisp - let's see what posix says - EINVAL - so right, we should simply convert it in glibc - man fsync mentions EINVAL - man pages aren't posix, even if they are usually close - aha - i think checking for MIG_BAD_ID and EOPNOTSUPP (like other - parts do) will b enough - *be - gnu_srs: there, it finished correctly even when piped - I saw that, congrats! - clisp is quite tricky to debug - i never had to deal with a program that installs break points - and handles segfaults itself in order to implement growing stacks :p - i suppose most interpreters do that - So the permanent change will be in glibc, not clisp? - yes - - IRC, freenode, #hurd, 2012-08-24: - - pinotree: The changes needed for fsync.c is at - http://paste.debian.net/185379/ if you want to try it out (confirmed - with rbraun) - I agree with the patch, posix indeed documents einval as the - "proper" error value - there's fdatasync too - other places use MIG_BAD_ID instead of EMIG_BAD_ID - pinotree: i assume that if you're telling us, it's because - they have different values - braunr: tbh i never seen the E version, and everywhere in - glibc the non-E version is used - in sysdeps/mach/hurd/bits/errno.h only the E version is - defined - look in gnumach/include/mach/mig_errors.h - (as the comment in errno.h say) - mig_errors.h yes. Which comment: from errors.h: /* Errors - from . */ and then the EMIG_ stuff? - Which one is used when building libc? - Answer: At least in fsync.c errno.h is used: #include - - Yes, fdatasync.c should be patched too. - pinotree: You are right: EMIG_ or MIG_ is confusing. - /usr/include/i386-gnu/bits/errno.h: /* Errors from - . */ - /usr/include/hurd.h:#include - - IRC, freenode, #hurd, 2012-09-02: - - braunr: regarding fsync(), I agree that EOPNOTSUPP probably - should be translated to EINVAL, if that's what POSIX says. it does - *not* sound right to translate MIG_BAD_ID though. the server should - explicitly return EOPNOTSUPP, and that's what the default trivfs stub - does. if you actually do see MIG_BAD_ID, there must be some other - bug... - antrik: right, pflocal doesn't call the trivfs stub for socket - objects - trivfs_demuxer is only called by the pflocal node demuxer, for - socket objects it's another call, and i don't think it's the right - thing to call trivfs_demuxer there either - handling MAG_BAD_ID isn't a bad idea anyway, you never know - what the underlying server actually implements - (imho) - for me, a bad id is the same as a not supported operation - ditto - from fsync's POV, both the results are the same anyway, ie - that the server does not support a file_sync operation - no, a bad ID means the server doesn't implement the protocol - (or not properly at least) - it's usually a bug IMHO - there is a reason we have EOPNOTSUPP for operations that are - part of a protocol but not implemented by a particular server - antrik: even if it could be the case, there's no reason to - make fsync fail anyway - pinotree: I think there is. it indicates a bug, which should - not be hidden - well, patches welcome then... - thing is, if sock objects are actually not supposed to - implement the file interface, glibc shouldn't even *try* to call - fsync on them - how? - i mean, can you check whether the file interface is not - implemented, without doing a roundtrip^ - ? - well, the sock objects are not files, i.e. they were *not* - obtained by file_name_lookup(), but rather a specific call. so glibc - actually *knows* that they are not files. - antrik: this way of thinking means we need an "fd" protocol - so that objects accessed through a file descriptor implement - all fd calls - now I wonder though whether there are conceivable use cases - where it would make sense for objects obtained through the socket - call to optionally implement the file interface... - which could actually make sense, if libc lets through other - file calls as well (which I guess it does, if the sock ports are - wrapped in normal fd structures?) - antrik: they are - and i'd personally be in favor of such an fd protocol, even if - it means implementing stubs for many useless calls - but the way things are now suggest a bad id really means an - operation is simply not supported - the question in this case is whether we should make the file - protocol mandatory for anything that can end up in an FD; or whether - we should keep it optional, and add the MIG_BAD_ID calls to *all* FD - operations - (there is no reason for fsync to be special in this regard) - yes - braunr: BTW, I'm rather undecided whether the right approach - is a) requiring an FD interface collection, b) always checking - MIG_BAD_ID, or perhaps c) think about introducing a mechanism to - explicitly query supported interfaces... - - IRC, freenode, #hurd, 2012-09-03: - - antrik: querying interfaces sounds like an additional penalty - on performance - braunr: the query usually has to be done only once. in fact it - could be integrated into the name lookup... - antrik: once for every object - antrik: yes, along with the lookup would be a nice thing - - [[!message-id "1351231423.8019.19.camel@hp.my.own.domain"]]. - - * `t/no-hp-timing` - - IRC, freenode, #hurd, 2012-11-16 - - tschwinge: wrt the glibc topgit branch t/no-hp-timing, - couldn't that file be just replaced by #include - ? - - * `flockfile`/`ftrylockfile`/`funlockfile` - - IRC, freenode, #hurd, 2012-11-16 - - youpi: uhm, in glibc we use - stdio-common/f{,try,un}lockfile.c, which do nothing (as opposed to eg - the nptl versions, which do lock/trylock/unlock); do you know more - about them? - pinotree: ouch - no, I don't know - well, I do know what they're supposed to do - i'm trying fillig them, let's see - but not why we don't have them - (except that libpthread is "recent") - yet another reason to build libpthread in glibc, btw - oh, but we do provide lockfile in libpthread, don't we ? - pinotree: yes, and libc has weak variants, so the libpthread - will take over - youpi: sure, but that in stuff linking to pthreads - if you do a simple application doing eg main() { fopen + - fwrite + fclose }, you get no locking - so? - if you don't have threads, you don't need locks :) - ... unless there is some indirect recursion - ? - basically, i was debugging why glibc tests with mtrace() and - ending with muntrace() would die (while tests without muntrace call - wouldn't) - well, I still don't see what a lock will bring - if you look at the muntrace implementation (in - malloc/mtrace.c), basically fclose can trigger a malloc hook (because - of the free for the FILE*) - either you have threads, and it's need, or you don't, and it's - a nop - yes, and ? - does the signal thread count ? - again, in linux, when you don't have threads, the lock is a nop - does the signal thread use IO ? - that's the question :) - i hope not - IIRC the signal thread just manages signals, and doesn't - execute the handler itself - sure - i was more thinking about debug stuff - can't hurt to add them anyway, but let me still doubt that it'd - fix muntrace, I don't see why it would, unless you have threads - that's what i'm going next - pardon, it seems i got confused a bit - it'd look like a genuine muntrace bug (muntrace → fclose → - free hook → lock lock → fprint (since the FILE is still set) → malloc - → malloc hook → lock lock → spin) - at least i got some light over the flockfile stuff, thanks - ;) - youpi: otoh, __libc_lock_lock (etc) are noop in the base - implementation, while doing real locks on hurd in any case, and on - linux only if nptl is loaded, it seems - that would explain why on linux you get no deadlock - unless using nptl, that is? - hm no, even with pthread it works - but hey, at least the affected glibc test now passes - will maybe try to do investigation on why it works on linux - tomorrow - - [[!message-id "201211172058.21035.toscano.pino@tiscali.it"]]. - - In context of [[libpthread]]. - - IRC, freenode, #hurd, 2013-01-21 - - ah, found something interesting - tschwinge: there seems to be a race on our file descriptors - the content written by one thread seems to be retained - somewhere and another thread writing data to the file descriptor will - resend what the first already did - it could be a FILE race instead of fd one though - yes, it's not at the fd level, it's above - so good news, seems like the low level message/signalling code - isn't faulty here - all right, simple explanation: our IO_lockfile functions are - no-ops - braunr: i found that out days ago, and samuel said they were - okay - well, they're not no-ops in libpthreads - so i suppose they replace the default libc stubs, yes - so the issue happens in cthreads-using apps? - no - we don't have cthreads apps any more - and aiui, libpthreads provides cthreads compatibility calls to - libc, so everything is actually using pthreads - more buffer management debugging needed :/ - hm, so how can it be that there's a multithread app with no - libpthread-provided file locking? - ? - file locking looks fine - hm, the recursive locking might be wrong though - ./sysdeps/mach/hurd/bits/libc-lock.h:#define - __libc_lock_owner_self() ((void *) __hurd_threadvar_location (0)) - nop, looks fine too - indeed, without stream buffering, the problem seems to go away - pinotree: it really looks like the stub IO_flockfile is used - i'll try to make sure it's the root of the problem - braunr: you earlier said that there's some race with - different threads, no? - yes - either a race or an error in the iostream management code - but i highly doubt the latter - if the stub locks are used, then libpthread is not - loaded... so which different threads are running? - that's the thing - the libpthread versions should be used - so the application is linked to pthread? - yes - i see, that was the detail i was missing earlier - the common code looks fine, but i can see wrong values even - there - e.g. when vfprintf calls write, the buffer is already wrong - i've made similar tests on linux sid, and it behaves as it - should - hm - i even used load to "slow down" my test program so that - preemption is much more likely to happen - note we have slightly different behaviour in glibc's libio, - ie different memory allocation ways (mmap on linux, malloc for us) - the problem gets systematic on the hurd while it never occurs - on linux - that shouldn't matter either - ok - but i'll make sure it doesn't anyway - this mach_print system call is proving very handy :) - and also, with load, unbuffered output is always correct too - braunr: you could try the following hack - http://paste.debian.net/227106/ - what does it do ? - (yes, ugly as f**k) - does it force libio to use mmap ? - or rather, enable ? - provides a EXEC_PAGESIZE define in libio, so it makes it use - mmap (like on linux) instead of malloc - - * `t/pagesize`. - - yes, the stub is used instead of the libpthreads code - tschwinge: ^ - i'll override those to check that it fixes the problem - hm, not that easy actually - copy their files from libpthreads to sysdeps/mach/hurd - hm right, in libpthread they are not that split as in glibc - let's check symbol declaration to understand why the stubs - aren't overriden by ld - _IO_vfprintf correctly calls @plt versions - i don't know enough about dynamic linking to see what causes - the problem :/ - youpi: it seems our stdio functions use the stub IO_flockfile - functions - really? I thought we were going through cthreads-compat.c - yes really - i don't know why, but that's the origin of the "duplicated" - messages issue - messages aren't duplicated, there is a race that makes on - thread reuse the content of the stream buffer - one* - k, quite bad - at least we know where the problem comes from now - youpi: what would be the most likely reason why weak symbols - in libc wouldn't be overriden by global ones from libpthread ? - being loaded after libc - i tried preloading it - i'll compare with what is done on wheezy - you have the local-dl-dynamic-weak.diff patch, right? - (on squeeze, the _IO_flockfile function in libc seems to do - real work unlike our noop stub) - it's the debian package, i have all patches provided there - indeed, on linux, libc provides valid IO_flock functions - ./sysdeps/pthread/flockfile.c:strong_alias (__flockfile, - _IO_flockfile) - that's how ntpl exports it - nptl* - imho we should restructure libpthread to be more close to - nptl - i wish i knew what it involves - file structing for sources and tests, for example - well yes obviously :) - i've just found a patch that does exactly that for linuxthreads - that = fix the file locking? - in addition to linuxthreads/lockfile.c (which we also - equivalently provide), there is - linuxthreads/sysdeps/pthread/flockfile.c - no, restructiring - restructuring* - i still have only a very limited idea of how the glibc sources - are organized - the latter is used as source file when compiling flockfile.c - in stdio-common - shouldn't we provide one too ? - that would mean it would be compiled as part of libc proper, - not libpthread - yes - that's what both linuxthreads and nptl seem to do - and the code is strictly the same, i.e. a call to the internal - _IO_lock_xxx functions - I guess that's for the hot-dlopen case - you need to have locks properly taken at dlopen time - youpi: do you mean adding an flockfile.c file to our sysdeps - will only solve the problem by side effect ? - and that the real problem is that the libpthread versions - aren't used ? - yes - ok - youpi: could it simply be a versioning issue ? - could be - it seems so - i've rebuilt with the flockfile functions versioned to 2.2.6 - (same as in libc) and the cthreads_compat functions are now used - and the problem doesn't occur any more with my test code - :) - could you post a patch? - i need a few info before - it'd be good to check which such functions are hooked - i suppose the version for functions declared in libpthreads - shouldn't change, right ? - yes - ok - they didn't have a vresion before - shall i commit directly ? - so it should be fine - well, they did - 2.12 - yes, but please tell me when it's done - sure - so I can commit that to debian's eglibc - I mean, before we integrated libpthread build into glibc - so they never had any version before 2.12 - ok - basically we need to check the symbols which are both in - libpthread and referenced in libc - to make sure they have the same version in the reference - ok - only weak references need to be checked, others would have - produced a runtime error - youpi: done - arg, the version i mention in the comment is wrong - i suppose people understand nonetheless - probably, yes - ah, i can now appreciate the headache this bug hunting gave me - these last days :) - - IRC, freenode, #hurd, 2013-01-22 - - braunr: commited to debian glibc - btw, it's normal that the program doesn't terminate, right? - (i.e. it's the original bug you were chasing) - youpi: about your earlier question (yesterday) about my test - code, it's expected to block, which is the problem i was initially - working on - ok, so all god - +o - - * `t/pagesize` - - IRC, freenode, #hurd, 2012-11-16 - - tschwinge: somehow related to your t/pagesize branch: due to - the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h - switches the allocation modes from mmap to malloc - - [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. - - IRC, freenode, #hurd, 2013-01-21 - - why is it a hack ? - because most probably glibc shouldn't rely on EXEC_PAGESIZE - like that - ah - there's a mail from roland, replying to thomas about this - issue, that this use of EXEC_PAGESIZE to enable mmap or not is just - wrong - ok - (the above is - http://thread.gmane.org/87mxd9hl2n.fsf@kepler.schwinge.homeip.net ) - thanks - (just added the reference to that in the wiki) - pinotree: btw, what's wrong with using malloc instead of mmap - in libio ? - braunr: i'm still not totally sure, most probably it should - be slightly slower currently - locking contention ? - pinotree: - http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html - pinotree: it looks to me there is now no valid reason not to - use malloc - the best argument for mmap is that libio requires zeroed - memory, but as the OP says, zeroing a page is usually more expensive - than a small calloc (even on kernel that keep a list of zeroed pages - for quick allocations, frequent mmaps() often make this list empty) - braunr: mmap allocations in libio are rounded to the page - size - well they have to - - * `LD_DEBUG` - - IRC, freenode, #hurd, 2012-11-22 - - woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and - then sigsegv - Yeah, that's known for years... :-D - Probably not too difficult to resolve, though. - - * IRC, OFTC, #debian-hurd, 2013-08-16: - - http://paste.debian.net/25934/ ← _hurd_thread_sigstate calls - malloc, boom - - * `conformtest` - - IRC, OFTC, #debian-hurd, 2013-09-22: - - btw, I noticed that glibc has a head conformance test which we - happily fail quite a bit :) - it's not so awful, we don't have twice as many failures as - linux, but not so far - youpi: do you mean "header" for "head", right? - err, where ? :) - btw, I noticed that glibc has a head conformance - test which we happily fail quite a bit :) - ah, yes - noticed that too - I had a quick look at the POSIX part, some things are probably - not too hard to change (e.g. exposing pthread_kill in signal.h) - others will by quite hard to fix (short type instead of int - type for some flock structure field) - s/by/be/ - - * `truncate`/`ftruncate` - - Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603, - glibc still to be done? - - IRC, freenode, #hurd, 2013-10-01: - - libdiskfs/node-drop.c: assert (np->dn_stat.st_size == 0); ← - this one? - iirc you constantly get that when building ustr - is ustr a package ? - yes - iirc the ustr tests are mostly disk-intensive - - IRC, freenode, #hurd, 2013-10-02: - - i've traced the problem up to truncate - which gets a negative size - shouldn't take long to find out where it comes from now - it seems our truncate doesn't handle negative values well though - EINVAL The argument length is negative or larger than the - maximum file size. - i still have to see whether it comes from the user (unlikely) or - if it's an internal inconsistency - i suspect some code wrongly handles vm_map failures - leading to that inconsistency - pinotree: looks like glibc doesn't check for length >= 0 - yeah - servers should do it nonetheless - should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both? - it appears a client does the truncate - i'd say both - can you take the glibc part ? :) - i was going to do the hurd part... :p - ok, i'll pick libc - well i'm doing it already - i want to write a test case first - to make sure that's the problem - already on the hurd part, you mean? - yes - ok - ok looks like it - i can't reproduce the assertion but it does make ext2fs freeze - pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c - merci - pinotree: ustr builds - wow - the client code (ustr) seems to perform a ftruncate with size - ((size_t)-1) whereas lengths are signed .. - i'll check other libraries and send a patch soon - - IRC, freenode, #hurd, 2013-10-03: - - youpi: i've committed a fix to hurd that checks for negative sizes - when truncating files - this allows building the ustr package without making ext2fs choke - on an assertion - pinotree is preparing a patch for glibc - see truncate/ftruncate - with an off_t size parameter, which can be negative - EINVAL The argument length is negative or larger than the - maximum file size. - hurd servers were not conforming to that before my change - - * `t/ptrmangle`: `PTR_MANGLE`/`PTR_DEMANGLE` - - * - - * See also [[t/tls|t/tls]]. - - * b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8 `ARM: Add pointer encryption - support.` may help to find all the places that need to be touched when - adding support. - - * Verify baseline changes, if we need any follow-up changes: - - * a11ec63713ea3903c482dc907a108be404191a02 - * 7e2b0c8562b35155820f87b5ff02a8b6850344cc - * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9 - * 5a2a1d75043138e696222ced4560de2fb90b8024 - * 5ae958d74180e2572d198bd7872c86f391de6da7 - * 5b08ac571ff8e94fe96511a532f0d20997de5f52 - * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26 - * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf - * 63c4ed22b5048c8701d8806026c23cc95f0df756 - * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c - * e35fcef8b739ed24e083ff8a3078ac14e101cf67 - * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba - * 8a492a675e566dc1e666df0a86cbf541442cb179 - * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef - * c86434ccb576a3ce35b5a74f72b9f03bd45b522a - * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 - * 15bac72bac03faeb3b725b1d208c62160f0c3ad7 - * c08fb0d7bba4015078406b28d3906ccc5fda9d5a - * 10b3bedcb03386cc280113f552479793e4bac35f - * 754f7da38b0904b4b989d3500cc8dd5be625cf6a - * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d - * 962dba7828cf251a9025ccb43bc6effa30379b72 - * 3162f12e58c3a848db883916843b332b9f8c9d39 - * 1c06ba3100847da6bd1f2e011dc24fa8debd9615 - * 84b9230c404aed4fd3a7bb3d045ca367043dde8c - * 090555538d4347a52807ba9f08cf20ed13206afe - * 817328eea788c746131cf151b64fd250200da333 - * c3758feebf7c8786231465da664743c6f0ec79cc - * 1ac7a2c7b448c851eb8976fcc290a906a4075203 - * c21cc9bcb38a87ff638d1099ca871d94a2192b31 - * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde - * b8b4863d78bf26b39918fc753b03ed98ef262903 - * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1 - * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in - `sysdeps/mach/hurd/dl-sysdep.c` - * 0e516e0e14f2f9783a21cd1727bc53776341f857 - * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc - * cf7c9078a5acdbb435498ace92cd81009637a971 - * db753e2cfb2051ebf20dc089f87c5b1297cc2cff - * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good. - * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b - * 451f001b50870604e1f2daef12f04f9f460d3997 + - a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484. `nptl/Versions - [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`. We don't even - define it yet. Also see - [[glibc___libc_alloca_cutoff_should_be_lowered]]. - * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34 - * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca - * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f - * 68dc949774cb651d53541df4abdc60327f7e096b - * 70181fddf1467996bea393d13294ffe76b8a0853 - * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca - * 32465c3ea007065acd8ca8199f130cdf4068130d - * 18ba70a559c52719fd94a713cc380514d9d19125 - * 620a05296fe3380b7441ba7720e8b25c48a8c28c - * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in - TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c` - hunk? - * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 + - 1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix - pathconf(_PC_BUF_SIZE).` - * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.` - * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 + - 6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long - paths` - * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler - call in spawn implementation` - * 3b85df27870a47ed1db84e948e37a5a50a178a92 + - f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf - * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid - timeouts in emulated pselect` - * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`; - strndupa? - * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative - error numbers in strerror_r`. Change needed for - `sysdeps/mach/_strerror.c`? - * 7ea72f99966a65a56aedba817ee2413ff9b1f23c + - adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer - in XPG strerror function`. Change needed for - `sysdeps/mach/xpg-strerror.c`? - * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss ([[debugging]], - [[profiling]]). Does it work? - * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 + - 80e2212d8e59933a1641f029ebd360526ff0e074 + - 4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code - used for raise()`. Also for `bits/siginfo.h`? - * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work? - Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`, - `/proc/[PID]/mem` ([[!tag open_issue_hurd]], - [[hurd/translator/procfs]]). - * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`. - Watch what happens. - * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`. Watch - what happens. Native build: apparently OK. - * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) + - 1b74661a6b93a892ecb1c717dedeedba5c2a976c + - fd5e21c75d8e9221d766f4bc922a237265514ec2. Watch what happens. Native - build: `use-default-link = no`. - * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`), - 4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in - {,f}pathconf`). What about stuff like that for us? - * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with - AC_CHECK_TOOL`). Aren't there more in other configure.in and Makefile - files? - * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in - cancellation initialization`). Is this needed in other places, too? - * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64 - bytes`). Probably we have hidden somewhere such a constant, too (in - libpthread). - * d96de9634a334af16c0ac711074c15ac1762b23c + - ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn* - only in compat mode`). Change looks good, but what about - `SPAWN_XFLAGS_TRY_SHELL` for us? - * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features - mandatory and simplify the code.`). Generally looks good. - * `locale/global-locale.c`: Apparently, no one is using - `_HURD_THREADVAR_LOCALE`. But it is exported via - `hurd/threadvar.h`. - * `mach/devstream.c`: reversed. Fixed in - `t/repair-mach_devstream.c`. - * `malloc/arena.c`: should be OK. - * `Remove support for !USE___THREAD`. - d063d164335938d557460bebaa7cfe388157b627 (generally looks good; - `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) + - (de82006d43e198fd162807c9adc720c7ebd728a3 + - 037e9fe21c92216ef7032ea2796781ec27ca182a) + - 995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) + - bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok). - * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all - kinds of unused configuration options and dead code.`). `NO_STARTER` - changes (should be OK). - * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify - malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237, - [[!sourceware_PR 11929]]. Is this all kosher for us? See - [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. - * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls - option, TLS support is required`). - * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in - __cmsg_nxthdr`). Probably just a C++ thing and not relevant for us; - see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]]. - * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7. Kosher with - respect to our [[glibc/mmap]] peculiarities? - * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`, - aa78043a4aafe5db1a1a76d544a833b63b4c5f5c + - 49a43d80ec5c97cf6136b1ee2687414773b2d5aa + - 3871f58f065dac3917eb18220a479e9591769c8c + - 9beb2334930db81ceada5aa6051fe5ac0554db32 + - 0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 + - edc5984d4d18296d7aa3d8f4ed8f7336a743170e + - 57769839788e2c62b68d9dfbf4b35052321278ba. - . - * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 + - 4efeffc1d583597e4f52985b9747269e47b754e2 + - d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror - `bits/siginfo.h` changes. - * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe, - [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for - us? - * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 -- - probably should do similar changes, also to the generic file. - * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id - "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]] - 02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same - for the generic version as used by GNU Hurd. - * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4, - [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what - about other architectures? - * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to - adapt for (conditional?) Sun RPC reversion (if that was the original - cause for the patch)? - * [low] `Add __fsword_t and use it in bits/statfs.h`, - 3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id - "20120517134700.GA19046@intel.com"]] -- only updates one copy of - `bits/statfs.h`; update the others, too, for consistency. - * [low] 789bd351b45f024b7f51e4886bf46b8e887ab6da: remove - `libc_hidden_def` in `sysdeps/mach/hurd/accept4.c`? - * 0948c3af9dfb3bc1312d6bed2f3a6bfd4e96eef4, - b80af2f40631871cf53a5e39d08d5d5516473b96, - 04570aaa8ad88caad303f8afe469beb4cf851e17 `_dl_initial_dtv`: OK? - * [very low] ea4d37b3169908615b7c17c9c506c6a6c16b3a26 `Implement - POSIX-generic sleep via nanosleep rather than SIGARLM.`: any benefit - using that one (with `sysdeps/mach/nanosleep.c`) instead of - `sysdeps/mach/sleep.c`? - * ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd, - 2012-11-20, pinotree: »tschwinge: i agree on your comments on - ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's - sleep.c is buggy (not considers interruption, extra time() (= RPC) - call)«. - * ba384f6ed9275f3966505f2375b56d169e3dc588, - 0409959c86f6840510851a851a1588677a2e537b, - e57b0c6100e63bfd816ae59339452eafc81f1d3a `C++11 thread_local - destructors support`. Anything needed to be done in our [[libpthread]] - and configured for us in [[GCC]]? Probably need to replicate the - `nptl/pthread_create.c` change, and fix - `stdlib/Makefile`:`$(objpfx)tst-tls-atexit`. - - +++ include/link.h - @@ -302,6 +302,9 @@ struct link_map - + /* Number of thread_local objects constructed by this DSO. */ - + size_t l_tls_dtor_count; - - +++ include/stdlib.h - @@ -100,6 +100,11 @@ extern int __cxa_atexit (void (*func) (void *), void *arg, void *d); - +extern int __cxa_thread_atexit_impl (void (*func) (void *), void *arg, - + void *d); - +extern void __call_tls_dtors (void); - +libc_hidden_proto (__call_tls_dtors); - - +++ nptl/pthread_create.c - @@ -311,6 +311,9 @@ start_thread (void *arg) - [after the thread function returns] - + /* Call destructors for the thread_local TLS variables. */ - + __call_tls_dtors (); - - +++ stdlib/Makefile - +$(objpfx)tst-tls-atexit = $(common-objpfx)nptl/libpthread.so \ - + $(common-objpfx)dlfcn/libdl.so - - +++ stdlib/cxa_thread_atexit_impl.c - - +++ stdlib/exit.c - __run_exit_handlers (int status, struct exit_function_list **listp, - bool run_list_atexit) - { - + /* First, call the TLS destructors. */ - + __call_tls_dtors (); - - +gcc-4.7 tst-tls-atexit.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parenth - +gcc-4.7 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit [...]/tschwinge/Roger_Whittaker.build/nptl/lib - +gcc-4.7: error: [...]/tschwinge/Roger_Whittaker.build/nptl/libpthread.so: No such file or directory - +make[2]: *** [[...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit] Error 1 - +gcc-4.7 tst-tls-atexit-lib.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-par - +tst-tls-atexit-lib.c: In function 'do_foo': - +tst-tls-atexit-lib.c:35:3: warning: implicit declaration of function '__cxa_thread_atexit_impl' [-Wimplicit-function-declaration] - * a600e5cef53e10147932d910cdb2fdfc62afae4e `Consolidate Linux and POSIX - libc_fatal code.` -- is `backtrace_and_maps` specific to Linux? - - IRC, freenode, #hurd, 2014-02-06: - - why wouldn't glibc double free detection code also print - the backtrace on hurd ? - I don't see any reason why - except missing telling glibc that it's essentially like on - linux - - * 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use __ehdr_start, if - available, as fallback for AT_PHDR.` -- once we require Binutils 2.23, - can we simplify [[glibc's process startup|glibc/process]] - (initialization of `_dl_phdr` and `_dl_phnum`)? As these are only used - for `[!SHARED]`, can we completely remove them (that is, the `phdr` and - `phdrsz` members) from `hurd_startup_data`, and simplify - [[hurd/interface/exec_startup_get_info]], or do we still require these - for the `[SHARED]` case? - * fab7ce3f5b4060bf62659e8b58529de4156b5a2f `Link extra-libs consistently - with libc and ld.so.` Alright for us? Probably have to adjust - [libpthread]/Makefile. - * b8c61b4b1d6afb69190169764c1b141f4659e48b `Remove trailing whitespace - from mach/*.sub.` Update `mach/Makefile`: generated - `mach/errsystems.c` is no longer checked in as of - 66e3dda448406399136e6f144a1b46679d5b2613. Rule had been disabled in - 421f82e5cc8f81ab003247d771bcecbad799be85, then re-enabled in - 8e3cc80f6d4f69ce003c82d3561ac324692792ad, but comment not removed. - * [low] 61dd6208fb1e59a423b6dfa712a3c896c34b2590 `New API to set default - thread attributes`. Implement in libpthread ([[!taglink - open_issue_libpthread]])? - * [high] e4608715e6e1dd2adc91982fd151d5ba4f761d69 `CVE-2013-2207, BZ - #15755: Disable pt_chown. -- [[!message-id - "51E8D4C1.9000705@redhat.com"]]; do we need it (`--enable-pt_chown`)? - cdfc721b8d2d5079325ea9f0beb5673d72b4cdd0. - * 91ce40854d0b7f865cf5024ef95a8026b76096f3 `CVE-2013-4237, BZ #14699: - Buffer overflow in readdir_r` -- [[!message-id - "519220C7.6050705@redhat.com"]]; do we need corresponding changes to - Hurd sysdep files? - * 8cc3269f95fa7faa8f448d741f68cbc40efbf4ee `Flesh out 4.4 bits/socket.h - with SOCK_CLOEXEC, SOCK_NONBLOCK.`, - e041fb8b6557882b6710a655a97bbf3541b56b54 `Replace generic bits/socket.h - with 4.4 file.` -- `sysdeps/mach/hurd/bits/socket.h` differs from the - generic `bits/socket.h` now only in the values of - [[`SOCK_CLOEXEC`|secure_file_descriptor_handling]] and - `SOCK_NONBLOCK`. If possible (no conflicts), would it make sense to - transition to the latter file, continuing to accept the former values - as deprecated for some time? - * [high] 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 `Fix unsafe compiler - optimization` -- have to revert, see [[!sourceware_PR 15605]]. For - analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49. - * 6c82a2f8d7c8e21e39237225c819f182ae438db3 `Coordinate IPv6 definitions - for Linux and glibc` -- alright for us? - * c61b4d41c9647a54a329aa021341c0eb032b793e `POINTER_CHK_GUARD` -- see - [[t/tls|t/tls]]. - * 5f855e3598a576c35e54623a13b256f3e87fcd4d `Fix erroneous (and circular) - implied pattern rule for linkobj/libc.so.` -- alright for us? - * [high] 7b7bab1391a3b16fff7e325e2c8a36b68eacba90 [Hurd] `Add fork hooks - for pthread_atfork` -- is that from a topic branch that can then be - annihilated? Verify emails. Verify no further changes in topic - branch. - * [high] 43d5c02c72bdaf59a8e0d4b06f2ae87e42269cbd `Fix build on hurd` -- - is that from a topic branch that can then be annihilated? Verify - emails. Verify no further changes in topic branch. - * 69a17d9d245dc3551792e95e1823cc2d877592f3 `Patch [1/4] - async-signal safe TLS.` -- do we also need an implementation of this? - (Not yet called from anywhere?) Now used in - 7f507ee17aee720fa423fa38502bc3caa0dd03d7 `Async-signal safe TLS`. - 7f507ee17aee720fa423fa38502bc3caa0dd03d7 has been reverted in - 73d61e4f6c65da714c0f8a3a233725322553ceba. - 1f33d36a8a9e78c81bed59b47f260723f56bb7e6, - 063b2acbce83549df82ab30f5af573f1b9c4bd19, - b627fdd58554bc36bd344dc40a8787c4b7a9cc46, - e81c64bba13d2d8b2a4e53254a82cc80f27c8497 have been reverted in - dd654bf9ba1848bf9ed250f8ebaa5097c383dcf8. - 35e8f7ab94c910659de9d507aa0f3e1f8973d914 has been reverted in - 8b6785f0836011cace9a77f3c24e51a7379238a0. - 69a17d9d245dc3551792e95e1823cc2d877592f3 has been reverted in - bf06bcee84d4c19a99925c0f58026a8cbd87a688. - a494421f5268df333c589d71104a39bb6a9cff19 has been reverted in - f482dbbec775bf72eb6510b6091fca141893c466. - * [low] In various commits, `menual/*.texi` files have been annotated - regarding MTASC-safety properties. The focus has not necessarily been - on Hurd, though. - * *baseline* - - -## Update - -`baseline`, `t/regenerate_configure` (could now be removed), -`t/master_backports`, `t/eglibc_backports`, `t/host-independency`, -`tschwinge/Roger_Whittaker` - - -# Build - -Here's a log of a glibc build run; this is from our [[Git repository's -f68531785b6d85fb0b405747688f93471b6a964f (2015-01-23; -9a869d822025be8e43b78234997b10bf0cf9d859 (2014-02-07)) -plus 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 reverted, -`id:"87a9fvguwq.fsf@schwinge.name"`, -`_SERVERS_STARTUP` hard-coded to `/servers/startup` in `sysdeps/mach/hurd/reboot.c` -sources|source_repositories/glibc]], run on laplace.SCHWINGE. - - $ export LC_ALL=C - $ ../Roger_Whittaker/configure --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build - [...] - $ make install_root=/INVALID 2>&1 | tee log_build_ - [...] - -This takes up around 600 MiB, and runs for [[TODO min|performance#measure]] on -kepler.SCHWINGE and [[19 min|performance#measure]] on laplace.SCHWINGE. - - - - -## Analysis - - $ toolchain/logs/process glibc build fetch laplace.SCHWINGE - -TODO. - - * baseline - fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b - (or probably Samuel's mmap backport) introduces: - - ../sysdeps/mach/hurd/mmap.c: In function '__mmap': - ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default] - ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default] - ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default] - ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default] - - * baseline - fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b - introduces: - - nscd_gethst_r.c: In function '__nscd_get_nl_timestamp': - nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] - - This was already present before: - - nscd_gethst_r.c: In function 'nscd_gethst_r': - nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] - - * baseline - 2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032 - introduces: - - tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] - - * baseline - fc56c5bbc1a0d56b9b49171dd377c73c268ebcfd..cbc818d0ee66065f3942beffdca82986615aa19a - introduces - - +gcc-4.6 tst-printf-round.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4. - +tst-printf-round.c: In function 'do_test': - +tst-printf-round.c:203:11: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - +tst-printf-round.c:208:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - +tst-printf-round.c:216:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - +tst-printf-round.c:224:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] - +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' - - gcc-4.6 test-wcschr.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 - +In file included from test-wcschr.c:2:0: - +../string/test-strchr.c: In function 'check1': - +../string/test-strchr.c:249:3: warning: passing argument 1 of 'stupid_STRCHR' from incompatible pointer type [enabled by default] - +../string/test-strchr.c:77:1: note: expected 'const wchar_t *' but argument is of type 'char *' - +../string/test-strchr.c:249:22: warning: initialization from incompatible pointer type [enabled by default] - +../string/test-strchr.c:252:5: warning: passing argument 2 of 'check_result' from incompatible pointer type [enabled by default] - +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *' - +../string/test-strchr.c:252:5: warning: passing argument 4 of 'check_result' from incompatible pointer type [enabled by default] - +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *' - - -# Install - -TODO. - - $ make install_root="$PWD".install install 2>&1 | tee log_install - [...] - -This takes up around 100 MiB, and runs for [[TODO min|performance#measure]] on -kepler.SCHWINGE and [[3 min|performance#measure]] on laplace.SCHWINGE. - - -## Analysis - - $ toolchain/logs/process glibc install fetch laplace.SCHWINGE - -TODO. - - -# Testsuite - - $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test - [...] - -This runs for [[TODO min|performance#measure]] on kepler.SCHWINGE and [[10 -min|performance#measure]] on laplace.SCHWINGE. - -Specifying `fast-check=yes` disables the `conformtest` which ran for 1.75 h (out -of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't -our most critical issue to solve. -`elf/tst-xmmymm.out` is another candidate to disable: needs 90 min to run. - - -## Analysis - - $ toolchain/logs/process glibc test fetch laplace.SCHWINGE - -Failures, mostly in order of appearance: - - * `check-abi`, `check-abi-libmachuser`, `check-abi-libhurduser`, - `check-abi-libBrokenLocale`, `check-abi-libm`, `check-abi-libdl`, - `check-abi-libcrypt`, `check-abi-libresolv`, `check-abi-librt`, - `check-abi-libnsl`, `check-abi-libutil`, `check-abi-libc`, `check-abi-ld`, - `c++-types.data` - - Reference files are missing. - - * `math/test-float.out`, `math/test-double.out` - - A handful of ULP failures. - - * `math/test-ldouble`, `math/test-ildoubl`, `math/test-ifloat`, - `math/test-idouble` - - SIGSEGV. Or SIGILL. - - * `stdlib/tst-secure-getenv.out` - - open (/proc/self/exe): No such file or directory - - Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]]. - - * `stdlib/tst-strtod-round.out` - - strtold (-0x0.7p-16445) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD) - strtold (-0x0.7p-16494) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD) - - * `stdio-common/bug22.out` - - Timed out: killed the child process - - Known problem. - - * `libio/tst-atime.out`, `dirent/tst-fdopendir.out` - - [[!message-id "201305102256.56636.toscano.pino@tiscali.it"]]. - - `libio/tst-atime.out`: - - atime has not changed - - Due to `ext2fs --no-atime`. - - * IRC, OFTC, #debian-hurd, 2013-05-08 - - bah, tst-atime failure :) - do you have its output? - well it's very simple - I have the noatime option on / :) - oh - fortunately fsysopts works :) - the test checks whether ST_NOATIME is in the mount - options, maybe it would be a good idea to provide it - yes - unfortunately it isn't in posix, so i'm not sure whether - adding it to the general bits/statvfs.h would be welcome - or whether we should fork it, like it is done for linux - oh no, we fork it already - \o/ - - `dirent/tst-fdopendir.out`: - - directory atime changed - - Due to `ext2fs --atime` (default). - - * `libio/tst-fopenloc.check`, `posix/bug-regex31-mem`, - `posix/tst-fnmatch-mem`, `misc/tst-error1-mem` - - Memory not freed: - ----------------- - Address Size Caller - 0x0807e268 0x8000 at 0x10c71c4 - - Caused by different memory allocation way in libio, see - [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]] - - * `dlfcn/bug-atexit3.out` - - Originally: - - dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory - - See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]]. - Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6 - /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`. - This is a bug in the glibc test harness. Should probably use some - `configure` magic akin to the `fixincludes` stuff (`gcc-4.4 - -print-file-name=libstdc++.so.6`, etc.). - - Even if that that is being worked around, the tests nowadays - ([[packaging_libpthread]]) fail with: - - dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6) - - * `dlfcn/tststatic.out`, `dlfcn/tststatic2.out`, `dlfcn/tststatic3.out`, - `dlfcn/tststatic4.out`, `dlfcn/tststatic5.out` - - SIGSEGV. - - `LD_LIBRARY_PATH` doesn't contain the `mach` and `hurd` directories; yet - the test shouldn't just SIGSEGV. - - * `dirent/opendir-tst1.out`, `dirent/tst-fdopendir2.out` - - `dirent/opendir-tst1.out`: - - `opendir' succeeded on a FIFO??? - - `dirent/tst-fdopendir2.out`: - - fdopendir with normal file descriptor did not fail - - `opendir` and `fdopendir` do not return `ENOTDIR` if `fd` is not a - directory. - - * `posix/tst-waitid.out` - - Intermittent. - - SIGCHLD for stopped status 0 - SIGCHLD for stopped pid -1 - SIGCHLD for killed code 1 - SIGCHLD for killed status 0 - SIGCHLD for killed pid -1 - - * `posix/bug-glob2.out` - - Intermittent. - - Timed out: killed the child process - - * `posix/annexc.out` - - Failure ignored by the glibc testsuite. - - * `posix/tst-getconf.out` - - Ends with: - - getconf POSIX_ALLOC_SIZE_MIN /: [...]/posix/getconf: pathconf: /: Invalid argument - - It fails because of unimplemented pathconf cases: `_PC_ALLOC_SIZE_MIN`, - `_PC_REC_INCR_XFER_SIZE`, `_PC_REC_MAX_XFER_SIZE`, `_PC_REC_MIN_XFER_SIZE`, - `_PC_REC_XFER_ALIGN`, `_PC_SYMLINK_MAX`, `_PC_2_SYMLINKS`. - - `_CS_GNU_LIBPTHREAD_VERSION` is provided by libpthread when compiled as - add-on. - - * `posix/tst-sysconf.out` - - Fails with: - - sysconf(_SC_BARRIERS) must be 200809L - sysconf(_SC_READER_WRITER_LOCKS) must be 200809L - sysconf(_SC_SEMAPHORES) must be 200809L - sysconf(_SC_SPIN_LOCKS) must be 200809L - sysconf(_SC_THREAD_ATTR_STACKADDR) must be 200809L - sysconf(_SC_THREAD_ATTR_STACKSIZE) must be 200809L - sysconf(_SC_THREADS) must be 200809L - sysconf(_SC_TIMEOUTS) must be 200809L - - That, I presume, is in response to our `sysdeps/mach/hurd/bits/posix_opt.h` - file, which uses *200112L* values. - `nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h` uses *200809L* values. - - * `posix/tst-vfork3-mem` - - + 0x0804cee0 Alloc 10 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 11 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 12 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 17 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 18 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 19 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 20 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 25 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 26 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 27 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 28 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 33 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 34 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 35 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 36 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 41 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 42 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 43 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 44 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 49 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 50 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 51 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 52 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 57 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 58 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 59 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 60 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 65 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 66 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 67 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 68 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 73 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 74 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 75 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - + 0x0804cfa8 Alloc 76 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x00000008 Alloc 81 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] - + 0x0804cee0 Alloc 82 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] - + 0x0804cf90 Alloc 83 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] - - 0x0804c8d8 Free 84 was never alloc'd 0x10955fc - - 0x0804c960 Free 87 was never alloc'd 0x115672f - - 0x0804c9b8 Free 88 was never alloc'd 0x1156737 - - Memory not freed: - ----------------- - Address Size Caller - 0x0804cfa8 0x73 at 0x10df0c8 - 0x00000008 0 at 0x10df0c8 - - Perhps because we implement `vfork` in terms of `fork` (`posix/vfork.c`)? - - * `posix/tst-pathconf.out` - - pathconf on directory failed: (os/kern) successful - - * `io/test-lfs.out` - - /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build/io/test-lfs: cannot write test string to large file: Invalid argument - - * `io/tst-futimesat.out` - - file created - futimesat failed - - `futimesat` is a stub. - - * `misc/tst-pselect.o` - - tst-pselect.c: In function 'do_test': - tst-pselect.c:33:17: error: 'SA_NOCLDWAIT' undeclared (first use in this function) - - * `gmon/tst-sprofil.out` - - Floating point exception - - * `nss//libnss_test1.so` - - [...]/nss/nss_test1.os: In function `_nss_test1_getpwent_r': - [...]/nss/nss_test1.c:60: undefined reference to `pthread_mutex_lock' - [...]/nss/nss_test1.c:85: undefined reference to `pthread_mutex_unlock' - - * `rt/tst-shm.out` - - read file outside of SHMDIR directory: (os/kern) successful - - * `rt/tst-timer.out` - - No message. - - * `rt/tst-timer2.o` - - tst-timer2.c: In function 'do_test': - tst-timer2.c:33:23: error: 'SIGRTMIN' undeclared (first use in this function) - - * `rt/tst-aio2`, `rt/tst-aio3`, `rt/tst-aio9`, `rt/tst-aio10`, - `rt/tst-mqueue3`, `rt/tst-mqueue5.o`, `rt/tst-mqueue6`, `rt/tst-mqueue8`, - `rt/tst-timer3`, `rt/tst-timer4.o`, `rt/tst-timer5.o`, `rt/tst-cpuclock2`, - `rt/tst-cputimer1.o`, `rt/tst-cputimer2.o`, `rt/tst-cputimer3.o`, - `elf/tst-thrlock` - - [...]/rt/tst-aio2.o: In function `do_test': - [...]/rt/tst-aio2.c:62: undefined reference to `pthread_barrier_init' - [...]/rt/tst-aio2.c:94: undefined reference to `pthread_barrier_wait' - [...]/rt/tst-aio2.o: In function `thrfct': - [...]/rt/tst-aio2.c:35: undefined reference to `pthread_barrier_wait' - - tst-mqueue5.c: In function 'rtmin_handler': - tst-mqueue5.c:50:14: error: 'SIGRTMIN' undeclared (first use in this function) - - [...]/rt/tst-mqueue6.o: In function `do_test': - [...]/rt/tst-mqueue6.c:127: undefined reference to `pthread_attr_init' - [...]/rt/tst-mqueue6.c:149: undefined reference to `pthread_attr_setguardsize' - [...]/rt/tst-mqueue6.c:211: undefined reference to `pthread_attr_setguardsize' - [...]/rt/tst-mqueue6.c:262: undefined reference to `pthread_attr_destroy' - [...]/rt/tst-mqueue6.c:128: undefined reference to `pthread_attr_setguardsize' - [...]/rt/tst-mqueue6.o: In function `fct': - [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_self' - [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_getattr_np' - [...]/rt/tst-mqueue6.c:88: undefined reference to `pthread_attr_getguardsize' - [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy' - [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy' - - [...]/elf/tst-thrlock.o: In function `do_test': - [...]/elf/tst-thrlock.c:38: undefined reference to `pthread_create' - [...]/elf/tst-thrlock.c:48: undefined reference to `pthread_join' - - * `rt/tst-aio8.out` - - r = -1, e = 1073741902 (Function not implemented) - - Should work with [[!message-id - "201209302353.51055.toscano.pino@tiscali.it"]] in libpthread. - - * `debug/tst-chk1.out` - - Intermittent. Timeout. Unknown. - - * `debug/tst-chk2.out`, `debug/tst-chk3.out`, `debug/tst-lfschk2.out`, - `debug/tst-lfschk3.out` - - Unknown. - - * `debug/tst-chk4.out`, `debug/tst-chk5.out`, `debug/tst-chk6.out`, - `debug/tst-lfschk4.out`, `debug/tst-lfschk5.out`, `debug/tst-lfschk6.out` - - [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6) - [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libgcc_s.so.1) - - * `debug/tst-longjmp_chk2.out` - - SIGSEGV. - - not on alternate stack - in signal handler - on alternate stack - out of signal handler - on alternate stack - - It says *alternate stack*. - - * `inet/tst-ether_line.o` - - tst-ether_line.c: In function 'do_test': - tst-ether_line.c:19:19: error: 'ETH_ALEN' undeclared (first use in this function) - - Will either need a `hurd/netinet/if_ether.h` that includes - ``, or can do that in the generic `netinet/if_ether.h`? - See also [[!sourceware_PR 11142]]. - - * `login/tst-grantpt.out` - - posix_openpt(O_RDWR) failed - errno 1073741902 (Function not implemented) - - `posix_openpt` is a stub. - - grantpt(): expected: return = -1, errno = 1073741846 - got: return = -1, errno = -303 - - `grantpt` (actually `ptsname_r`), does not fail with `ENOTTY` when the `fd` - does not refer to a PTY master. - - * `elf/tst-auxv.out` - - SIGSEGV. - - * `elf/tst-stackguard1-static.out`, `elf/tst-stackguard1.out` - - differences 0 defaults 0 - stack guard canaries are not randomized enough - nor equal to the default canary value - - Sometimes times out. - - * `elf/tst-ptrguard1-static.o`, `elf/tst-ptrguard1.o` - - In file included from tst-ptrguard1-static.c:1:0: - tst-ptrguard1.c: In function 'con': - tst-ptrguard1.c:42:24: error: 'tcbhead_t' has no member named 'pointer_guard' - tst-ptrguard1.c: In function 'do_test': - tst-ptrguard1.c:65:29: error: 'tcbhead_t' has no member named 'pointer_guard' - tst-ptrguard1.c:104:30: error: 'tcbhead_t' has no member named 'pointer_guard' - - See [[t/tls|t/tls]]. - - * `elf/tst-tls9-static.out` - - SIGSEGV. - - * `elf/tst-audit1.out`, `elf/tst-audit2.out`, `elf/tst-audit8.out` - - SIGKILL. - - * `elf/tst-null-argv.out` - - Inconsistency detected by ld.so: ../sysdeps/mach/hurd/dl-sysdep.c: 338: open_file: Assertion `!(flags & ~(0x0001 | 0x00400000))' failed! - - * `elf/check-textrel.out` - - $BUILDDIR/libc.so.dyn: *** text relocations used - - * `elf/check-execstack.out` - - $BUILDDIR/libc.so.phdr: *** executable stack signaled - - * `elf/check-localplt.out` - - Around 500 or so `Extra PLT reference`. - - * `check-local-headers.out` - - A lot. Including `/usr/include/device/*.h`, `/usr/include/mach/*.h`, - `/usr/include/hurd/*.h`. - - * `debug/tst-longjmp_chk2.out`, `debug/tst-longjmp_chk3.out`, - `debug/tst-longjmp_chk4.out`, `debug/tst-longjmp_chk5.out`, - `debug/tst-backtrace2.out`, `debug/tst-backtrace3.out`, - `debug/tst-backtrace4.out`, `debug/tst-backtrace5.out` - `debug/tst-backtrace6.out` - - All say: `Obtained backtrace with 0 functions`. - -Earlier failures; no longer seen: - - * `test-assert-perr.out` - - Fails intermittently. Unknown. - - * `test-multiarch.out` - - Needs [[`/proc/cpuinfo`|hurd/translator/procfs/jkoenig/discussion]] - providing the `flags` line. - - * `elf/tst-array*` - - No longer fail with GCC 4.7. - [[!message-id "50950082.1070906@df1tl.local.here"]]. - - * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`, - `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`, - `grp/tst_fgetgrent`, - `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf` - - /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory - - Looking into `localedata/bug-setlocale1.c`, it is clear what it going on: - only the root of the build directory is added for `--library-path`, but - none of the other directories that are additionally used. This is a bug in - the glibc test harness. Hacked around by `ln -s mach/libmachuser.so.1 - hurd/libhurduser.so.0.3 ./`. Hopefully the other instances are similar. - - * `assert/test-assert.out` - - Fails sometimes... - - * `math/test-fenv.out` - - Used to fail (is listed in Debian eglibc-2.13-21's - `expected-results-i486-gnu-libc`), but something between - 22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and - 005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely - Jérémie's signaling work. - - * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d, - [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]]) - - Unused direct dependencies: - /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2 - - As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes -- - correct? - - * `stdlib/bug-getcontext.out` - - getcontext failed, errno: 1073741902. - - Fixed, implemented in `t/context_functions`. - - * `resource/bug-ulimit1.out` - - Result of ulimit (UL_SETFSIZE, 10000): 0 - Result of ulimit(UL_GETFSIZE): 10000 - - Buggy `sysdeps/unix/bsd/ulimit.c` return values. - - Fixed, [[!message-id "201211182342.51619.toscano.pino@tiscali.it"]]. - -Compared to Debian: - - $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test > log_test.filtered - $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered -- cgit v1.2.3