Change https://golang.org/cl/227857 mentions this issue: net/http: httputil: reverse quit logic in DumpRequestOut to fix lockup

@bcmills @bradfitz

@nerd2 There is a data race in the sample program you provided.

I believe that using DumpRequestOut while executing the Request is invalid although not documented. once RoundTrip is underway, the request.Body may be altered to handle retries as well as reading the actual body. DumpRequestOut is also manipulating the req.Body which causes the data race mentioned.

As in #37669, the lock up is internal to DumpRequestOut due to a race between the main thread and the quit and is nothing to do with external body manipulation.

I have updated the example to remove the actual request and put it here:
https://github.com/nerd2/bugs/blob/master/38352/dumplock.go

If you have a chance to look at the PR in https://github.com/golang/go/pull/38353/files perhaps you can see the issue?

I can't seem to reproduce the hang. Both your examples always execute and complete.

Try adding a 1 second sleep on line 2277 of net/http/transport.go, before the select

With the 1 second delay, I get a race:

==================
WARNING: DATA RACE
Read at 0x00c0002b6340 by goroutine 78:
  net/http.newTransferWriter()
      net/http/transfer.go:83 +0x1582
  net/http.(*Request).write()
      net/http/request.go:631 +0x614
  net/http.(*persistConn).writeLoop()
      net/http/transport.go:2283 +0x33e

Previous write at 0x00c0002b6340 by goroutine 12:
  net/http/httputil.DumpRequestOut()
      net/http/httputil/dump.go:147 +0x7cb
  main.testDumpRoundTripRace()
      command-line-arguments/issue38352.go:61 +0x6a0
  main.main.func1.1()
      command-line-arguments/issue38352.go:30 +0x5b
  runtime/pprof.Do()
      runtime/pprof/runtime.go:40 +0x11c
  main.main.func1()
      command-line-arguments/issue38352.go:29 +0x134

Or

==================
WARNING: DATA RACE
Read at 0x00c0003a2940 by goroutine 145:
  net/http.newTransferWriter()
      net/http/transfer.go:83 +0x1582
  net/http.(*Request).write()
      net/http/request.go:631 +0x614
  net/http.(*persistConn).writeLoop()
      net/http/transport.go:2283 +0x33e

Previous write at 0x00c0003a2940 by goroutine 136:
  ??()
      -:0 +0xffffffffffffffff
  encoding/base64.(*Encoding).EncodeToString()
      encoding/base64/base64.go:179 +0xf6
  main.randomBase64EncodedString()
      command-line-arguments/issue38352.go:75 +0x113
  main.testDumpRoundTripRace()
      command-line-arguments/issue38352.go:51 +0x160
  main.main.func1.1()
      command-line-arguments/issue38352.go:30 +0x5b
  runtime/pprof.Do()
      runtime/pprof/runtime.go:40 +0x11c
  main.main.func1()
      command-line-arguments/issue38352.go:29 +0x134

With the 1 second delay, I get a race:

==================
WARNING: DATA RACE
Read at 0x00c0002b6340 by goroutine 78:
  net/http.newTransferWriter()
      net/http/transfer.go:83 +0x1582
  net/http.(*Request).write()
      net/http/request.go:631 +0x614
  net/http.(*persistConn).writeLoop()
      net/http/transport.go:2283 +0x33e

Previous write at 0x00c0002b6340 by goroutine 12:
  net/http/httputil.DumpRequestOut()
      net/http/httputil/dump.go:147 +0x7cb
  main.testDumpRoundTripRace()
      command-line-arguments/issue38352.go:61 +0x6a0
  main.main.func1.1()
      command-line-arguments/issue38352.go:30 +0x5b
  runtime/pprof.Do()
      runtime/pprof/runtime.go:40 +0x11c
  main.main.func1()
      command-line-arguments/issue38352.go:29 +0x134

#37669

Change https://golang.org/cl/232798 mentions this issue: net/http/httputil: Fix deadlock in DumpRequestOut

We have request debugging in our app which uses httputil.DumpRequestOut and this deadlock took the entire app down. Given the original PR has been sat with changes pending for a while I had a look separately.

The test case added also triggered the above data race, for which I have a two part fix https://golang.org/cl/232798 and https://golang.org/cl/232799