Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

when calling strings.Split, it panics. #39495

Closed
LihuaWu opened this issue Jun 10, 2020 · 9 comments
Closed

when calling strings.Split, it panics. #39495

LihuaWu opened this issue Jun 10, 2020 · 9 comments

Comments

@LihuaWu
Copy link

@LihuaWu LihuaWu commented Jun 10, 2020

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 10, 2020

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

@hantmac
Copy link

@hantmac hantmac commented Jun 10, 2020

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

@LihuaWu
Copy link
Author

@LihuaWu LihuaWu commented Jun 10, 2020

@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
Copy link
Contributor

@rsc rsc commented Jun 10, 2020

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
Copy link
Author

@LihuaWu LihuaWu commented Jun 10, 2020

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
Copy link
Contributor

@randall77 randall77 commented Jun 10, 2020

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
Copy link
Contributor

@randall77 randall77 commented Jun 10, 2020

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
Copy link
Author

@LihuaWu LihuaWu commented Jun 10, 2020

@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
Copy link
Contributor

@davecheney davecheney commented Jun 10, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.