Comment 1:

Not sure about this.  C.malloc is an ordinary function, so it's 
hard to make that one panic.  It's difficult to see why C.CString
should be different.
FWIW, you're on Linux so it will never happen anyway.

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

Comment 2:

Just to check, what will never happen? malloc returning ENOMEM?

Comment 3:

Yes, Linux overallocates VM, so seeing a NULL from malloc or strdup is
very very rare.

Comment 4:

With /proc/sys/vm/overcommit_memory set to 2 or with a memory controller cgroup, this
picture changes a little.

Comment 5:

OS X may force us into handling C.malloc specially, because it changed
the argument from size_t to ulong in the XCode for 10.9 Mavericks.
If so, maybe it makes sense for both C.malloc and C.CString to panic
when out of memory.

Labels changed: added go1.2maybe.

Comment 6:

Status changed to Started.

Comment 7:

This issue was closed by revision 397ba2c.

Status changed to Fixed.

Comment 8 by ralph.corderoy:

The definition of Cmalloc,
http://code.google.com/p/go/source/browse/src/cmd/cgo/out.go?spec=svn46fd4ef6c0deeb184aa0b843dfc080cc869a7e19&name=46fd4ef6c0de&r=46fd4ef6c0deeb184aa0b843dfc080cc869a7e19#1226
assumes a NULL return from malloc() means it's out of memory, but NULL is a 
valid return for malloc(0).  Perhaps Cmalloc will never be called for zero 
bytes of memory and this isn't an issue, but I thought it worth checking.  If
Cmalloc(0) isn't possible, a comment to that affect would stop future readers
wondering.

Comment 9:

Thank you for the reminder; how quickly we forget. 
Filed issue #6390