In the problem panel, the errors are displayed correctly only when the task is called for the first time

[MaikMichel]

Type: Bug

I have developed an extension (dbFlux). This calls SQLPlus as a shell task and displays the output in the problem panel. So far so good. This worked fine up to and including VSCode 1.73.1.

With version 1.74.2 this does not work anymore. Instead of the actual error message, only the complete file name is displayed. I have already tried to fix the problem with a workaround, but it does not work.

This is a gif with version 1.73.1, which is working as expected:

And this is a gif with version 1.74.2, which behaves not as expected (Showing the filename instead of the actual error message)

This is the Link to my extension:

• https://marketplace.visualstudio.com/items?itemName=MaikMichel.dbflow
• https://github.com/MaikMichel/dbFlux

To reproduce the steps you have to install dbFLux an configure a valid connection to an Oracle database. Furter more you need to have Bash and SQLPlus or SQLcl installed on your machine. Once everything is running you have to compile an invalid package to display the error message.

"problemMatchers": [
            {
                "name": "dbflux-plsql",
                "owner": "external",
                "fileLocation": [
                    "relative",
                    "${workspaceFolder}"
                ],
                "applyTo": "openDocuments",
                "pattern": [
                    {
                        "regexp": "(WARNING|ERROR) (.*)",
                        "severity": 1,
                        "code": 2
                    },
                    {
                        "regexp": "(.*?):(\\d+):(\\d+)",
                        "file": 1,
                        "line": 2,
                        "column": 3
                    },
                    {
                        "regexp": "(.*)",
                        "message": 1
                    }
                ]
            }]

The output itself is a multiline output.

I think something in the terminal area will have changed from version 1.73 to 1.74. What do I have to do so that my extension generates a clean error output again? If I close the terminal window manually after compiling, it works again. But I can't expect my users to do that.

VS Code version: Code 1.74.2 (e8a3071ea4344d9d48ef8a4df2c097372b0c5161, 2022-12-20T10:29:14.590Z) OS version: Windows_NT x64 10.0.19044 Modes: Sandboxed: Yes

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 x 2592)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off| |Load (avg)|undefined| |Memory (System)|31.76GB (10.53GB free)| |Process Argv|C:\\Users\\MMI\\Projekte\\privat\\dbFlux\\dbFlux --crash-reporter-id 49c433d5-5fea-4d02-ae1f-6b1c28faeba7| |Screen Reader|no| |VM|0%|

Extensions (33)

Extension|Author (truncated)|Version ---|---|--- better-comments|aar|3.0.2 cucumberautocomplete|ale|2.15.2 asciidoctor-vscode|asc|2.9.8 vagrant|bbe|0.5.0 gitlens|eam|13.2.0 auto-type|eee|0.1.0 html-preview-vscode|geo|0.2.5 vscode-circuitpython|joe|0.1.19 paste-image-to-markdown|Liu|1.0.0 dbflow|Mai|4.2.1 git-graph|mhu|1.30.0 dotenv|mik|1.0.1 vscode-docker|ms-|1.23.3 isort|ms-|2022.8.0 python|ms-|2022.20.1 vscode-pylance|ms-|2023.1.10 jupyter|ms-|2022.11.1003412109 jupyter-keymap|ms-|1.0.0 jupyter-renderers|ms-|1.0.12 vscode-jupyter-cell-tags|ms-|0.1.6 vscode-jupyter-slideshow|ms-|0.1.5 remote-ssh|ms-|0.94.0 remote-ssh-edit|ms-|0.84.0 remote-wsl|ms-|0.72.0 remote-explorer|ms-|0.0.3 material-icon-theme|PKi|4.23.1 vscode-thunder-client|ran|2.3.0 java|red|1.13.0 vscode-xml|red|0.23.0 vscode-yaml|red|1.11.0 quokka-vscode|Wal|1.0.520 plsql-language|xyz|1.8.2 cursor-align|yo1|1.1.0

A/B Experiments

