Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnixGram implementation problems #945

Closed
gopherbot opened this issue Jul 23, 2010 · 5 comments
Closed

UnixGram implementation problems #945

gopherbot opened this issue Jul 23, 2010 · 5 comments

Comments

@gopherbot
Copy link

by jdnurmi:

What steps will reproduce the problem?
1. See attached (C) (go) and (python) files
  - Python files are demonstration senders (unbound unix socket and bound unix sockets)
  - C shows returns & errors for packets RX'd
  - .go's implement unix dgram using Read, ReadFrom, and for kicks, ReadFromUDP.
2. Make files;  See that the .c rxsock always reports data received (but not always an
address) regardless of a bound or unbound client.
3. Run any of the .go versions to experience deviations.

What is the expected output?
I would expect the matrix of Data&Addr to yield:

           |Bound|Unbound|Error|
Read       |   X | X     | -   |
ReadFrom   |   X | X (nil address)| ?|
ReadFromUDP| -   | -     | X |

In all cases (but the last), I would expect Read* to return the number of bytes read,
and the error (or lack of address) to indicate an unbound sender.

ReadFrom should return the sending unix socket address when querying readFrom, instead
of returning null

What do you see instead?

Read always works.
ReadFrom returns 0 for len, an error, and a nil address for an un-named socket.
ReadFrom returns the correct number of bytes, no address, and an error for a named
socket.


ReadFrom returns nil for the address regardless of a bound or unbound client socket.

What is your $GOOS?  $GOARCH?
linux, amd64

Which revision are you using?  (hg identify)
pulled  HEAD, 20100722

Please provide any additional information below.
@gopherbot
Copy link
Author

Comment 1 by jdnurmi:

Grr, forgot to attach...

Attachments:

  1. bug1.zip (6216 bytes)

@gopherbot
Copy link
Author

Comment 2 by jdnurmi:

Side notes that I didn't mention in the original report:
ReadFromUDP panics in either case, but I thought it a potential answer while I was
debugging my issue.
When ReadFrom an anonymous socket returns 0,err,err, you /can/ still read the bytes if
you assume the range, but since no return value indicates how many bytes were actually
read, I'd feel more comfortable if an anonymous ReadFrom instead returned (bytesRead,
nil, UnparsableAddress) or perhaps (bytesRead, UNBOUND_CONST, nil) in the case of a
successful ReadFrom with an unsuccessful address parse.
I also didn't explicitly call it out, but even in the _bound_ ReadFrom case, you don't
actually get a valid return address (you get a parsing error or nil IIRC), but the
nBytes is correctly >0.

@adg
Copy link
Contributor

adg commented Jul 26, 2010

Comment 3:

It's actually the call to Printf that leads to the panic. The *UDPAddr type has a String
method that dereferences the pointer, and if it's a nil pointer (as in this case) it
panics. I've created a CL.
Relevant stack trace:
adg ~/test/udp$ ./rxsock-go-readfrom-udp 
panic: runtime error: invalid memory address or nil pointer dereference
panic PC=0x2c39e8
runtime.panic+0x7c /Users/adg/go/src/pkg/runtime/proc.c:1012
    runtime.panic(0x0, 0x7830)
panicstring+0x60 /Users/adg/go/src/pkg/runtime/runtime.c:83
    panicstring(0x5cf70, 0x2ea240)
sigpanic+0x84 /Users/adg/go/src/pkg/runtime/darwin/thread.c:459
    sigpanic()
net.*UDPAddr·String+0x17 /Users/adg/go/src/pkg/net/udpsock.go:33
    net.*UDPAddr·String(0x16d9d, 0x32f068, 0x20000000c, 0x66e7)
fmt.*pp·printField+0x26d6 /Users/adg/go/src/pkg/fmt/print.go:626
    fmt.*pp·printField(0x0, 0x5e4d8, 0x0, 0x2dd420, 0x0, ...)
fmt.*pp·doPrintf+0x6cc /Users/adg/go/src/pkg/fmt/print.go:958
    fmt.*pp·doPrintf(0x32f000, 0x5e4d8, 0x0, 0x76, 0x0, ...)
fmt.Fprintf+0x57 /Users/adg/go/src/pkg/fmt/print.go:263
    fmt.Fprintf(0x32f000, 0x62078, 0x13, 0x2dd210, 0x300000003, ...)
fmt.Printf+0x72 /Users/adg/go/src/pkg/fmt/print.go:271
    fmt.Printf(0x2dd2a0, 0x2d4090, 0x62078, 0x13, 0x2dd210, ...)
main.main+0x31b /Users/adg/test/udp/rxsock-readfrom-udp.go:24
    main.main()
mainstart+0xf /Users/adg/go/src/pkg/runtime/amd64/asm.s:60
    mainstart()
goexit /Users/adg/go/src/pkg/runtime/proc.c:145
    goexit()

Owner changed to a...@golang.org.

Status changed to Accepted.

@adg
Copy link
Contributor

adg commented Jul 27, 2010

Comment 4:

This issue was closed by revision fc4ba15.

Status changed to Fixed.

@gopherbot
Copy link
Author

Comment 5 by jdnurmi:

Ok, I can confirm this fixes the crash in RecvFromUDP();
It does not, however fix the n=0, when an anonymous socket sends data to a socket using
the recvfrom() call.
(See the ./rxsock-go-readfrom && ./sockecho_anon.py tests).
Since the creator of the listening application has no way to know if a client is using
an unbound socket, I would propose that 'NBytes' should always be set, and
error/addr==nil used as an indicator that there was no address received.
Thanks much!

@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc unassigned adg Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants