Re: [go-nuts] go fails to detect a point-time race condition

['Dan Kortschak' via golang-nuts]

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:~/src/race2$ go run -race race.go

Try this:

./race2


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f77bc42928d875b64fafa76da8874e63a4c52d1b.camel%40kortschak.io.

Re: [go-nuts] go fails to detect a point-time race condition

[Zhaoxun Yan]

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 RACE
Read at 0x006489c0 by main goroutine:
  main.read()
  /home/zxun/src/race2/race.go:13 +0x6d
  main.main()
  /home/zxun/src/race2/race.go:24 +0x5d

Previous write at 0x006489c0 by goroutine 7:
  main.increase()
  /home/zxun/src/race2/race.go:9 +0x64
  main.main.func1()
  /home/zxun/src/race2/race.go:19 +0x38

Goroutine 7 (running) created at:
  main.main()
  /home/zxun/src/race2/race.go:17 +0x4f
==
5
Found 1 data race(s)
exit status 66

在2022年4月30日星期六 UTC+8 14:22:26 写道：

> 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 -race` you
> should see the race report.
>
> Dan
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0236f4a2-80d7-4a6b-927b-0024029b5b74n%40googlegroups.com.

Re: [go-nuts] go fails to detect a point-time race condition

['Axel Wagner' via golang-nuts]

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, 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 -race` you
> should see the race report.
>
> Dan
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/cd0f1261a31406e92affdabb66dcdba0348bb4ce.camel%40kortschak.io
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG0Ef1pfK0ef1y2Yq4v_hsoyj0hRQdn9XBC8Aw3PoB5HQ%40mail.gmail.com.

Re: [go-nuts] go fails to detect a point-time race condition

['Dan Kortschak' via golang-nuts]

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 -race` you
should see the race report.

Dan


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cd0f1261a31406e92affdabb66dcdba0348bb4ce.camel%40kortschak.io.

Re: [go-nuts] go fails to detect a point-time race condition

[Zhaoxun Yan]

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 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
> ==
> WARNING: DATA RACE
> Read at 0x006489c0 by main goroutine:
>   main.read()
>   /home/zxun/src/race.go:13 +0x6d
>   main.main()
>   /home/zxun/src/race.go:24 +0x5d
>
> Previous write at 0x006489c0 by goroutine 7:
>   main.increase()
>   /home/zxun/src/race.go:9 +0x64
>   main.main.func1()
>   /home/zxun/src/race.go:19 +0x38
>
>
> Goroutine 7 (running) created at:
>   main.main()
>   /home/zxun/src/race.go:17 +0x4f
> ==
> 5
> Found 1 data race(s)
>
> Do you know the syntax to detect race condition for a whole folder of 
> codes, instead of one file?
> Thanks.
>   Zhaoxun
>
> 在2022年4月30日星期六 UTC+8 14:05:45 写道：
>
>> 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()
>>>   /home/mero/tmp/x/x.go:15 +0xab
>>>   main.main()
>>>   /home/mero/tmp/x/x.go:26 +0x99
>>
>>
>>> Previous write at 0x005cb580 by goroutine 7:
>>>   main.increase()
>>>   /home/mero/tmp/x/x.go:11 +0x54
>>>   main.main.func1()
>>>   /home/mero/tmp/x/x.go:21 +0x30
>>>   main.main.func2()
>>>   /home/mero/tmp/x/x.go:24 +0x3e
>>
>>
>>> Goroutine 7 (running) created at:
>>>   main.main()
>>>   /home/mero/tmp/x/x.go:19 +0x8e
>>> ==
>>> 4
>>> Found 1 data race(s)
>>> exit status 66
>>
>>  
>> Go version is
>> go version go1.18 linux/amd64
>>
>> So, I don't really understand why you think the race detector can't 
>> detect that race.
>>
>>
>> Thanks to Rust on emphasizing the single entrance to any variable,  I 
>>> realized this possibility and have to add sync.Mutex to both functions. 
>>>
>>> What is your opinion?
>>>  
>>> Best Regards,
>>>   Zhaoxun
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/5c6ae730-36a7-46ce-abb9-ea8d24da601bn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/97623349-0132-4fa3-b608-ff1342b02372n%40googlegroups.com.

Re: [go-nuts] go fails to detect a point-time race condition

[Zhaoxun Yan]

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
==
WARNING: DATA RACE
Read at 0x006489c0 by main goroutine:
  main.read()
  /home/zxun/src/race.go:13 +0x6d
  main.main()
  /home/zxun/src/race.go:24 +0x5d

Previous write at 0x006489c0 by goroutine 7:
  main.increase()
  /home/zxun/src/race.go:9 +0x64
  main.main.func1()
  /home/zxun/src/race.go:19 +0x38

Goroutine 7 (running) created at:
  main.main()
  /home/zxun/src/race.go:17 +0x4f
==
5
Found 1 data race(s)

Do you know the syntax to detect race condition for a whole folder of 
codes, instead of one file?
Thanks.
  Zhaoxun

在2022年4月30日星期六 UTC+8 14:05:45 写道：

> 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()
>>   /home/mero/tmp/x/x.go:15 +0xab
>>   main.main()
>>   /home/mero/tmp/x/x.go:26 +0x99
>
>
>> Previous write at 0x005cb580 by goroutine 7:
>>   main.increase()
>>   /home/mero/tmp/x/x.go:11 +0x54
>>   main.main.func1()
>>   /home/mero/tmp/x/x.go:21 +0x30
>>   main.main.func2()
>>   /home/mero/tmp/x/x.go:24 +0x3e
>
>
>> Goroutine 7 (running) created at:
>>   main.main()
>>   /home/mero/tmp/x/x.go:19 +0x8e
>> ==
>> 4
>> Found 1 data race(s)
>> exit status 66
>
>  
> Go version is
> go version go1.18 linux/amd64
>
> So, I don't really understand why you think the race detector can't detect 
> that race.
>
>
> Thanks to Rust on emphasizing the single entrance to any variable,  I 
>> realized this possibility and have to add sync.Mutex to both functions. 
>>
>> What is your opinion?
>>  
>> Best Regards,
>>   Zhaoxun
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/5c6ae730-36a7-46ce-abb9-ea8d24da601bn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/98c29132-d7d2-42f1-a219-e5bb558b67ban%40googlegroups.com.

[go-nuts] Re: go fails to detect a point-time race condition

[Zhaoxun Yan]

 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()
}


在2022年4月30日星期六 UTC+8 13:49:11 写道：

> 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()
> time.Sleep(500 * time.Millisecond)
>  }
>  }(5)
>time.Sleep(2 * time.Second)
>read()
> }
>
> Obviously, the increase function is writing the global variable 'index' 
> while the read is reading it. It is highly unlikely that they could 
> function at the same time, but not impossible.  Further, if the increase 
> function takes longer time to manipulate the global, such as an array which 
> might enlarge itself, and reading during the changing of the global is 
> dangerous. 
>
> The code in my project has a little variation -  the writing of the 
> variable is controlled by crontask of "github.com/robfig/cron". However, 
> the essence is the same. Point-time race condition is undetectable by `go 
> build race`. Thanks to Rust on emphasizing the single entrance to any 
> variable,  I realized this possibility and have to add sync.Mutex to both 
> functions. 
>
> What is your opinion?
>  
> Best Regards,
>   Zhaoxun
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d6667b87-3ef9-4cff-b63d-aaef8b035ea3n%40googlegroups.com.

Re: [go-nuts] go fails to detect a point-time race condition

['Axel Wagner' via golang-nuts]

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()
>   /home/mero/tmp/x/x.go:15 +0xab
>   main.main()
>   /home/mero/tmp/x/x.go:26 +0x99


> Previous write at 0x005cb580 by goroutine 7:
>   main.increase()
>   /home/mero/tmp/x/x.go:11 +0x54
>   main.main.func1()
>   /home/mero/tmp/x/x.go:21 +0x30
>   main.main.func2()
>   /home/mero/tmp/x/x.go:24 +0x3e


> Goroutine 7 (running) created at:
>   main.main()
>   /home/mero/tmp/x/x.go:19 +0x8e
> ==
> 4
> Found 1 data race(s)
> exit status 66


Go version is
go version go1.18 linux/amd64

So, I don't really understand why you think the race detector can't detect
that race.


Thanks to Rust on emphasizing the single entrance to any variable,  I
> realized this possibility and have to add sync.Mutex to both functions.
>
> What is your opinion?
>
> Best Regards,
>   Zhaoxun
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5c6ae730-36a7-46ce-abb9-ea8d24da601bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEBkjOmx0ZBCUEkETq7iM7_9vs0GQt3LjbA%2BqR6g0%2B%3DUQ%40mail.gmail.com.

[go-nuts] go fails to detect a point-time race condition

[Zhaoxun Yan]

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()
time.Sleep(500 * time.Millisecond)
 }
 }(5)
   time.Sleep(2 * time.Second)
   read()
}

Obviously, the increase function is writing the global variable 'index' 
while the read is reading it. It is highly unlikely that they could 
function at the same time, but not impossible.  Further, if the increase 
function takes longer time to manipulate the global, such as an array which 
might enlarge itself, and reading during the changing of the global is 
dangerous. 

The code in my project has a little variation -  the writing of the 
variable is controlled by crontask of "github.com/robfig/cron". However, 
the essence is the same. Point-time race condition is undetectable by `go 
build race`. Thanks to Rust on emphasizing the single entrance to any 
variable,  I realized this possibility and have to add sync.Mutex to both 
functions. 

What is your opinion?
 
Best Regards,
  Zhaoxun

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5c6ae730-36a7-46ce-abb9-ea8d24da601bn%40googlegroups.com.

Re: [go-nuts] Golang and virustotal

[Ian Lance Taylor]

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 disincentive to golang usage,
> Because if binary distributions, that can be sometimes necessary in 
> production, are seen as infected,
> even if by false positive, this is for sure a deterrent.
> Don't you think?

I'm not sure quite what you are suggesting, but as the FAQ suggests
this happens with every new Go release.  And of course it is mentioned
on the Go site: in the FAQ.  There is very little that the Go project
can do about this problem.

Ian



> On Friday, April 29, 2022 at 12:34:16 PM UTC+2 Rob 'Commander' Pike wrote:
>>
>> 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.
>> > Anyone has this issue too?
>> > I tested this from many machines, some completely virgin, so it should not 
>> > be my environment.
>> > Thanks
>> > Paolo
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to golang-nuts...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/9cc862fa-d61d-46a4-a86f-0a63e4fcc660n%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/18a9f0cd-d038-42cb-9901-5e987bd88062n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXh70gbJ%2BPb3cw-vVjpg5AdRMjqQvqdr02F4QwWd98k5A%40mail.gmail.com.

[go-nuts] GO program's memory footprint is confusing

[garenchan]

*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="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY=""
GOROOT="/home/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/home/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.6"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/demo/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build4023324410=/tmp/go-build 
-gno-record-gcc-switches"

*What did you do?*

I encountered a memory problem with the GO program, see here for 
details.(https://stackoverflow.com/questions/71994609/memory-footprint-of-the-same-program-varies-greatly-in-two-similar-environments)

In order to simplify the analysis, I wrote a simple program to test.

```go
package main

import (
"time"
)

func main() {
time.Sleep(60*time.Second)
}
```


   - I compiled it into binary file on a linux host `host1` with kernel 
   4.18. Then I run it on `host1` and the process takes up close to 5MB RSS.
   - I then copy the binary file to another host `host2` with kernel 4.18. 
   I also ran it on `host2`, but this time the process took up less than 1MB 
   RSS.
   - I repeated the test many times and observed the same thing.


```
$ uname -a
Linux host1 4.18.0 #1 SMP Wed Nov 10 20:46:19 CST 2021 x86_64 x86_64 x86_64 
GNU/Linux

$ uname -a
Linux host2 4.18.0 #1 SMP Fri May 8 10:59:10 UTC 2021 x86_64 x86_64 x86_64 
GNU/Linux
```

Why is memory footprint of the same program in similar environments so 
different? What factors might be contributing to this problem?

*What did you expect to see?*

I would expect to see the memory footprint of the same program in similar 
environments be close. I look forward to your answers. Thank you very much.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/daba9d60-7c45-45f3-83c8-afc2471841c6n%40googlegroups.com.
$ cat /proc/1002592/smaps
0040-00458000 r-xp  fd:02 139
/home/demo/demo
Size:352 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss: 352 kB
Pss: 352 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean:   352 kB
Private_Dirty: 0 kB
Referenced:  352 kB
Anonymous: 0 kB
LazyFree:  0 kB
AnonHugePages: 0 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:0 kB
VmFlags: rd ex mr mw me dw sd
00458000-004c r--p 00058000 fd:02 139
/home/demo/demo
Size:416 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss: 416 kB
Pss: 416 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean:   416 kB
Private_Dirty: 0 kB
Referenced:  416 kB
Anonymous: 0 kB
LazyFree:  0 kB
AnonHugePages: 0 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:0 kB
VmFlags: rd mr mw me dw sd
004c-004c5000 rw-p 000c fd:02 139
/home/demo/demo
Size: 20 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss:  20 kB
Pss:  20 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean: 4 kB
Private_Dirty:16 kB
Referenced:   20 kB
Anonymous:16 kB
LazyFree:  0 kB
AnonHugePages: 0 kB
ShmemPmdMapped:0 kB
Shared_Hugetlb:0 kB
Private_Hugetlb:   0 kB
Swap:  0 kB
SwapPss:   0 kB
Locked:0 kB
VmFlags: rd wr mr mw me dw ac sd
004c5000-004f8000 rw-p  00:00 0
Size:204 kB
KernelPageSize:4 kB
MMUPageSize:   4 kB
Rss:  52 kB
Pss:  52 kB
Shared_Clean:  0 kB
Shared_Dirty:  0 kB
Private_Clean: 0 kB
Private_Dirty:52 kB
Referenced:   52 kB
Anonymous:52 kB
La

Re: [go-nuts] Re: Windows Binaries and stdout

[stephen.t....@gmail.com]

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 for the Windows version.
On Friday, April 29, 2022 at 1:22:45 PM UTC+1 jake...@gmail.com wrote:

> 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 sounds like a 'rabbit hole' to me. I would suggest going back to what 
> you actually want to accomplish, and thinking about alternative ways of 
> achieving it.  
>
> On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com 
> wrote:
>
>> 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 window and the console is used 
>>> for stdout output (I did not check that). If command line program is 
>>> started from existing cmd.exe console, new process just uses the same 
>>> console.
>>>
>>> When you click on GUI executable in Windows explorer, no console windows 
>>> is started (I did not check that). Same for GUI executable started from 
>>> cmd.exe console - new GUI process is not attached to parent console (I did 
>>> not check that).
>>>
>>
>> Right. So I have a GUI executable that might be launched from a console 
>> but it will not be "attached" to that parent console.
>>
>> Is there a way to attach the GUI executable to the parent console, 
>> perhaps using a Windows system call?
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c8b4a749-3c1a-4823-b37b-8573165accafn%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[jake...@gmail.com]

 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 sounds like a 'rabbit hole' to me. I would suggest going back to what 
you actually want to accomplish, and thinking about alternative ways of 
achieving it.  

On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com wrote:

> 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 window and the console is used 
>> for stdout output (I did not check that). If command line program is 
>> started from existing cmd.exe console, new process just uses the same 
>> console.
>>
>> When you click on GUI executable in Windows explorer, no console windows 
>> is started (I did not check that). Same for GUI executable started from 
>> cmd.exe console - new GUI process is not attached to parent console (I did 
>> not check that).
>>
>
> Right. So I have a GUI executable that might be launched from a console 
> but it will not be "attached" to that parent console.
>
> Is there a way to attach the GUI executable to the parent console, perhaps 
> using a Windows system call?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a20dab65-79a4-4111-9cd4-44450109ba4cn%40googlegroups.com.

Re: [go-nuts] Golang and virustotal

[Paolo C.]

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, that can be sometimes necessary in 
production, are seen as infected,
even if by false positive, this is for sure a deterrent.
Don't you think?
Paolo
On Friday, April 29, 2022 at 12:34:16 PM UTC+2 Rob 'Commander' Pike wrote:

> 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.
> > Anyone has this issue too?
> > I tested this from many machines, some completely virgin, so it should 
> not be my environment.
> > Thanks
> > Paolo
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9cc862fa-d61d-46a4-a86f-0a63e4fcc660n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/18a9f0cd-d038-42cb-9901-5e987bd88062n%40googlegroups.com.

Re: [go-nuts] Golang and virustotal

[Rob Pike]

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.
> Anyone has this issue too?
> I tested this from many machines, some completely virgin, so it should not be 
> my environment.
> Thanks
> Paolo
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9cc862fa-d61d-46a4-a86f-0a63e4fcc660n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZQqf7pFvpxEDzQzrCW3-Oh7XTnGb_EHUUy1m0BH94sjvw%40mail.gmail.com.

[go-nuts] Golang and virustotal

[Paolo C.]

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 it should not 
be my environment.
Thanks
Paolo

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9cc862fa-d61d-46a4-a86f-0a63e4fcc660n%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[Stephen Illingworth]

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 window and the console is used
> for stdout output (I did not check that). If command line program is
> started from existing cmd.exe console, new process just uses the same
> console.
>
> When you click on GUI executable in Windows explorer, no console windows
> is started (I did not check that). Same for GUI executable started from
> cmd.exe console - new GUI process is not attached to parent console (I did
> not check that).
>

Right. So I have a GUI executable that might be launched from a console but
it will not be "attached" to that parent console.

Is there a way to attach the GUI executable to the parent console, perhaps
using a Windows system call?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPmHGLNS1QMVKqHrjoLskEy1SFhCYXc_Ra%2BnEiysHoA%3DV7Fw2A%40mail.gmail.com.

[go-nuts] Re: Windows Binaries and stdout

[brainman]

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 how this program 
executes.

When command line program is executed by clicking in explorer window 
Windows automatically starts a new console window and the console is used 
for stdout output (I did not check that). If command line program is 
started from existing cmd.exe console, new process just uses the same 
console.

When you click on GUI executable in Windows explorer, no console windows is 
started (I did not check that). Same for GUI executable started from 
cmd.exe console - new GUI process is not attached to parent console (I did 
not check that).

If you want GUI with console window, you have to create console window in 
your code.

Alex 


On Friday, 29 April 2022 at 17:34:29 UTC+10 stephen.t@gmail.com wrote:

> 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" this does 
> not seem to be the case.
>
> If I create a "console binary" then stdout is indeed the console I'm 
> running from. But this means that when I run the binary from a desktop 
> icon, Windows will open up a console window, even if there is nothing to 
> output.
>
> Context for this is an application that has a GUI by default and 
> optionally, a terminal interface (using stdout).
>
> I'm not a Windows person and I'm sorry if this is a dumb question but this 
> is a complete mystery to me. Do I really need two separate binaries?
>
> On Monday, April 25, 2022 at 9:48:18 AM UTC+1 stephen.t@gmail.com 
> wrote:
>
>> Hello,
>>
>> I'm cross-compiling my Go application to Windows and I'm having 
>> difficulty understanding how Windows interacts with stdout.
>>
>> I'm compiling the Windows binary with the "-H=windowsgui" LD flag. This 
>> works great but I've found that the program will never print to stdout, 
>> even if the program is launched from the command prompt
>>
>> The alternative LD flag "-H=windows" will print to stdout but with the 
>> downside that a "DOS" window will always open, even if the program is 
>> launched from the desktop icon and even when there is no stdout activity.
>>
>> For the most part, compiling with "-H=windowsgui" is fine but 
>> occasionally it's useful for users to run with the program's -log option, 
>> which outputs to stdout.
>>
>> My solution for now is to have two Windows binaries. One for regular use 
>> and another for diagnosing problems. This is a poor solution.
>>
>> What I require is a single binary that can:
>>
>> 1) Launch from the desktop icon without a "DOS" window opening.
>> 2) To launch from a command prompt and for stdout to be echoed to the 
>> command prompt window.
>>
>> Is there a Go compilation option that I've missed. Or is the solution 
>> more complex?
>>
>> Regards
>>
>> Stephen
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ea7da703-d5e6-464e-add7-f741cdf12464n%40googlegroups.com.

[go-nuts] Re: Constant CPU usage on an idle HTTP server from Go 1.17

[Santiago Corredoira]

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 Go 1.16. I am glad that it may be fixed in 
1.19. 

Thank you for pointing it out!
El jueves, 28 de abril de 2022 a las 18:23:25 UTC+2, klau...@gmail.com 
escribió:

> This "smells" a lot like https://github.com/golang/go/issues/51654 - 
> though the repro is with TLS.
>
> This is very disruptive for us (MinIO) as well, seeing this at several 
> customers. Obviously downgrading to Go 1.16.6 is less than optimal for us.
>
> /Klaus
>
> On Tuesday, 12 April 2022 at 14:55:41 UTC+2 Brian Candler wrote:
>
>> Correct: "go run" builds a binary and then fork/execs the binary it has 
>> built, to run it.
>>
>> On Tuesday, 12 April 2022 at 08:19:38 UTC+1 scorr...@gmail.com wrote:
>>
>>> By the way, the difference that I thought I saw between go run and the 
>>> compiled version was because the pid of the process to look at in the below 
>>> example should be 63668, the tmp file, not 63548, the go run call.
>>>
>>> $ ps aux | grep test
>>> bill   63548  0.2  0.1 2044984 17588 pts/0   Sl+  09:15   0:00 go 
>>> run test.go
>>> bill   63668  155  0.0 1891292 12140 pts/0   Sl+  09:15   1:52 
>>> /tmp/go-build910547164/b001/exe/test
>>> bill   63750  0.0  0.0  11564   652 pts/1S+   09:16   0:00 grep 
>>> --color=auto test
>>>
>>> El martes, 12 de abril de 2022 a las 9:13:41 UTC+2, Santiago Corredoira 
>>> escribió:
>>>
 Hi, yes, all about the toy program is the same. It was an attempt to 
 get to a minimal example that anyone can reproduce so I could ask for 
 help. 
 The real problem is with a larger program where I get this 100% CPU usages 
 ramdomly when the server is idle.

 I was thinking and with the basic example the nanosleep calls maybe is 
 not the scheduller signaling itself because:

  - GODEBUG=asyncpreemptoff=1 has no effect
  - It doesn't happen with Go 1.16
  - It is random. If it where the normal working of the scheduler, 
 wouldn't it be predictable?


 El martes, 12 de abril de 2022 a las 8:59:06 UTC+2, Brian Candler 
 escribió:

> At the start of the thread, you said "if I compile and run this simple 
> program ..."
>
> Does the problem no longer reproduce with that?
>
> On Monday, 11 April 2022 at 22:59:55 UTC+1 scorr...@gmail.com wrote:
>
>> I tried with a more complex application and already got constant 100% 
>> CPU usage twice. 
>>
>> When I attach strace I see the same as with the minimal demo but with 
>> much more frecuency:
>>
>> [pid 42659] 23:36:49.035120 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035133 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>> [pid 42659] 23:36:49.035145 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035158 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>> [pid 42659] 23:36:49.035170 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035182 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>> [pid 42659] 23:36:49.035195 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035207 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>> [pid 42659] 23:36:49.035219 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035232 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>> [pid 42659] 23:36:49.035244 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035257 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>> [pid 42659] 23:36:49.035269 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035281 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>> [pid 42659] 23:36:49.035293 epoll_pwait(3, [], 128, 0, NULL, 
>> 140341803388040) = 0
>> [pid 42659] 23:36:49.035306 epoll_pwait(3, [], 128, 0, NULL, 
>> 18704162493558) = 0
>>
>> The program is too large to post here. I have tested it with go race 
>> and it doesn't run into any problem. Any idea of what to look for?
>>
>> Thank you!
>>
>> El lunes, 11 de abril de 2022 a las 17:08:40 UTC+2, Santiago 
>> Corredoira escribió:
>>
>>> I tried with the stripped tmp version of "go run" and after a while 
>>> I was able to reproduce it too. It definitely took me more time but 
>>> probably is just random. 
>>>
>>> I tried "$ GODEBUG=asyncpreemptoff=1 ./test" and I kept seeing the 
>>> the calls every 10ms. Is this expected to happen?
>>>
>>

[go-nuts] Re: Windows Binaries and stdout

[stephen.t....@gmail.com]

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" this does 
not seem to be the case.

If I create a "console binary" then stdout is indeed the console I'm 
running from. But this means that when I run the binary from a desktop 
icon, Windows will open up a console window, even if there is nothing to 
output.

Context for this is an application that has a GUI by default and 
optionally, a terminal interface (using stdout).

I'm not a Windows person and I'm sorry if this is a dumb question but this 
is a complete mystery to me. Do I really need two separate binaries?

On Monday, April 25, 2022 at 9:48:18 AM UTC+1 stephen.t@gmail.com wrote:

> Hello,
>
> I'm cross-compiling my Go application to Windows and I'm having difficulty 
> understanding how Windows interacts with stdout.
>
> I'm compiling the Windows binary with the "-H=windowsgui" LD flag. This 
> works great but I've found that the program will never print to stdout, 
> even if the program is launched from the command prompt
>
> The alternative LD flag "-H=windows" will print to stdout but with the 
> downside that a "DOS" window will always open, even if the program is 
> launched from the desktop icon and even when there is no stdout activity.
>
> For the most part, compiling with "-H=windowsgui" is fine but occasionally 
> it's useful for users to run with the program's -log option, which outputs 
> to stdout.
>
> My solution for now is to have two Windows binaries. One for regular use 
> and another for diagnosing problems. This is a poor solution.
>
> What I require is a single binary that can:
>
> 1) Launch from the desktop icon without a "DOS" window opening.
> 2) To launch from a command prompt and for stdout to be echoed to the 
> command prompt window.
>
> Is there a Go compilation option that I've missed. Or is the solution more 
> complex?
>
> Regards
>
> Stephen
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/84d95a6c-441e-4b83-b1e2-abc59838bf7cn%40googlegroups.com.