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. 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 <https://go.dev/play/p/AGMEBkD3JbA>, for debugging. That should at least tell you whether it's nil, as a first step. On Sun, Sep 25, 2022 at 8:36 PM Jason Phillips <jasonryanphill...@gmail.com> wrote: > Have your tried building and running your application with the race > detector enabled[1]? You may have a data race. > > 1 - https://go.dev/doc/articles/race_detector > > On Sunday, September 25, 2022 at 2:16:23 PM UTC-4 Bernd Fix wrote: > >> Hi folks, >> >> I am using go1.19.1 for development and see a strange panic ("invalid >> memory address") in an application; the panic is definitely not >> triggered by a nil dereference (the object in question is a string): >> >> key = peer.Key() >> entry, ok := tbl.recs[key] >> >> The panic happens in the second line of the code. After checking that >> 'tbl' and 'tbl.recs' are valid (not nil), I inserted a log line in >> between: >> >> key = peer.Key() >> log.Printf("Key=%v", key) >> entry, ok := tbl.recs[key] >> >> Now the panic happens in the log line; the object 'key' seems to have an >> invalid address (but I don't know how I can check if I can't access the >> object and printf, where the new panic happens, obviously doesn't know >> either). >> >> The 'Key()' function returns a string (there is no way to return nil >> from a function with a string return value that I know of), so obviously >> something strange is going on. >> >> It even got a bit stranger when I removed the log line and tried a >> recover: >> >> defer func() { >> if r := recover(); r != nil { >> log.Printf("key=%s", peer.Key()) >> log.Printf("key=%v", key) >> } >> }() >> >> The first log line (now) works (it delivers a valid string result), but >> the second line still panics within recovery. >> >> Maybe I should mention that the application heavily uses channels and go >> routines; I have the subjective impression that the more go routines are >> running the more likely the panic occurs after some time. But maybe that >> is irrelevant. >> >> I compiled the same source with go1.18 (the earliest version that could >> compile the code), and the panic still occurs. >> >> Is there anthing I can do to hunt down the problem? I am happy to share >> the code (it is free software anyway) and can explain how to reproduce >> the panic on your own machine (I guess that running the application >> might requires some explanation). >> >> Cheers, Bernd. >> >> -- > 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/1c12eec5-470a-491c-b18f-741f34cecba6n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/1c12eec5-470a-491c-b18f-741f34cecba6n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfHguW0T6NQjV83ojUHk0KuLqhR319ztmcVOGmSAhtHSfA%40mail.gmail.com.
