profile
viewpoint

alexbrainman/odbc 192

odbc driver written in go

alexbrainman/printer 111

Windows printing

alexbrainman/sspi 46

Windows SSPI

alexbrainman/gowingui 10

Small Windows GUI app written in Go

alexbrainman/ps 3

Windows jobs

alexbrainman/pc 1

Windows performance counters (MANY THINGS ARE BROKEN)

alexbrainman/delve 0

Delve is a debugger for the Go programming language.

issue commentgolang/go

os: os.Args parsing is non-equivalent to Python's sys.argv commandLineToArgv on Windows

Windows provides two functions that return command line input, GetCommandLineW and __p___wargv:

There are more than two ways to encode parameters on Windows. You provided the ref yourself

http://daviddeley.com/autohotkey/parameters/parameters.htm#WIN

So Go must use GetCommandLineW/CommandLineToArgvW for this purpose:

Go does uses GetCommandLineW. But we don't use CommandLineToArgvW, we have written pure Go command line parser similar to CommandLineToArgvW.

That is unfortunate because the code for __p___wargv is different from the code for CommandLineToArgvW

Yes that parser / rules are different. But I don't see why it is unfortunately. Either parser is fine.

What is more important, in my opinion, that rules don't change from version to version. Go users can keep compiling their programs with new version of Go, and their executable will behave the same way as before.

Alex

nu8

comment created time in 5 hours

issue commentgolang/go

runtime: exit status 0xC0000005 from test process on windows-amd64-longtest builder

Another thing that caught my attention is that when memory mapped file are used, it is possible for Windows exception to be raised during simple memory access.

https://docs.microsoft.com/en-us/windows/win32/memory/reading-and-writing-from-a-file-view

If something like that happens, Go exception handler would be called. But I expect to see Go stack trace.

Alex

bcmills

comment created time in 7 hours

issue commentgolang/go

runtime: exit status 0xC0000005 from test process on windows-amd64-longtest builder

I don't use windbg or crash dumps, so don't assume I am an expert. @zx2c4 is your man.

I'm trying to get a user crash dump captured so I can windbg it, but I'm not sure if that's even a reasonable thing to do ...

From what I understand, you will be able to see process state at the time of the crash. That assumes that the program exists due to Windows exception. And you will need the executable file itself too to use with your crash dump.

I am not sure what that buys you. You won't be able to use any Go symbols - windbg does not understand DWARF. You will see all Windows DLL functions.

... and I'm just not getting any files in my crash dump directory.

Assuming our program raises Windows exception, you need to adjust Go runtime to let that exception out of Go process. Currently Go does not let exceptions out of the process. Go prints stack trace, if it cannot handle exception.

There is #20498 to adjust Go to allow for exceptions to be handled externally.

https://go-review.googlesource.com/c/go/+/195577/ is latest attempt to solve that problem.

Once you adjust runtime, then you will need to configure your system to handle exception as crash dump. I don't know how to do it, so your guess is as good as mine. Perhaps your instructions above are fine.

Hopefully it is any help.

Alex

bcmills

comment created time in 9 hours

issue commentgolang/go

os: Symlink on Windows with a to-be-created directory path silently creates a link of the wrong type

@bcmills

I din't think we are making progress in our discussion, because we are repeating ourselves. I will just sum up my position here and let others decide.

I agree there is a problem here, that Go can create symlink of wrong type. You propose to solve this problem by verifying target file type during symlink creation.

I don't see how your solution is an improvement.

Your change will break perfectly valid Go programs, like https://play.golang.org/p/APh87cnpUgC

You change will make some programs - https://play.golang.org/p/APh87cnpUgC - behave differently on different OS.

Your change will still allow for symlinks of wrong type to exists. The program cannot control what happens to the target file. So, if someone removes abc directory, and creates abc file after symlink to abc was created, the symlink will still be broken.

I do not know what you are building, but maybe you should use hard links instead. Hard links won't work without targets. That is what you want. Don't you?

Please bear in mind that among our Gopher values is to “be charitable”. If you don't know what I am building, then ask — or read the issues and CLs to which I have already referred to see for yourself what they are doing.

I did ask here. I am trying to understand why you created an issue in the first place. I don't see how I offended you or anyone else here. If I did offend, I apologize.

You said

Symlink assumes that it is a file rather than reporting the error to the caller go/src/os/file_windows.go

Lines 337 to 338 in 567556d

fi, err := Stat(destpath) isdir := err == nil && fi.IsDir() That assumption seems like a mistake. If a Windows user needs to create a symlink to a not-yet-existing file or directory on Windows, they should be made aware that the call is missing essential information (the destination type), and can then make an explicit choice to use

The That assumption seems like a mistake is an opinion, and not fact.

I also looked at CL 234737 and issue 38772. These weren't helpful either.

What I want is to be able to more easily debug failures in programs that unintentionally create symbolic links of the incorrect type, such as golang.org/x/tools/go/packages/packagestest prior to CL 234112.

So you want to make your change to be able to debug easier. Fair enough. But see my points above about downsides of your change.

Alex

bcmills

comment created time in 13 hours

issue commentgolang/go

runtime: exit status 0xC0000005 from test process on windows-amd64-longtest builder

Do we know which process is failing?

I don't think we know.

We can see "exit status 0xC0000005" in the error output. The message is parent process reporting child process failure. I wonder, if we could add debug code to the parent process to print more information there. Maybe we could include command name and argument list there. Extend whatever os package structures are required to print that information in exit string. Just for debugging this.

Sorry I don't have time to try it now.

Alex

bcmills

comment created time in 2 days

issue commentgolang/go

os: os.Args parsing is non-equivalent to Python's sys.argv commandLineToArgv on Windows

Not sure why that was chosen. @alexbrainman may know, he wrote the code.

We designed Go command line parser to work exactly like CommandLineToArgv Windows API

https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw

Originally Go os package called CommandLineToArgv Windows API directly. But then we discovered that Shell32.dll (that contains the API) takes too long to load. So we replaced the DLL loading with pure Go code.

But we still test that our parser produces the same result as CommandLineToArgv Windows API. You can see it in os.TestCmdArgs. In fact you can try and add whatever string you like to the test, and, if the test pass, you know, the string is parsed like CommandLineToArgv Windows API.

I think it would make sense to update the parsing code.

I don't see why it makes sense to update parsing code. Can you explain more.

Thank you.

Alex

nu8

comment created time in 2 days

issue commentgolang/go

os: Symlink on Windows with a to-be-created directory path silently creates a link of the wrong type

@bcmills

But that is not what symlinks created with CreateSymbolicLink API do. For example, they could point to a file on another volume / drive, and that drive might not be mounted all the time. It is obviously fine for symlinks point to non-existing file / directory.

Yes. But they still need to point to the correct type of non-existing target — ...

The target type can change after symlink is created. What do you propose to do about that?

The target can get deleted after symlink is created. What do you propose to do about that?

See this test https://play.golang.org/p/APh87cnpUgC - it works fine at this moment on both Linux and Windows. It will fail on Windows after your proposed change.

Symlinks currently work independent of their target - that is how they are designed. You propose to break that design to fix file / directory flag on Windows. I say it is not worth it. Linux has the same problem where symlink stops working when target is removed / does not exist. That is what everyone expects. I consider file / directory flag bug to be in the same boat as symlink pointing to non-existing target.

Did you read https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions

I don't think that document is relevant to this issue..? This issue is specifically about symbolic links, not junctions or hard-links. (I haven't checked whether an analogous bug exists for os.Link, but I have no reason to suspect that it would.)

I provided this document to point to hard links description. I do not know what you are building, but maybe you should use hard links instead. Hard links won't work without targets. That is what you want. Don't you?

Thinking about this some more: even if we decide to retain the current os.Symlink behavior for nonexistent targets, I think it is important that we change it to propagate Stat errors for which os.IsNotExist returns false.

Otherwise, it would be possible to successfully create a directory on a network share, then lose the connection to that share, then “successfully” create a symlink to that directory, and end up with a symlink that is still permanently broken once the share is reconnected.

This is already happening now. Imagine you create symlink to a file, and then replace file with directory of the same name. We cannot do anything about it. Why should we worry about symlinks to be correct at the moment of their creation?

Alex

bcmills

comment created time in 2 days

issue commentgolang/go

os: Symlink on Windows with a to-be-created directory path silently creates a link of the wrong type

@bcmills

I don't see why we should second guess API intentions and fail os.Symlink.

The API of os.Symlink is narrower than CreateSymbolicLink. When the link target does not exist, CreateSymbolicLink receives an extra bit of explicit information that os.Symlink lacks: the intended type of the link target, passed as a flag to CreateSymbolicLink but not available to os.Symlink.

But that is not what symlinks created with CreateSymbolicLink API do. For example, they could point to a file on another volume / drive, and that drive might not be mounted all the time. It is obviously fine for symlinks point to non-existing file / directory.

Did you read

https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions

?

Alex

bcmills

comment created time in 5 days

issue commentgolang/go

net: cannot send multicast using ListenPacket("udp4", "") on Windows 10 (1909)

@alexbrainman The listed tests are skipped for Windows because the function used (fd *netFD) dup() is not implemented. It seems that there is no relevant test of UDP on Windows.

Fair enough. Thank you for explaining.

Alex

filimonic

comment created time in 8 days

issue commentgolang/go

os: Symlink on Windows with a to-be-created directory path silently creates a link of the wrong type

That assumption seems like a mistake.

I don't see why it is mistake.

If a Windows user needs to create a symlink to a not-yet-existing file or directory on Windows, they should be made aware that the call is missing essential information (the destination type),

Sure. It is nice to have this information. But I don't see how you can provide information about the file / directory that has not been created yet.

and can then make an explicit choice to use golang.org/x/sys/windows.CreateSymbolicLink instead of os.Syscall if they are able to supply the missing information.

I don't see what you are proposing here. Please try again.

I think we should change os.Symlink at the beginning of the Go 1.16 cycle so that it propagates the Stat error instead of implicitly assuming that the destination is a file.

It looks like Windows CreateSymbolicLink API succeeds without target file or directory, I don't see why we should second guess API intentions and fail os.Symlink.

/cc @mattn since he loves symlinks

Alex

bcmills

comment created time in 10 days

issue commentgolang/go

runtime: error error 3221226356 (C0000374) in CGO module in Windows

cc @alexbrainman probably knows if this is a supported configuration on windows.

I don't know, if this is a supported configuration or not.

I don't use Cgo in my Windows programs.

Alex

bsrdjan

comment created time in 10 days

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

@andybons this issue is about broken os package. It should not be labeled as tools. And we should fix the issue before releasing go 1.15, because we broke this code in go 1.14.

Thank you.

Alex

cmMcKeevek

comment created time in 12 days

issue commentgolang/go

crypto/rand: Currently using deprecated API for random number generation on Windows

@alexbrainman hello, when is the deadline for one of the changes to merge with respect to the golang 1.15 release cycle?

I think deadline for 1.15 is already past. Perhaps it is OK to finish existing CL. I do not know. @ianlancetaylor asked on PS3 of https://go-review.googlesource.com/c/go/+/210057/

Filippo, Jason, any interest in trying to get this into 1.15? Needs to be soon.

Perhaps it is OK to resolve this issue for 1.15.

on Monday, i can try asking someone from the Microsoft cryptography team to add an up-to-date comment here to facilitate your mediation.

I am not the one who will decide. I don't consider myself a security expert. I will let others decide.

Alex

randomvariable

comment created time in 22 days

issue commentgolang/go

crypto/rand: Currently using deprecated API for random number generation on Windows

RtlGenRandom

Thank you, Jason. (You can be pretty good salesmen!)

Anyone wants to say few good words about BCryptGenRandom? Apart from this page

https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom

vaguely recommends it as a replacement for CryptGenRandom (which we use now).

Alex

randomvariable

comment created time in 22 days

IssuesEvent

issue commentgolang/go

crypto/rand: Currently using deprecated API for random number generation on Windows

We have 2 alternative CLs to replace CryptGenRandom

CL 210057 uses RtlGenRandom (aka advapi32.SystemFunction036)

CL 232860 uses BCryptGenRandom

Lets decide here which one to pick. I don't have preference. What about others?

Thank you.

Alex

randomvariable

comment created time in 22 days

issue closedgolang/go

crypto/rand: Currently using deprecated API for random number generation on Windows

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

N/A

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Any release of Windows supported by Microsoft

What did you do?

Reviewing cryptographic protocols for a downstream project

What did you expect to see?

Use of a modern Windows API to retrieve entropy, namely BCryptGenRandom from CryptoNG, which is compliant with CTR_DRBG from NIST SP800-90.

What did you see instead?

Go calls CryptGenRandom from a deprecated API. The algorithm is not fully documented and is only known in part.

closed time in 22 days

randomvariable

issue commentgolang/go

os: investigate why Stat(non-existent-file) on Windows with builders returns error prefixed with "CreateFile"

CreateFile is the WinApi name for Posix open(2). It only creates filesystem entries in certain cases.

Correct. CreateFile Windows API is generally used to open files

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea

There is no open syscall on Windows. It will be confusing, if we just blindly replace CreateFile with open string. For example, the errors you see relate directly to CreateFile API, and have different meaning when returned for different APIs.

