-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/review/git-codereview: query both remote.origin.pushurl and remote.origin.url to determine the gerrit URL? #9600
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
OlingCat
added a commit
to Go-zh/review
that referenced
this issue
Jan 15, 2015
workaround golang/go#9599, golang/go#9600 patched by @minux Change-Id: Ib544b44436d454c59861a80cefeb94d0111ea0ec Reviewed-on: https://go.minux.info/6 Reviewed-by: Minux <[email protected]>
0xhaven
pushed a commit
to 0xhaven/go
that referenced
this issue
Jan 16, 2015
These signals are used by glibc to broadcast setuid/setgid to all threads and to send pthread cancellations. Unlike other signals, the Go runtime does not intercept these because they must invoke the libc handlers (see issues golang#3871 and golang#6997). However, because 1) these signals may be issued asynchronously by a thread running C code to another thread running Go code and 2) glibc does not set SA_ONSTACK for its handlers, glibc's signal handler may be run on a Go stack. Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so this may overflow the Go stack and corrupt heap (or other stack) data. Fix this by ensuring that these signal handlers have the SA_ONSTACK flag (but not otherwise taking over the handler). This has been a problem since Go 1.1, but it's likely that people haven't encountered it because it only affects setuid/setgid and pthread_cancel. Fixes golang#9600. Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300 Reviewed-on: https://go-review.googlesource.com/1887 Reviewed-by: Ian Lance Taylor <[email protected]>
Why? |
because in certain areas, the google services are blocked, and the
user must use a proxy to access them, so it's more desirable to pull
from github and only use the googlesource only when pushing CLs.
|
Is this still an issue now that codereview.cfg can explicitly specify the gerrit URL? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
remote.origin.pushurl should override remote.origin.url in
this case.
It's reasonable to set only the pushurl to a Gerrit instance,
and still pull from github.
The text was updated successfully, but these errors were encountered: