when calling strings.Split, it panics.

[LihuaWu]

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

$ go version
go1.13.5

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
Linux amd64

What did you do?

We just call the func strings.Split() in our app.

What did you expect to see?

do not panic.

What did you see instead?

It panics. details as follows
dat.txt

[ianlancetaylor]

Please show us a small program that demonstrates the problem. Thanks.

[hantmac]

I suspect that it was caused by out of index because of your incorrect code.

[LihuaWu]

@ianlancetaylor
I don't have a way to reproduce this case for now since it is caused in the production environment.
IMHO, strings.Split should not panic in whatever cases.

@hantmac
We just call strings.Split in the most trivial way. If it is incorrect as what you suspect, it is a library internal issue, I believe.

[rsc]

It's true that strings.Split should never panic. However, many many Go users are using strings.Split every day and not seeing panics. There is nothing obviously wrong with strings.Split. For us to debug this further, we need a specific piece of code that panics reliably. Otherwise there's really very little we can do.

The crashing line in your stack trace is:

 1044				return bytealg.IndexString(s, substr)

It is unclear why there is no stack frame for bytealg.IndexString itself. Something is very strange about your environment.

[LihuaWu]

Yes, it is true.
The code is cross-compiled in a mac environment and the program is running on a Linux server. Do you think this is the issue that the stack frame is lost?

[randall77]

Something strange is happening here. One of the strings on the stack has gone bad. If you look at the entry for strings.Count:

strings.Count(0x14, 0x2a, 0xcf103a, 0x3, 0xc00019e9a0)

That first string is bad. It has a backing store pointer of 0x14, which is clearly wrong.
That string is derived from the first string passed to strings.genSplit, which looks ok. The former is a subslice of the latter, but you can't get a bad backing store pointer from slicing a string like that.

I suspect clobbering of the stack from some unknown source. Hard to be sure. Running with -race may find something suspicious. Audit all your uses of unsafe.

[randall77]

I don't think cross-compiling would be a problem, unless you use cgo and your C cross-compiler setup is broken. Which seems unlikely - that would probably cause a crash long before this code could execute.

[LihuaWu]

@randall77
I don't know the stack format in golang quite well, it is different from c language and is not obvious to understand.
I wonder if 0x14 represents the backing store pointer for the first string.

It seems hard to trace the root cause for now, and obviously not a reason of strings.Split itself.
I will close this ticket if you can do nothing more.
Thanks for your time.

[davecheney]

This looks like memory corruption. Have you tried running your program under the race detector? See https://blog.golang.org/race-detector .

[elipoz]

this can happen if a string is created from a []byte slice with some non utf-8 literals.
https://blog.golang.org/strings explains that iteration over bytes and over runes is not the same.