Re: [go-nuts] BoringCrypto on arm64?

[Eric Hubbard]

Not sure if this helps but there is also this repo that does things a
little differently..

https://github.com/golang-fips/go

-Eric
http://www.google.com/profiles/eric.hubbard


On Mon, Sep 26, 2022 at 12:02 PM Ian Lance Taylor  wrote:

> On Mon, Sep 26, 2022 at 2:51 PM Louisa Berger  wrote:
> >
> > I've been using the BoringCrypto package, and would like to use it on
> Graviton as well. I see from the caveat here (
> https://go.googlesource.com/go/+/dev.boringcrypto/misc/boring#caveat )
> that BoringCrypto is only supported for GOOS=linux, GOARCH=amd64.
> >
> > Are there any plans to support BoringCrypto on arm64? If so, when? And
> if not, is there a recommended alternative?
>
> On tip, and the future Go 1.20, you can build with
> GOEXPERIMENT=boringcrypto, and get a version of Go that uses
> boringcrypto and supports arm64.  This was added in
> https://go.dev/cl/423362.  Not sure whether it is documented anywhere
> yet.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcULMkdHjX1Ww4Vr_4SLOuBW1JiCjwWpoZLVkgYk%3DK%3DcyQ%40mail.gmail.com
> .
>

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

Re: [go-nuts] BoringCrypto on arm64?

[Ian Lance Taylor]

On Mon, Sep 26, 2022 at 2:51 PM Louisa Berger  wrote:
>
> I've been using the BoringCrypto package, and would like to use it on 
> Graviton as well. I see from the caveat here 
> (https://go.googlesource.com/go/+/dev.boringcrypto/misc/boring#caveat ) that 
> BoringCrypto is only supported for GOOS=linux, GOARCH=amd64.
>
> Are there any plans to support BoringCrypto on arm64? If so, when? And if 
> not, is there a recommended alternative?

On tip, and the future Go 1.20, you can build with
GOEXPERIMENT=boringcrypto, and get a version of Go that uses
boringcrypto and supports arm64.  This was added in
https://go.dev/cl/423362.  Not sure whether it is documented anywhere
yet.

Ian

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

[go-nuts] BoringCrypto on arm64?

[Louisa Berger]

Hello, 

I've been using the BoringCrypto package, and would like to use it on 
Graviton as well. I see from the caveat here (
https://go.googlesource.com/go/+/dev.boringcrypto/misc/boring#caveat ) that 
BoringCrypto is only supported for GOOS=linux, GOARCH=amd64. 

Are there any plans to support BoringCrypto on arm64? If so, when? And if 
not, is there a recommended alternative?

Thank you! 

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

[go-nuts] Re: Go Get Issues

[Rich]

After I posted this on Friday I saw about adding .git to the end, and that 
didn't work. Then it started saying:

repository.web.mycompany.com/st_nsres.git 
but package is
repository.web.mycompany.com/st_nsres 


Or something like that. What I had to do was delete the go.mod of 
repository.web.mycompany.com/st_nsres 
, reinitialize go mod 
init repository.web.mycompany.com/st_nsres.git. I then pushed that, created 
a tag:
git tag "v0.1.1", then git push origin "v0.1.1". 

Then in the application I built that used that package I had to go get "
repository.web.mycompany.com/st_nsres.git". --THEN it started working.

When I look at the source code to go get  -- MAN the work the Go authors 
put into that is pretty amazing. Does anybody think it might be possible to 
write a go git command that might do the same things go get does but ... 
just for git?  In the days before go mod, I could just go into my goroot: 
go/src/repository.web.mycompany.com/ then do a git pull 
repository.web.mycompany.com/st_nsres.git. From there Go would look for it 
there and you wouldn't need to do a go get on it. I am not sure where it 
stores it today, if it were possible to somehow cache it manually like that?

Thanks for the help Christoph!!!


On Sunday, September 25, 2022 at 7:20:48 AM UTC-4 christoph...@gmail.com 
wrote:

> Hi Rich,
>
> I guess, you run into the behavior described here 
> :
>
>
> *> To declare the code location, an import path of the form> *
> repository.vcs/path
> *> specifies the given repository, with or without the .vcs suffix, using 
> the named version control system, and then the path inside that repository.*
> *> (...)*
> *> If the import path is not a known code hosting site and also lacks a 
> version control qualifier, the go tool attempts to fetch the import over 
> https/http and looks for a  tag in the document's HTML . *
> (emphasis mine)
>
> So it seems the go get command does not recognize the import path to be a 
> Git repository. Otherwise it would have tried SSH, too.
>
> I would try changing the import path to 
> repository.web.mycompany.com/st_nsres.git to give go get a hint that the 
> import path is a Git repo.
>
> On Saturday, September 24, 2022 at 1:14:45 AM UTC+2 Rich wrote:
>
>> Sorry the last line was messed up.
>>
>> The error I get is:
>>  github.com/stretchr/testify/require: 
>> repository.web.mycompany.com/st_nsres@ v0.2.0: unrecognized import 
>> path "repository.web.mycompany.com/st_nsres":   https fetch: Get "
>> https://repository.web.mycompany.com/st_nsres?go-get=1":  Unable to 
>> connect
>>
>> It keeps trying to connect via https -- IT's SSH
>> Again I have ~/.gitconfig configured:
>>
>> [url "ssh://g...@internal.repository.web.mycompany.com:7999/ 
>> "]
>>  insteadOf = https://repository.web.mycompany.com/
>>
>> And GOPRIVATE set to repository.web.mycompany.com
>> On Friday, September 23, 2022 at 4:59:44 PM UTC-4 Rich wrote:
>>
>>> I have been having a really hard time with Go Get It just isn't working. 
>>> We have a private Repositiory, that repository requires us to use SSH. 
>>> There is no option for using https.
>>>
>>> So, I've configured my git config "~/.gitconfig' 
>>>
>>> ```
>>> [url "ssh://g...@internal.repository.web.mycompany.com:7999/ 
>>> "]
>>>  insteadOf = https://repository.web.mycompany.com/
>>> ```
>>> I have GOPRIVATE set
>>> ```
>>> export GOPRIVATE="repository.web.mycompany.com"
>>> ```
>>> Then when I use go get:
>>> ```
>>> repository.web.mycompany.com
>>> ```
>>>
>>

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

[go-nuts] Re: how to organise code with channels and error handling?

['Bryan C. Mills' via golang-nuts]

On Friday, September 23, 2022 at 10:24:36 AM UTC-4 joche...@gmail.com wrote:

> Dear all,
>
> I am writing a program which processes data in stages.  To structure the 
> code cleanly, I would like implement each stage as an individual function 
> and use channels to pass data between stages.
>

I would suggest that you reconsider whether a channel architecture is 
really cleaner after all.
It is usually much easier to reason about functions that accept and return 
values than about long-running goroutines.

For example, you could restructure your example as (
https://go.dev/play/p/R0eDbFKnKgE):
• an iterator function (instead of a channel) that returns the next value 
when called
• a synchronous “process” function that returns a result and error, and
• a synchronous “add” method that accumulates the result.

That results in a somewhat larger “func main”, but makes the error behavior 
much clearer and substantially reduces the risk of things like deadlocks 
and goroutine leaks.

For (much) more detail, see the first section of my talk on Rethinking 
Classical Concurrency Patterns 
 from 
GopherCon '18.

My questions:
> - How to structure the code?  Is my approach described below reasonable?
> - How to deal with errors?
>
> Here is a sketch of I currently have (runnable version at 
> https://go.dev/play/p/7Rrq-OLARl_R ):
>
> func getInputs() <-chan t1 {
> c := make(chan t1)
> go func() {
> for ... {
> ...
> c <- x
> }
> close(c)
> }()
> return c
> }
>
> func process(in <-chan t1) <-chan t2 {
> c := make(chan t2)
> go func() {
> for i := range in {
> x, err := ...
> _ = err // what to do with the error?
> c <- x
> }
> close(c)
> }()
> return c
> }
>
> func main() {
> c1 := getInputs()
> c2 := process(c1)
> summarise(c2)
> }
>
> There are some things I like about this approach:
>
>- the main function looks nice and tidy
>- the stages of work are cleanly separated
>
> But there are also things I don't like:
>
>- I can't see an obvious way to handle errors in the stages.  In my 
>case the first stage is locating input files on the file system, and there 
>may be read errors etc.  The second stage processes the files, and files 
>may have invalid contents.
>- The code for the individual stages looks a bit strange with the 
>double indentation from the outer func(){} and the go func() {}().
>
> So my questions are:
>
>- What would be a good way to incorporate error handling into my 
>code?  I assume this will require one or more additional channels, just 
> for 
>errors.  Or is there a better way?
>- Is there a better way to structure my code?
>
> Many thanks,
> Jochen
>
>

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

Re: [go-nuts] Invalid memory address of string object

[Kurtis Rader]

On Mon, Sep 26, 2022 at 12:03 AM Bernd Fix  wrote:

> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x49388d]
>

Notice the "addr=0x0"? That's a nil pointer dereference.


> > Can you show the definition of peer.Key()?
>
> Sure:
>
> // Key returns a string used for map operations
> func (p *PeerID) Key() string {
>  if p == nil {
>  return "(nil)"
>  }
>  if len(p.str64) == 0 {
>  p.str64 = base64.StdEncoding.EncodeToString(p.Data)
>  }
>  return p.str64
> }
>

I agree with Axel's hypothesis when he writes: "So I would guess something
is calling this method concurrently (or calling it concurrently with a
similar method), causing a data-race, returning a string which has the
length of the base64.EncodeToString return value, but not the data
pointer."  Try doing everything inside that function while holding a mutex.
I'll bet the problem disappears. Which is not to say that is the correct
fix but would confirm or refute the hypothesis.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

Re: [go-nuts] importing Go is static linking or dynamic linking?

[TheDiveO]

Actually, it depends on which std libs are used. 
https://www.arp242.net/static-go.html is a concise introduction. net and 
os/user normally prevent a static binary, unless build tags netgo and 
osusergo are used.

On Monday, September 26, 2022 at 4:37:00 PM UTC+2 Ian Lance Taylor wrote:

> On Mon, Sep 26, 2022 at 7:22 AM Jessica Park
>  wrote:
> >
> > When java...
> > can import .jar ... in this case, we call dynamic link..
> >
> > How about golang?
> >
> > Is it dynamic linking or static linking?
>
> A pure Go program that does not use cgo will use static linking on
> most operating systems.
>
> A mixed Go/C program that does use cgo will use dynamic linking on
> most operating systems.
>
> > I need clear information.
>
> A more precise answer will require more details as to exactly what you
> are doing and what operating system you are using.
>
> Ian
>

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

Re: [go-nuts] importing Go is static linking or dynamic linking?

[Ian Lance Taylor]

On Mon, Sep 26, 2022 at 7:22 AM Jessica Park
 wrote:
>
> When java...
> can import .jar ... in this case, we call dynamic link..
>
> How about golang?
>
> Is it dynamic linking or static linking?

A pure Go program that does not use cgo will use static linking on
most operating systems.

A mixed Go/C program that does use cgo will use dynamic linking on
most operating systems.

> I need clear information.

A more precise answer will require more details as to exactly what you
are doing and what operating system you are using.

Ian

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

[go-nuts] importing Go is static linking or dynamic linking?

[Jessica Park]

When java...
can import .jar ... in this case, we call dynamic link..

How about golang?

Is it dynamic linking or static linking?

I need clear information.
Thank you.

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

Re: [go-nuts] Invalid memory address of string object

['Axel Wagner' via golang-nuts]

Also, this is consistent with your observation that calling peer.Key again
returns a valid string. After the first call (returning the invalid string)
the concurrent modification of p.str64 has finished and subsequent calls
return the full value.

Which is to say: Run your code under the race detector. It should catch
this.

You mentioned above that you checked that all accesses to "unsafe
structures like maps or arrays" are protected by mutexes. But that's a
fallacy. *Any* concurrent access must be made safe. There is no such thing
as a benign data race.

On Mon, Sep 26, 2022 at 11:20 AM Axel Wagner 
wrote:

> On Mon, Sep 26, 2022 at 9:03 AM Bernd Fix  wrote:
>
>> Sure:
>>
>> // Key returns a string used for map operations
>> func (p *PeerID) Key() string {
>>  if p == nil {
>>  return "(nil)"
>>  }
>>  if len(p.str64) == 0 {
>>  p.str64 = base64.StdEncoding.EncodeToString(p.Data)
>>  }
>>  return p.str64
>> }
>>
>
> Looking at this code, the only cay I can imagine this returning such an
> invalid string is a data race.
> Note that calling PeerID.Key is not concurrency safe, as it both reads an
> writes p.str64, without any sort of mutex or atomicity - but it might very
> well *seem* that way, as it might *seem* it should be a read-only operation.
> So I would guess something is calling this method concurrently (or calling
> it concurrently with a similar method), causing a data-race, returning a
> string which has the length of the base64.EncodeToString return value, but
> not the data pointer.
>
>
>>
>> > Is it (or any function it calls) using "unsafe"?
>>
>> As said before, "sdlcanvas" as a cgo library might use that but it is
>> not logically involved in the process that panics.>Y<
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/3a7e6721-1a4e-c789-97aa-132f1a76466b%40hoi-polloi.org
>> .
>>
>

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

Re: [go-nuts] Invalid memory address of string object

['Axel Wagner' via golang-nuts]

On Mon, Sep 26, 2022 at 9:03 AM Bernd Fix  wrote:

> Sure:
>
> // Key returns a string used for map operations
> func (p *PeerID) Key() string {
>  if p == nil {
>  return "(nil)"
>  }
>  if len(p.str64) == 0 {
>  p.str64 = base64.StdEncoding.EncodeToString(p.Data)
>  }
>  return p.str64
> }
>

Looking at this code, the only cay I can imagine this returning such an
invalid string is a data race.
Note that calling PeerID.Key is not concurrency safe, as it both reads an
writes p.str64, without any sort of mutex or atomicity - but it might very
well *seem* that way, as it might *seem* it should be a read-only operation.
So I would guess something is calling this method concurrently (or calling
it concurrently with a similar method), causing a data-race, returning a
string which has the length of the base64.EncodeToString return value, but
not the data pointer.


>
> > Is it (or any function it calls) using "unsafe"?
>
> As said before, "sdlcanvas" as a cgo library might use that but it is
> not logically involved in the process that panics.>Y<
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3a7e6721-1a4e-c789-97aa-132f1a76466b%40hoi-polloi.org
> .
>

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

Re: [go-nuts] Invalid memory address of string object

[Bernd Fix]

No, p.Data is not nil - and the panic does not happen in the Key() 
method, but in the code from my first email.>Y<


On 9/26/22 07:08, Andrew Harris wrote:

could p.Data could be nil here?

On Monday, September 26, 2022 at 12:03:20 AM UTC-7 Bernd Fix wrote:


On 9/25/22 19:05, Kurtis Rader wrote:

Insufficient information. Show us the panic

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x49388d]

goroutine 100037 [running]:
leatea/core.(*ForwardTable).Learn(0xcb6d80, 0xc000c22660)
/prj/net/routing/leatea/core/forward_table.go:455 +0x25a
leatea/core.(*Node).Receive(0xcb6d80, {0x7275b0?, 0xc000c22660?})
/prj/net/routing/leatea/core/node.go:164 +0x2f5
created by leatea/core.(*Node).Start
/prj/net/routing/leatea/core/node.go:98 +0x2ea


Are you using CGO?


A third party library ("sdlcanvas") does, but I don't think it is
related to the problem as rendering happens later (after the panic).


Can you show the definition of peer.Key()?


Sure:

// Key returns a string used for map operations
func (p *PeerID) Key() string {
if p == nil {
return "(nil)"
}
if len(p.str64) == 0 {
p.str64 = base64.StdEncoding.EncodeToString(p.Data)
}
return p.str64
}


Is it (or any function it calls) using "unsafe"?


As said before, "sdlcanvas" as a cgo library might use that but it is
not logically involved in the process that panics. >Y<






--
"Es sind nicht die besten Massen, die für Brot und Spiele den Verlust
der Freiheit verschmerzen." (Kautsky, 1919, "Diktatur des Proletariats")

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ee956d09-ae19-30cf-a6fa-782519fdf91f%40hoi-polloi.org.

Re: [go-nuts] Invalid memory address of string object

[Andrew Harris]

could p.Data could be nil here?

On Monday, September 26, 2022 at 12:03:20 AM UTC-7 Bernd Fix wrote:

> On 9/25/22 19:05, Kurtis Rader wrote:
> > Insufficient information. Show us the panic
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x49388d]
>
> goroutine 100037 [running]:
> leatea/core.(*ForwardTable).Learn(0xcb6d80, 0xc000c22660)
> /prj/net/routing/leatea/core/forward_table.go:455 +0x25a
> leatea/core.(*Node).Receive(0xcb6d80, {0x7275b0?, 0xc000c22660?})
> /prj/net/routing/leatea/core/node.go:164 +0x2f5
> created by leatea/core.(*Node).Start
> /prj/net/routing/leatea/core/node.go:98 +0x2ea
>
> > Are you using CGO?
>
> A third party library ("sdlcanvas") does, but I don't think it is 
> related to the problem as rendering happens later (after the panic).
>
> > Can you show the definition of peer.Key()?
>
> Sure:
>
> // Key returns a string used for map operations
> func (p *PeerID) Key() string {
> if p == nil {
> return "(nil)"
> }
> if len(p.str64) == 0 {
> p.str64 = base64.StdEncoding.EncodeToString(p.Data)
> }
> return p.str64
> }
>
> > Is it (or any function it calls) using "unsafe"?
>
> As said before, "sdlcanvas" as a cgo library might use that but it is 
> not logically involved in the process that panics. >Y<
>

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

Re: [go-nuts] Invalid memory address of string object

[Bernd Fix]

On 9/25/22 19:05, Kurtis Rader wrote:

Insufficient information. Show us the panic

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x49388d]

goroutine 100037 [running]:
leatea/core.(*ForwardTable).Learn(0xcb6d80, 0xc000c22660)
/prj/net/routing/leatea/core/forward_table.go:455 +0x25a
leatea/core.(*Node).Receive(0xcb6d80, {0x7275b0?, 0xc000c22660?})
/prj/net/routing/leatea/core/node.go:164 +0x2f5
created by leatea/core.(*Node).Start
/prj/net/routing/leatea/core/node.go:98 +0x2ea


Are you using CGO?


A third party library ("sdlcanvas") does, but I don't think it is 
related to the problem as rendering happens later (after the panic).



Can you show the definition of peer.Key()?


Sure:

// Key returns a string used for map operations
func (p *PeerID) Key() string {
if p == nil {
return "(nil)"
}
if len(p.str64) == 0 {
p.str64 = base64.StdEncoding.EncodeToString(p.Data)
}
return p.str64
}


Is it (or any function it calls) using "unsafe"?


As said before, "sdlcanvas" as a cgo library might use that but it is 
not logically involved in the process that panics.>Y<


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3a7e6721-1a4e-c789-97aa-132f1a76466b%40hoi-polloi.org.

Re: [go-nuts] Re: Invalid memory address of string object

[Bernd Fix]

On 9/25/22 19:06, 'Axel Wagner' via golang-nuts wrote:

Another possibility is someone trying (and failing) to use unsafe to speed
things up in a []byte/string conversion and accidentally converts a
nil-slice.


No unsafe in my own code, but I use a third-party library ("sdlcanvas") 
for rendering that I think is using cgo and might use unsafe too, but 
that does not relate to the part of the code that panics.



It's also possible that the value is not nil, but a pointer to another
piece of invalid memory - an mmaped region which got unmapped or a string
pointing into the C stack, or something.

FWIW you can check the actual data pointer of the string using unsafe
, for debugging. That should at least
tell you whether it's nil, as a first step.


I will try that; thanks for the advice.>Y<

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/47103683-7d0f-215b-c41a-2dd0ba140e19%40hoi-polloi.org.

Re: [go-nuts] Re: Invalid memory address of string object

[Bernd Fix]

On 9/25/22 18:35, Jason Phillips wrote:

Have your tried building and running your application with the race
detector enabled[1]? You may have a data race.


Thanks for the advice; that is possible although I have checked that 
access to all unsafe types like maps and arrays is controlled by 
mutexes, but something might have escaped my attention. Will check as 
soon as I can.>Y<


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7ad1b740-de59-3560-a0ea-0c84ee608fcb%40hoi-polloi.org.