Alex

odeke-em

comment created time in 22 days

issue commentgolang/go

runtime: exit status 0xC0000005 from test process on windows-amd64-longtest builder

I'm wondering if it's possible that when memory allocation fails while calling into Windows, such as when starting a new thread, that this exit status might occur.

The way threads are created by Go runtime is by calling CreateThread Windows API (in runtime.newosproc). So, if CreateThread fails and returns an error, it should be printed by runtime. Same when Go allocates memory.

I also considered bug in how we implemented exception handling. Windows exception handling on 386 is very different from amd64. The fact that both 368 and amd64 builders fail with this error points that the problem is not exception handler related.

Maybe crashing program does print at least some stack trace, but its output is lost by the parent process. Maybe stdout is not read for some reason by parent process. The fact that exit code is 0xc0000005 does not supports that theory, but ...

Alex

bcmills

comment created time in a month

issue commentgolang/go

x/net/icmp: listen icmp in Windows not work properly

the problem isn't icmp, problem 1: in windows, socket need set SIO_RCVALL flag to monitor raw sock (linux didn't). problem 2: in windows, socket bind on 0.0.0.0 canot set SIO_RCVALL flag.

@lochv I know nothing about these things. If you want to fix the code, here is how to contribute

https://golang.org/doc/contribute.html

Maybe altogether we can fix the code.

Thank you.

Alex

lochv

comment created time in a month

issue commentgolang/go

cmd/go: -buildmode=c-shared without specifying output file fails does not add .dll extension on Windows and .so extension on linux

What do you mean with you cannot rename output files?

c:\Users\Alex\dev\src\issue\go\38244>dir
 Volume in drive C has no label.
 Volume Serial Number is 9012-A870

 Directory of c:\Users\Alex\dev\src\issue\go\38244

03/05/2020  06:41 PM    <DIR>          .
03/05/2020  06:41 PM    <DIR>          ..
03/05/2020  06:34 PM               129 main.go
               1 File(s)            129 bytes
               2 Dir(s)  10,984,325,120 bytes free

c:\Users\Alex\dev\src\issue\go\38244>type main.go
package main

import "fmt"
import "C"

//export Test
func Test() {
        fmt.Println("Hello World!")
}

func main() {

}

c:\Users\Alex\dev\src\issue\go\38244>go build -buildmode=c-shared

c:\Users\Alex\dev\src\issue\go\38244>dir
 Volume in drive C has no label.
 Volume Serial Number is 9012-A870

 Directory of c:\Users\Alex\dev\src\issue\go\38244

03/05/2020  06:41 PM    <DIR>          .
03/05/2020  06:41 PM    <DIR>          ..
03/05/2020  06:41 PM         3,651,068 38244
03/05/2020  06:41 PM             1,578 38244.h
03/05/2020  06:34 PM               129 main.go
               3 File(s)      3,652,775 bytes
               2 Dir(s)  10,980,343,808 bytes free

c:\Users\Alex\dev\src\issue\go\38244>copy con main.c
#include "38244.h"
#include <stdio.h>

int main() {
  printf("This is a C Application.\n");
  Test();
  return 0;
}
^Z
        1 file(s) copied.

c:\Users\Alex\dev\src\issue\go\38244>gcc -o a main.c 38244

c:\Users\Alex\dev\src\issue\go\38244>a
This is a C Application.
Hello World!

c:\Users\Alex\dev\src\issue\go\38244>ren 38244 38244.dll

c:\Users\Alex\dev\src\issue\go\38244>gcc -o a main.c 38244.dll

c:\Users\Alex\dev\src\issue\go\38244>a

c:\Users\Alex\dev\src\issue\go\38244>

Running last command brings this box

image

Alex

Sebi2020

comment created time in a month

issue commentgolang/go

runtime: exit status 0xC0000005 from test process on windows-amd64-longtest builder

It's strange to see this exit status.

The process returned ERROR_ACCESS_DENIED. ERROR_ACCESS_DENIED is just another Windows error. There is no restriction on what error process can and cannot return.

It should be handled as an exception by the runtime package (code in runtime/signal_windows.go).

I agree,

Mind you, if something goes wrong in exception handle, it won't exit the process properly, and Windows itself will exit process.

Also, maybe we have a bug and exception handler does not run for some reason.

Even if the runtime package doesn't handle the exception, it should still cause a stack trace and an exit with status 2.

The exception handler can fail as it is printing stack trace.

I don't know under what conditions Windows can still have a 0xc0000005 exit status.

If I run this program

https://play.golang.org/p/r_g4sD76FOh

it prints

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x9853ca]

goroutine 1 [running]:
main.main()
        /home/a/src/issues/go/38440/a.go:9 +0x2a

on Windows. I reckon (I did not test) the program will return 0xc0000005 exit code, if I disable exception handler.

Do we know which program is failing? I still don't see which program failed from test output. Maybe, if we know which program fails, we can add some temporary debugging code to it.

Alex

Alex

bcmills

comment created time in a month

pull request commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

@awaken are you going to go ahead with this PR? If yes, then, please, address my latest comments. If not, please close the PR.

I am waiting for you. Perhaps you also waiting for me. So lets not wait for each other.

Thank you.

Alex

awaken

comment created time in a month

issue commentalexbrainman/odbc

Using package when built with --race "fatal error: checkptr: unsafe pointer conversion"

Thank you for the fast turnaround.

No worries.

I can confirm the issue is now resolved in branch fix144

Thanks for checking. The fix should be on master now.

Alex

MarkSonghurst

comment created time in a month

push eventalexbrainman/odbc

Alex Brainman

commit sha f0492dfa15751dfa8566a9eda47542a084908cdb

