diff options
Diffstat (limited to 'open_issues/glibc.mdwn')
| -rw-r--r-- | open_issues/glibc.mdwn | 319 |
1 files changed, 319 insertions, 0 deletions
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index b453b44f..292c6256 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -330,6 +330,33 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 clearly not a priority <nalaginrut> ok + IRC, freenode, #hurd, 2013-09-26: + + <nalaginrut> if I want to have epoll/kqueue like things, where + should it dwell? kernel or some libs? + <braunr> libs + <pinotree> userland + <braunr> that would be a good project to work on, something i + intended to do (so i can help) but it requires a lot of work + <braunr> you basically need to add a way to explicitely install and + remove polling requests (instead of the currently way that + implicitely remove polling requests when select/poll returns) + <braunr> while keeping the existing way working for some time + <braunr> glibc implements select + <braunr> the hurd io interface shows the select interface + <braunr> servers such as pfinet/pflocal implement it + <braunr> glibc implements the client-side of the call + <nalaginrut> where's poll? since epoll just added edge-trigger in + poll + <braunr> both select and poll are implemented on top of the hurd io + select call (which isn't exactly select) + <braunr> + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/hurd/io.defs + <braunr> this is the io interface + <braunr> + http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/blob/refs/heads/tschwinge/Roger_Whittaker:/hurd/hurdselect.c + <braunr> this is the client side implementation + * `sys/eventfd.h` * `sys/inotify.h` @@ -854,6 +881,298 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8 <braunr> to check where those locks are held and determine the right order + IRC, OFTC, #debian-hurd, 2013-09-28: + + <gg0_> now we'd just need tls + <gg0_> http://bugs.ruby-lang.org/issues/8937 + <gg0_> well, it would pass makecheck at least. makecheckall would + keep hanging on threads/pipes tests i guess, unless tls/thread + destruction patches fix them + + IRC, OFTC, #debian-hurd, 2013-10-05: + + <youpi> so what is missing for ruby2.0, only disabling use of + context for now, no? + <pinotree> i'm not tracking it closely, gg0_ is + <gg0_> maybe terceiro would accept a patch which only disables + *context, "maybe" because he rightly said changes must go + upstream + <gg0_> anyway with or without *context, many many tests in + makecheckall fail by making it hang, first with and without + assertion you removed, now they all simply hang + <gg0_> youpi: what do we want to do? if you're about finishing tls + migration (as i thought a couple of weeks ago), i won't propose + anything upstream. otherwise i could but that will have to be + reverted upstream once you finish + <gg0_> about tests, current ruby2.0 doesn't run makecheckall, only + makecheck which succeeds on hurd (w/o context) + <gg0_> if anyone wants to give it a try: + http://paste.debian.net/plain/51089 + <gg0_> first hunk makes makecheck (not makecheckall) succeed and + has been upstreamed, not packaged yet + <pinotree> what about makecheckall for ruby2.0? + <gg0_> 16:58 < gg0_> anyway with or without *context, many many + tests in makecheckall fail by making it hang, first with and + without assertion you removed, now they all simply hang + <pinotree> i for a moment thought it as for 1.9.1, ok + <pinotree> these hangs should be debugged, yes + <gg0_> nope, tests behavior doesn't change between 1.9 and 2.0. i + started suppressing tests onebyone on 2.0 as well and as happened + on 1.9, i gave up cause there were too many + <gg0_> yep a smart mind could start debugging them, starting from + patch above pasted by a lazy one owner + <gg0_> one problem is that one can't reproduce them by isolate + them, they don't fail. start makecheckall then wait for one fail + <gg0_> now after my stupid report, someone like pinotree could take + it over, play with it for half an hour/an hour (which equals to + half a gg0's year/a gg0's year + <gg0_> ) + <gg0_> and fix them all + + <gg0_> 17:05 < gg0_> youpi: what do we want to do? if you're about + finishing tls migration (as i thought a couple of weeks ago), i + won't propose anything upstream. otherwise i could but that will + have to be reverted upstream once you finish + <youpi> gg0_: I don't really know what to answer + <youpi> that's why I didn't answer :) + <gg0_> youpi: well then we could upstream context disable and keep + it disabled even if you fix tls. ruby won't be as fast as it + would be with context but i don't think anyone will complain + about that. then once packaged, if terceiro doesn't enable + makecheckall, we will have ruby2.0 in main + <youpi> that can be a plan yes + <gg0_> btw reverting it upstream should not be a problem eventually + <youpi> sure, the thing is remembering to do it + <gg0_> filed http://bugs.ruby-lang.org/issues/8990 + <gg0_> please don't fix tls too soon :) + <gg0_> s/makecheck/maketest/g + + IRC, OFTC, #debian-hurd, 2013-10-08: + + <gg0_> ok. *context disabled http://bugs.ruby-lang.org/issues/8990 + + <gg0> bt full of an attached stuck ruby test + http://paste.debian.net/plain/53788/ + <gg0> anything useful? + <youpi> uh, is that really all? + <youpi> there's not much interesting unfortunately + <youpi> did you run thread apply all bt full ? + <youpi> (not just bt full) + <gg0> no just bt full + <gg0> http://paste.debian.net/plain/53790/ + <gg0> wait, there's a child + <gg0> damn ctrl-c'ing while it was loading symbols made it crash :/ + <gg0> restarted testsuite + <gg0> isn't it interesting that failed tests fail only if testsuite + runs from beginning, whereas if run singularly, they succeed? + <gg0> as it got out of whatever resources + <gg0> youpi: http://paste.debian.net/plain/53798/ + <youpi> the interesting part is actually right at the top + <youpi> it's indeed stuck in the critical section spinlock + <youpi> question being what is keeping it + <youpi> iirc I had already checked in the whole glibc code that all + paths which lock critical_section_lock actually release it in + all cases, but maybe I have missed some + <youpi> (I did find some missing paths, which I fixed) + <gg0> i guess the same check you and braunr talk about in + discussion just before this anchor + http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg + <youpi> yes, but the issue we were discussing there is not what + happens here + <youpi> we would see another thread stuck in the other way roudn, + otherwise + <gg0> no way to get what is locking? + <youpi> no, that's not recorded + <gg0> and what about writing it somewhere right after getting the + lock? + <youpi> one will have to do that in all spots taking that lock + <youpi> but yes, that's the usual approach + <gg0> i would give it try but eglibc rebuild takes too much time, + that conflicts with my laziness + <gg0> i read even making locks timed would help + + IRC, OFTC, #debian-hurd, 2013-10-09: + + <gg0> so correct order would be: + <gg0> __spin_lock (&ss->lock); // locks sigstate + <gg0> __spin_lock (&ss->critical_section_lock); + <gg0> [do critical stuff] + <gg0> __spin_unlock (&ss->critical_section_lock); + <gg0> __spin_unlock (&ss->lock); // unlocks sigstate + <gg0> ? + + <gg0> 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is + waiting) https://bugs.ruby-lang.org/issues/9000 + <gg0> 21:46 < gg0> that means that if you take a 2.0 snapshot, + it'll build fine on hurd (unless you introduce maketestall as in + 1.9, that would make it get stuck like 1.9) + <gg0> 21:48 < terceiro> gg0: nice + <gg0> 21:48 < terceiro> I will try to upload a snapshot as soon as + I can + <gg0> 21:52 < gg0> no problem. you might break my "conditional + satisfaction" by adding maketestall. better if you do that on + next+1 upload so we'll have at least one 2.0 built :) + + <gg0> would it be a problem granting me access to a porter box to + rebuild eglibc+ruby2.0? + <gg0> i'm already doing it on another vm but host often loses power + <pinotree> you cannot install random stuff on a porterbox though + <gg0> i know i'd just need build-deps of eglibc+ruby2.0 i guess + <gg0> (already accessed to porter machines in the past, account + lele, mips iirc) + <gg0> ldap should remember that + <gg0> don't want to disturb anyone else work btw. if it's not a + problem, nice. otherwise no problem + <pinotree> please send a request to admin@exodar.debian.net so it + is not forgotten + <gg0> following this one would be too "official"? + http://dsa.debian.org/doc/guest-account/ + <pinotree> hurd is not a release architecture, so hurd machines are + not managed by DSA + <gg0> ok + <pinotree> the general procedure outlines is ok though, just need + to be sent to the address above + <gg0> sent + <gg0> (1st signed mail with mutt, in the worst case i've attached + passphrase :)) + <youpi> gg0: could you send me an ssh key? + <pinotree> no alioth account? + <youpi> yes, but EPERM + <gg0> youpi: sent to youpi@ + <youpi> youpi@ ? + <gg0> (... which doesn't exist :/) + <gg0> sthibault@ + <youpi> please test gg0-guest@exodar.debian.net ? + <youpi> (I'd rather not adduser the ldap name, who knows what might + happen when you get your DD account) + <gg0> i'm in. thanks + <youpi> you're welcome + <gg0> ldap users need to be adduser'ed? + <youpi> I'm not getting your ldap user account from ud-replicate, + at least + <gg0> (btw i never planned to apply nm, i'd be honoured but i + simply think not to deserve it) + <youpi> never say never ;) + <gg0> bah i like failing. that would be a success. i can't :) + <gg0> gg0-guest@exodar:~$ dchroot + <gg0> E: Access not authorised + <gg0> I: You do not have permission to access the schroot service. + <gg0> I: This failure will be reported. + <youpi> ah, right, iirc I need to add you somewhere + <youpi> gg0: please retry? + <gg0> works + <youpi> good + <gg0> are there already eglibc+ruby2.0 build-deps? + <youpi> yes + <gg0> oh that means i should do something myself now :) + <youpi> yep, that had to happen at some point :) + <gg0> my laziness thanks: "at some point" is better than "now" :) + + IRC, freenode, #hurd, 2013-10-10: + + <gg0> ok just reproduced the + former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits + <braunr> 20:37 < braunr> gg0: does ruby create and destroy threads + ? + <gg0> no idea + <gg0> braunr: days ago you and youpi talked about locking order + (just before this anchor + http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg) + <braunr> oh right + <gg0> <youpi> could you submit the fix for jmp-unwind.c to + upstream? + <braunr> it didn't made it in the todo list + <gg0> so correct order is in hurd_thread_cancel, right? + <braunr> sorry about that + <braunr> we need to make a pass to make sure it is + <gg0> that means locking first ss->critical_section_lock _then_ + ss->lock + <gg0> correct? + <braunr> but considering how critical hurd_thread_cancel is, i + expect so + + <gg0> i get the same deadlock by swapping locks + <gg0> braunr: youpi: fyi ^ + <gg0> 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and + destroy threads ? + <gg0> how could i check it? + <braunr> gg0: ps -eflw + <youpi> gg0: that's not surprising, since in the b acktrace you + posted there isn't another thread locked in the other order + <youpi> so it's really that somehow the thread is already in + critical sesction + <braunr> youpi: you mean there is ? + <braunr> ah, it's not the same bug + <youpi> no, in what he posted, no other thread is stuck + <youpi> so it's not a locking order + <youpi> just that the critical section is actually busy + <gg0> youpi: ack + <gg0> braunr: what's the other bug? ext2fs one? + <braunr> gg0: idk + <gg0> braunr: thanks. doesn't show threads (found -T for that) but + at least doesn't limit columns number if piped (thanks to -w) + <braunr> it does + <braunr> there is a TH column + <gg0> ok thread count. -T gives more info + + IRC, freenode, #hurd, 2013-10-24: + + <youpi> ruby2.0 builds fine with the to-be-uploaded libc btw + <gg0> youpi: without d-ports patches? surprise me :) + <youpi> gg0: plain main archive source + <gg0> you did it. surprised + <gg0> ah ok you just pushed your tls. great! + <braunr> tls will fix a lot of things + + * `sigaltstack` + + IRC, freenode, #hurd, 2013-10-09: + + <gnu_srs1> Hi, is sigaltstack() really supported, even if it is + defined as well as SA_ONSTACK? + <braunr> probably not + <braunr> well, + <braunr> i don't know actually, mistaking with something else + <braunr> it may be supported + <pinotree> iirc no + <gnu_srs1> pinotree: are you sure? + <pinotree> this is what i remember + <pinotree> if you want to be sure that $foo works, just do the + usual way: test it yourself + <gnu_srs1> found it: hurd/TODO: *** does sigaltstack/sigstack + really work? -- NO + <pinotree> well TODO is old and there were signal-related patches + by jk in the meanwhile, although i don't think they would have + changed this lack + <pinotree> in any case, test it + <gnu_srs1> anybody fluent in assembly? Looks like this code + destroys the stack: http://paste.debian.net/54331/ + <braunr> gnu_srs1: why would it ? + <braunr> it does something special with the stack pointer but it + just looks like it aligns it to 16 bytes, maybe because of sse2 + restrictions (recent gcc align the stack already anyway) + <gnu_srs1> Well, in that case it is the called function: + http://paste.debian.net/54341/ + <braunr> how do you know there is a problem with the stack in the + first place ? + <gnu_srs1> tracing up to here, everything is OK. then esp and ebp + are destroyed. + <gnu_srs1> and single stepping goes backward until it segfaults + <braunr> "destroyed" ? + <gnu_srs1> zero if I remember correctly now. the x86 version built + for is i586, should that be changed to i486? + <braunr> this shouldn't change anything + <braunr> and they shouldn't get to 0 + <braunr> use gdb to determine exactly which instruction resets the + stack pointer + <gnu_srs1> how to step into the assembly part? using 's' steps + through the function since no line information: + <gnu_srs1> Single stepping until exit from function + wine_call_on_stack, + <gnu_srs1> which has no line number information. + <braunr> gnu_srs1: use break on the address + <gnu_srs1> how do i get the address of where the assembly starts? + * `recvmmsg`/`sendmmsg` (`t/sendmmsg`) From [[!message-id "20120625233206.C000A2C06F@topped-with-meat.com"]], |