OpenGL's glClear() causes Access Violation (0xc0000005) in Windows 64

Take a look at this super-simple small test-case OpenGL program written in Go:

package main
import (
	"runtime"
	"./glfw"
	gl "github.com/chsc/gogl/gl21"
)
func onExit (err error) {
	glfw.Terminate()
	if err != nil { panic(err) }
}
func main () {
	runtime.LockOSThread()
	err := glfw.Init()
	if err != nil { panic(err) }
	err = glfw.OpenWindow(1280, 720, 0, 0, 0, 0, 0, 0, glfw.Windowed)
	if err != nil { onExit(err) }
	err = gl.Init()
	if err != nil || gl.GetError() != 0 { onExit(err) }
	for glfw.WindowParam(glfw.Opened) == 1 {
		gl.Viewport(0, 0, 1280, 720)
		gl.ClearColor(1, 0, 0, 1)
		gl.Clear(gl.COLOR_BUFFER_BIT) // THE CRASH
		gl.Begin(gl.TRIANGLES)
		gl.Color3f(1, 0, 0)
		gl.Vertex3f(-1, -1, 0)
		gl.Color3f(0, 1, 0)
		gl.Vertex3f(0, 1, 0)
		gl.Color3f(0, 0, 1)
		gl.Vertex3f(1, -1, 0)
		gl.End()
		glfw.SwapBuffers()
		if glfw.Key(glfw.KeyEsc) == 1 {
			glfw.CloseWindow()
		}
	}
	onExit(nil)
}

This builds fine under Windows 7 64-bit with Go 1.0.1 64-bit.

It also works fine (OpenGL draws a single rainbow-colored 2D triangle until the Window is closed) IF you take out (or comment-out) the gl.Clear(gl.COLOR_BUFFER_BIT) line.

As soon as gl.Clear is called however (no matter what arguments are passed), it crashes, Windows informs me that "glfw-win.exe has stopped working..." and the Windows Event Viewer has the following error log for me:

Faulting application name: glfw-win.exe, version: 0.0.0.0, time stamp: 0x4f9f5ec5
Faulting module name: glfw-win.exe, version: 0.0.0.0, time stamp: 0x4f9f5ec5
Exception code: 0xc0000005
Fault offset: 0x0000000000012883
Faulting process id: 0xd4c
Faulting application start time: 0x01cd274e4c69a3d3
Faulting application path: C:\mytmp\glfw-win\glfw-win.exe
Faulting module path: C:\mytmp\glfw-win\glfw-win.exe
Report Id: 8a5bacc0-9341-11e1-911a-d067e544ad7f

Now, a couple of noteworthy points...

1. The glfw package is simply a custom package exposing the exact same API as github.com/jteeuwen/glfw but internally using LoadLibrary/GetProcAddress for using glfw.dll rather than compile-time CGO/GCC/LD linking -- since the latter cannot be made to work in 64-bit Windows sadly, not sure whether mingw64 or gcc or cgo is to blame. With LoadLibrary/GetProcAddress calling my custom 64-bit build of glfw.dll is working mighty fine. Clearly the issue here is with a call to the gl package, not glfw.

2. The gl package is indeed simply this one, unmodified. I experimented with a few LDFLAGS modifications such as -m64 -lmingw32 -Wl,/windows/opengl32.dll etc. but no difference, the original works just as fine as the modified ones as long as gl.Clear() is not called, so I reverted back to the original. Of course later on I'll move on to OpenGL 4.2.

3. Using Process Explorer, I can see my process is 64-bit and all loaded DLLs are 64-bit images too (including opengl32.dll and glfw.dll).

4. "could it be that the gl21 package could not obtain a valid address for the glClear() function exported by opengl32.dll?" -- unlikely: according to line 2926, my call to gl.Init() would fail if this were the case.

5. GPU driver issues? Even more unlikely. The very newest official nVidia Quadro 5010M driver 296.35 is installed. Also tried the "performance driver" but seems to be exactly the same driver anyway. Full OpenGL 4.2 support according to nVidia Control Panel (although opengl32.dll is dated 2009 -- anyway, plenty for 2.1 I'm currently targeting). Plus, the OpenGL shaders in "Geeks3D GPU Caps Viewer" and "Shader Toy Mark" run, as does the GLFW example program particles.exe -- all of them use glClear() as well.

6. Exact same issue happens when using gl42 instead of gl21, so that's not the cause either.

Do note how all other gl.SomeExportedFunc() calls do not crash in this example...

What to do, how to proceed?

I could live with this if this only happens with gl.Clear() and no other funcs ever -- I'm only ever rendering full-screen quads with custom content anyway -- but I'm fairly early in testing Win64 here (got a lot of gl42 code working just fine under Linux64, now about to "port" to Win64) and I fear that additional further calls later on will expose the same problem so I'm reporting this now. I will soon find out which other calls are affected by this.

You cannot call C functions without the CGO generated stubs.

No longer an issue with the newest releases of Go, GLFW and Mingw-w64.