``` vsliv368cf:30146710 vsreu685:30147344 python383cf:30185419 vspor879:30202332 vspor708:30202333 vspor363:30204092 vstes627:30244334 vslsvsres303:30308271 pythonvspyl392:30443607 vserr242cf:30382550 pythontb:30283811 vsjup518:30340749 pythonptprofiler:30281270 vshan820:30294714 vstes263cf:30335440 vscorecescf:30445987 pythondataviewer:30285071 vscod805cf:30301675 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 cmake_vspar411:30581797 vsaa593cf:30376535 pythonvs932:30410667 cppdebug:30492333 vscaac:30438847 vsclangdf:30486550 c4g48928:30535728 dsvsc012cf:30540253 azure-dev_surveyonecf:30548226 vsccc:30610678 pyindex848:30577860 nodejswelcome1cf:30587006 2e4cg342:30602488 3d0df643:30613357 89544117:30613380 fim-prod:30623723 vscsb:30628654 ```

[meganrogge]

the only thing that sticks out from your tasks.json that changed is fileLocation via https://github.com/microsoft/vscode/issues/160771 from @babakks

there weren't changes to problem matchers during this time.

[babakks]

I'll look into it.

[babakks]

@meganrogge I can confirm the problem. However, when I checked the problem matchers, encountered a strange behavior. In short, the handle method of the MultiLineMatcher class (which extends the AbstractLineMatcher) is not always called with accurate arguments.

What I did was to use the problem matcher definition given in @MaikMichel's comment, and defined a dummy task that outputs such a constant string:

ERROR 123
file.txt:10:10
error message

The first time I ran the task, everything seemed fine. That is, the MultiLineMatcher.handle method was called with the exact three lines above. But when I ran the task for the second time, the input arguments were inaccurate:

As you can see, the first line is repeated. Note that the problem matcher expects to see the error message text on the third line, and that's why the correct error message is not shown to the user.

So, I think it's not related to our last modifications to problem matchers (i.e., the introduction of search file location method).

Do you agree, @meganrogge ?

[meganrogge]

Thanks for investigating @babakks and yes your exploration above confirms that this isn't a regression caused by your changes.

[MaikMichel]

Hi, any news about that bug? It is still not resolved. How can I help? Unfortunately I am not able to build VSCode by myself to make a PullRequest here ;-(

[wendyn-projects]

I think I am facing the same problem.

When I run my task for the first time, everything is ok. But when I try to run it again, 3rd regexp is being matched against the same line as 2nd one was for some reason and I don't get anything (only when I changed the 3rd regexp to be 2nd regexp friendly I got something).

{
    "label": "Run in Valgrind",
    "type": "shell",
    "command": "valgrind",
    "args": [
        "--leak-check=yes",
        "--fullpath-after=${workspaceFolder}",
        "${workspaceFolder}/main"
    ],
    "dependsOn": [
        "Build"
    ],
    "problemMatcher": [
        {
            "owner": "Valgrind",
            "severity": "warning",
            "fileLocation": [ "relative", "${workspaceFolder}" ],
            "pattern": [
                { "regexp": "^==\\d+== (\\S.+?) \\d+ of \\d+$", "message": 1 },
                { "regexp": "^==\\d+==    at .+?: (.+?) \\(.+?\\)$", "code": 1 },
                { "regexp": "^==\\d+==    by .+?: (.+? \\((.+?):(\\d+)\\))$", "message": 1, "file": 2, "line": 3 }
            ]
        },
    ]
}

I'm running this against following output:

...
==12345== 8 bytes in 2 blocks are definitely lost in loss record 18 of 26
==12345==    at 0x9ABCDEF: operator new(unsigned long) (coregrind/m_replacemalloc/vg_replace_malloc.c:342)
==12345==    by 0x9ABCDEF: my_method(char const*) (file.cpp:9)
==12345==    by 0x9ABCDEF: char const* std::__invoke_impl<char const*,... (/usr/include/...)
==12345==    by 0x9ABCDEF: std::enable_if<is_invocable_r_v<char const*,... (/usr/include/...)
...
==12345==
...