From 6c7d45e4631784d0e077e806521a736da6b0266e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 7 Apr 2013 18:18:44 +0200 Subject: IRC. --- open_issues/glibc/debian/experimental.mdwn | 115 +++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 open_issues/glibc/debian/experimental.mdwn (limited to 'open_issues/glibc/debian/experimental.mdwn') diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn new file mode 100644 index 00000000..8d117e99 --- /dev/null +++ b/open_issues/glibc/debian/experimental.mdwn @@ -0,0 +1,115 @@ +[[!meta copyright="Copyright © 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]] + +Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental. + + +# IRC, OFTC, #debian-hurd, 2013-03-14 + + I have a strange tcp via localhost question: + 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? + At least it seems to work that way on Linux, but not on + Hurd. + Got a simple repro with nc, if you're interested... + markus_wanner: yes, we're interested + youpi: okay, here we go: + session 1: nc -l -p 7777 localhost + session 2: nc 127.0.0.1 7777 + session 2: a b c + session 1: [ pause with Ctrl-Z ] + session 2: [ send more data ] d e f + session 2: [ quit with Ctrl-C ] + session 1: [ resume with 'fg' ] + The server on session 1 doesn't get the data sent after it + paused and before the client closed the connection. + 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. + I'm working on a C-code test case, ATM. + markus_wanner: on which box are you seeing this behavior? + exodar does not have it + i.e. I do get the d e f + a private VM (I'm not a DD) + ..updated to latest experimental stuff. + GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU + ok, I can't reproduce it on my vm either + maybe the C program will help + Hm.. cannot corrently reproduce that in C. (Netcat still + shows the issue, though). + I'll try to strace netcat... + ..Meh. strace not available on Hurd? + no, but there is rpctrace to show the various rpc + Cool, looks helpful. + Thx + Uh.. that introduces another error: + rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward: + Assertion `reply_type == 18' failed. + +[[hurd/debugging/rpctrace]]. + + I'm checking on a box without ipv6 configuration + maybe that's the difference between you and me + I guess your /etc/alternatives/nc is /bin/nc.traditional ? + Yup, nc.traditional. + Looks like that box only has IPv4 configured. + Something very strange is going on here. No matter how hard + I try, I cannot reproduce this with netcat, anymore. + not even after a reboot? + Woo.. here, it happened, again! This is driving me crazy! + Now, nc seemingly connects, but is unable to send data + between the two. Netcat would somehow complain, if it failed to connect, + no? + No it worked. + 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. + 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. + Anything I can try to investigate? Or shall I simply + restart and see if the problem persists? + maybe restart, yes + did you restart since the upgrade ? + Yes, I restarted after that. + Hm.. okay, restarted. Some problem persists. + I currently have two netcat processes connected, the + listening one got some first two messages and seems stuck now. + With the client, I tried to send more data, but the server + doesn't get it, anymore. + Any idea on what I can do to analyze the situation? + for the netcat issue, I haven't experienced this + are you running in kvm or virtualbox or something else? + I'm currently puzzled about what "experimental" actually + ships. + On kvm. + My libc0.3 used to be 2.13-39+hurd.3. + But packages.d.o already shows 2.17.0experimental2. + experimental ships experimental versions, which you aren't supposed + to use + unless you know what you are doing + iirc 2.17 is known to be quite broken for now + Okay. So I guess I'll try to "downgrade" to unstable, then. + Phew, okay, successfully downgraded to unstable. + Hopefully monotone's test suite runs through fine, now. + 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 + + 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?) + that was libc0.3 packages + which are indeed known to break the network -- cgit v1.2.3