I would check if it reproduces on Go 1.16.2
On Thursday, 25 March 2021 at 05:50:24 UTC Kurtis Rader wrote: > On Wed, Mar 24, 2021 at 8:25 PM Kurtis Rader <kra...@skepticism.us> wrote: > >> On Wed, Mar 24, 2021 at 7:05 PM awer...@gmail.com <awer...@gmail.com> >> wrote: >> >>> Oh, we've got another confirmed case of the scary runtime error. I guess >>> now the question is, does anybody know of any memory corruption bugs in >>> macOS and go1.15.5? I didn't see anything obvious. >>> >> >> I'm unaware of any memory corruption bugs inimical to Go on macOS. Note >> that you can use the vmmap(1) command to examine the memory map of a >> process on macOS. On my system running that against an Elvish process (a >> shell written in Go) does not show any addresses with a 0xffffff prefix. So >> the 0xfffffff800000019 address is suspicious on its face. The first half >> would be -8 interpreted as an int32 and the second half would be 25 >> (decimal). You say the "memory referenced by the stack trace should have >> been allocated at init time". What do you mean by that? Are you saying you >> explicitly mmap memory at 0xfffffff80000000 (or a base address in the >> general range)? That doesn't seem likely so I don't know how to interpret >> your assertion. >> > > Also, values like 8 (and -8, 4, -4) are particularly suspect in problems > of this nature since they suggest invalid pointer arithmetic. > > -- > 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/62aceb2b-162d-4a79-b2f1-584f80bf3c84n%40googlegroups.com.
