From 451667a67f5b7765bb4d1d5e94e12ea1b18cfe23 Mon Sep 17 00:00:00 2001
From: Rob Pike <r@golang.org>
Date: Fri, 17 Jan 2014 13:19:00 -0800
Subject: [PATCH] syscall: allocate 64 bits of "basep" for Getdirentries Recent
crashes on 386 Darwin appear to be caused by this system call smashing the
stack. Phenomenology shows that allocating more data here addresses the
probem. The guess is that since the actual system call is getdirentries64, 64
is what we should allocate.
Should fix the darwin/386 build.
R=rsc
CC=golang-codereviews
https://golang.org/cl/53840043
---
src/pkg/syscall/syscall_bsd.go | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/pkg/syscall/syscall_bsd.go b/src/pkg/syscall/syscall_bsd.go
index a62cbe28359..71efced3d8a 100644
--- a/src/pkg/syscall/syscall_bsd.go
+++ b/src/pkg/syscall/syscall_bsd.go
@@ -64,8 +64,11 @@ func Setgroups(gids []int) (err error) {
func ReadDirent(fd int, buf []byte) (n int, err error) {
// Final argument is (basep *uintptr) and the syscall doesn't take nil.
+ // 64 bits should be enough. (32 bits isn't even on 386). Since the
+ // actual system call is getdirentries64, 64 is a good guess.
// TODO(rsc): Can we use a single global basep for all calls?
- return Getdirentries(fd, buf, new(uintptr))
+ var base = (*uintptr)(unsafe.Pointer(new(uint64)))
+ return Getdirentries(fd, buf, base)
}
// Wait status is 7 bits at bottom, either 0 (exited),
--
GitLab