[VSC] Editor freeze on deleted image

[levrik]

Issue Type: Bug

The whole editor freezes if I click on a deleted image in the changes view of VSC (Git).

(GIF)

This is really annoying if you click on it by accident and have to wait for one/two minutes till you can restart the editor.

VS Code version: Code 1.31.1 (1b8e830, 2019-02-12T02:16:38.656Z)
OS version: Darwin x64 18.2.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz (4 x 2600)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: enabled rasterization: enabled surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 4, 3
Memory (System)	16.00GB (0.55GB free)
Process Argv	-psn_0_7645002
Screen Reader	no
VM	0%

Extensions (12)

Extension	Author (truncated)	Version
gitignore	cod	0.6.0
vscode-eslint	dba	1.8.0
gitlens	eam	9.5.0
EditorConfig	Edi	0.12.8
prettier-vscode	esb	1.8.1
vscode-pull-request-github	Git	0.4.0
vscode-styled-components	jpo	0.0.25
vscode-language-pack-de	MS-	1.31.4
vscode-kubernetes-tools	ms-	0.1.16
python	ms-	2019.1.0
vscode-yaml	red	0.2.1
code-settings-sync	Sha	3.2.4

(1 theme extensions excluded)

With all extensions disabled it hangs for about 10 seconds, then the image loads.
With extensions enabled it hangs a one or two minutes before getting the prompt.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• VSC freezes when debugging (#66281)

[joaomoreno]

@bpasero I thought we had size limits here?

[bpasero]

@joaomoreno are you opening these files via the data-URI trick? The size should be encoded as META_DATA_SIZE which then (if large enough) would cause the image to not be rendered inline. But I am not sure that is happening here.

@levrik do you see a text editor opening eventually or the image shown inline?

[levrik]

@bpasero Already explained in the original issue.
Without any extensions enabled the image opens normally after about 10 seconds. With all my extensions enabled it loads one or two minutes before getting the unresponsive message.

[joaomoreno]

@levrik How big, in bytes, is that JPEG?

[levrik]

@joaomoreno 293.398 bytes

[joaomoreno]

Any chance you can send it to me?

[levrik]

@joaomoreno You can download it here: https://hypatos.ai/content/6-imprint/og-image.jpg

[bpasero]

@levrik can you point out the extension that is causing it e.g. by disabling the extensions one by one?

[joaomoreno]

@bpasero I can repro this without extensions.

1. Add the file to a git repo, commit
2. Delete the file
3. Open the file in SCM, opens fast
4. Close it and open it again, opens very slowly

[levrik]

@joaomoreno Yep. Exactly this. With extensions enabled it doesn't load at all. It just shows the unresponsive warning at some point.

[bpasero]

@joaomoreno can you check if memory goes beserk?

[joaomoreno]

@bpasero Pretty weird profile:

Profile-20190227T105432.json.zip

[bpasero]

@joaomoreno yeah it looks like V8 is spending a very long time in this._models[modelId]; where modelId is the entire data URI which is probably very long.

Maybe I can make that call smarter and not do the getModel lookup when I have a data resource in hand. It only seems to be used to render a proper icon for the editor.

[joaomoreno]

Yeah could be a good idea. Another couple ideas:

• Maybe try using ES6 map? I wonder...
• Maybe store modelId hashes in the map instead of modelIds themselves.

[bpasero]

@alexandrudima on #69334 (comment). The idea would be to change to a Map for getModel or a different approach that does not take the entire URI as hash lookup key. Though I am not sure that would work given this is in the standalone editor part.

[bpasero]

My fix is to avoid the getModel() call for data URIs and use the metadata encoded in the URI instead.

[alexdima]

@bpasero I suggest we remove the data-uri hack rather than blaming v8 or rewriting our code for the hack.

[kieferrm]

According to #74515 still happening in 1.34.

[bpasero]

@levrik can you give some exact steps how to reproduce this? I tried with the original image (which I guess I still had) and could not:

Also maybe try to reproduce in our insiders release.

[levrik]

@bpasero Happened with a different image this time but I also tried with the original one and it happened there as well. But there was a difference. With all extensions disabled it didn't happen anymore. I could track it down to the Kubernetes extension. It's a bit weird that this extension is causing this since it shouldn't do anything with version control.
I opened an issue over there anyway: vscode-kubernetes-tools/vscode-kubernetes-tools#558

[vscodebot]

This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the marketplace for VS Code. See also our issue reporting guidelines.

Happy Coding!

[itowlson]

I'm the maintainer of the Kubernetes extension that @levrik has identified as suffering from this issue. The thing is that having the extension present results in the hang even if the extension has not activated. Even if I delete all of our extension's activation events, the hang still happens!

From hacking around our package.json, it looks like the issue is a particular filenamePattern in a language contribution. I feel this is a VS Code issue, as this is a legitimate pattern and I don't see any reason why it should affected deleted image previews. I've raised an issue on VS Code, and provided a minimal extension that reproduces the issue at https://github.com/itowlson/git-deleted-image-hang-o-matic. Hope this helps!

[bpasero]

We should not test these URIs in our language detection (mime.ts?). Happy for a PR if someone has cycles.

[bpasero]

@mjbvz did we recently increase the max-size for images? I wonder if this also means we now have much larger data URIs in our system. It used to be 1MB I think.

[joaomoreno]

From #74926

---

Issue Type: Bug

This relates to #69334, which was resolved but recurs in this specific situation. See also vscode-kubernetes-tools/vscode-kubernetes-tools#558 which is how it came to me.

Steps to reproduce:

1. Create a git repo. Add an image (e.g. JPEG) to it and commit. Delete the image and do not commit. If you click on the deleted file diff in the SCM explorer, VS Code will show the deleted image. This is all as expected so far.

2. Create a new VS Code extension and add the following contribution:

        "languages": [
            {
                "id": "hanglywangly",
                "filenamePatterns": [
                    "**/foo/*.hanglywangly"
                ]
            }
        ]

(I have provided an extension which reproduces the problem at https://github.com/itowlson/git-deleted-image-hang-o-matic.)

3. Run the extension in the Extension Development Host.

4. In the Extension Development Host, open the git repo from step 1, go to the SCM view and click on the deleted image.

VS Code freezes up as described in #69334.

VS Code version: Code 1.35.0 (553cfb2, 2019-06-04T01:17:12.481Z)
OS version: Windows_NT x64 10.0.18362

[levrik]

@bpasero Any plans when the fix is getting shipped? I'm running into that issue on a daily basis and it's kinda annoying having to wait for the dialog to come up, reload, and that stuff.

[bpasero]

@levrik in around 1 hour in our insiders build: You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[levrik]

@bpasero I can confirm that this issue is fixed now! Thanks a lot!