kustomize build cause the panic with non-ASCII characters

[110y]

Describe the bug

When I execute kustomize build with patches including comments with non-ASCII characters, it cause the panic like below:

panic: runtime error: index out of range [7] with length 6 [recovered]
        panic: runtime error: index out of range [7] with length 6

Files that can reproduce the issue

I've created the repository which can reproduce this issue: https://github.com/110y/kustomize-issue-3605

> git clone https://github.com/110y/kustomize-issue-3605.git
> cd kustomize-issue-3605
> kustomize build .

> cd kustomize-issue-3605
> cat kustomization.yaml
---
resources:
  - ./deployment.yaml

patchesStrategicMerge:
  - ./patch-deployment.yaml

> cat deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: nginx
  labels:
    app: nginx
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.19.6
          ports:
            - containerPort: 80

> cat patch-deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: nginx
spec:
  replicas: 3 # 本番環境

Expected output

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: nginx
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.19.6
        name: nginx
        ports:
        - containerPort: 80

Actual output

panic: runtime error: index out of range [7] with length 6 [recovered]
        panic: runtime error: index out of range [7] with length 6

Kustomize version

• Linux

> kustomize version
{Version:kustomize/v4.0.1 GitCommit:516ff1fa56040adc0173ff6ece66350eb4ed78a9 BuildDate:2021-02-13T21:21:14Z GoOs:linux GoArch:amd64}

• macOS

> kustomize version
{Version:kustomize/v4.0.1 GitCommit:516ff1fa56040adc0173ff6ece66350eb4ed78a9 BuildDate:2021-02-13T21:21:14Z GoOs:darwin GoArch:amd64}

Platform

I've just checked this behavior with the following platforms:

• Linux
• macOS

Additional context

The same issue was already filed as #3417.
Although #3417 said:

Seems that this issue is resolved in kustomize v3.9.2.

I think this problem is still reproducible as my investigation.

[hansanghoon]

I have different observation regarding placement of the comment.

This doesn't cause problem in 4.0.1

apiVersion: v1
kind: Namespace
metadata:
  name: quote-dev #한글한글

Those below cause problem.

apiVersion: v1
kind: Namespace
metadata:
#한글한글
  name: quote-dev

or

#한글한글
apiVersion: v1
kind: Namespace
metadata:
  name: quote-dev

panic: runtime error: index out of range [6] with length 5 [recovered]
	panic: runtime error: index out of range [6] with length 5
...

$ kustomize version
{Version:kustomize/v4.0.1 GitCommit:516ff1fa56040adc0173ff6ece66350eb4ed78a9 BuildDate:2021-02-14T05:00:02+00:00 GoOs:darwin GoArch:amd64}

[Shell32-Natsu]

#3417 (comment)

We need to update go-yaml version but it introduces some other changes so we haven't decided.

@monopole Another reason to update go-yaml version.

[yanniszark]

@Shell32-Natsu @monopole this is the only issue preventing us from upgrading to kustomize v4.0.5 right now.
Since:

• This is a regression from previous versions
• The fix is to upgrade a library
  I can devote some time to develop a fix.

@Shell32-Natsu from your comment here:

We need to update go-yaml version but it introduces some other changes so we haven't decided.

I understand that you may have already tried upgrading the library. Do you have any desired version?
Should I be aware of any issues you already know?
Please let me know how I can help move this forward.

[Shell32-Natsu]

@yanniszark One concern in my mind is go-yaml changed the indention behavior in newer version and that will break a lot of tests. @monopole Do you have any other objections? IMO we need to update the go-yaml version since the current one has a bunch of bugs.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[110y]

With the latest version of kustomize (4.2.0), my PoC for this issue has seemed to be resolved.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.