<p dir="auto">by <strong>Benny.TPNG</strong>:</p>
<pre class="notranslate">What does 'go version' print?
go1.3.3 windows/amd64
go1.3.3 linux/amd64

What steps reproduce the problem?
1. go run main.go

What happened?
The 2nd request will fail with EOF.

What should have happened instead?
Both requests should succeed without error.

Please provide any additional information below.
The server is an IIS reverse proxy to a go http server.

Response header sample:
HTTP/1.1 200 OK
Date: Tue, 18 Nov 2014 11:12:09 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: application/json;charset=utf-8
Date: Tue, 18 Nov 2014 11:12:08 GMT
Transfer-Encoding: chunked
Via: 1.1 203.80.2.39 (IIRF v2.1)</pre>
<p dir="auto">Attachments:</p>
<ol dir="auto">
<li><a href="https://storage.googleapis.com/go-attachment/9122/0/main.go" rel="nofollow">main.go</a> (399 bytes)</li>
</ol>
<p dir="auto">by <strong>erik.westrup</strong>:</p>
<pre class="notranslate">The resulting ELF produced does not contain a ".debug_gdb_script" section.
Thus no Go runtime support for Go is loaded when running the ELF in GDB.


&gt; What does 'go version' print?

go version devel +e3ff5d42017d Mon Mar 10 07:57:58 2014 +0100 linux/amd64

&gt; What steps reproduce the problem?
1. $ hg clone -u release <a href="https://code.google.com/p/go" rel="nofollow">https://code.google.com/p/go</a>
   $ cd go
   $ hg update default
   $ src/all.bash
2. $ go build hello.go
3. $ readelf -S hello | grep -c debug_gdb_script
   0

&gt; What happened?
No debug gdb script path included.

&gt; What should have happened instead?
$ readelf -S hello | grep -c debug_gdb_script
1
which happens on the release-branch.go1.2 branch.


&gt; Please provide any additional information below.
Has the way of loading the debug_gdb_script changed intentionally?</pre>