Say I install golang 1.20.12 and go clean -cache and go clean -modcache.
Then I build.
Will that executable be using crypto/tls and other packages "as they were
in 1.20.12"? Or is golang fetching the newest available compatible sources,
and therefore I may be spinning my wheels trying to see if
I tried go1.21.6 and see the same behavior. I'm going to try to backport
the project to go1.18 to see what happens.
On Wednesday, January 10, 2024 at 3:51:16 PM UTC-8 Andrew Athan wrote:
> As you can see in the below output from pprof, the golang TLS
> implementation seems to be i
As you can see in the below output from pprof, the golang TLS
implementation seems to be in some kind of tight loop in
crypto/internal/bigmod.addMulVVW2048 causing CPU starvation, wherein the
net.HTTP server stops calling my request handler. Eventually the TLS
handshakes fail, and the connectio
This stack trace was indeed a contexts with very deep parenthood.
On Friday, May 12, 2023 at 8:34:40 AM UTC-7 Andrew Athan wrote:
> Alex:
>
> I’ll see how/if this can happen. Among other strangeness in this stack is
> that Err() doesn’t take a param but I guess it may be di
that context was `nil` or otherwise invalid, that would explain why the panic happens. Though I'm not sure how that would happen, unless you use `unsafe` somewhere.On Fri, May 12, 2023 at 5:03 AM Andrew Athan <andrew...@gmail.com> wrote:goroutine 1299607 [runnable]:context.(*valueCtx).Err
goroutine 1299607 [runnable]:
context.(*valueCtx).Err(0xc00a52c3c0?)
:1 +0x3e
context.(*valueCtx).Err(0x48860a?)
:1 +0x2a
... repeats many many many times ...
...additional frames elided...
created by
one_of_my_functions()
somefile.go:2092 +0x4a5
What is going on here? is this likely to be an
I could go read the source code so thanks in advance for saving me that
step. Part of the reason I"m writing here is to also understand the
recommended pattern...
Does StateActive imply the handler function will definitely be called, or
can this state occur without the Handler ever being called
conn.Close()
}
???
I'll install golang 1.20 and see if the code has been improved and/or will
submit a PR
On Friday, February 10, 2023 at 2:25:53 PM UTC-8 Andrew Athan wrote:
> Sorry, I meant to mention this is go 1.19
>
> On Friday, February 10, 2023 at 2:24:39 PM UTC-8 Andrew Athan
Sorry, I meant to mention this is go 1.19
On Friday, February 10, 2023 at 2:24:39 PM UTC-8 Andrew Athan wrote:
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x5d073c]
> goroutine 4133611
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x5d073c]
goroutine 4133611 [running]:
crypto/tls.(*Conn).handshakeContext.func2()
/usr/local/go/src/crypto/tls/conn.go:1441 +0xbc
created by crypto/tls.(*Conn).ha
Wed, Jan 25, 2023 at 12:05 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Wed, 2023-01-25 at 07:21 -0800, Andrew Athan wrote:
> > I'm sure I'm not the first to say this, but here's my +1:
> >
> > It seems wr
I'm sure I'm not the first to say this, but here's my +1:
It seems wrong to me that golang displays nil-valued reference types as an
empty instance of the type with no indication that the reference is nil.
E.g.
```
var m map[string]string
fmt.Printf("%+v",m)
```
displays as "map[]"
I think it
Ian:
Thanks. The example I posted is a silly uber short simplification of my
usecase. In fact, have a complex struct with a large set of methods and
only one of the methods requires comparable types; it'd be nice to not have
to constrain to comparable at the struct level, and only have actual
ice not to jump through declarative hoops to make that happen.
A.
On Wednesday, January 18, 2023 at 4:59:51 PM UTC-8 bse...@computer.org
wrote:
> On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan wrote:
>
>> (Possibly related to issues such as those discussed in
>> https://groups.
I found the error message so
confusing. v==v, after all, involves two variables of the exact same type
by definition :)
A.
On Wednesday, January 18, 2023 at 4:59:51 PM UTC-8 bse...@computer.org
wrote:
> On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan wrote:
>
>> (Possibly related
(Possibly related to issues such as those discussed
in https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?)
If I do:
```
func Foo[V any](v V)bool {
return v==v
}
```
golang 1.19 reports:
```
invalid operation: v == v (incomparable types in type set)
```
There are two issu
involved
are inlined, etc...
On Monday, December 5, 2022 at 3:18:09 PM UTC-8 Andrew Athan wrote:
> The statement I made is actually a bit stronger than the one you
> confirmed: Even if the goroutines are using atomic load/store, the
> preemtive nature of the os threads could easily inte
ssion about
same here:
https://github.com/alphadose/haxmap/issues/26
(I ran across haxmap while reviewing issues in the golang repo relative to
sync.Map)
On Monday, December 5, 2022 at 10:45:10 AM UTC-8 Ian Lance Taylor wrote:
> On Mon, Dec 5, 2022 at 10:03 AM Andrew Athan wrote:
> >
I'm having trouble finding definitive information about golang's preemption
model when running with GOMAXPROCS>1 on a multi-core Intel with preemtive
linux kernel.
As I understand it, in such a scenario, two goroutines may be scheduled by
the go runtime onto two separate system threads on two s
Thursday, December 1, 2022 at 3:53:13 PM UTC-8 Ian Lance Taylor wrote:
> On Thu, Dec 1, 2022 at 3:23 PM Andrew Athan wrote:
> >
> > I am new to go devops (but not to the language). First, I must say, the
> go module documentation is thorough but absolutely inscrutable for new
>
I am new to go devops (but not to the language). First, I must say, the go
module documentation is thorough but absolutely inscrutable for new users.
Googling for things like "golang add github module vendor" brings up what
appear to be either outdated or incorrect cookbooks. I've already wasted
21 matches
Mail list logo
