[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_glibc]] Here's what's to be done for maintaining glibc. [[!toc levels=2]] # [[General information|/glibc]] # [[Sources|source_repositories/glibc]] # [[Debian Cheat Sheet|debian]] # Configuration Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 (2013-05-24) 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, amongst many more. Many more are missing, some of which have been announced in `NEWS`, others typically haven't (like new flags to existing functions). Typically, porters will notice missing functionaly. But in case you're looking for something to work on, here's a list. `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`, `CLOCK_REALTIME_ALARM`, `O_PATH`, `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27, b1b2aaf8eb9eed301ea8f65b96844568ca017f8b), `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several `MAP_*`|glibc/mmap]], `PTR_MANGLE`/`PTR_DEMANGLE` (`t/ptrmangle`) 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`. * `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 * `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 * `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? 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/ * 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`? * *baseline* * 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`:`LDFLAGS-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 +LDFLAGS-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? * 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? ## 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 83fed41a9ed81db6ca517185aefb296f74868c2f (2013-05-26; 0323d08657f111267efa47bd448fbf6cd76befe8 (2013-05-24)) plus 2b66ef5d55325b2957d6c62908ca065228e56814, ec9dd97cecafba5ddf5c3ec683db7ad5b4421923, 07b4c13d0be4814ef10bbfbfd68db604978aa0e5, 528c24058fb100fb27fe5c211b92be84c67a6659, `t/elfosabi_gnu` reverted, ec9dd97cecafba5ddf5c3ec683db7ad5b4421923 (again...), `id:"87bo7xo1ay.fsf@kepler.schwinge.homeip.net"` sources|source_repositories/glibc]], run on coulomb.SCHWINGE. $ export LC_ALL=C $ ../Roger_Whittaker/configure AUTOCONF=: --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build [...] $ make install_root=/INVALID 2>&1 | tee log_build_ [...] This takes up around 550 MiB, and needs roughly X min on kepler.SCHWINGE and 100 min on coulomb.SCHWINGE. ## Analysis $ toolchain/logs/process glibc build fetch coulomb.SCHWINGE TODO. * With GCC >= 4.5, there's a ton of these warnings: hurd/hurd.h: In function '__hurd_fail': hurd/hurd.h:73: warning: case value '0' not in enumerated type 'error_t' ... as well as a few individual instances: hurdselect.c: In function '_hurd_select': hurdselect.c:265: warning: case value '0' not in enumerated type 'error_t' get-host.c: In function '_hurd_get_host_config': get-host.c:38: warning: case value '0' not in enumerated type 'error_t' hurdmsg.c: In function '_S_msg_get_init_ints': hurdmsg.c:186: warning: case value '0' not in enumerated type 'error_t' hurdmsg.c: In function '_S_msg_set_init_ints': hurdmsg.c:273: warning: case value '0' not in enumerated type 'error_t' intr-msg.c: In function '_hurd_intr_rpc_mach_msg': intr-msg.c:363: warning: case value '0' not in enumerated type 'error_t' sysdeps/mach/hurd/setitimer.c: In function 'timer_thread': sysdeps/mach/hurd/setitimer.c:117: warning: case value '0' not in enumerated type 'error_t' sysdeps/mach/hurd/wait4.c: In function '__wait4': sysdeps/mach/hurd/wait4.c:40: warning: case value '0' not in enumerated type 'error_t' sysdeps/mach/hurd/fork.c: In function '__fork': sysdeps/mach/hurd/fork.c:423: warning: case value '0' not in enumerated type 'error_t' sysdeps/mach/hurd/spawni.c: In function '__spawni': sysdeps/mach/hurd/spawni.c:600: warning: case value '0' not in enumerated type 'error_t' sysdeps/mach/hurd/setpriority.c: In function 'setonepriority': sysdeps/mach/hurd/setpriority.c:66: warning: case value '0' not in enumerated type 'error_t' sysdeps/mach/hurd/ioctl.c: In function 'send_rpc': sysdeps/mach/hurd/ioctl.c:177: warning: case value '0' not in enumerated type 'error_t' sysdeps/mach/hurd/ioctl.c: In function '__ioctl': sysdeps/mach/hurd/ioctl.c:306: warning: case value '0' not in enumerated type 'error_t' [[!message-id "20120723195143.7F8142C0B9@topped-with-meat.com"]]. IRC, freenode, #hurd, 2013-08-27: < gnu_srs> Hi, is this fixed by now? < gnu_srs> ../hurd/hurd.h:72:5: warning: case value ‘0’ not in enumerated type ‘error_t’ [-Wswitch] < pinotree> nope * 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 needs roughly X min on kepler.SCHWINGE and 14 min on coulomb.SCHWINGE. ## Analysis $ toolchain/logs/process glibc install fetch coulomb.SCHWINGE TODO. # Testsuite $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test [...] This needs roughly X min on kepler.SCHWINGE and 145 min on coulomb.SCHWINGE. Specifying `fast-check=yes` disables the `conformtest` which takes 1.75 h (out of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't our most critical issue to solve. `elf/tst-xmmymm.out` is another candidate to disable: needs 90 min to run. ## Analysis $ toolchain/logs/process glibc test fetch coulomb.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` 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-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-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-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-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-tls9-static.out` SIGSEGV. * `elf/tst-dlmopen1.out` SIGSEGV. * `elf/tst-audit1.out`, `elf/tst-audit2.out`, `elf/tst-audit8.out` SIGKILL. * `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` 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