On Wed, Mar 24, 2021 at 7:05 PM awer...@gmail.com <awerne...@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. Looking at your project it appears you are using CGO which means the most likely cause of the corruption is the linked C code. -- 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%3DD98KND2m87R7-VpYqLVWYrceJeciJxR%3DJqu6ytoHd_jzA%40mail.gmail.com.