make sure current code is not crashing even when compiled with -gcflags=all=-d=checkptr flag (see https://golang.org/issues/34964 for details). Verified with go test ... --race on both Windows and Linux. Fixes #144

view details

push time in a month

issue closedalexbrainman/odbc

Using package when built with --race "fatal error: checkptr: unsafe pointer conversion"

Hi When I build my Linux program using the master branch with go build --race I'm constantly getting an fatal error. I've tried older branches of the package back to 2018 but they exhibit the same error. I've not had time to try an older version of Go, I'm using go version go1.14.2 linux/amd64

The program appears to run fine when built without race detection. I doubt the error is race related, but maybe they've improved pointer checking in newer Go versions..?

fatal error: checkptr: unsafe pointer conversion

goroutine 1 [running]:
runtime.throw(0x1bd6cd2, 0x23)
	/usr/local/go/src/runtime/panic.go:1116 +0x72 fp=0xc0004cad88 sp=0xc0004cad58 pc=0x447a62
runtime.checkptrAlignment(0xc00043a000, 0x189be60, 0x1)
	/usr/local/go/src/runtime/checkptr.go:20 +0xc9 fp=0xc0004cadb8 sp=0xc0004cad88 pc=0x419319
bitbucket.org/XXXX/taishuh-ced/vendor/github.com/alexbrainman/odbc.(*BaseColumn).Value(0xc00000e020, 0xc00043a000, 0x3a, 0x202, 0x37a76b8, 0xc000000000, 0x415ed6, 0xc00040b180)
	/home/mark/go/src/bitbucket.org/XXXX/taishuh-ced/vendor/github.com/alexbrainman/odbc/column.go:144 +0x700 fp=0xc0004caf30 sp=0xc0004cadb8 pc=0xe0e090
bitbucket.org/XXXX/taishuh-ced/vendor/github.com/alexbrainman/odbc.(*BindableColumn).Value(0xc000280000, 0x7f95481510a0, 0x0, 0xe15351, 0x7f9582a14108, 0x0, 0xc0000a4c90)
	/home/mark/go/src/bitbucket.org/XXXX/taishuh-ced/vendor/github.com/alexbrainman/odbc/column.go:259 +0x14c fp=0xc0004cb010 sp=0xc0004caf30 pc=0xe0f39c
bitbucket.org/XXXX/taishuh-ced/vendor/github.com/alexbrainman/odbc.(*Rows).Next(0xc000010008, 0xc0000a4c90, 0x3, 0x3, 0x4581f5, 0x17623d0)
	/home/mark/go/src/bitbucket.org/XXXX/taishuh-ced/vendor/github.com/alexbrainman/odbc/rows.go:35 +0x1a6 fp=0xc0004cb0a8 sp=0xc0004cb010 pc=0xe15546
database/sql.(*Rows).nextLocked(0xc000282180, 0xc000000000)
	/usr/local/go/src/database/sql/sql.go:2767 +0x19d fp=0xc0004cb170 sp=0xc0004cb0a8 pc=0xdde36d
database/sql.(*Rows).Next.func1()
	/usr/local/go/src/database/sql/sql.go:2745 +0x58 fp=0xc0004cb1b0 sp=0xc0004cb170 pc=0xde3498
database/sql.withLock(0x1ffb660, 0xc0002821b0, 0xc0004cb248)
	/usr/local/go/src/database/sql/sql.go:3184 +0x7f fp=0xc0004cb218 sp=0xc0004cb1b0 pc=0xde152f
database/sql.(*Rows).Next(0xc000282180, 0x200f7a0)
	/usr/local/go/src/database/sql/sql.go:2744 +0x95 fp=0xc0004cb278 sp=0xc0004cb218 pc=0xdde185
bitbucket.org/XXXX/taishuh-ced/operator.InitAPIKey(0x0, 0x0)
	/home/mark/go/src/bitbucket.org/XXXX/taishuh-ced/operator/apikey.go:53 +0x253 fp=0xc0004cb530 sp=0xc0004cb278 pc=0x100fa53
bitbucket.org/XXXX/taishuh-ced/daemon.Run(0x1baa123, 0x3)
	/home/mark/go/src/bitbucket.org/XXXX/taishuh-ced/daemon/daemon.go:252 +0x1d6b fp=0xc0004cbf68 sp=0xc0004cb530 pc=0x17542eb
main.main()
	/home/mark/go/src/bitbucket.org/XXXX/taishuh-ced/taishuh-ced.go:12 +0x44 fp=0xc0004cbf88 sp=0xc0004cbf68 pc=0x175a5d4
runtime.main()
	/usr/local/go/src/runtime/proc.go:203 +0x212 fp=0xc0004cbfe0 sp=0xc0004cbf88 pc=0x44a0e2
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc0004cbfe8 sp=0xc0004cbfe0 pc=0x47c4d1

According to the trace The crash is occurring within the call to rows.Next() my code line 53. I've added a comment in my code snippet below:

	rows, err := in.DB.Query(`EXEC dbo.UP_SC_GetScResourceLookup`)
	switch {
	case err != nil:
		return err

	default:
		defer rows.Close()
		var rowsError error
		for rows.Next() {               // <------ THIS IS LINE 53
			ak := APIKey{}
			err := rows.Scan(&ak.Resource, &ak.APIKey, &ak.Owner)
			switch {
			case err != nil:
				if rowsError == nil {
					rowsError = err
				}

			default:
				apiKeysCount++
				ak.APIKey = strings.TrimSpace(ak.APIKey)
				apiKeyCache.Store(ak.Resource, ak)
			}
		}
		if err = rows.Err(); err != nil {
			if rowsError == nil {
				rowsError = err
			}
		}
		if rowsError != nil {
			return err
		}
	}

Looking at the odbc package code, the unsafe pointer conversion being reported by Go is on column.go:144

https://github.com/alexbrainman/odbc/blob/fd264d0ff3809a946737df4b1a0cef2a0baf6c57/column.go#L144

Sorry, this is too low level for me to offer any suggestions in how to fix this.

closed time in a month

MarkSonghurst

issue commentalexbrainman/odbc

Using package when built with --race "fatal error: checkptr: unsafe pointer conversion"

@MarkSonghurst I just pushed

https://github.com/alexbrainman/odbc/tree/fix144

branch for you to test it. Cam you, please, verify and let me know, And I will merge into master.

Thank you.

Alex

MarkSonghurst

comment created time in a month

create barnchalexbrainman/odbc

branch : fix144

created branch time in a month

issue commentgolang/go

runtime: make.bat hangs

I did some more searching around and I'm almost positive tmmon64 and TmUmEvt64 are related to Trend Micro anti-virus,

You are, probably, correct. I use this PC at work. Our admin run whatever software they like on it.

... we're doing something really unusual with suspending our own threads, which, sadly, probably makes this our problem.

I agree. I run a lot of different programs on that computer, and none of it hangs.

This makes Go build tools impossible to use on this computer. I suspect the same can be said about programs built with Go.

The PC is still running Windows 7 - which is rare this days. Hopefully this bug is uncommon.

The downsides of using SuspendThread keep piling up, but I have no idea what to replace it with. :(

Personally I don't see any benefits from preemption. I don't run any code that requires preemption on Windows. I would just disable preempt code on Windows. You will also avoid Delve problems on Windows.

Fascinating. It seems .NET uses SuspendThread for driving threads to GC safe-points. It seems they ran into similar problems with Windows heap locks in general, though not specifically related to system call interceptors.

It is quite possible. But I expect to see restrictions like that mentioned on Windows API descriptions. I am not aware of any such thing.

Adding @zx2c4 in case he has some bright ideas.

Alex

alexbrainman

comment created time in a month

issue commentalexbrainman/odbc

Using package when built with --race "fatal error: checkptr: unsafe pointer conversion"

Thank you for reporting this failure.

I doubt the error is race related, but maybe they've improved pointer checking in newer Go versions..?

That is correct. Go compiler now is more strict with unsafe package usage.

I will investigate this issue when I have some free time.

Alex

MarkSonghurst

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

I think that for ioutil.WriteFile and for os.OpenFile the permission argument should only be used when the file is newly created. We should not change the permission of an existing file. I think that is the intent of the documentation and I think it's how those functions work on Unix.

I understand what we are trying to achieve. @heschik already explained it to me.

Therefore, for O_CREAT | O_TRUNC without O_EXCL, I think that syscall.Open should first call GetFileInformationByHandle, and, if the file exists, preserve FILE_ATTRIBUTE_READONLY.

GetFileInformationByHandle requires file handle, so you will need to use CreateFile first, then GetFileInformationByHandle, then CloseHandle, then you will call existing CreateFile. That is 4 calls, instead of 1 for every single opened file.

And what about the race between GetFileInformationByHandle and second CreateFile? What happens, if another program or thread changes file attribute?

I don't think having FILE_ATTRIBUTE_READONLY mapped to UNIX attribute is worth the trouble. Maybe we should just revert https://golang.org/cl/202439 ?

@zx2c4 what do you think?

Change https://golang.org/cl/229297 mentions this issue: cmd/goimports: set correct permissions on Windows

@heschik Thank you for preparing this CL. But, lets see, if we can find general solution.

Alex

cmMcKeevek

comment created time in a month

issue commentgolang/go

runtime: make.bat hangs

I just tried to verify this issue. And it is still broken on af9ab6b. It gets stuck here

c:\Users\alexb\dev\go\src>make
Building Go cmd/dist using c:\users\alexb\dev\\go1.4
Building Go toolchain1 using c:\users\alexb\dev\\go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.

This what process tree looks like when stuck

image

And this is what windbg says about compile.exe process with pid of 11956:


Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

*** wait with pending attach
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 00000000`00400000 00000000`0175a000   c:\Users\alexb\dev\go\pkg\tool\windows_amd64\compile.exe
ModLoad: 00000000`76fb0000 00000000`7715a000   C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 00000000`76d90000 00000000`76eaf000   C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fce10000 000007fe`fce7a000   C:\Windows\system32\KERNELBASE.dll
ModLoad: 000007fe`fa450000 000007fe`fa622000   C:\Windows\system32\tmumh\20019\AddOn\8.50.0.2071\TmUmEvt64.dll
ModLoad: 00000000`77160000 00000000`77167000   C:\Windows\system32\PSAPI.DLL
ModLoad: 00000000`76eb0000 00000000`76faa000   C:\Windows\system32\USER32.dll
ModLoad: 000007fe`fd850000 000007fe`fd8b7000   C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`fee80000 000007fe`fee8e000   C:\Windows\system32\LPK.dll
ModLoad: 000007fe`fefa0000 000007fe`ff06b000   C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fee90000 000007fe`fef2f000   C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`fd0e0000 000007fe`fd1bb000   C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fee60000 000007fe`fee7f000   C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fe920000 000007fe`fea4d000   C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fe`fd2a0000 000007fe`fd2ce000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fd370000 000007fe`fd479000   C:\Windows\system32\MSCTF.dll
ModLoad: 000007fe`fa440000 000007fe`fa443000   C:\Windows\system32\api-ms-win-core-synch-l1-2-0.DLL
ModLoad: 00000000`747b0000 00000000`7491e000   C:\Windows\system32\tmumh\20019\TmMon\2.8.0.1034\tmmon64.dll
ModLoad: 000007fe`faab0000 000007fe`faaeb000   C:\Windows\system32\winmm.dll
ModLoad: 000007fe`fef50000 000007fe`fef9d000   C:\Windows\system32\ws2_32.dll
ModLoad: 000007fe`ff070000 000007fe`ff078000   C:\Windows\system32\NSI.dll
ModLoad: 000007fe`fcb40000 000007fe`fcb4f000   C:\Windows\system32\cryptbase.dll
ModLoad: 000007fe`fb350000 000007fe`fb37c000   C:\Windows\system32\powrprof.dll
ModLoad: 000007fe`ff080000 000007fe`ff257000   C:\Windows\system32\SETUPAPI.dll
ModLoad: 000007fe`fcd80000 000007fe`fcdb6000   C:\Windows\system32\CFGMGR32.dll
ModLoad: 000007fe`fd1c0000 000007fe`fd29a000   C:\Windows\system32\OLEAUT32.dll
ModLoad: 000007fe`fec60000 000007fe`fee5c000   C:\Windows\system32\ole32.dll
ModLoad: 000007fe`fcdd0000 000007fe`fcdea000   C:\Windows\system32\DEVOBJ.dll
(2eb4.2e3c): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\SYSTEM32\ntdll.dll - 
ntdll!DbgBreakPoint:
00000000`76ffafb0 cc              int     3
0:011> !uniqstack
Processing 12 threads, please wait
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\tmumh\20019\AddOn\8.50.0.2071\TmUmEvt64.dll - 
*** ERROR: Module load completed but symbols could not be loaded for C:\Windows\system32\tmumh\20019\TmMon\2.8.0.1034\tmmon64.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\KERNELBASE.dll - 
*** WARNING: Unable to verify timestamp for c:\Users\alexb\dev\go\pkg\tool\windows_amd64\compile.exe
*** ERROR: Module load completed but symbols could not be loaded for c:\Users\alexb\dev\go\pkg\tool\windows_amd64\compile.exe

.  0  Id: 2eb4.270c Suspend: 1 Teb: 000007ff`fffdd000 Unfrozen
      Start: compile+0x69500 (00000000`00469500) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`0022e618 00000000`76ff8f58 ntdll!ZwWaitForSingleObject+0xa
00000000`0022e620 00000000`76ff8e54 ntdll!RtlDeNormalizeProcessParams+0x5a8
00000000`0022e6d0 00000000`76ffe0b5 ntdll!RtlDeNormalizeProcessParams+0x4a4
00000000`0022e700 00000000`76ffddd8 ntdll!RtlAllocateHeap+0x455
00000000`0022e8e0 000007fe`fa553774 ntdll!RtlAllocateHeap+0x178
00000000`0022e9f0 000007fe`fa46427b TmUmEvt64!GetInterface+0x46e24
00000000`0022ea20 000007fe`fa4aef35 TmUmEvt64+0x1427b
00000000`0022ea50 000007fe`fa4cbea0 TmUmEvt64+0x5ef35
00000000`0022eaa0 000007fe`fa4cc560 TmUmEvt64+0x7bea0
00000000`0022eb70 000007fe`fa4d19f1 TmUmEvt64+0x7c560
00000000`0022ebc0 000007fe`fa4d4b8b TmUmEvt64+0x819f1
00000000`0022ec00 000007fe`fa4ceec8 TmUmEvt64+0x84b8b
00000000`0022f0f0 000007fe`fa4c0618 TmUmEvt64+0x7eec8
00000000`0022f120 000007fe`fa4e9730 TmUmEvt64+0x70618
00000000`0022f230 00000000`747df146 TmUmEvt64+0x99730
00000000`0022f470 00000000`74892d7d tmmon64+0x2f146
00000000`0022f550 00000000`748929f4 tmmon64+0xe2d7d
00000000`0022f610 00000000`747e30ac tmmon64+0xe29f4
00000000`0022f680 000007fe`fce17c3f tmmon64+0x330ac
00000000`0022f750 00000000`0046967e KERNELBASE!ResumeThread+0xf
00000000`0022f780 ffffffff`ffffffff compile+0x6967e
00000000`0022f788 00000000`00000000 0xffffffff`ffffffff
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\kernel32.dll - 

.  1  Id: 2eb4.2ed0 Suspend: 1 Teb: 000007ff`fffdb000 Unfrozen
      Start: tmmon64+0x8adac (00000000`7483adac) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`0395fcb8 000007fe`fce11430 ntdll!ZwWaitForMultipleObjects+0xa
00000000`0395fcc0 00000000`76da06c0 KERNELBASE!GetCurrentProcess+0x40
00000000`0395fdc0 00000000`7485eed4 kernel32!WaitForMultipleObjects+0xb0
00000000`0395fe50 00000000`7483ad07 tmmon64+0xaeed4
00000000`0395ff00 00000000`7483aeae tmmon64+0x8ad07
00000000`0395ff30 00000000`76da59cd tmmon64+0x8aeae
00000000`0395ff60 00000000`76fda561 kernel32!BaseThreadInitThunk+0xd
00000000`0395ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

.  2  Id: 2eb4.1b48 Suspend: 1 Teb: 000007ff`fffd9000 Unfrozen
      Start: ntdll!RtlDestroyHandleTable+0x270 (00000000`76fcf6f0) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`03b5fcc8 00000000`76fced15 ntdll!ZwWaitForWorkViaWorkerFactory+0xa
00000000`03b5fcd0 00000000`76da59cd ntdll!RtlValidateHeap+0x155
00000000`03b5ff60 00000000`76fda561 kernel32!BaseThreadInitThunk+0xd
00000000`03b5ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

.  3  Id: 2eb4.2b3c Suspend: 1 Teb: 000007ff`fffd7000 Unfrozen
      Start: ntdll!TpIsTimerSet+0x8b0 (00000000`76fca280) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`03d5fcb8 00000000`76fca3c7 ntdll!ZwWaitForMultipleObjects+0xa
00000000`03d5fcc0 00000000`76da59cd ntdll!TpIsTimerSet+0x9f7
00000000`03d5ff60 00000000`76fda561 kernel32!BaseThreadInitThunk+0xd
00000000`03d5ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

.  4  Id: 2eb4.125c Suspend: 1 Teb: 000007ff`fffd5000 Unfrozen
      Start: compile+0x69940 (00000000`00469940) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`2956e648 00000000`76ff8f58 ntdll!ZwWaitForSingleObject+0xa
00000000`2956e650 00000000`76ff8e54 ntdll!RtlDeNormalizeProcessParams+0x5a8
00000000`2956e700 00000000`76ffe0b5 ntdll!RtlDeNormalizeProcessParams+0x4a4
00000000`2956e730 00000000`76ffddd8 ntdll!RtlAllocateHeap+0x455
00000000`2956e910 000007fe`fa553774 ntdll!RtlAllocateHeap+0x178
00000000`2956ea20 000007fe`fa46427b TmUmEvt64!GetInterface+0x46e24
00000000`2956ea50 000007fe`fa4aef35 TmUmEvt64+0x1427b
00000000`2956ea80 000007fe`fa4cbea0 TmUmEvt64+0x5ef35
00000000`2956ead0 000007fe`fa4cc560 TmUmEvt64+0x7bea0
00000000`2956eba0 000007fe`fa4d19f1 TmUmEvt64+0x7c560
00000000`2956ebf0 000007fe`fa4d4b8b TmUmEvt64+0x819f1
00000000`2956ec30 000007fe`fa4ceec8 TmUmEvt64+0x84b8b
00000000`2956f120 000007fe`fa4c0618 TmUmEvt64+0x7eec8
00000000`2956f150 000007fe`fa4e9730 TmUmEvt64+0x70618
00000000`2956f260 00000000`747df146 TmUmEvt64+0x99730
00000000`2956f4a0 00000000`74892d7d tmmon64+0x2f146
00000000`2956f580 00000000`748929f4 tmmon64+0xe2d7d
00000000`2956f640 00000000`747e30ac tmmon64+0xe29f4
00000000`2956f6b0 000007fe`fce17c3f tmmon64+0x330ac
00000000`2956f780 00000000`0046967e KERNELBASE!ResumeThread+0xf
00000000`2956f7b0 ffffffff`ffffffff compile+0x6967e
00000000`2956f7b8 00000000`00000001 0xffffffff`ffffffff
00000000`2956f7c0 ffffffff`ffffffff 0x1
00000000`2956f7c8 00000000`2956f928 0xffffffff`ffffffff
00000000`2956f7d0 00000000`00000000 0x2956f928

.  5  Id: 2eb4.2a8c Suspend: 1 Teb: 000007ff`fffd3000 Unfrozen
      Start: compile+0x69940 (00000000`00469940) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`2976fbc8 000007fe`fce110ac ntdll!ZwWaitForSingleObject+0xa
