runtime: invalid string values

[alxtrsintegra]

What version of Go are you using (go version)?

go version go1.18.3 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

set GOHOSTARCH=amd64
set GOHOSTOS=windows

What did you do?

I have long running process and after few hours I this error

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x942db0]

goroutine 10644263 [running]:
strings.Count({0x0?, 0x1f75651aee0?}, {0x17dcc00?, 0x1f72eff0eb8?})
	C:/Program Files/Go/src/strings/strings.go:47 +0x50
strings.Replace({0x0, 0x2d}, {0x17dcc00, 0x1}, {0x0, 0x0}, 0xffffffffffffffff)
	C:/Program Files/Go/src/strings/strings.go:1003 +0xcf
src/data_copy/trg_db/mapper.(*OrderMgr).removeNull(...)

All I'm trying to do here is this

removeNull(inputStr string) string {
  return strings.Replace(inputStr, "\x00", "", -1)
}

and the reason I'm trying to do it because strings.Trim(inputStr) was crashing with the similar error few lines below. Not sure how to reproduce this issue, because when I restart the process from the point when it died, it works and I don't see this issue again. Next time I restart process from beginning, 50/50 it is going to happen again (not at the same spot where it failed last time).

[ianlancetaylor]

Your string values look corrupt. That should be impossible in a pure Go program with no races. Have you run your program under the race detector? Are you creating the strings in unsafe ways? Does your program use cgo?

Is there a way that we can reproduce the problem?

[alxtrsintegra]

Yes, program pulls data and spread across 20 go routines for processing. Don't use cgo, but you are right, I started it with race detector and see a few. Will fix / re-test and update here results. Thank you for help.

[alxtrsintegra]

@ianlancetaylor, as soon as races were fixed all issues with strings disappeared. It now makes sense why it happened, but tbh without your reply I wouldn't be able to resolve it as I wasn't even digging this way. Does it make sense to show a better error message (like in maps) or maybe make simple data types thread-safe?

[randall77]

For maps it is possible to show an error because there is a spot in memory to record whether anyone is accessing it, and how (read or write). That spot doesn't exist for strings.

Unfortunately, it would be very expensive to make strings thread safe.