Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(510)

Issue 80850044: code review 80850044: cmd/dist: zero output variables on entry to goc2c functions (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
11 years, 2 months ago by rsc
Modified:
11 years, 2 months ago
Reviewers:
iant, khr1
CC:
iant, khr, khr1, golang-codereviews
Visibility:
Public.

Description

cmd/dist: zero output variables on entry to goc2c functions Zeroing the outputs makes sure that during function calls in those functions we do not let the garbage collector treat uninitialized values as pointers. The garbage collector may still see uninitialized values if a preemption occurs during the function prologue, before the zeroing has had a chance to run. This reduces the number of 'bad pointer' messages when that runtime check is enabled, but it doesn't fix all of them, so the check is still disabled. It will also avoid leaks, although I doubt any of these were particularly serious.

Patch Set 1 #

Patch Set 2 : diff -r 0a3722aa9092 https://code.google.com/p/go/ #

Patch Set 3 : diff -r 0a3722aa9092 https://code.google.com/p/go/ #

Patch Set 4 : diff -r 411981469cba https://code.google.com/p/go/ #

Unified diffs Side-by-side diffs Delta from patch set Stats (+19 lines, -0 lines) Patch
M src/cmd/dist/goc2c.c View 1 2 chunks +19 lines, -0 lines 0 comments Download

Messages

Total messages: 4
rsc
Hello iant, khr (cc: golang-codereviews@googlegroups.com), I'd like you to review this change to https://code.google.com/p/go/
11 years, 2 months ago (2014-03-26 23:13:09 UTC) #1
iant
LGTM
11 years, 2 months ago (2014-03-26 23:38:57 UTC) #2
khr1
LGTM. On Wed, Mar 26, 2014 at 4:13 PM, <rsc@golang.org> wrote: > Reviewers: iant, khr, ...
11 years, 2 months ago (2014-03-26 23:44:00 UTC) #3
rsc
11 years, 2 months ago (2014-03-27 18:05:30 UTC) #4
*** Submitted as https://code.google.com/p/go/source/detail?r=02a3adf6301b ***

cmd/dist: zero output variables on entry to goc2c functions

Zeroing the outputs makes sure that during function calls
in those functions we do not let the garbage collector
treat uninitialized values as pointers.

The garbage collector may still see uninitialized values
if a preemption occurs during the function prologue,
before the zeroing has had a chance to run.

This reduces the number of 'bad pointer' messages when
that runtime check is enabled, but it doesn't fix all of them,
so the check is still disabled.

It will also avoid leaks, although I doubt any of these were
particularly serious.

LGTM=iant, khr
R=iant, khr
CC=golang-codereviews
https://codereview.appspot.com/80850044
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b