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

net: ReadFromUDP Mangled Bytes #8881

Closed
gopherbot opened this issue Oct 7, 2014 · 10 comments

Comments

Projects
None yet
4 participants
@gopherbot
Copy link

commented Oct 7, 2014

by rpzrpzrpz:

(rpzrpzxxx@gxxxx.com)

ReadFromUDP( ) is returning a good Remote Address net.UDPAddr{port,IP} but it is not
handling the returned buffer too well.

Run the attached program files in Go and the support test program in python to see the
ReadFromUDP( ) fail miserably.

The function cannot seem to handle go routines spawned after returning from ReadFromUDP(
). 

The only work around is to process the bytes first and then go back and get more UDP
data from ReadFromUDP( ), but do not start a go routine to process those bytes and then
go back simultaneously and get more bytes.

Go just does not provide good isolation.

If for some strange reason my buffer handling does not make a COPY of the data during
the go routine execution, let me know, but I have tried every combination of create
array with calls like make([]byte,1024) etc to work around the problem

Attachments:

  1. pycli.py (1191 bytes)
  2. main.go (2520 bytes)
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

Comment 1:

I'm sorry, I don't really understand the bug report.  You say that there are goroutines
after the call to ReadFromUDP, but I don't see any.  I also don't see any code that
copies the buffer.

Labels changed: added repo-main, release-none.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

Comment 2:

Issue #8858 has been merged into this issue.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

Comment 3:

Issue #8858 has been merged into this issue.

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

Comment 4:

OP, your program has a data race on line 19, and other places where gstop is
used/referenced.
@gopherbot

This comment has been minimized.

Copy link
Author

commented Oct 7, 2014

Comment 5 by rpzrpzrpz:

Oops, I am sorry, I left the sample code in a FIXED state.
Simply add a "go" directive in front of the call to udpcallbackfunc()
go udpcallbackfunc(gconn, grxadd, glen, gbuf[0:glen]) instead of just 
the call to udpcallbackfunc( ).
Then run the python program and watch it DIE!
@davecheney

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

Comment 6:

rp, can you please run your sample code under the race detector and confirm that it is
free of race conditions.

Status changed to WaitingForReply.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

Comment 7:

If you change the call to udpcallbackfunc to run in a goroutine, then the program is
clearly racy, because both the new goroutine and the original one will be using gbuf.

Status changed to WontFix.

@gopherbot

This comment has been minimized.

Copy link
Author

commented Oct 7, 2014

Comment 8 by rpzrpzrpz:

Racy?  How to make a copy of the gbuf and pass that copy to the goroutine thus isolating
the bytes and NOT mangling them.
As has been stated, I have tried many different ways to un-race the code.
For example:
gtemp := gbuf[0:glen]
go udpcallbackfunc(gconn, grxadd, glen, gtemp[0:]) 
Nope, the bytes are STILL mangled.  No way to call a go routine with any combination of
the bytes.  
Can you suggest a change to the code?
Thx,
md
@gopherbot

This comment has been minimized.

Copy link
Author

commented Oct 7, 2014

Comment 9 by rpzrpzrpz:

And by definition, if the gbuf is racy, then grxadd should be racy.  But it is NOT.
The grxadd is dispatched to udpcallbackfunc( ) perfect every time.  The gbuf or any
version of a copy of gbuf, not at all.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

Comment 10:

gtemp := gbuf[0:glen] does not make a copy of the underlying array.  It just gives you a
new slice referring to the same underlying array.
See http://blog.golang.org/slices .

@golang golang locked and limited conversation to collaborators Jun 25, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.