Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental. Now in unstable.
IRC, OFTC, #debian-hurd, 2013-03-14
<markus_w1nner> I have a strange tcp via localhost question: <markus_wanner> The other side closes the connection, but I haven't read all data, yet. I should still be able to read the pending data, no? <markus_wanner> At least it seems to work that way on Linux, but not on Hurd. <markus_wanner> Got a simple repro with nc, if you're interested... <youpi> markus_wanner: yes, we're interested <markus_wanner> youpi: okay, here we go: <markus_wanner> session 1: nc -l -p 7777 localhost <markus_wanner> session 2: nc 127.0.0.1 7777 <markus_wanner> session 2: a <RET> b <RET> c <RET> <markus_wanner> session 1: [ pause with Ctrl-Z ] <markus_wanner> session 2: [ send more data ] d <RET> e <RET> f <RET> <markus_wanner> session 2: [ quit with Ctrl-C ] <markus_wanner> session 1: [ resume with 'fg' ] <markus_wanner> The server on session 1 doesn't get the data sent after it paused and before the client closed the connection. <markus_wanner> I'm not sure if that's a valid TCP thing. However, on Linux, the server still gets the data. On hurd it doesn't. <markus_wanner> I'm working on a C-code test case, ATM. <youpi> markus_wanner: on which box are you seeing this behavior? <youpi> exodar does not have it <youpi> i.e. I do get the d e f <markus_wanner> a private VM (I'm not a DD) <markus_wanner> ..updated to latest experimental stuff. <markus_wanner> GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU <youpi> ok, I can't reproduce it on my vm either <youpi> maybe the C program will help <markus_wanner> Hm.. cannot corrently reproduce that in C. (Netcat still shows the issue, though). <markus_wanner> I'll try to strace netcat... <markus_wanner> ..Meh. strace not available on Hurd? <pinotree> no, but there is rpctrace to show the various rpc <markus_wanner> Cool, looks helpful. <markus_wanner> Thx <markus_wanner> Uh.. that introduces another error: <markus_wanner> rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward: Assertion `reply_type == 18' failed.
<youpi> I'm checking on a box without ipv6 configuration <youpi> maybe that's the difference between you and me <youpi> I guess your /etc/alternatives/nc is /bin/nc.traditional ? <markus_wanner> Yup, nc.traditional. <markus_wanner> Looks like that box only has IPv4 configured. <markus_wanner> Something very strange is going on here. No matter how hard I try, I cannot reproduce this with netcat, anymore. <pinotree> not even after a reboot? <markus_wanner> Woo.. here, it happened, again! This is driving me crazy! <markus_wanner> Now, nc seemingly connects, but is unable to send data between the two. Netcat would somehow complain, if it failed to connect, no? <markus_wanner> No it worked. <markus_wanner> So this seems to be an intermittent issue. So far, I could only ever repro it as a normal user, not as root. May be coincidental, though. <markus_wanner> Now, 'a' and 'b' made it through, but not the 'c' sent manually just after that. Something with that TCP/IP stack is definitely fishy. <markus_wanner> Anything I can try to investigate? Or shall I simply restart and see if the problem persists? <youpi> maybe restart, yes <youpi> did you restart since the upgrade ? <markus_wanner> Yes, I restarted after that. <markus_wanner> Hm.. okay, restarted. Some problem persists. <markus_wanner> I currently have two netcat processes connected, the listening one got some first two messages and seems stuck now. <markus_wanner> With the client, I tried to send more data, but the server doesn't get it, anymore. <markus_wanner> Any idea on what I can do to analyze the situation? <youpi> for the netcat issue, I haven't experienced this <youpi> are you running in kvm or virtualbox or something else? <markus_wanner> I'm currently puzzled about what "experimental" actually ships. <markus_wanner> On kvm. <markus_wanner> My libc0.3 used to be 2.13-39+hurd.3. <markus_wanner> But packages.d.o already shows 2.17.0experimental2. <youpi> experimental ships experimental versions, which you aren't supposed to use <youpi> unless you know what you are doing <youpi> iirc 2.17 is known to be quite broken for now <markus_wanner> Okay. So I guess I'll try to "downgrade" to unstable, then. <markus_wanner> Phew, okay, successfully downgraded to unstable. <markus_wanner> Hopefully monotone's test suite runs through fine, now. <markus_wanner> Yup, WORKING! Looks like some experimental packages caused the problem. The netcat test as well as that one failing monotone test work fine, now.
IRC, OFTC, #debian-hurd, 2013-03-19
<tschwinge> pinotree, youpi: Is there anything from that markus_wanner discussion about pfinet/netcat/signals that needs to be filed? I guess we don't know what exactly he changed so that everything workedd fine eventually? (Some experimental package(s), but which?) <youpi> that was libc0.3 packages <youpi> which are indeed known to break the network
IRC, freenode, #hurd, 2013-06-18
<braunr> root@darnassus:~# dpkg-reconfigure locales <braunr> Generating locales (this might take a while)... en_US.UTF-8...Segmentation fault <braunr> is it known ? <youpi> uh, no
IRC, OFTC, #debian-hurd, 2013-06-19
<pinotree> btw i saw too the segmentation fault when generating locales
IRC, OFTC, #debian-hurd, 2013-06-20
<youpi> damn <youpi> hang at ext2fs boot <youpi> static linking issue, clearly
IRC, freenode, #hurd, 2013-06-30
<youpi> Mmm <youpi> __access ("/etc/ld.so.nohwcap", F_OK) at startup of ext2fs <youpi> deemed to fail.... <pinotree> when does that happen? <youpi> at hwcap initialization <youpi> at least that's were ext2fs.static linked against libc 2.17 hangs at startup <youpi> and this is indeed a very good culprit :) <pinotree> ah, a debian patch <youpi> does anybody know a quick way to know whether one is the / ext2fs ? :) <pinotree> isn't the root fs given a special port? <youpi> I was thinking about something like this, yes <youpi> ok, boots <youpi> I'll build a 8~0 that includes the fix <youpi> so people can easily build the hurd package <youpi> Mmm, no, the bootstrap port is also NULL for normally-started processes :/ <youpi> I don't understand why <youpi> ah, only translators get a bootstrap port :/ <youpi> perhaps CRDIR then <youpi> (which makes a lot of sense)
IRC, freenode, #hurd, 2013-07-01
<braunr> youpi: what is local-no-bootstrap-fs-access.diff supposed to fix ? <youpi> ext2fs.static linked againt debian glibc 2.17 <youpi> well, as long as you don't build & use ext2fs.static with it... <braunr> that's thing, i want to :) <braunr> +the <youpi> I'd warmly welcome a way to detect whether being the / translator process btw <youpi> it seems far from trivial