On Fri, 2022-04-29 at 23:29 -0700, Zhaoxun Yan wrote:
> Hi Dan!
>
> I did as you told, but go build -race still not functions:
> zxun@zxun-virtual:~/src/race2$ go build
> zxun@zxun-virtual:~/src/race2$ ls
> race2 race.go
> zxun@zxun-virtual:~/src/race2$ go build -race race2
> zxun@zxun-virtual:~/s
Hi Dan!
I did as you told, but go build -race still not functions:
zxun@zxun-virtual:~/src/race2$ go build
zxun@zxun-virtual:~/src/race2$ ls
race2 race.go
zxun@zxun-virtual:~/src/race2$ go build -race race2
zxun@zxun-virtual:~/src/race2$ go run -race race.go
==
WARNING: DATA RAC
Also, Go 1.15 is real old at this point and for these kinds of tests, I
would recommend first updating to the latest stable version (which is Go
1.18).
On Sat, Apr 30, 2022 at 8:22 AM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Fri, 2022-04-29 at 23:18 -0700, Zhaox
On Fri, 2022-04-29 at 23:18 -0700, Zhaoxun Yan wrote:
> And then in that folder you run:
> # go build -race
> Nothing happens, at least in my go1.15
The race detector needs to run to detect data races; it's not a static
analysis tool.
So if you execute the binary that you built with `go build -ra
go build -race
go build -race .
Either would not detect race condition for the whole project (folder).
在2022年4月30日星期六 UTC+8 14:18:55 写道：
> Hi Axel!
>
> My project is in a folder.
> So actually the best way to mimic the situation is to put this file in a
> folder.
> And then in that folder you
Hi Axel!
My project is in a folder.
So actually the best way to mimic the situation is to put this file in a
folder.
And then in that folder you run:
# go build -race
Nothing happens, at least in my go1.15
It did mention the race condition with `go run -race [filename]`
$ go run -race race.go
==
package main
import "time"
import "fmt"
var index int64
func increase(){
index++
}
func read(){
fmt.Println(index)
}
func main(){
go func(N int){
for i:=0; i < N; i++{
increase()
time.Sleep(500 * time.Millisecond)
}
}(5)
time.Sleep(2 * time.Second)
read
On Sat, Apr 30, 2022 at 7:49 AM Zhaoxun Yan wrote:
> Point-time race condition is undetectable by `go build race`.
>
When I run your code using `go run -race`, it reports a data race:
>
> ==
> WARNING: DATA RACE
> Read at 0x005cb580 by main goroutine:
> main.read()
>
point race means I/O on a global might clash at certain point of time.
consider this example:
package main
import "time"
import "fmt"
var index int64
func increase(){
index++
}
func read(){
fmt.Println(index)
}
func main(){
go func(N){
for i:=0; i < N; i++{
increase()
On Fri, Apr 29, 2022 at 4:12 AM Paolo C. wrote:
>
> Rob, thanks a lot.
> I saw the disclaimer, but it appeared a little generic, and since with
> version 18 the av complaining are many, I tought that the issue should be at
> least mentioned on golang site.
> I think this could be a potential dis
*What version of Go are you using (go version)?*
$ go version
go version go1.17.6 linux/amd64
*Does this issue reproduce with the latest release?*
uncertain
*What operating system and processor architecture are you using (go env)?*
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/ro
You're right, it is a Windows issue. I can see that now. I bought up the
issue originally because I was unsure if there was something in addition to
-H=windows or -H=windowsgui that I could make use of. My understanding of
Windows is now exhausted.
The alternative way is to have two binaries fo
This is really a Windows issue, and not related to Go. According to this
very old post:
https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
it is technically possible to do that, but the technique has flaws, foibles
and limitations.
This sound
Rob, thanks a lot.
I saw the disclaimer, but it appeared a little generic, and since with
version 18 the av complaining are many, I tought that the issue should be
at least mentioned on golang site.
I think this could be a potential disincentive to golang usage,
Because if binary distributions,
https://go.dev/doc/faq#virus
On Fri, Apr 29, 2022 at 8:22 PM Paolo C. wrote:
>
> Hello,
> I noticed that if you download golang portable zip for aMD64 and upload the
> go.exe or gofnt.exe to virustotal one av complains.
> If you compile a simple helloword main and upload, 4 or 5 minor av complain
Hello,
I noticed that if you download golang portable zip for aMD64 and upload the
go.exe or gofnt.exe to virustotal one av complains.
If you compile a simple helloword main and upload, 4 or 5 minor av complain.
Anyone has this issue too?
I tested this from many machines, some completely virgin, so
Hello Alex. Thanks for your response.
On Fri, Apr 29, 2022 at 9:34 AM brainman wrote:
> Once windows executable is built, go has no control over how this program
> executes.
>
> When command line program is executed by clicking in explorer window
> Windows automatically starts a new console wind
Hello Stephen,
Windows uses special flag in every executable binary to determine if
executable is a GUI or command line program.
go program uses "-H windows" linker flag to set that flag. See
debug/pe.TestBuildingWindowsGUI for details.
Once windows executable is built, go has no control over
I was having the same problem without TLS but the symptoms are exactly the
same, even the part "The "loop" seems to be interruptable by triggering a
new connection, or by itself after ~1m54s"
I spent 4 days trying to get a consistent way to reproduce it but coulnd't
so I gave up and keept using
I've read through my post again. I'll try to simplify my question:
Where is stdout for a Windows "GUI binary"? (see -H option)
https://pkg.go.dev/cmd/link
If I run from the command prompt I would have thought that stdout is the
console I'm running from but if the executable is a "GUI binary" th
20 matches
Mail list logo
