Comment 1 by x41@freeshell.org:

/usr/include/bits/string3.h:106: warning: 
call to __builtin___strcpy_chk will always overflow destination buffer
And this i intentionally not allowed with -D_FORTIFY_SOURCE=2, which doesn't allow
crossing field boundaries for str*/stp* etc. functions (and still allows that
for mem* etc.).
If we use -00 the problem is resolved, but if we really need to use -02 or -03
we have to edit Make.conf and modify like this:
 
CFLAGS=-ggdb -I$(GOROOT)/include -O2 -fno-inline -D_FORTIFY_SOURCE=1
The difference between -D_FORTIFY_SOURCE=1 and -D_FORTIFY_SOURCE=2
is e.g. for
struct S { struct T { char buf[5]; int x; } t; char buf[20]; } var;
With -D_FORTIFY_SOURCE=1,
strcpy (&var.t.buf[1], "abcdefg");
is not considered an overflow (object is whole VAR), while
with -D_FORTIFY_SOURCE=2
strcpy (&var.t.buf[1], "abcdefg");
will be considered a buffer overflow.
==================================================
 NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2
 is set by default, and is activated when -O is set to 2 or higher.
 This enables additional compile-time and run-time checks for several
 libc functions.  To disable, specify either -U_FORTIFY_SOURCE or
 -D_FORTIFY_SOURCE=0.
==================================================
It thus OK to keep the bug as RESOLVED

Comment 2:

Owner changed to r...@golang.org.

Status changed to Duplicate.

Merged into issue #393.

Comment 3 by jeff.allen:

This is a different bug than 393, Russ.
The root cause of this one is that alloc() in lexbody goes into an infinite loop
allocating all memory in the machine if you ask it to allocate an object larger than
NHUNK (50000) bytes due to "while (nhunk < n) gethunk()".
A simple fix would be for it to refuse (return NULL), and let the caller deal with the
consequences. Another fix would be to use a two-tier allocation model, where big things
come direct from malloc and little things are managed by alloc().
I am still reading source to decide which of these might be best. Your suggestion?

Comment 4 by jeff.allen:

It seems as all the users of alloc() do not free the memory (since the process is going
to exit soon anyway). So a simple change to a two-tier model works, because since there
is no free, the freer does not need to know which pool it came from.
Here's a proposed patch.
diff -r 9f5f89e6da5c src/cmd/cc/lexbody
--- a/src/cmd/cc/lexbody    Mon Oct 25 18:35:08 2010 +0200
+++ b/src/cmd/cc/lexbody    Mon Oct 25 19:24:12 2010 +0200
@@ -101,11 +101,15 @@
 {
    void *p;
 
+   /* for requests that are too big, don't use the hunk allocator */
+   if (n > NHUNK)
+       return malloc(n);
+
    while((uintptr)hunk & MAXALIGN) {
        hunk++;
        nhunk--;
    }
-   while(nhunk < n)
+   if (nhunk < n)
        gethunk();
    p = hunk;
    nhunk -= n;

Comment 5:

all the while loops should turn into calls to mal.
look in the linkers for examples.
(they all used to have those loops too.)
russ

Comment 6:

This issue was closed by revision 1558834.

Status changed to Fixed.