1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
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
<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.
[[hurd/debugging/rpctrace]].
<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
|