00000000`2976fbd0 00000000`0046967e KERNELBASE!WaitForSingleObjectEx+0x9c
00000000`2976fc70 000000c0`0002ca78 compile+0x6967e
00000000`2976fc78 00000000`02030000 0xc0`0002ca78
00000000`2976fc80 00000000`00000000 0x2030000

.  6  Id: 2eb4.2670 Suspend: 3 Teb: 000007ff`fffae000 Unfrozen
      Start: compile+0x69940 (00000000`00469940) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`2996e638 00000000`7701cf71 ntdll!RtlUnlockHeap+0x90
00000000`2996e640 00000000`76ffddd8 ntdll!TpAlpcRegisterCompletionList+0xaf91
00000000`2996e820 000007fe`fa553774 ntdll!RtlAllocateHeap+0x178
00000000`2996e930 000007fe`fa46427b TmUmEvt64!GetInterface+0x46e24
00000000`2996e960 000007fe`fa4aef35 TmUmEvt64+0x1427b
00000000`2996e990 000007fe`fa4cbea0 TmUmEvt64+0x5ef35
00000000`2996e9e0 000007fe`fa4cc560 TmUmEvt64+0x7bea0
00000000`2996eab0 000007fe`fa4d19f1 TmUmEvt64+0x7c560
00000000`2996eb00 000007fe`fa4d4b8b TmUmEvt64+0x819f1
00000000`2996eb40 000007fe`fa4ceec8 TmUmEvt64+0x84b8b
00000000`2996f030 000007fe`fa4c0618 TmUmEvt64+0x7eec8
00000000`2996f060 000007fe`fa4e9730 TmUmEvt64+0x70618
00000000`2996f170 00000000`747df146 TmUmEvt64+0x99730
00000000`2996f3b0 00000000`74892d7d tmmon64+0x2f146
00000000`2996f490 00000000`748929f4 tmmon64+0xe2d7d
00000000`2996f550 00000000`747e30ac tmmon64+0xe29f4
00000000`2996f5c0 000007fe`fce17c3f tmmon64+0x330ac
00000000`2996f690 00000000`0046967e KERNELBASE!ResumeThread+0xf
00000000`2996f6c0 ffffffff`ffffffff compile+0x6967e
00000000`2996f6c8 00000000`00000001 0xffffffff`ffffffff
00000000`2996f6d0 ffffffff`ffffffff 0x1
00000000`2996f6d8 00000000`2996f840 0xffffffff`ffffffff
00000000`2996f6e0 00000000`00000000 0x2996f840

.  7  Id: 2eb4.2870 Suspend: 1 Teb: 000007ff`fffac000 Unfrozen
      Start: compile+0x69940 (00000000`00469940) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`29e7fb08 000007fe`fce110ac ntdll!ZwWaitForSingleObject+0xa
00000000`29e7fb10 00000000`0046967e KERNELBASE!WaitForSingleObjectEx+0x9c
00000000`29e7fbb0 000000c0`00400278 compile+0x6967e
00000000`29e7fbb8 00000000`0041f9d7 0xc0`00400278
00000000`29e7fbc0 000000c0`00000000 compile+0x1f9d7
00000000`29e7fbc8 00000000`00000188 0xc0`00000000
00000000`29e7fbd0 00000000`00000000 0x188

.  8  Id: 2eb4.2f24 Suspend: 2 Teb: 000007ff`fffaa000 Unfrozen
      Start: compile+0x69940 (00000000`00469940) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`2a07fba8 000007fe`fce11945 ntdll!ZwAllocateVirtualMemory+0xa
00000000`2a07fbb0 00000000`747e0631 KERNELBASE!VirtualAlloc+0x45
00000000`2a07fbf0 00000000`0046967e tmmon64+0x30631
00000000`2a07fcc0 000000c0`013aa000 compile+0x6967e
00000000`2a07fcc8 00000000`00002000 0xc0`013aa000
00000000`2a07fcd0 00000000`00001000 0x2000
00000000`2a07fcd8 00000000`00000004 0x1000
00000000`2a07fce0 00000000`00000012 0x4
00000000`2a07fce8 00000000`00000003 0x12
00000000`2a07fcf0 00000000`00000000 0x3

.  9  Id: 2eb4.2188 Suspend: 1 Teb: 000007ff`fffa8000 Unfrozen
      Start: compile+0x69940 (00000000`00469940) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`2a28fbd8 000007fe`fce110ac ntdll!ZwWaitForSingleObject+0xa
00000000`2a28fbe0 00000000`0046967e KERNELBASE!WaitForSingleObjectEx+0x9c
00000000`2a28fc80 000000c0`00388278 compile+0x6967e
00000000`2a28fc88 00000000`00000000 0xc0`00388278

. 10  Id: 2eb4.25c8 Suspend: 1 Teb: 000007ff`fffa6000 Unfrozen
      Start: ntdll!RtlDestroyHandleTable+0x270 (00000000`76fcf6f0) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`2a56f418 00000000`76ff8f58 ntdll!ZwWaitForSingleObject+0xa
00000000`2a56f420 00000000`76ff8e54 ntdll!RtlDeNormalizeProcessParams+0x5a8
00000000`2a56f4d0 00000000`76ffe0b5 ntdll!RtlDeNormalizeProcessParams+0x4a4
00000000`2a56f500 00000000`76ffddd8 ntdll!RtlAllocateHeap+0x455
00000000`2a56f6e0 000007fe`fa5537eb ntdll!RtlAllocateHeap+0x178
00000000`2a56f7f0 000007fe`fa52a163 TmUmEvt64!GetInterface+0x46e9b
00000000`2a56f820 000007fe`fa529c2d TmUmEvt64!GetInterface+0x1d813
00000000`2a56f850 000007fe`fa525c19 TmUmEvt64!GetInterface+0x1d2dd
00000000`2a56f880 000007fe`fa525fc9 TmUmEvt64!GetInterface+0x192c9
00000000`2a56f8b0 000007fe`fa5261f9 TmUmEvt64!GetInterface+0x19679
00000000`2a56f8e0 00000000`76fda719 TmUmEvt64!GetInterface+0x198a9
00000000`2a56f940 00000000`76fda46f ntdll!RtlUserThreadStart+0x1d9
00000000`2a56fa40 00000000`76fda36e ntdll!LdrInitializeThunk+0x10f
00000000`2a56fab0 00000000`00000000 ntdll!LdrInitializeThunk+0xe

. 11  Id: 2eb4.2e3c Suspend: 1 Teb: 000007ff`fffa4000 Unfrozen
      Start: ntdll!DbgUiRemoteBreakin (00000000`770a2dd0) 
      Priority: 0  Priority class: 32  Affinity: f
Child-SP          RetAddr           Call Site
00000000`2a76ff28 00000000`770a2e08 ntdll!DbgBreakPoint
00000000`2a76ff30 00000000`76da59cd ntdll!DbgUiRemoteBreakin+0x38
00000000`2a76ff60 00000000`76fda561 kernel32!BaseThreadInitThunk+0xd
00000000`2a76ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

Total threads: 12

Alex

alexbrainman

comment created time in a month

issue commentgolang/go

x/net/icmp: listen icmp in Windows not work properly

@lochv I don't know anything about icmp. I don't want to confuse you.

Alex

lochv

comment created time in a month

issue commentgolang/go

cmd/go: -buildmode=c-shared without specifying output file fails does not add .dll extension on Windows and .so extension on linux

@Sebi2020 I don't disagree with your arguments. But I suggest you use -o flag to solve your problem, instead of letting go command pick file name for your output file.

I haven't used -buildmode=c-shared mode for many years, and I could be wrong. But, I suspect, you will discover, that you cannot rename output files anyway. So you argument is pointless.

Alex

Sebi2020

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

From the WriteFile docs: "If the file does not exist, WriteFile creates it with permissions perm (before umask); otherwise WriteFile truncates it before writing." That would appear to me to say that perm is only used when creating the file.

I disagree. That is not how I read this documentation. But I won't argue with you.

Anyway, I don't see how we can implement what you require.

Looking at windows version of syscall.Open. We should use createmode to determine, if FILE_ATTRIBUTE_READONLY should be included.

We should include FILE_ATTRIBUTE_READONLY, if createmode is CREATE_NEW.

I don't see how to deal with CREATE_ALWAYS. CREATE_ALWAYS deals with both exiting and non-existing files. We want FILE_ATTRIBUTE_READONLY set for new files, but not for existing files.

Here is CreateFile Windows API documentation.

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew

Alex

cmMcKeevek

comment created time in a month

issue commentgolang/go

runtime: exit status 0xC0000005 from test process on windows-amd64-longtest builder

There is also mysterious #36492 bug.

Alex

bcmills

comment created time in 2 months

issue commentgolang/go

cmd/go: -buildmode=c-shared without specifying output file fails does not add .dll extension on Windows and .so extension on linux

@Sebi2020 I think this is working as expected.

If you running

go build -buildmode=c-shared

command, it creates output file without extension.

If you want some particular file name, just use -o parameter. Like so

go build -buildmode=c-shared -o a.dll

Alex

Sebi2020

comment created time in 2 months

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

My question is whether it's intentional to apply them when opening an existing file, rather than creating a new one.

I did not know ioutil.WriteFile should use perm parameter differently if it is applied to a new or existing file. Where does it say that?

Alex

cmMcKeevek

comment created time in 2 months

issue commentgolang/go

testing: benchmark is using low resolution time on Windows

I updated testing to use QueryPerformanceCounter in https://go-review.googlesource.com/c/go/+/227499, but I'm not sure whether this is the best way to go about it. Other ideas how to make benchmarking less noisy on quick runs would helpful.

I spent some time investigating this. And, I agree, if we use QueryPerformanceCounter, we could improve our time.Duration precision from 1 millisecond to around few microsecond. Same with either QueryInterruptTimePrecise or QueryUnbiasedInterruptTimePrecise. But using syscall.Syscall to implement this code (similar to your CL 227499) is 10 times slower than current time.Now implementation. This is what I see

BenchmarkNow
BenchmarkNow-4                                  161259765                7.30 ns/op
BenchmarkQPC
BenchmarkQPC-4                                  11327251               106 ns/op
BenchmarkUnbiasedInterruptTime
BenchmarkUnbiasedInterruptTime-4                13963765                86.8 ns/op
BenchmarkUnbiasedInterruptPreciseTime
BenchmarkUnbiasedInterruptPreciseTime-4         11112705               107 ns/op

I don't think it is acceptable for time.Now. Maybe it is acceptable for testing package benchmark code. I am not sure.

Unrelated to this. Austin tried replacing our current time.Now implementation with asm version of QueryUnbiasedInterruptTime (see https://go-review.googlesource.com/c/go/+/211307 ) - and it is fast enough replacement. Maybe we could do something similar for *Precise version - if only for time.Now implementation, not runtime.nanotime implementation.

Alex

egonelbre

comment created time in 2 months

issue commentgolang/go

os: permit Rename to read-only file on Windows

Any other opinions?

This bug does not affect me. But the fix will affect me - os.Rename will have to do more to implement this logic. We always adjust windows code to match whatever Unix syscalls implements.

Adding @zx2c4 since he is the author of 16f0f9c

Thank you.

Alex

calmh

comment created time in 2 months

issue commentgolang/go

net: cannot send multicast using ListenPacket("udp4", "") on Windows 10 (1909)

@filimonic sorry I am not network person, so I do not know why your program does not work reliably. I also don't have Wireshark program installed on my computer, so I cannot even try to reproduce your problem.

But I noticed there are some tests in net package (in %GOROOT%\src\net directory), that call ListenPacket

$ git grep -e ListenPacket.*udp4 -n
mockserver_test.go:337:                 return ListenPacket("udp4", "127.0.0.1:0
mockserver_test.go:344:                 return ListenPacket("udp4", "127.0.0.1:0
$

All tests in net are obviously succeed on everyone's Windows computers. Maybe you can use net test code and adjust it to make it do what you need?

Alex

filimonic

comment created time in 2 months

issue commentgolang/go

net: UDPConn.WriteToUDP not sending anything on Windows

@jmarkel44

I never used this package github.com/hashicorp/mdns - I don't know what it does. But I tried running your program on Linux:

searching for new entries
2020/04/05 16:52:10 [INFO] mdns: Closing client {0xc000010030 0xc000010038 0xc000010040 0xc000010048 true 0xc000068180 {1 0}}
2020/04/05 16:52:10 [ERR] mdns: Failed to read packet: read udp4 0.0.0.0:55783: use of closed network connection

and on Windows

searching for new entries
2020/04/05 16:54:47 [ERR] mdns: Failed to bind to udp6 port: listen udp6 [ff02::fb]:5353: setsockopt: not supported by windows
2020/04/05 16:54:48 [INFO] mdns: Closing client {0xc00014c020 0xc00014c028 0xc00014c030 <nil> true 0xc000108180 {1 0}}
2020/04/05 16:54:48 [ERR] mdns: Failed to read packet: read udp4 0.0.0.0:54096: use of closed network connection

And 2 outputs looks very similar to me.

If you think the problem is in UDPConn.WriteToUDP, please, create small program that we can run on our computers to investigate. Do not assume we have Wireshark installed or other special tools available.

Thank you.

Alex

jmarkel44

comment created time in 2 months

issue commentgolang/go

cmd/compile/internal/logopt: TestLogOpt/Copy fails with 'Access is denied.' error

logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build191589167: Access is denied.

Just briefly looking at the error.

It looks like this test is creating directory in my Windows directory (C:\WINDOWS). This is not allowed. I suspect our builders succeed because they, probably, run as Administrator.

Alex

alexbrainman

comment created time in 2 months

issue commentgolang/go

all: get standard library building with -d=checkptr

And I submitted CL 227003. So I don't see what else to do for this current issue. Leaving it for others to close.

Alex

mdempsky

comment created time in 2 months

issue commentgolang/go

all: get standard library building with -d=checkptr

I sent https://golang.org/cl/227003 But it fails here when I run all.bat with this error:

--- FAIL: TestLogOpt (0.63s)
    --- FAIL: TestLogOpt/Copy (0.27s)
        --- FAIL: TestLogOpt/Copy/arm (0.02s)

TestLogOpt failure is unrelated to CL 227003. I filled #38251 for that.

Alex

mdempsky

comment created time in 2 months

issue openedgolang/go

cmd/compile/internal/logopt: TestLogOpt/Copy fails with 'Access is denied.' error

What version of Go are you using (go version)?

<pre> go version devel +fff7509d47 Sat Apr 4 01:01:04 2020 +0000 windows/amd64 </pre>

Does this issue reproduce with the latest release?

I don't know.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> set GO111MODULE=off set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\Alex\AppData\Local\go-build set GOENV=C:\Users\Alex\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=c:\users\alex\dev set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=c:\users\alex\dev\go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=c:\users\alex\dev\go\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Alex\AppData\Local\Temp\go-build775355946=/tmp/go-build -gno-record-gcc-switches </pre></details>

What did you do?

I run

go test -short cmd/compile/internal/logopt

command.

What did you expect to see?

I expected command to succeed.

What did you see instead?

Test fails with:

--- FAIL: TestLogOpt (0.30s)
    --- FAIL: TestLogOpt/Copy (0.16s)
        --- FAIL: TestLogOpt/Copy/arm (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build191589167: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/arm64 (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build401421879: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/386 (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build231443483: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/amd64 (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build091527347: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/mips (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build209411947: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/mips64 (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build066462375: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/ppc64le (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build464334239: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/s390x (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build220467091: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/wasm (0.02s)
            logopt_test.go:199: [c:\users\alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt028005011\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build247928563: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
FAIL
FAIL    cmd/compile/internal/logopt     0.386s
FAIL

I was able to bisect this failure to

47ade08141b23cfeafed92943e16012d5dc5eb8b is the first bad commit
commit 47ade08141b23cfeafed92943e16012d5dc5eb8b
Author: David Chase <drchase@google.com>
Date:   Sat Nov 2 23:57:11 2019 -0400

    cmd/compile: add logging for large (>= 128 byte) copies

    For 1.15, unless someone really wants it in 1.14.

    A performance-sensitive user thought this would be useful,
    though "large" was not well-defined.  If 128 is large,
    there are 139 static instances of "large" copies in the compiler
    itself.

    Includes test.

    Change-Id: I81f20c62da59d37072429f3a22c1809e6fb2946d
    Reviewed-on: https://go-review.googlesource.com/c/go/+/205066
    Run-TryBot: David Chase <drchase@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Cherry Zhang <cherryyz@google.com>

:040000 040000 46c10febf7a9c71e49d1ad7ff4027e3be81453af cb045d689803f00f1f8dd3fb2ab912a5f38df682 M  src

/cc @dr2chase and @cherrymui

Alex

created time in 2 months

issue commentgolang/go

all: get standard library building with -d=checkptr

There are still 2 failures. But I don't think they are related to -d=checkptr.

Do they also happen without checkptr?

Do they also happen without checkptr?

Yes. Running

go test -a -short std cmd

fails in exactly the same way as

go test -a -short -gcflags=all=-d=checkptr std cmd

command.

... Should I send windows version of https://go-review.googlesource.com/c/go/+/201783/ ?

That would be awesome.

I sent https://golang.org/cl/227003 But it fails here when I run all.bat with this error:

--- FAIL: TestLogOpt (0.63s)
    --- FAIL: TestLogOpt/Copy (0.27s)
        --- FAIL: TestLogOpt/Copy/arm (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build210684795: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/arm64 (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build080355363: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/386 (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build929204411: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/amd64 (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build049316543: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/mips (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build251041127: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/mips64 (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build593677423: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/ppc64le (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build772328963: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/s390x (0.02s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build555385451: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
        --- FAIL: TestLogOpt/Copy/wasm (0.08s)
            logopt_test.go:199: [c:\Users\Alex\dev\go\bin\go.exe tool compile -p x -json=0,file://log/opt -o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.o C:\Users\Alex\AppData\Local\Temp\TestLogOpt659564243\copy.go]
            logopt_test.go:204: go: creating work dir: mkdir C:\WINDOWS\go-build914568571: Access is denied.
            logopt_test.go:131: -json=0,file://log/opt should have succeeded
            logopt_test.go:135: -json=0,file://log/opt missing expected log file
            logopt_test.go:138:
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":3,"character":2},"end":{"line":3,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:37: did not see phrase {"range":{"start":{"line":9,"character":2},"end":{"line":9,"character":2}},"severity":3,"code":"copy","source":"go compiler","message":"128 bytes"} in
            logopt_test.go:43: expected exactly 2 occurences of "code":"copy" in
FAIL
FAIL    cmd/compile/internal/logopt     0.741s

Mind you, I created CL on current tip. And current tip has new linker code. Maybe failure is related. I did not investigate it properly.

There are still 2 failures. But I don't think they are related to -d=checkptr.

Do those resolve if you run go install cmd without -d=checkptr before running go test?

Running

go install cmd

before

go test -a -short -gcflags=all=-d=checkptr std cmd

makes things worse (I am showing just errors)

--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/test_relative_import_dash_i (0.48s)
        script_test.go:205:
            # Relative imports in go test -i
            # Run tests outside GOPATH. (0.000s)
            # Check that it's safe to pass -i (which installs dependencies in $GOPATH/pkg) to go test. (0.463s)
            > ! stale runtime # don't let test -i overwrite runtime
            FAIL: testdata\script\test_relative_import_dash_i.txt:7: runtime is unexpectedly stale


    --- FAIL: TestScript/test_race_install_cgo (2.53s)
        script_test.go:205:
            # Tests Issue #10500 (2.500s)
            > [!race] skip
            > [!darwin] ! stale cmd/cgo  # The darwin builders are spuriously stale; see #33598.
            FAIL: testdata\script\test_race_install_cgo.txt:5: cmd/cgo is unexpectedly stale


    --- FAIL: TestScript/build_package_not_stale_trailing_slash (0.16s)
        script_test.go:205:
            # Tests Issue #12690 (0.160s)
            > [gccgo] skip 'gccgo does not have GOROOT'
            > ! stale runtime
            FAIL: testdata\script\build_package_not_stale_trailing_slash.txt:5: runtime is unexpectedly stale


FAIL
FAIL    cmd/go  195.196s

and

--- FAIL: TestDWARF (1.32s)
    dwarf_test.go:39: cmd/link is stale - run go install cmd/link
FAIL
FAIL    cmd/link        16.210s

All tested on top of 801cd7c84d4.

Alex

mdempsky

comment created time in 2 months

issue commentgolang/go

all: get standard library building with -d=checkptr

I think I finished all -d=checkptr related changes. Running (on top of 801cd7c )

c:\Users\Alex\dev\go\src>go test -a -short -gcflags=all=-d=checkptr std cmd
ok      archive/tar     0.648s
ok      archive/zip     0.170s
ok      bufio   0.089s
ok      bytes   0.325s
ok      compress/bzip2  0.287s
ok      compress/flate  1.147s
ok      compress/gzip   0.250s
ok      compress/lzw    0.371s
ok      compress/zlib   0.106s
ok      container/heap  0.118s
ok      container/list  0.244s
ok      container/ring  0.082s
ok      context 0.151s
ok      crypto  0.526s
ok      crypto/aes      0.220s
ok      crypto/cipher   0.554s
ok      crypto/des      0.259s
ok      crypto/dsa      0.108s
ok      crypto/ecdsa    0.235s
ok      crypto/ed25519  0.359s
?       crypto/ed25519/internal/edwards25519    [no test files]
ok      crypto/elliptic 0.208s
ok      crypto/hmac     0.833s
?       crypto/internal/randutil        [no test files]
ok      crypto/internal/subtle  0.724s
ok      crypto/md5      0.830s
ok      crypto/rand     0.146s
ok      crypto/rc4      0.127s
ok      crypto/rsa      0.257s
ok      crypto/sha1     0.116s
ok      crypto/sha256   0.132s
ok      crypto/sha512   0.079s
ok      crypto/subtle   0.074s
ok      crypto/tls      4.314s
ok      crypto/x509     1.605s
?       crypto/x509/pkix        [no test files]
ok      database/sql    0.762s
ok      database/sql/driver     0.053s
ok      debug/dwarf     1.120s
ok      debug/elf       1.395s
ok      debug/gosym     0.157s
ok      debug/macho     0.434s
ok      debug/pe        12.299s
ok      debug/plan9obj  0.182s
?       encoding        [no test files]
ok      encoding/ascii85        0.093s
ok      encoding/asn1   0.063s
ok      encoding/base32 0.120s
ok      encoding/base64 0.098s
ok      encoding/binary 0.056s
ok      encoding/csv    0.084s
ok      encoding/gob    0.505s
ok      encoding/hex    0.495s
ok      encoding/json   0.447s
ok      encoding/pem    0.140s
ok      encoding/xml    0.096s
ok      errors  0.110s
ok      expvar  0.206s
ok      flag    0.159s
ok      fmt     0.157s
ok      go/ast  0.059s
ok      go/build        19.119s
ok      go/constant     0.113s
ok      go/doc  1.058s
ok      go/format       0.075s
ok      go/importer     0.401s
ok      go/internal/gccgoimporter       2.147s
ok      go/internal/gcimporter  2.170s
ok      go/internal/srcimporter 3.413s
ok      go/parser       0.403s
ok      go/printer      0.569s
ok      go/scanner      0.094s
ok      go/token        0.158s
ok      go/types        4.196s
ok      hash    0.051s
ok      hash/adler32    0.102s
ok      hash/crc32      0.217s
ok      hash/crc64      0.159s
ok      hash/fnv        0.160s
ok      hash/maphash    0.178s
ok      html    0.048s
ok      html/template   0.139s
ok      image   0.312s
ok      image/color     0.139s
?       image/color/palette     [no test files]
ok      image/draw      0.250s
ok      image/gif       0.747s
?       image/internal/imageutil        [no test files]
ok      image/jpeg      0.573s
ok      image/png       0.268s
ok      index/suffixarray       0.274s
?       internal/bytealg        [no test files]
?       internal/cfg    [no test files]
ok      internal/cpu    0.111s
ok      internal/fmtsort        0.096s
?       internal/goroot [no test files]
?       internal/goversion      [no test files]
?       internal/lazyregexp     [no test files]
?       internal/lazytemplate   [no test files]
?       internal/nettrace       [no test files]
?       internal/obscuretestdata        [no test files]
?       internal/oserror        [no test files]
ok      internal/poll   0.165s
?       internal/race   [no test files]
ok      internal/reflectlite    0.130s
ok      internal/singleflight   0.107s
?       internal/syscall/execenv        [no test files]
ok      internal/syscall/windows        0.085s
ok      internal/syscall/windows/registry       0.207s
?       internal/syscall/windows/sysdll [no test files]
?       internal/testenv        [no test files]
?       internal/testlog        [no test files]
ok      internal/trace  0.737s
ok      internal/xcoff  1.169s
ok      io      0.239s
ok      io/ioutil       0.302s
ok      log     0.078s
?       log/syslog      [no test files]
ok      math    0.138s
ok      math/big        1.337s
ok      math/bits       0.116s
ok      math/cmplx      0.072s
ok      math/rand       0.416s
ok      mime    0.526s
ok      mime/multipart  0.931s
ok      mime/quotedprintable    0.067s
ok      net     32.163s
ok      net/http        14.201s
ok      net/http/cgi    0.608s
ok      net/http/cookiejar      0.125s
ok      net/http/fcgi   0.891s
ok      net/http/httptest       2.162s
ok      net/http/httptrace      0.289s
ok      net/http/httputil       0.451s
ok      net/http/internal       0.299s
ok      net/http/pprof  2.254s
ok      net/internal/socktest   0.061s
ok      net/mail        0.079s
ok      net/rpc 0.357s
ok      net/rpc/jsonrpc 0.649s
ok      net/smtp        0.323s
ok      net/textproto   0.116s
ok      net/url 0.113s
ok      os      7.549s
ok      os/exec 7.068s
ok      os/signal       2.068s
ok      os/user 0.121s
ok      path    0.071s
ok      path/filepath   1.260s
ok      plugin  0.114s
ok      reflect 1.269s
ok      regexp  0.754s
ok      regexp/syntax   0.519s
ok      runtime 99.905s
?       runtime/cgo     [no test files]
ok      runtime/debug   0.096s
ok      runtime/internal/atomic 0.116s
ok      runtime/internal/math   0.060s
ok      runtime/internal/sys    0.190s
ok      runtime/pprof   13.023s
ok      runtime/pprof/internal/profile  0.085s
?       runtime/race    [no test files]
ok      runtime/trace   0.765s
ok      sort    0.101s
ok      strconv 0.690s
ok      strings 0.268s
ok      sync    0.583s
ok      sync/atomic     0.117s
ok      syscall 0.072s
ok      testing 0.737s
?       testing/internal/testdeps       [no test files]
ok      testing/iotest  0.135s
ok      testing/quick   0.270s
ok      text/scanner    0.106s
ok      text/tabwriter  0.071s
ok      text/template   0.125s
ok      text/template/parse     0.055s
ok      time    2.523s
ok      unicode 0.173s
ok      unicode/utf16   0.193s
ok      unicode/utf8    0.062s
?       unsafe  [no test files]
?       vendor/golang.org/x/crypto/chacha20     [no test files]
?       vendor/golang.org/x/crypto/chacha20poly1305     [no test files]
?       vendor/golang.org/x/crypto/cryptobyte   [no test files]
?       vendor/golang.org/x/crypto/cryptobyte/asn1      [no test files]
?       vendor/golang.org/x/crypto/curve25519   [no test files]
?       vendor/golang.org/x/crypto/hkdf [no test files]
?       vendor/golang.org/x/crypto/internal/subtle      [no test files]
?       vendor/golang.org/x/crypto/poly1305     [no test files]
?       vendor/golang.org/x/net/dns/dnsmessage  [no test files]
?       vendor/golang.org/x/net/http/httpguts   [no test files]
?       vendor/golang.org/x/net/http/httpproxy  [no test files]
?       vendor/golang.org/x/net/http2/hpack     [no test files]
?       vendor/golang.org/x/net/idna    [no test files]
?       vendor/golang.org/x/net/nettest [no test files]
?       vendor/golang.org/x/sys/cpu     [no test files]
?       vendor/golang.org/x/text/secure/bidirule        [no test files]
?       vendor/golang.org/x/text/transform      [no test files]
?       vendor/golang.org/x/text/unicode/bidi   [no test files]
?       vendor/golang.org/x/text/unicode/norm   [no test files]
ok      cmd/addr2line   20.369s
ok      cmd/api 24.461s
?       cmd/asm [no test files]
?       cmd/asm/internal/arch   [no test files]
ok      cmd/asm/internal/asm    4.127s
?       cmd/asm/internal/flags  [no test files]
ok      cmd/asm/internal/lex    0.800s
?       cmd/buildid     [no test files]
?       cmd/cgo [no test files]
ok      cmd/compile     0.624s
?       cmd/compile/internal/amd64      [no test files]
?       cmd/compile/internal/arm        [no test files]
?       cmd/compile/internal/arm64      [no test files]
ok      cmd/compile/internal/gc 18.001s
ok      cmd/compile/internal/logopt     3.718s
?       cmd/compile/internal/mips       [no test files]
?       cmd/compile/internal/mips64     [no test files]
?       cmd/compile/internal/ppc64      [no test files]
?       cmd/compile/internal/riscv64    [no test files]
?       cmd/compile/internal/s390x      [no test files]
ok      cmd/compile/internal/ssa        0.668s
ok      cmd/compile/internal/syntax     0.188s
ok      cmd/compile/internal/test       0.140s [no tests to run]
ok      cmd/compile/internal/types      0.047s
?       cmd/compile/internal/wasm       [no test files]
?       cmd/compile/internal/x86        [no test files]
ok      cmd/cover       11.431s
?       cmd/dist        [no test files]
ok      cmd/doc 0.266s
ok      cmd/fix 6.998s
go test proxy running at GOPROXY=http://127.0.0.1:62204/mod
go proxy: no archive rsc.io v1.5.2: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.1.0: file does not exist
go proxy: no archive rsc.io v1.5.1: file does not exist
go proxy: no archive example.com/newcycle v1.0.0: file does not exist
go proxy: no archive rsc.io v1.5.2: file does not exist
--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/test_race_install_cgo (1.32s)
        script_test.go:205:
            # Tests Issue #10500 (1.244s)
            > [!race] skip
            > [!darwin] ! stale cmd/cgo  # The darwin builders are spuriously stale; see #33598.
            FAIL: testdata\script\test_race_install_cgo.txt:5: cmd/cgo is unexpectedly stale


FAIL
FAIL    cmd/go  201.196s
ok      cmd/go/internal/auth    0.349s
?       cmd/go/internal/base    [no test files]
?       cmd/go/internal/bug     [no test files]
ok      cmd/go/internal/cache   5.082s
?       cmd/go/internal/cfg     [no test files]
?       cmd/go/internal/clean   [no test files]
?       cmd/go/internal/cmdflag [no test files]
?       cmd/go/internal/doc     [no test files]
?       cmd/go/internal/envcmd  [no test files]
?       cmd/go/internal/fix     [no test files]
?       cmd/go/internal/fmtcmd  [no test files]
ok      cmd/go/internal/generate        0.479s
ok      cmd/go/internal/get     0.385s
?       cmd/go/internal/help    [no test files]
ok      cmd/go/internal/imports 0.065s
?       cmd/go/internal/list    [no test files]
ok      cmd/go/internal/load    0.224s
ok      cmd/go/internal/lockedfile      0.381s
ok      cmd/go/internal/lockedfile/internal/filelock    0.321s
?       cmd/go/internal/modcmd  [no test files]
ok      cmd/go/internal/modconv 0.412s
ok      cmd/go/internal/modfetch        1.165s
ok      cmd/go/internal/modfetch/codehost       0.241s
ok      cmd/go/internal/modfetch/zip_sum_test   0.772s
?       cmd/go/internal/modget  [no test files]
?       cmd/go/internal/modinfo [no test files]
ok      cmd/go/internal/modload 0.237s
ok      cmd/go/internal/mvs     0.109s
ok      cmd/go/internal/par     0.078s
ok      cmd/go/internal/renameio        15.631s
?       cmd/go/internal/robustio        [no test files]
?       cmd/go/internal/run     [no test files]
ok      cmd/go/internal/search  0.304s
?       cmd/go/internal/str     [no test files]
ok      cmd/go/internal/test    1.983s
?       cmd/go/internal/tool    [no test files]
ok      cmd/go/internal/txtar   0.180s
?       cmd/go/internal/version [no test files]
?       cmd/go/internal/vet     [no test files]
ok      cmd/go/internal/web     0.654s
ok      cmd/go/internal/work    0.682s
ok      cmd/gofmt       1.146s
?       cmd/internal/bio        [no test files]
?       cmd/internal/browser    [no test files]
ok      cmd/internal/buildid    1.306s
?       cmd/internal/diff       [no test files]
ok      cmd/internal/dwarf      0.085s
ok      cmd/internal/edit       0.134s
?       cmd/internal/gcprog     [no test files]
ok      cmd/internal/goobj      2.878s
?       cmd/internal/goobj2     [no test files]
ok      cmd/internal/moddeps    8.717s
ok      cmd/internal/obj        0.080s
?       cmd/internal/obj/arm    [no test files]
ok      cmd/internal/obj/arm64  0.592s
?       cmd/internal/obj/mips   [no test files]
ok      cmd/internal/obj/ppc64  0.404s
ok      cmd/internal/obj/riscv  0.258s
?       cmd/internal/obj/s390x  [no test files]
?       cmd/internal/obj/wasm   [no test files]
ok      cmd/internal/obj/x86    6.724s
ok      cmd/internal/objabi     0.079s
?       cmd/internal/objfile    [no test files]
ok      cmd/internal/src        0.081s
?       cmd/internal/sys        [no test files]
ok      cmd/internal/test2json  0.789s
--- FAIL: TestDWARF (0.40s)
    dwarf_test.go:39: cmd/link is stale - run go install cmd/link
FAIL
FAIL    cmd/link        19.864s
?       cmd/link/internal/amd64 [no test files]
?       cmd/link/internal/arm   [no test files]
?       cmd/link/internal/arm64 [no test files]
ok      cmd/link/internal/ld    20.019s
?       cmd/link/internal/loadelf       [no test files]
?       cmd/link/internal/loader        [no test files]
?       cmd/link/internal/loadmacho     [no test files]
?       cmd/link/internal/loadpe        [no test files]
?       cmd/link/internal/loadxcoff     [no test files]
?       cmd/link/internal/mips  [no test files]
?       cmd/link/internal/mips64        [no test files]
?       cmd/link/internal/objfile       [no test files]
?       cmd/link/internal/ppc64 [no test files]
?       cmd/link/internal/riscv64       [no test files]
?       cmd/link/internal/s390x [no test files]
ok      cmd/link/internal/sym   0.407s
?       cmd/link/internal/wasm  [no test files]
?       cmd/link/internal/x86   [no test files]
ok      cmd/nm  15.778s
ok      cmd/objdump     5.883s
ok      cmd/pack        7.192s
?       cmd/pprof       [no test files]
?       cmd/test2json   [no test files]
ok      cmd/trace       1.206s
?       cmd/vendor/github.com/google/pprof/driver       [no test files]
?       cmd/vendor/github.com/google/pprof/internal/binutils    [no test files]
?       cmd/vendor/github.com/google/pprof/internal/driver      [no test files]
?       cmd/vendor/github.com/google/pprof/internal/elfexec     [no test files]
?       cmd/vendor/github.com/google/pprof/internal/graph       [no test files]
?       cmd/vendor/github.com/google/pprof/internal/measurement [no test files]
?       cmd/vendor/github.com/google/pprof/internal/plugin      [no test files]
?       cmd/vendor/github.com/google/pprof/internal/report      [no test files]
?       cmd/vendor/github.com/google/pprof/internal/symbolizer  [no test files]
?       cmd/vendor/github.com/google/pprof/internal/symbolz     [no test files]
?       cmd/vendor/github.com/google/pprof/internal/transport   [no test files]
?       cmd/vendor/github.com/google/pprof/profile      [no test files]
?       cmd/vendor/github.com/google/pprof/third_party/d3       [no test files]
?       cmd/vendor/github.com/google/pprof/third_party/d3flamegraph     [no test files]
?       cmd/vendor/github.com/google/pprof/third_party/svgpan   [no test files]
?       cmd/vendor/github.com/ianlancetaylor/demangle   [no test files]
?       cmd/vendor/golang.org/x/arch/arm/armasm [no test files]
?       cmd/vendor/golang.org/x/arch/arm64/arm64asm     [no test files]
?       cmd/vendor/golang.org/x/arch/ppc64/ppc64asm     [no test files]
?       cmd/vendor/golang.org/x/arch/x86/x86asm [no test files]
?       cmd/vendor/golang.org/x/crypto/ed25519  [no test files]
?       cmd/vendor/golang.org/x/crypto/ed25519/internal/edwards25519    [no test files]
?       cmd/vendor/golang.org/x/crypto/ssh/terminal     [no test files]
?       cmd/vendor/golang.org/x/mod/internal/lazyregexp [no test files]
?       cmd/vendor/golang.org/x/mod/modfile     [no test files]
?       cmd/vendor/golang.org/x/mod/module      [no test files]
?       cmd/vendor/golang.org/x/mod/semver      [no test files]
?       cmd/vendor/golang.org/x/mod/sumdb       [no test files]
?       cmd/vendor/golang.org/x/mod/sumdb/dirhash       [no test files]
?       cmd/vendor/golang.org/x/mod/sumdb/note  [no test files]
?       cmd/vendor/golang.org/x/mod/sumdb/tlog  [no test files]
?       cmd/vendor/golang.org/x/mod/zip [no test files]
?       cmd/vendor/golang.org/x/sys/unix        [no test files]
?       cmd/vendor/golang.org/x/sys/windows     [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis       [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/internal/analysisflags   [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/internal/facts        [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/asmdecl        [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/assign [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/atomic [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/bools  [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/buildtag       [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/cgocall        [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/composite      [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/copylock       [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/ctrlflow       [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/errorsas       [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/httpresponse   [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/ifaceassert    [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/inspect        [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/internal/analysisutil      [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/loopclosure    [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/lostcancel     [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/nilfunc        [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/printf [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/shift  [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/stdmethods     [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/stringintconv  [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/structtag      [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/tests  [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/unmarshal      [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/unreachable    [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/unsafeptr      [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/passes/unusedresult   [no test files]
?       cmd/vendor/golang.org/x/tools/go/analysis/unitchecker   [no test files]
?       cmd/vendor/golang.org/x/tools/go/ast/astutil    [no test files]
?       cmd/vendor/golang.org/x/tools/go/ast/inspector  [no test files]
?       cmd/vendor/golang.org/x/tools/go/cfg    [no test files]
?       cmd/vendor/golang.org/x/tools/go/types/objectpath       [no test files]
?       cmd/vendor/golang.org/x/tools/go/types/typeutil [no test files]
?       cmd/vendor/golang.org/x/xerrors [no test files]
?       cmd/vendor/golang.org/x/xerrors/internal        [no test files]
ok      cmd/vet 29.924s
FAIL

c:\Users\Alex\dev\go\src>

There are still 2 failures. But I don't think they are related to -d=checkptr.

I am not sure what to do next. Should I send windows version of

https://go-review.googlesource.com/c/go/+/201783/

?

Thank you.

Alex

mdempsky

comment created time in 2 months

issue closedgolang/go

cmd/go: does not find packages under GOPATH when run from GOROOT\src directory on windows

What version of Go are you using (go version)?

<pre> go version devel +5aef51a729 Sun Mar 29 02:01:34 2020 +0000 windows/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre>

set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\Alex\AppData\Local\go-build set GOENV=C:\Users\Alex\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=c:\users\alex\dev set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=c:\users\alex\dev\go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=c:\users\alex\dev\go\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Alex\AppData\Local\Temp\go-build421324630=/tmp/go-build -gno-record-gcc-switches </pre></details>

What did you do?

c:\>cd %GOROOT%\src

c:\Users\Alex\dev\go\src>type %GOPATH%\src\a\main.go
package main

import (
        "fmt"
)

func main() {
        fmt.Println("Hello")
}

c:\Users\Alex\dev\go\src>go build -o %TMP%\a.exe a && %TMP%\a.exe
package a: cannot find package "." in:
        c:\Users\Alex\dev\go\src\a

c:\Users\Alex\dev\go\src>

What did you expect to see?

I expected my program in package a in my GOPATH directory to build.

What did you see instead?

I see the error above.

This used to work, but was broken by

0fc89a72edc2c73651f7f6841b1146af723f517f is the first bad commit
commit 0fc89a72edc2c73651f7f6841b1146af723f517f
Author: Bryan C. Mills <bcmills@google.com>
Date:   Wed Feb 20 18:25:37 2019 -0500

    cmd,std: add go.mod files

    Updates #30241
    Updates #30228

    Change-Id: Ida0fe8263bf44e0498fed2048e22283ba5716835
    Reviewed-on: https://go-review.googlesource.com/c/go/+/164622
    Run-TryBot: Bryan C. Mills <bcmills@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Jay Conrod <jayconrod@google.com>

@bcmills @jayconrod let me know, if you need help to debug this.

Thank you.

Alex

closed time in 2 months

alexbrainman

issue commentgolang/go

cmd/go: does not find packages under GOPATH when run from GOROOT\src directory on windows

So this seems to be working as designed. If you want to build in GOPATH mode, either run the go command from outside of a module, or set GO111MODULE=off explicitly.

You are correct. My Linux shell is configured with GO111MODULE=off. But I don't have GO111MODULE=off set on my Windows computer. That is why they are different. Setting GO111MODULE=off on Windows makes the command above work as I expected it.

Sorry to waste your time. Closing the issue.

Alex

alexbrainman

comment created time in 2 months

issue openedgolang/go

cmd/go: does not find packages under GOPATH when run from GOROOT\src directory on windows

What version of Go are you using (go version)?

<pre> go version devel +5aef51a729 Sun Mar 29 02:01:34 2020 +0000 windows/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre>

set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\Alex\AppData\Local\go-build set GOENV=C:\Users\Alex\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=c:\users\alex\dev set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=c:\users\alex\dev\go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=c:\users\alex\dev\go\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Alex\AppData\Local\Temp\go-build421324630=/tmp/go-build -gno-record-gcc-switches </pre></details>

What did you do?

c:\>cd %GOROOT%\src

c:\Users\Alex\dev\go\src>type %GOPATH%\src\a\main.go
package main

import (
        "fmt"
)

func main() {
        fmt.Println("Hello")
}

c:\Users\Alex\dev\go\src>go build -o %TMP%\a.exe a && %TMP%\a.exe
package a: cannot find package "." in:
        c:\Users\Alex\dev\go\src\a

c:\Users\Alex\dev\go\src>

What did you expect to see?

I expected my program in package a in my GOPATH directory to build.

What did you see instead?

I see the error above.

This used to work, but was broken by

0fc89a72edc2c73651f7f6841b1146af723f517f is the first bad commit
commit 0fc89a72edc2c73651f7f6841b1146af723f517f
Author: Bryan C. Mills <bcmills@google.com>
Date:   Wed Feb 20 18:25:37 2019 -0500

    cmd,std: add go.mod files

    Updates #30241
    Updates #30228

    Change-Id: Ida0fe8263bf44e0498fed2048e22283ba5716835
    Reviewed-on: https://go-review.googlesource.com/c/go/+/164622
    Run-TryBot: Bryan C. Mills <bcmills@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Jay Conrod <jayconrod@google.com>

@bcmills @jayconrod let me know, if you need help to debug this.

Thank you.

Alex

created time in 2 months

issue commentgolang/go

proposal: time: add time/tzdata package and timetzdata tag to embed tzdata in program

Adding to proposal minutes but this seems headed for likely accept.

@rsc what about my comment https://github.com/golang/go/issues/38017#issuecomment-603042727 ?

Thank you.

Alex

ianlancetaylor

comment created time in 2 months

issue commentgolang/go

runtime: Windows service timeout during system startup

currently I am trying to repro myself from scratch in GCE.

That would be nice, if you can repro on GCE. What version of Go is your service built with?

I think additional services need to be installed to slow boot down.

What is your environment where this error happen to you? Does the error happens consistently?

Alex

kneden

comment created time in 2 months

issue commentgolang/go

os/user: On windows, current() -> t.GetUserProfileDirectory() errors when for RemoteInteractive Logon session on system without user profile

Alternatively, instead of returning, you could just make dir = nil on any error, but that's probably not an ideal solution:

I am not sure that is better than your original proposal. And I don't have good suggestions. Leaving for others to decide.

Alex

khyberspache

comment created time in 2 months

issue commentgolang/go

net: Issue with LookupAddr for "0.0.0.0" on Windows in 1.14

The main issue being difference across various OS. If the intended behaviour is to return hostname for 0.0.0.0 it should be consistent.

Fair enough. Leaving for others to decide what to do here.

Alex

prashantthakre

comment created time in 2 months

issue commentgolang/go

runtime: Windows service timeout during system startup

this issue only appears to show up (for me) if you are heavily disk I/O constrained.

@adjackura

Do you have any suggestions on how I can reproduce it? What version of Go do you use? What is your program?

Grasping for straws.

Thank you.

Alex

kneden

comment created time in 2 months

issue commentgolang/go

proposal: time: add time/tzdata package and timetzdata tag to embed tzdata in program

@ianlancetaylor

Over the years, I never needed time zone information in my program. I believe majority of Go users are in the same situation as me.

If this proposal is accepted, I am concerned that all my programs will become 800K larger. Same for many other users. I think some package developers will just add import _ "time/tzdata" to one of their source files, and all executables that use that package will silently become 800K larger.

Go executables are large as they are - #6853 - and a lot of developers spend their time making executables smaller. Every 1 K counts. And here we are just wasting 800K of their efforts on something that users won't even use.

  • adding the timezone information into a program should be optional, as it increases the size of the program by approximately 800K, and most programs do not need timezone information other than for the local system

How do you propose I will control if 800K is added to my executable or not?

The only reasonable solution I see here is to restrict import _ "time/tzdata" to main package only.

Thank you.

Alex

PS: Some runt. If this issue is to please users complaining about #21881, then someone should just spent some time and implement https://github.com/golang/go/issues/21881#issuecomment-554520916 or https://github.com/golang/go/issues/21881#issuecomment-342347609

ianlancetaylor

comment created time in 2 months

issue commentgolang/go

net: Issue with LookupAddr for "0.0.0.0" on Windows in 1.14

It shouldn't be printing that, if condition should never be satisfied. Please try the same with go1.13.x. You could also try this on macOS/*nix with go1.14 to see the difference.

Yes, I misread your original issue. I bisected this issue to cb325fed43009d5197caa5b1afa859cbc0e39355

But why do you think 0.0.0.0 should not resolve. For example, try running

Resolve-DnsName -Name 0.0.0.0 -Type PTR | FL

in Powershell. It prints

Name     : 0.0.0.0.in-addr.arpa.
Type     : PTR
TTL      : 1200
Section  : Question
NameHost : issue37657

here.

I reviewed

https://go-review.googlesource.com/c/go/+/178701

But, I am not network expert, maybe I am wrong?

Thank you.

/cc @tdabasinskas

Alex

prashantthakre

comment created time in 2 months

issue commentgolang/go

os/user: On windows, current() -> t.GetUserProfileDirectory() errors when for RemoteInteractive Logon session on system without user profile

dir, e := t.GetUserProfileDirectory()
if e != nil && e != syscall.ERROR_FILE_NOT_FOUND {
	return nil, e
}

What happens, if home disrectlry exists and t.GetUserProfileDirectory returns syscall.ERROR_FILE_NOT_FOUND for a reason?

Alex

khyberspache

comment created time in 2 months

issue commentgolang/go

time: LoadLocation doesn't work on windows if Go is not installed

With that CL, any program that imports the new time/tzdata package (as import _ "time/tzdata") will get an embedded copy of the tzdata database. ... This increases the size of the program by about 800K.

This will effectively means that all my programs will become 800K larger. Some developers of some package I use in my program will decide to include "time/tzdata", and I have to carry this useless extra disk space. This does not scale.

Alex

iman75

comment created time in 2 months

issue commentgolang/go

os/user: On windows, current() -> t.GetUserProfileDirectory() errors when for RemoteInteractive Logon session on system without user profile

cc @alexbrainman @zx2c4

I am not security expert. I wouldn't trust myself making any decisions here. Sorry.

Maybe Jason have some opinion about this.

Alex

khyberspache

comment created time in 2 months

issue commentgolang/go

net: Issue with LookupAddr for "0.0.0.0" on Windows in 1.14

@prashantthakre I just built your program with go1.14, and run it on my Windows 10 computer. And it prints

C:\Users\Alex>u:\test
2020/03/21 17:39:57 Host: issue37657

C:\Users\Alex>

What am I doing wrong?

Thank you.

Alex

prashantthakre

comment created time in 2 months

issue commentgolang/go

runtime: require GetQueuedCompletionStatusEx in Windows netpoll code

@ianlancetaylor I agree. We can remove all code that calls GetQueuedCompletionStatus.

Do you want me to do the honors?

Alex

ianlancetaylor

comment created time in 2 months

issue commentgolang/go

internal/poll: stop using dedicated threads on Windows

@ianlancetaylor I agree. We should remove all code that calls CancelIo, because it should not be needed now.

Do you want me to do the honors?

Alex

ianlancetaylor

comment created time in 2 months

issue commentgolang/go

make.bat: should use \r\n instead of \n as line delimiters

I will write a simple test that works only on the working copy and rebase the CL, so that you can approve it

Sounds good to me. As we agreed.

Alex

alexbrainman

comment created time in 2 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0

I am not convinced that adding new exported functionality is useful here. How will you use these in your code?

And IsPooling() and IsFullPooling are terrible names. How is IsPooling not full? What do we do if we discover another shade of pooling in the future? The only sensible things to do here is to use original Microsoft names - but these names aren't better.

I suggest we keep thing private until someone really needs them.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 func initDriver() error { 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_ODBC_VERSION, api.SQL_OV_ODBC3, 0) 	if IsError(ret) { 		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr", drv.h)+		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3)", drv.h)

I am still not convinced that it is helpful. But, since you insist, lets add private Error.apiParam string. And it will only be displayed, if it is not empty.

I don't want anyone use new filed directly, so we can change the code if we want to.

awaken

comment created time in 3 months

issue commentgolang/go

x/text/cmd/gotext: generate for one GOOS/GOARCH from a different GOOS/GOARCH

Not sure that will help.

You are correct, I don't see how it will solve your problem.

Alex

zx2c4

comment created time in 3 months

pull request commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

Changes for compliance with the official ODBC specifications:

Also, please move some of PR comment into commit commit. Once I submit this change, no one will see PR comment, but commit comment will remain.

Alex

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode+}++func (d *Driver) PoolMode() DriverPoolMode {+	return d.poolMode+}++func (d *Driver) IsPooling() bool {+	return d.poolMode != DriverPoolModeNone+}++func (d *Driver) IsFullPooling() bool {+	return d.poolMode == DriverPoolModeFull+}++func (d *Driver) Close() error {+	// TODO(brainman): who will call (*Driver).Close (to dispose all opened handles)?+	h := d.h+	d.h = api.SQLHENV(api.SQL_NULL_HENV)+	return releaseHandle(h) }  func initDriver() error { +	//TODO: find a way to make this attribute changeable at runtime+	//Enable connection pooling (this should be executed before allocating the environment handle)+	ret := api.SQLSetEnvUIntPtrAttr(api.SQLHENV(api.SQL_NULL_HENV), api.SQL_ATTR_CONNECTION_POOLING, api.SQL_CP_ONE_PER_HENV, api.SQL_IS_UINTEGER)+	if IsError(ret) {+		drv.poolMode = DriverPoolModeNone+	} else {+		drv.poolMode = DriverPoolModeBasic+	}+ 	//Allocate environment handle 	var out api.SQLHANDLE 	in := api.SQLHANDLE(api.SQL_NULL_HANDLE)-	ret := api.SQLAllocHandle(api.SQL_HANDLE_ENV, in, &out)+	ret = api.SQLAllocHandle(api.SQL_HANDLE_ENV, in, &out) 	if IsError(ret) { 		return NewError("SQLAllocHandle", api.SQLHENV(in)) 	} 	drv.h = api.SQLHENV(out) 	err := drv.Stats.updateHandleCount(api.SQL_HANDLE_ENV, 1) 	if err != nil {+		drv.Close() 		return err 	}  	// will use ODBC v3 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_ODBC_VERSION, api.SQL_OV_ODBC3, 0) 	if IsError(ret) {-		defer releaseHandle(drv.h)+		defer drv.Close() 		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3)", drv.h) 	} -	//TODO: find a way to make this attribute changeable at runtime-	//Enable connection pooling-	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_CONNECTION_POOLING, api.SQL_CP_ONE_PER_HENV, api.SQL_IS_UINTEGER)-	if IsError(ret) {-		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_CONNECTION_POOLING, SQL_CP_ONE_PER_HENV)", drv.h)-	}--	//Set relaxed connection pool matching-	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_CP_MATCH, api.SQL_CP_RELAXED_MATCH, api.SQL_IS_UINTEGER)-	if IsError(ret) {-		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_CP_MATCH, SQL_CP_RELAXED_MATCH)", drv.h)+	if drv.IsPooling() {+		//Set relaxed connection pool matching+		ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_CP_MATCH, api.SQL_CP_RELAXED_MATCH, api.SQL_IS_UINTEGER)+		if !IsError(ret) {

Remove next 3 lines, since drv.poolMode won't be used.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode+}++func (d *Driver) PoolMode() DriverPoolMode {+	return d.poolMode+}++func (d *Driver) IsPooling() bool {+	return d.poolMode != DriverPoolModeNone+}++func (d *Driver) IsFullPooling() bool {+	return d.poolMode == DriverPoolModeFull+}++func (d *Driver) Close() error {+	// TODO(brainman): who will call (*Driver).Close (to dispose all opened handles)?+	h := d.h+	d.h = api.SQLHENV(api.SQL_NULL_HENV)+	return releaseHandle(h) }  func initDriver() error { +	//TODO: find a way to make this attribute changeable at runtime+	//Enable connection pooling (this should be executed before allocating the environment handle)+	ret := api.SQLSetEnvUIntPtrAttr(api.SQLHENV(api.SQL_NULL_HENV), api.SQL_ATTR_CONNECTION_POOLING, api.SQL_CP_ONE_PER_HENV, api.SQL_IS_UINTEGER)+	if IsError(ret) {

Just use local variable instead. Something like

isPooling := !IsError(ret)

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode+}++func (d *Driver) PoolMode() DriverPoolMode {+	return d.poolMode+}++func (d *Driver) IsPooling() bool {+	return d.poolMode != DriverPoolModeNone+}++func (d *Driver) IsFullPooling() bool {+	return d.poolMode == DriverPoolModeFull+}++func (d *Driver) Close() error {+	// TODO(brainman): who will call (*Driver).Close (to dispose all opened handles)?+	h := d.h+	d.h = api.SQLHENV(api.SQL_NULL_HENV)+	return releaseHandle(h) }  func initDriver() error { +	//TODO: find a way to make this attribute changeable at runtime+	//Enable connection pooling (this should be executed before allocating the environment handle)

Maybe add some reference from this page

https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/driver-manager-connection-pooling?view=sql-server-ver15

explaining why you are doing what you are doing.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode+}++func (d *Driver) PoolMode() DriverPoolMode {+	return d.poolMode+}++func (d *Driver) IsPooling() bool {+	return d.poolMode != DriverPoolModeNone+}++func (d *Driver) IsFullPooling() bool {+	return d.poolMode == DriverPoolModeFull+}++func (d *Driver) Close() error {

Do not move code around - the move is not related to this PR.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode+}++func (d *Driver) PoolMode() DriverPoolMode {+	return d.poolMode+}++func (d *Driver) IsPooling() bool {+	return d.poolMode != DriverPoolModeNone+}++func (d *Driver) IsFullPooling() bool {

Same. Remove. Not needed.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode

Remove. Not needed. Just use variable in initDriver instead.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode+}++func (d *Driver) PoolMode() DriverPoolMode {+	return d.poolMode+}++func (d *Driver) IsPooling() bool {

Same. Remove. Not needed.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int+ var drv Driver  type Driver struct { 	Stats-	h       api.SQLHENV // environment handle-	initErr error+	h        api.SQLHENV // environment handle+	initErr  error+	poolMode DriverPoolMode+}++func (d *Driver) PoolMode() DriverPoolMode {

Same. Remove. Not needed.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0+	DriverPoolModeBasic DriverPoolMode = 1+	DriverPoolModeFull  DriverPoolMode = 2+)++type DriverPoolMode int

Same. Remove. Not needed.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 import ( 	"github.com/alexbrainman/odbc/api" ) +const (+	DriverPoolModeNone  DriverPoolMode = 0

Users of this package don't need to see these consts. Do they?

Remove. Not needed.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 func initDriver() error { 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_ODBC_VERSION, api.SQL_OV_ODBC3, 0) 	if IsError(ret) { 		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr", drv.h)+		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3)", drv.h) 	}  	//TODO: find a way to make this attribute changeable at runtime 	//Enable connection pooling 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_CONNECTION_POOLING, api.SQL_CP_ONE_PER_HENV, api.SQL_IS_UINTEGER) 	if IsError(ret) { 		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr", drv.h)+		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_CONNECTION_POOLING, SQL_CP_ONE_PER_HENV)", drv.h) 	}  	//Set relaxed connection pool matching 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_CP_MATCH, api.SQL_CP_RELAXED_MATCH, api.SQL_IS_UINTEGER) 	if IsError(ret) { 		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr", drv.h)+		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_CP_MATCH, SQL_CP_RELAXED_MATCH)", drv.h)

Same.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 func initDriver() error { 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_ODBC_VERSION, api.SQL_OV_ODBC3, 0) 	if IsError(ret) { 		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr", drv.h)+		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3)", drv.h) 	}  	//TODO: find a way to make this attribute changeable at runtime 	//Enable connection pooling 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_CONNECTION_POOLING, api.SQL_CP_ONE_PER_HENV, api.SQL_IS_UINTEGER) 	if IsError(ret) { 		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr", drv.h)+		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_CONNECTION_POOLING, SQL_CP_ONE_PER_HENV)", drv.h)

Same.

awaken

comment created time in 3 months

Pull request review commentalexbrainman/odbc

connection pooling setup compliant with official ODBC specs

 func initDriver() error { 	ret = api.SQLSetEnvUIntPtrAttr(drv.h, api.SQL_ATTR_ODBC_VERSION, api.SQL_OV_ODBC3, 0) 	if IsError(ret) { 		defer releaseHandle(drv.h)-		return NewError("SQLSetEnvUIntPtrAttr", drv.h)+		return NewError("SQLSetEnvUIntPtrAttr(SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3)", drv.h)

This will return

&Error{APIName: "SQLSetEnvUIntPtrAttr(SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3)"}

But "SQLSetEnvUIntPtrAttr(SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3)" is not an API name. "SQLSetEnvUIntPtrAttr" is an API name.

Error type was not designed to pass any extra parameters.

I can see how you wanted to know which of those 3 lines failed in your program. But you managed to solve this problem, probably, by adding extra print statement. And I don't see how these errors are seen by many users.

I am not sure it is worth the trouble extending Error type to support this scenario.

awaken

comment created time in 3 months

issue commentgolang/go

x/text/cmd/gotext: generate for one GOOS/GOARCH from a different GOOS/GOARCH

@zx2c4 can you use generate build tag?

https://github.com/golang/go/issues/31920#issuecomment-490652787

https://go-review.googlesource.com/c/go/+/175983/

Alex

zx2c4

comment created time in 3 months

issue commentgolang/go

make.bat: should use \r\n instead of \n as line delimiters

For instance, I could add a test within test/ that walks all GOROOT, find all batch files, and verify that they contain at least a "CRLF" sequence (or, if we want to be more precise, that it never contains a LF without a preceding CR

I would only test *.bat files in src directory. Your testing approach sounds good to me. It is difficult to say where to put the test. Maybe in cmd/go/go_test.go?

But I have no clue where I am supposed to write code that checks Gerrit downloads.

No clue.

Lets wait for a day or two. Hopefully others will chime in. Maybe even Brad will reply.

Thank you.

Alex

alexbrainman

comment created time in 3 months

issue openedgolang/go

make.bat: should use \r\n instead of \n as line delimiters

What version of Go are you using (go version)?

<pre> go version devel +b5c66de089 Sun Mar 8 19:03:08 2020 +0000 windows/amd64 </pre>

Does this issue reproduce with the latest release?

Yes, it does.

What did you do?

@rasky was changing src/make.bat file in CL 96495 and he was having unexpected errors of

The system cannot find the batch label specified - ...

while making changes to make.bat file. It appears Windows cmd.exe sometimes fails with this error when its executing batch file with only \n as delimiters. As soon as you replace \n with \r\n, everything works as expected.

@rasky send me these links with gruesome details (for anyone who is interested)

https://web.archive.org/web/20160305063042/help.wugnet.com/windows/system-find-batch-label-ftopict615555.html

https://stackoverflow.com/questions/232651/why-the-system-cannot-find-the-batch-label-specified-is-thrown-even-if-label-e/6419068

He is also provided small repro batch file - good_and_bad.zip

And indeed I can reproduce the problem on my currently updated Windows 10.

C:\Users\Alex\AppData\Local\Temp\a>good

C:\Users\Alex\AppData\Local\Temp\a>goto BROWSER

C:\Users\Alex\AppData\Local\Temp\a>bad

C:\Users\Alex\AppData\Local\Temp\a>goto BROWSER
The system cannot find the batch label specified - BROWSER

C:\Users\Alex\AppData\Local\Temp\a>

I think, we should change all *.bat files in the source tree to use \r\n instead of \n.

This is what CL 96495 does. And I am happy to +2 the CL, but decided to post here in case someone objects.

Also @bradfitz (while reviewing CL 96495) said

Please still add a test.

I want to make sure our release zip files absolutely have the right line endings.

Will the Gerrit *.tar.gz serving endpoint respect this gitattributes file? I'm not sure.

What kind of test do we want? How can we verify Gerrit *.tar.gz?

I am sure Microsoft will not change anything, but adding @jstarks FYI.

Thank you.

Alex

created time in 3 months

issue commentgolang/go

net: Interfaces() does not return all interfaces on Windows

I found the list of net.Interfaces() is same with ipconfig or GetAdaptersAddresses/GetAdaptersInfo, Wireshark use another Windows API pcap.FindAllDevs/pcapFindalldevsPtr.

Sorry, but I don't have time even to investigate this. I don't think net.Interfaces is very useful on Windows.

Alex

ChenYahui2019

comment created time in 3 months

issue commentalexbrainman/odbc

Panic on init

Here's the PR #143!

It contains a fix for better compatibility, in accordance to the odbc specs. Now I can query Teradata Vantage from Go.

As you can see, it is pretty simple, I hope you will merge it to the master branch. Greetings

I will have a look at it sometime this week.

Thank you.

Alex

HJTP

comment created time in 3 months

issue commentalexbrainman/odbc

Panic on init

I tested it, and it works properly, I am able to keep my app and running. Thanks a lot! Yes, submit it please.

No worries. Submitted.

I will send you the PR.

Sounds good.

Alex

HJTP

comment created time in 3 months

push eventalexbrainman/odbc

Alex Brainman

commit sha fd264d0ff3809a946737df4b1a0cef2a0baf6c57

do not panic in init() Instead return initDriver error from (Driver).Open.

view details

push time in 3 months

issue commentgolang/go

cmd/go: 'Access is denied' when renaming module cache directory

I think the problem is that antivirus and other tools are walking these directories and opening files as they are created, before they are renamed to their final locations.

I run this test on my computer https://play.golang.org/p/ldwnbko393L and this is what I see:

C:\Users\Alex>u:\test -test.v
=== RUN   TestRenameAfterOpenFile
    TestRenameAfterOpenFile: main_test.go:63: rename C:\Users\Alex\AppData\Local\Temp\TestRename993273147\from C:\Users\Alex\AppData\Local\Temp\TestRename993273147\to: Access is denied.
--- FAIL: TestRenameAfterOpenFile (1.05s)
=== RUN   TestRenameAfterChdir
    TestRenameAfterChdir: main_test.go:63: rename C:\Users\Alex\AppData\Local\Temp\TestRename352688990\from C:\Users\Alex\AppData\Local\Temp\TestRename352688990\to: Access is denied.
--- FAIL: TestRenameAfterChdir (1.02s)
FAIL

C:\Users\Alex>

So, I agree, os.Rename will not work properly in general. I don't think we should use os.Rename to move directories.

But that does not mean we cannot implement this process in the way that works on Windows.

For example, we could store cache directory locations in a little table of import_path -> random_path_on_my_disk pairs (text file or something). Then you download your package zip into random directory (it can starts with some recognizable name to help debugging), and then you update your text file / table to note where package files are stored.

My example is very simplistic. I am sure you guys can come up with something better.

Alex

kiwionly

comment created time in 3 months

issue commentalexbrainman/odbc

Panic on init

I would be great if you can change the initDriver function for returning a little more detailed error,

https://github.com/alexbrainman/odbc/tree/do_not_panic

change is only about not panicking during init. If you want to change error messages, please, send separate PR.

So, should I submit do_not_panic branch? Does it fixes your problem of not panicking in init?

Thank you.

Alex

HJTP

comment created time in 3 months

issue commentalexbrainman/odbc

Panic on init

Therefore, I am just asking you to avoid to call panic from any init function. You might keep track of the arisen error (from init) into some (unexported) global variable, so that, any future call for creating a new database instance will fail, returning this error. Does it sound appropriate to you?

It does sounds good to me.

I just pushed this branch

https://github.com/alexbrainman/odbc/tree/do_not_panic

with your change. Does it look good to you?

Thank you.

Alex

HJTP

comment created time in 3 months

create barnchalexbrainman/odbc

branch : do_not_panic

created branch time in 3 months

more