Skip to content
Snippets Groups Projects
Commit 451667a6 authored by Rob Pike's avatar Rob Pike
Browse files

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
parent 1e67453d
Branches main
No related tags found
No related merge requests found
...@@ -64,8 +64,11 @@ func Setgroups(gids []int) (err error) { ...@@ -64,8 +64,11 @@ func Setgroups(gids []int) (err error) {
func ReadDirent(fd int, buf []byte) (n 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. // 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? // 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), // Wait status is 7 bits at bottom, either 0 (exited),
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment