<pre class="notranslate">Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
W7/32b in VirtualBox running in Ubuntu 12.04, x86_64.

Which version are you using?  (run 'go version')
go version 1.1.2

Please provide any additional information below.

Excerpts from a mail converstaion with the Camlistore developers:

----
We've just got this report:
<a href="http://camlistore.org/issue/214" rel="nofollow">http://camlistore.org/issue/214</a>

so I've tried in winxp in a virtualbox a very basic test like
<a href="https://gist.github.com/mpl/6366649">https://gist.github.com/mpl/6366649</a>
and I indeed get an error like:
kv.Create foo.kv: read foo.kv: Fin de fichier atteinte. (which means EOF)
----
First partial result:

C:\home\src\github.com\cznic\kv&gt;go test -run TestCreate$

The problem is here: <a href="https://github.com/cznic/exp/blob/master/lldb/xact.go#L211">https://github.com/cznic/exp/blob/master/lldb/xact.go#L211</a>
The first call to ReadAt(112 bytes at offset 16) at L211, returns
correctly (0, err) on Linux - the file is only 16 bytes long at that
moment (that's the kv header). 'err' is such that 'err == io.EOF' is
true.

However, on Windows the error is("%T(%#v)"):
*os.PathError(&amp;os.PathError{Op:"read", Path:"_testdata/tempname",
Err:0x26})

and for this 'err == io.EOF' is false. Which breaks the logic the DB
engine relies on.

FYI: Some info about 0x26 error here:
<a href="http://social.technet.microsoft.com/Forums/windowsserver/en-US/1a16311b-c625-46cf-830b-6a26af488435/how-to-solve-error-38-0x26-errorhandleeof-using-fsctlgetretrievalpointers" rel="nofollow">http://social.technet.microsoft.com/Forums/windowsserver/en-US/1a16311b-c625-46cf-830b-6a26af488435/how-to-solve-error-38-0x26-errorhandleeof-using-fsctlgetretrievalpointers</a>
From that link it may also be the case that it's actually a Windows
bug (happens only for small files).
----

====

I'm aware that this issue report is lacking a small, self contained reproduction case.
I'm trying to first figure out if the 0x26 error should be translated to an io.EOF by
the Go runtime on Windows - or not?

If a small reproduction case turns out to be unavoidable, I'll attempt to prepare one
over the weekend.</pre>
<p dir="auto">by <strong><a href="mailto:austin@google.com">austin@google.com</a></strong>:</p>
<pre class="notranslate">What steps will reproduce the problem?
1. GOARCH=power64 go run run.go -- nilptr2.go

Lines marked "removed repeated nil check" fail in this test because the test
depends on duplicate store elimination, which doesn't currently happen on power64x.

To see the cause, run
  GOARCH=power64 gdb --args $(go tool -n 9g) nilptr3.go
  br nilopt
  r
  dis 1
  set debug_checknil = 2
  c

On power64, prior to nilopt, f2 looks like
0:00041 (nilptr3.go:64)        TEXT      "".f2(SB),$0-0
0:00042 (nilptr3.go:64) FUNCDATA    $0,"".gcargs·2(SB)
0:00043 (nilptr3.go:64) FUNCDATA    $1,"".gclocals·3(SB)
0:00052 (nilptr3.go:66) MOVD    $0,R7
0:00053 (nilptr3.go:66) MOVD    R7,"".intp-0(SP)
0:00054 (nilptr3.go:67) MOVD    $0,R7
0:00055 (nilptr3.go:67) MOVD    R7,"".arrayp-0(SP)
0:00056 (nilptr3.go:68) MOVD    $0,R7
0:00057 (nilptr3.go:68) MOVD    R7,"".array0p-0(SP)
0:00058 (nilptr3.go:69) MOVD    $0,R7
0:00059 (nilptr3.go:69) MOVD    R7,"".bigarrayp-0(SP)
0:00060 (nilptr3.go:70) MOVD    $0,R7
0:00061 (nilptr3.go:70) MOVD    R7,"".structp-0(SP)
0:00062 (nilptr3.go:71) MOVD    $0,R7
0:00063 (nilptr3.go:71) MOVD    R7,"".bigstructp-0(SP)
0:00064 (nilptr3.go:72) MOVD    $0,R7
0:00065 (nilptr3.go:72) MOVD    R7,"".emptyp-0(SP)
0:00066 (nilptr3.go:73) MOVD    $0,R7
0:00067 (nilptr3.go:73) MOVD    R7,"".empty1p-0(SP)
0:00068 (nilptr3.go:76) MOVD    "".intp-0(SP),R7
0:00069 (nilptr3.go:76) CHECKNIL    R7,
0:00070 (nilptr3.go:77) MOVD    "".arrayp-0(SP),R7
0:00071 (nilptr3.go:77) CHECKNIL    R7,
0:00072 (nilptr3.go:78) MOVD    "".array0p-0(SP),R7
0:00073 (nilptr3.go:78) CHECKNIL    R7,
0:00074 (nilptr3.go:79) MOVD    "".array0p-0(SP),R7
0:00075 (nilptr3.go:79) CHECKNIL    R7,
0:00076 (nilptr3.go:80) MOVD    "".intp-0(SP),R7
0:00077 (nilptr3.go:80) CHECKNIL    R7,
0:00078 (nilptr3.go:81) MOVD    "".arrayp-0(SP),R7
0:00079 (nilptr3.go:81) CHECKNIL    R7,
0:00080 (nilptr3.go:82) MOVD    "".structp-0(SP),R7
0:00081 (nilptr3.go:82) CHECKNIL    R7,
0:00082 (nilptr3.go:83) MOVD    "".emptyp-0(SP),R7
0:00083 (nilptr3.go:83) CHECKNIL    R7,
0:00084 (nilptr3.go:84) MOVD    "".arrayp-0(SP),R7
0:00085 (nilptr3.go:84) CHECKNIL    R7,
0:00086 (nilptr3.go:85) MOVD    "".bigarrayp-0(SP),R7
0:00087 (nilptr3.go:85) CHECKNIL    R7,
0:00088 (nilptr3.go:86) MOVD    "".bigstructp-0(SP),R7
0:00089 (nilptr3.go:86) CHECKNIL    R7,
0:00090 (nilptr3.go:87) MOVD    "".empty1p-0(SP),R7
0:00091 (nilptr3.go:87) CHECKNIL    R7,
0:00092 (nilptr3.go:88) RETURN  ,

These extra MOVDs inhibit the repeated nil check optimization.  In contrast, on amd64,
prior to nilopt, f2 looks like
0:00032 (nilptr3.go:64) TEXT    "".f2+0(SB),$0-0
0:00033 (nilptr3.go:64) FUNCDATA    $0,"".gcargs·2+0(SB)
0:00034 (nilptr3.go:64) FUNCDATA    $1,"".gclocals·3+0(SB)
0:00043 (nilptr3.go:66) MOVQ    $0,DX
0:00044 (nilptr3.go:67) MOVQ    $0,AX
0:00045 (nilptr3.go:68) MOVQ    $0,CX
0:00046 (nilptr3.go:69) MOVQ    $0,R8
0:00047 (nilptr3.go:70) MOVQ    $0,DI
0:00048 (nilptr3.go:71) MOVQ    $0,SI
0:00049 (nilptr3.go:72) MOVQ    $0,BP
0:00050 (nilptr3.go:73) MOVQ    $0,BX
0:00051 (nilptr3.go:76) CHECKNIL    DX,
0:00052 (nilptr3.go:77) CHECKNIL    AX,
0:00053 (nilptr3.go:78) CHECKNIL    CX,
0:00054 (nilptr3.go:79) CHECKNIL    CX,
0:00055 (nilptr3.go:80) CHECKNIL    DX,
0:00056 (nilptr3.go:81) CHECKNIL    AX,
0:00057 (nilptr3.go:82) CHECKNIL    DI,
0:00058 (nilptr3.go:83) CHECKNIL    BP,
0:00059 (nilptr3.go:84) CHECKNIL    AX,
0:00060 (nilptr3.go:85) CHECKNIL    R8,
0:00061 (nilptr3.go:86) CHECKNIL    SI,
0:00062 (nilptr3.go:87) CHECKNIL    BX,
0:00063 (nilptr3.go:88) RET ,</pre>