diff options
Diffstat (limited to 'open_issues/glibc.mdwn')
| -rw-r--r-- | open_issues/glibc.mdwn | 627 |
1 files changed, 625 insertions, 2 deletions
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 31437744..b453b44f 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -281,14 +281,55 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 [[glibc_madvise_vs_static_linking]]. + IRC, OFTC, #debian-hurd, 2013-09-09: + + <gg0> 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 + <gg0> 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: + + <youpi> 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`. - * `sys/epoll.h` + * `epoll`, `sys/epoll.h` Used by [[wayland]], for example. + IRC, freenode, #hurd, 2013-08-08: + + <nalaginrut> is there any possible to have kquque/epoll alike + things in hurd? or there is one? + <braunr> nalaginrut: use select/poll + <nalaginrut> is it possible to implement epoll? + <braunr> it is + <braunr> we don't care enough about it to do it + <braunr> (for now) + <nalaginrut> 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 + <nalaginrut> but if someday someone care about it, I'll be + interested on it + <braunr> epoll is a scalability improvement over poll + <braunr> the hurd being full of scalability issues, this one is + clearly not a priority + <nalaginrut> ok + * `sys/eventfd.h` * `sys/inotify.h` @@ -390,6 +431,429 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim, and more. + IRC, OFTC, #debian-hurd, 2013-09-08: + + <pinotree> oh, and even ruby2.0 suffers because of fixed-stack + threads + <youpi> yes, we definitely need to finish fixing it + <youpi> my current work is in our glibc repo, youpi/tls-threadvar + <pinotree> | *** makecontext: a stack at 0xbc000 with size 0x40000 + is not usable with threadvars + <pinotree> all 8 failing tests with that + <youpi> maybe we can hand-disable the use of contexts in ruby for + now? + <pinotree> gg0: ↑ :) + <gg0> after the pseudo-patch i RFCed, i don't deserve to say + anything else about that :) + <pinotree> i mean, feel free to investigate and "fix" ruby2.0 as + above :) + <gg0> eh maybe i'd just be able to hand-disable failing + thread-related _tests_ :) + <gg0> i'm still hoping some real developer picks and actually fixes + it, seems it's not enough interesting though + <azeem> 21:37 < youpi> yes, we definitely need to finish fixing it + <gg0> 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 + <youpi> gg0: "actually fixing" means fixing threadvars-tls + migration + <youpi> "just fixing" ruby can be done by simply disabling context + use in ruby + + IRC, OFTC, #debian-hurd, 2013-09-10: + + <gg0> this one fixes make test by disabling context and giving more + time to timing related tests http://paste.debian.net/plain/37977/ + <gg0> make test-all is another story + <youpi> gg0: AIUI, the sleep part should get fixed by the next + glibc upload, which will include the getclk patch + <youpi> but the disabling context part could be good to submit to + the debian ruby package, mentioning that this is a workaround for + now + <gg0> unfortunately still not enough, test-all still fails + <youpi> does it make the package not build? + <gg0> test-all is the second part of what we call tests + <gg0> 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 + <gg0> well after or during the build doesn't matter, it's their + testsuite + <gg0> ok just failed: + <gg0> TestBug4409#test_bug4409 = Illegal instruction + <gg0> make: *** [yes-test-all] Error 132 + <gg0> what to do with Illegal instruction? + <gg0> just found 2 words that make everybody shut up :p + <pinotree> same as above: debug it + <teythoon> 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 + <gg0> seems i'm running tests which are disabled on _all_ archs, + better so + <gg0> 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 + <teythoon> gg0: yeah, I'm running all my hurd instances on qemu/kvm + as well, I meant did you get this twice in a row? + <gg0> to be honest i got another illegal instruction months ago but + don't recall doing what + <gg0> 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 + <gg0> but i could try to reproduce it + <gg0> ok now i recall i got it another one few hours ago on real + hardware, from logs: + <gg0> TestIO#test_copy_stream_socket = Illegal instruction + <gg0> teythoon: on real hardware though + <gg0> and this is the one i should debug once it finishes, still + running + + IRC, freenode, #hurd, 2013-09-11: + + <gg0_> ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: + Assertion `! __spin_lock_locked (&ss->critical_section_lock)' + failed. + <gg0_> and + <gg0_> ../libpthread/sysdeps/mach/pt-thread-halt.c:51: + __pthread_thread_halt: Unexpected error: (ipc/send) invalid + destination port. + <tschwinge> gg0_: Which libpthread source are these? Stock Debian + package? + <gg0_> tschwinge: everything debian, ruby rebuilt with + http://paste.debian.net/plain/38519/ which should disable + *context + + IRC, OFTC, #debian-hurd, 2013-09-11: + + <gg0_> 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 + <gg0_> if they failed gracefully, we could leave them enabled and + just ignoring testsuite result, but most of them block testsuite + run when fail + <gg0_> anyone against? any better idea (and intention to implement + it? :p)? + <gg0_> youpi: is disabling some tests acceptable? ^ + <youpi> it'd be good to at least know what is failing + <youpi> so as to know what impact hiding these failures will have + <youpi> remember that hiding bugs usually means getting bitten by + them even harder later :) + <gg0_> many of them use pipes + <gg0_> here the final list, see commented out ones + http://paste.debian.net/plain/38426 + <gg0_> and as said some don't always fails + <gg0_> test_copy_stream_socket uses a socket + <youpi> note that we can still at least build packages with notest + <youpi> at least to get the binaries uploaded + <youpi> disabling *context should however really be done + <youpi> and the pipe issues are concerning + <youpi> I don't remember other pipe issues + <youpi> so maybe it's a but in the ruby bindings + <gg0_> i just remember they didn't die, then something unknown + fixed it + <youpi> I see something frightening in io.c + <youpi> #if BSD_STDIO + <youpi> preserving_errno(fseeko(f, lseek(fileno(f), + (off_t)0, SEEK_CUR), SEEK_SET)); + <youpi> #endif + <youpi> this looks very much like a workaround for an odd thing in + BSD + <youpi> it happens that that gets enabled on hurd too, since + __MACH__ is defined + <youpi> you could try to drop these three lines, just to see + <youpi> this is very probably very worth investigating, at any rate + <youpi> 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 + <youpi> starting debugging it would be a matter of putting printfs + in io.c, to check what gets called, with what parameters, etc. + <youpi> just a matter of taking the time to do it, it's not very + complex + <gg0_> youpi: are you looking at 1.8? no BSD_STDIO here + <youpi> yes, 1.8 + <gg0_> 1.9.3.448 + <gg0_> landed to sid few days ago + <youpi> ah, I have 1.87 + <youpi> +. + <gg0_> my favourites are TestIO#test_copy_stream_socket and + TestIO#test_cross_thread_close_fd -> Illegal instruction + <gg0_> 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]]? + + <gg0_> trying to debug illegal instruction + http://paste.debian.net/plain/38585/ + <gg0_> (yes, i'm not even good at gdbing) + <gg0_> any hint? + <gg0_> oh found out there's an intree .gdbinit, that might + complicate things + + IRC, OFTC, #debian-hurd, 2013-09-13: + + <gg0_> where should it be implemented MAP_STACK? plus, is it worth + doing it considering migration to tls, wouldn't it be useless? + <gg0_> sysdeps/mach/hurd/mmap.c i should reduce stupid questions + frequency from daily to weekly basis + + IRC, OFTC, #debian-hurd, 2013-09-14: + + <gg0_> say i managed to mmap 0x200000-aligned memory + <gg0_> now i get almost the same failed tests i get disabling + *context + <gg0_> that would mean they don't depend on threading + + IRC, freenode, #hurd, 2013-09-16: + + <gg0> i get many ../sysdeps/mach/hurd/jmp-unwind.c:53: + _longjmp_unwind: Assertion `! __spin_lock_locked + (&ss->critical_section_lock)' failed. + <gg0> 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 + <gg0> read/write operations with pipes + <braunr> gg0: that's weird + <braunr> gg0: debian glibc ? + <gg0> braunr: yep, debian 2.17-92 + <gg0> sometimes assertion above, sometimes tests in question get + stuck reading + <gg0> it would be nice reproducing it w/o ruby + <gg0> probably massive io on pipes could do the job + <gg0> also more nice finding someone who finds it interesting to + fix :p + <gg0> ruby is rebuilt with http://paste.debian.net/plain/40755/, no + *context + <gg0> 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 + <tschwinge> gg0: About the jmp-unwind assertion failure: is it be + chance this issue: + <http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html>? + I didn't look in detail. + <braunr> tschwinge: that's what i thought too about the assertion, + which is why i find it strange + <gg0> asserting it's not locked then locking it doesn't exclude + race conditions + + IRC, OFTC, #debian-hurd, 2013-09-17: + + <gg0> youpi: i guess no one saw it anymore since + tg-thread-cancel.diff patch + <gg0> 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 + <gg0> this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though + <gg0> another assertion to remove? + <youpi> gg0: it's not exactly the same: in hurd_thread_cancel we + hold no lock at all at the assertion point + <youpi> in jmp-unwind.c, we do hold a lock + <youpi> and the assertion might be actually true because all other + threads are supposed to hold the first lock before taking the + other one + <youpi> you could check for that in other places + <youpi> and maybe it's the other place which wouldhave to be fixed + <youpi> also look for documentation which would say that + + IRC, freenode, #hurd, 2013-09-17: + + <braunr_> gg0: is that what we do ?? + <gg0> braunr: well, i was looking at + http://sources.debian.net/src/eglibc/2.17-92/debian/patches/hurd-i386/tg-thread-cancel.diff + <gg0> 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 + <gg0> the one i get now is + http://sources.debian.net/src/eglibc/2.17-92/sysdeps/mach/hurd/jmp-unwind.c#L53 + <gg0> 09:12 < youpi> gg0: it's not exactly the same: in + hurd_thread_cancel we hold no lock at all at the assertion point + <gg0> 09:13 < youpi> in jmp-unwind.c, we do hold a lock + <gg0> 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 + <braunr> gg0: that assertion is normal + <braunr> it says there is a deadlock + <braunr> ss->critical_section_lock must be taken before ss->lock + <gg0> you mean ss->lock before ss->critical_section_lock + <braunr> no + <gg0> ah ok got it + <braunr> that's a bug + <braunr> longjmp + <braunr> ugh + <braunr> you could make a pass through the various uses of those + locks and check what the intended locking protocol should be + <braunr> i inferred ss->critical_section_lock before ss->lock from + hurd_thread_cancel + <braunr> this might be wrong too but considering this function is + used a lot, i doubt it + <gg0> (no, i hadn't got it, i was looking at jmp-unwind.c where + lock is before critical_section_lock) + <gg0> could we get useful info from gdb'ing the assertion? + <tschwinge> 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. + <gg0> i can offer an irc interface if anyone is interested, it's + ready, just to attach :) + <gg0> this is the test + http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L937 + <gg0> pipe function creates two threads + http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26 + <gg0> Attaching to pid 15552 + <gg0> [New Thread 15552.1] + <gg0> [New Thread 15552.2] + <gg0> (gdb) + + IRC, freenode, #hurd, 2013-09-21: + + <youpi> gg0: it seems the assert (! __spin_lock_locked + (&ss->critical_section_lock)); is bogus + <youpi> but it'd be good to catch a call trace + <youpi> well, it may not be bogus, in case that lock is only ever + taken by the thread itself + <youpi> in that case, inside longjmp_unwind we're not supposed to + have it already + <youpi> ok, that's what we had tried to discuss with Roland + <youpi> it can happen when playing with thread cancelation + <braunr> youpi: the assertion isn't exactly bogus + <braunr> the lock ordering is + <youpi> braunr: which one are you talking about? + <youpi> the one in hurd_thread_cancel looks really wrong + <youpi> 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: + + <gg0> how much does this patch suck on a scale from 1 to 10? + http://paste.debian.net/plain/44810/ + <youpi> well, the stack allocation issue will go away once I get + the threadvars away + <youpi> I'm working on it right now + <youpi> about the lib paths, it makes sense to add the gnu case, + but i386-gnu shouldn't be put in the path + <gg0> that's great + <gg0> so seems the wrong moment for what i've already done + ie. asking terceiro what he thinks about patch above :/ + <gg0> any distro-independent way to get libc.so and libm.so path? + <gg0> ruby as last resource takes them from "ldd ruby" + <pinotree> gg0: should work fine then + <gg0> 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 + <gg0> btw even linux and kfreebsd with debian multipath have broken + cases but they don't hit default and get fixed by ldd later + <pinotree> why it is broken? are arguments passed to that script? + <gg0> i'm not sure about what propose. a broken case so it doesn't + hit default like linux and kfbsd + <gg0> yes they are :/ + <pinotree> and which ones are? who executes that script and which + arguments does it pass to it? + <gg0> other ruby scripts which have nothing to do with libc/libm + <pinotree> well, if they pass arguments which should be the paths + to libc and libm, they must be getting such paths, aren't they? + <gg0> they don't. arguments are other ruby scripts, don't know why, + maybe something else broken before + <gg0> but that would mean that before there's a smarter path + detection way, i doubt + <pinotree> then add the case for hurd, but setting both libc and + libm as nil + <pinotree> so they will be fetched again + <gg0> yep and would really ugly + <gg0> +be + <gg0> "please commit this one which wrongly sets paths." + <gg0> an alternative would be removing default case + <gg0> or pointing it out by proposing ldd in hurd case might make + them review the whole detection + <gg0> by setting correct paths like in patch above it wouldn't + break a possible hurd-amd64, it would work due to ldd + <youpi> gg0: that's why I said the patch is fine, but without the + i386-gnu part of the path + <youpi> just like it happens to be on linux & kfreebsd + <gg0> i might take ldconfig -p output + <gg0> to make it uselessly correct from start + <gg0> http://bugs.ruby-lang.org/issues/8937 + <pinotree> note thar ruby 1.8 is EOL + <pinotree> *that + <gg0> -- 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." -- + <gg0> 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 + <pinotree> did you check ruby2.0 too, btw? + <gg0> switched to ruby2 few hours ago. i pointed out 2nd part of + testsuite is not enabled, probably terceiro will enable it soon + <gg0> by applying my patch above we'd completely fix current + ruby2.0 build (yes because tests are not completely enabled) + <pinotree> what you run those extra tests? + <gg0> + http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/run-test-suites.bash + <gg0> make test + make test-all + <gg0> (test-all is 2nd part) + <gg0> many are problematic. i didn't finish yet to suppress them + one-by-one. one i suppress, another one pops up + <gg0> either get stuck or well known assertion + <pinotree> check those that get stuck :) + <gg0> which kind of check? + <pinotree> "check" as in "debug" + <gg0> btw i tested puppet few days ago (with ruby1.8), it seems to + be working, at least at trasferring files from master + <gg0> don't know about any advanced usage + <pinotree> ruby 1.8 is going to die soon, so testing things against + it is not totally useful + <gg0> so you assume 1.8 is less broken than 1.9/2.0, right? + <pinotree> no + <gg0> i just can see it's been built without tests itself too + <pinotree> erm no + <gg0> well ok, if i can be wrong, i'll be wrong + <gg0> i say that after a quick check time ago, might be wrong + <pinotree> `getbuildlogs ruby1.8 last hurd-i386`, see the last + build log + <gg0> ah from pkg-kde-tools + <gg0> i hate kde :) + <pinotree> no? + <gg0> no what? + <pinotree> devscripts: /usr/bin/getbuildlog + <gg0> pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs + <pinotree> which is not what i said + <gg0> wait that's what apt-file found + <gg0> maybe i should update it + <gg0> is it so recent? + <pinotree> no + <pinotree> i just added an 's' more at the end of the command, but + typing getbu<tab> could have been helpful anyway... + <gg0> yeah just got it + <gg0> my fault not to have tried to run it before looking for it + <pinotree> and btw, i don't see what hating kde has to do with + tools developed by qt/kde debian packagers + <gg0> j/k i simply don't use kde, never used and apt-file search + told me it was from pkg-kde-tools + <gg0> btw build log says "make test" fails, doesn't even start. and + its failure doesn't block the build + <pinotree> exactly + <gg0> s/make test/make test-all/ + <gg0> "make test" (aka "1st part" above) doesn't run. i guess it's + missing in packaging + + IRC, freenode, #hurd, 2013-09-22: + + <braunr> youpi: i mean the lock order where the assertion occurs is + reserved compared to the one in hurd_thread_cancel + <braunr> (and the one in hurd_thread_cancel is the same used in + hurd condition-related functions) + <youpi> "reserved" ? + <braunr> reversed + <braunr> :) + <youpi> by "the assertion occurs", you mean gg0's spot? + <braunr> yes + <youpi> well , the assertion also happens in hurd_thread_cancel + <braunr> it does oO + <braunr> i didn't see that + <youpi> but otherwise yes, it's completely bogus that we have both + locking in different orders + <youpi> could you submit the fix for jmp-unwind.c to upstream? + <braunr> what fix ? + <youpi> reversing the lock order + <braunr> ah, simply that + <youpi> (well, provided that hurd_thread_cancel is right) + <braunr> that's what i suggested to gg0 + <braunr> 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"]], @@ -401,13 +865,140 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 Then perhaps the Linux fallback case should be that instead of stubs, too.* + * `SOCK_CLOEXEC` + + IRC, freenode, #hurd, 2013-09-02: + + <gnu_srs1> Do we support accept4 with the SOCK_CLOEXEC flag? + <gnu_srs1> According to the code in sysdeps/mach/hurd/accept4.c + that case is not covered + <gnu_srs1> (only O_NONBLOCK, not SOCK_NONBLOCK??)) + <pinotree> gnu_srs1: we do + <pinotree> but only for accept4, not for socket and socketpair + <gnu_srs1> pinotree: cannot find the case for O_CLOEXEC covered in + __libc_accept4() + <pinotree> gnu_srs1: no, you need SOCK_* + <gnu_srs1> The only code for accept4() is in sysdeps/mach/hurd/ and + it uses O_* for flags ? + <pinotree> flags = sock_to_o_flags (flags); + <pinotree> tried checking it? + <gnu_srs1> Aha, tks:-D + <pinotree> 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: + + <gnu_srs> any ideas about the SOCK_CLOEXEC issue? + <pinotree> didn't i tell already about it? + <gnu_srs> I did not find any hurd related code in tschwinges + branches. + <pinotree> you didn't check deep then... + <gnu_srs> so why does socket/socketpair not return ENOSYS then? + <pinotree> why should it, since they are implemented? + <braunr> ... + <gnu_srs> for socket/socketpair? + <braunr> gnu_srs: enosys means no system call + <gnu_srs> s/ENOSYS/EINVAL/ + <gnu_srs> see the mail to the bug-hurd/debian-hurd ML for more info + <gnu_srs> and tschwinges reply + <pinotree> which is what i knew already? + <gnu_srs> pinotree: please reply on the mailing list on the EINVAL + vs EPROTOTYPE issue to clarify things + <pinotree> gnu_srs: + https://sourceware.org/ml/libc-alpha/2013-02/msg00092.html + <pinotree> gnu_srs: things were clear already... + <gnu_srs> pinotree: I've read that patch and still pflocal/pf.c + returns EPROTOTYPE not changed by the __socket wrapper in eglibc + <pinotree> gnu_srs: what about realizing SOCK_CLOEXEC and friends + are NOT posix? + <gnu_srs> since socket/socketpair does not return EINVAL the dbus + code has to be patched then? + <pinotree> pflocal should never ever get such flags mixed to the + protocol, so any invalid value of protocol correctly returns + EPROTOTYPE + <gnu_srs> this is the question I need answered: Which way to go? + <pinotree> all of them + <gnu_srs> ? + <pinotree> - 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 + <pinotree> - glibc should (as the idea of my patch) handle + implementations providing SOCK_* but not supporting them for + socket/socketpair + <pinotree> - finally the hurd part of glibc could implement them + <gnu_srs> to conclude: should I send a bug report for dbus then? + <gnu_srs> pinotree: yes or no? + <pinotree> gnu_srs: *shrug* i wrote it above, so an *upstream* + report (not a debian one) + + IRC, freenode, #hurd, 2013-09-06: + + <gnu_srs> I've found another error code issue, now in glib2.0 (and + dbus). Are you really sure the error code + <gnu_srs> for protocol of pflocal/pf.c should be + EPROTONOSUPPORT. The code expects EINVAL for a protocol with + <gnu_srs> SOCK_CLOEXEC, which is a flag. Maybe pf.c should add + this case and return EINVAL instead of + <gnu_srs> submitting bug reports upstream. Yes, I know this is not + POSIX, but it is defined for Hurd too, + <gnu_srs> currently only supported for accept4, not socket or + socketpair. + <pinotree> gnu_srs: no, and i explained already why it is wrong + this way + <pinotree> pflocal shouldn't even get such flags + <pinotree> (pflocal or any other server implementing socket_create) + <gnu_srs> (20:19:35) pinotree: pflocal shouldn't even get such + flags + <gnu_srs> then the glibc wrapper code is missing to catch this + flag:( + <gnu_srs> youpi: ? + <pinotree> gnu_srs: because, as told many times, socket and + socketpair do not support such flags + <pinotree> given they don't do, they filter nothing + <pinotree> 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: + + <gnu_srs> A correction from yesterdays discussion: + s/EPROTONOSUPPORT/EPROTOTYPE + + IRC, freenode, #hurd, 2013-09-10: + + <gnu_srs> for dbus2.0 I found out that the third SOCK_CLOEXEC case + needs a patch too (more working tests), + <gnu_srs> the updated patch is at http://paste.debian.net/37948/ if + you have the time, otherwise I'll do it. + <pinotree> gnu_srs: which is what i wrote in my bug report... + <gnu_srs> Yes you wrote that, but the patch is not updated yet? + <pinotree> it refers to a different socket access, recently added, + which is not used by default + <gnu_srs> I got two more tests running when adding that patch:-/ + <pinotree> tests of what? + <gnu_srs> run-test.sh and run-test-systemserver.sh:P + <pinotree> tests of what? + <pinotree> i don't have the universal knowledge of the files in all + the sources + <gnu_srs> dbus-1.6.14/test/name-test/* + + [[!message-id "523A3D6C.2030200@gmx.de"]]. + + IRC, OFTC, #debian-hurd, 2013-09-19: + + <pinotree> 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`. - * Add tests from Linux kernel commit messages for `t/dup3` et al. + * [[Secure_file_descriptor_handling]]. * In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of `-DHAVE_SENDFILE` -- but we do have `sendfile`, too. @@ -927,6 +1518,31 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 <tschwinge> Yeah, that's known for years... :-D <tschwinge> Probably not too difficult to resolve, though. + * IRC, OFTC, #debian-hurd, 2013-08-16: + + <pinotree> http://paste.debian.net/25934/ ← _hurd_thread_sigstate calls + malloc, boom + + * `conformtest` + + IRC, OFTC, #debian-hurd, 2013-09-22: + + <youpi> btw, I noticed that glibc has a head conformance test which we + happily fail quite a bit :) + <youpi> it's not so awful, we don't have twice as many failures as + linux, but not so far + <pinotree> youpi: do you mean "header" for "head", right? + <youpi> err, where ? :) + <pinotree> <youpi> btw, I noticed that glibc has a head conformance + test which we happily fail quite a bit :) + <youpi> ah, yes + <pinotree> noticed that too + <youpi> 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) + <youpi> others will by quite hard to fix (short type instead of int + type for some flock structure field) + <youpi> s/by/be/ + * Verify baseline changes, if we need any follow-up changes: * a11ec63713ea3903c482dc907a108be404191a02 @@ -1253,6 +1869,13 @@ TODO. [[!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: |