Skip to content

G
go
Switch branch/tag
  1. 28 Apr, 2011 5 commits
    • Lorenzo Stoakes's avatar
      gc: correctly handle fields of pointer type to recursive forward references · b6f0632e
      Lorenzo Stoakes authored 
      Previously, whether declaring a type which copied the structure of a type it was referenced in via a pointer field would work depended on whether you declared it before or after the type it copied, e.g. type T2 T1; type T1 struct { F *T2 } would work, however type T1 struct { F *T2 }; type T2 T1 wouldn't.

Fixes #667.

R=rsc
CC=golang-dev
https://golang.org/cl/4313064
      b6f0632e
    • Russ Cox's avatar
      runtime: stack split + garbage collection bug · 370276a3
      Russ Cox authored 
      The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).

That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls.  Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.

The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp.  In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number.  Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory.  On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number.  Scanblock would not scan anything, possibly
causing in-use blocks to be freed.

In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.

Fixes #1620.
Fixes #1746.

R=iant, r
CC=golang-dev
https://golang.org/cl/4437075
      370276a3
    • Russ Cox's avatar
      cgo: handle versioned ELF symbols · 09092a78
      Russ Cox authored 
      Fixes #1397.

R=iant
CC=golang-dev
https://golang.org/cl/4444064
      09092a78
    • Russ Cox's avatar
      runtime: allow use of >512 MB on 32-bit platforms · 70b0de8e
      Russ Cox authored 
      runtime: memory allocated by OS not in usable range
runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
throw: out of memory

runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
        runtime.throw(0x1fffd, 0x101)
runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
        runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
        runtime.mal(0x100004, 0x20bc4)
runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
        runtime.new(0x100004, 0x8fe84000, 0x20bc4)
main.main+0x29 /Users/rsc/x.go:11
        main.main()
runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
        runtime.mainstart()
runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
        runtime.goexit()
----- goroutine created by -----
_rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80

R=iant, r
CC=golang-dev
https://golang.org/cl/4444073
      70b0de8e
    • Andrew Gerrand's avatar
      mime/multipart: add ReadForm and associated types · 33ca16d6
      Andrew Gerrand authored 
      R=brad_danga_com, rsc, dfc, r, dchest, bradfitz
CC=golang-dev
https://golang.org/cl/4439075
      33ca16d6
  3. 27 Apr, 2011 13 commits
  5. 26 Apr, 2011 13 commits
  7. 25 Apr, 2011 9 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7