<p dir="auto">by <strong><a href="mailto:mseigneurin@aliceadsl.fr">mseigneurin@aliceadsl.fr</a></strong>:</p>
<pre class="notranslate">The http.ResonseWriter exposes a UsingTLS() method which is good, but the other info
stored in the tls.Conn structure is not available. Could the interface be
extended/changed to allow access to more of the TLS properties?

(this is related to <a href="https://golang.org/issue/155)" rel="nofollow">https://golang.org/issue/155)</a>

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
linux,x86_64

Which revision are you using?  (hg identify)
d206790cdd7d tip

Please provide any additional information below.

I can "patch in" by creating a custom Listener that mimics the
tls.Listener and gets the information there, but I can't figure out a
way of propagating that info up the stack to the actual handlers
without:
a) hacking in the http/server.go and adding an accessor there similar
to the way UsingTLS() is implemented - which is not real nice I guess.
or b) writing a custom equivalent of http.conn/http.response, which is
a lot of duplicated code.</pre>
<p dir="auto">by <strong>jnwhiteh</strong>:</p>
<pre class="notranslate">What steps will reproduce the problem?
1. Run make test on the attached source
2. Note the line number for cache.go in the stack trace

What is the expected output?

The actual invalid memory address/nil pointer dereference happens on line 178. I was
able to verify this by adding debug/panic statements.

What do you see instead?

The stack trace lists cache.go:226, which is actually never reached:

panic: runtime error: invalid memory address or nil pointer dereference

[signal 0xb code=0x1 addr=0x30 pc=0x16951]

runtime.panic+0xac /Users/jnwhiteh/scm/golang.hg/src/pkg/runtime/proc.c:1060
    runtime.panic(0x96148, 0xf840001410)
runtime.panicstring+0xa3 /Users/jnwhiteh/scm/golang.hg/src/pkg/runtime/runtime.c:116
    runtime.panicstring(0x11cdbf, 0x2a97a)
runtime.sigpanic+0x144 /Users/jnwhiteh/scm/golang.hg/src/pkg/runtime/darwin/thread.c:470
    runtime.sigpanic()
jnwhiteh/minixfs.*LRUCache·GetBlock+0x5dc /Users/jnwhiteh/Desktop/minixfs/cache.go:226
    jnwhiteh/minixfs.*LRUCache·GetBlock(0xf840025ae0, 0x400000000, 0x0, 0x100000008, 0x18e8a, ...)
jnwhiteh/minixfs.*FileSystem·get_block+0x49 /Users/jnwhiteh/Desktop/minixfs/fs.go:80
    jnwhiteh/minixfs.*FileSystem·get_block(0xf84000c820, 0x400000000, 0x0, 0x2a7af, 0xf84001a800, ...)
jnwhiteh/minixfs.*FileSystem·get_inode+0x1ce /Users/jnwhiteh/Desktop/minixfs/inode.go:73
    jnwhiteh/minixfs.*FileSystem·get_inode(0xf84000c820, 0x100000000, 0xf84000c7d0, 0xf84000fc30, 0xf84000c780, ...)
jnwhiteh/minixfs.OpenFileSystemFile+0x407 /Users/jnwhiteh/Desktop/minixfs/fs.go:55
    jnwhiteh/minixfs.OpenFileSystemFile(0xb1b9c, 0x746f6f620000000c, 0xf840003000, 0xf84001a678, 0x217af98, ...)


Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

Mac OS X 10.6.7

Which revision are you using?  (hg identify)

$ hg identify
26a2b651a7a9 tip

Please provide any additional information below.

There was indeed a bug in my program (uncomment line 99 and things work properly) but
it's rather difficult to track down a bug when you're looking 40+ lines away from the
actual issue.

Let me know if I can provide any further information.</pre>
<p dir="auto">Attachments:</p>
<ol dir="auto">
<li><a href="https://storage.googleapis.com/go-attachment/1873/0/badlinenum.zip" rel="nofollow">badlinenum.zip</a> (477905 bytes)</li>
</ol>