search

BashSupport-Pro / bashsupport-pro

Public issue tracking for BashSupport Pro. This is a plugin, which provides advanced support for Bash scripts for JetBrains IDEs.
https://www.bashsupport.com
48 stars 2 forks source link

Possible line ending problem in WSL debugging #180

Closed bedge closed 1 month ago

bedge commented 1 month ago

Given the nature of WSL I expect there's a mix of line ending configurations. Maybe one is "correct", if so, I'm probably not using it.

Here's what I see in the console tail:

2024-10-06 12:22:44,195 [2878225]   WARN - #bashpro.debug - failed to set breakpoint at //wsl.localhost/Ubuntu/home/edgeb1/git/upp/upp-gh-actions/github/gh-cli-test.sh:32, error: ** File "" not found in read-in files.\r\n** See 'info files' for a list of known files and\r\n** 'load' to read in a file.
pro.bashsupport.shell.m4: failed to set breakpoint at //wsl.localhost/Ubuntu/home/edgeb1/git/upp/upp-gh-actions/github/gh-cli-test.sh:32, error: ** File "" not found in read-in files.\r\n** See 'info files' for a list of known files and\r\n** 'load' to read in a file.
    at pro.bashsupport.shell.zy.A(zy.java:28)
    at pro.bashsupport.shell.hz.invokeSuspend(hz.java)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)

and here's (some) the debug console output:

bashdb<11> break //wsl.localhost/Ubuntu/home/edgeb1/git/upp/upp-gh-actions/github/gh-cli-test.sh:32
** File "" not found in read-in files.
** See 'info files' for a list of known files and
** 'load' to read in a file.
bashdb<12> break //wsl.localhost/Ubuntu/home/edgeb1/git/upp/upp-gh-actions/github/set-base-version.sh:26
** File "" not found in read-in files.
** See 'info files' for a list of known files and
** 'load' to read in a file.

The gh-cli-test.sh is the script I'm testing.

set-base-version.sh is a file in the same directory, but which is unrelated.

As a guess, perhaps the line ending issue is affecting a dir iteration and subsequent parse problem for the file it's looking for?

Same problem with current bashsupportpro in EAP and reg IJ versions, all up to date as of today.

jansorg commented 1 month ago

This is very likely a problem with the //wsl.localhost/ path prefix. This should have been remapped to an actual path because bashdb won't understand it otherwise.

Is you project located inside a WSL container or on a Windows drive like c:?

Is you IDE running inside WSL or as a regular Windows application? The content of Help>About would be helpful, if ypu don't mind.

jansorg commented 1 month ago

I was unable to reproduce this. If you let me know from where your project and the debugged Bash scripts were opened, I could try again...

bedge commented 1 month ago

Hi Joachim,

You are entirely correct. I've been ignoring the context and opening projects on WSL volumes from IntelliJ in windows, because it didn't seem to matter a whole lot. In fact it bypassed what appeared to be a nested IDE situation that just made things slower.

Regardless, now that you're pointed out my lack of etiquette, I've opened the project as, most likely, intended within a WSL bridged IDE instance.

I checked the run config, and even though it was created in a windows instance with a "wsl:/home/edgeb1/git/upp/upp-gh-actions/github/gh-cli-test.sh" path, the run config as seen in the WSL intellij now shows the correct path (no wsl: prefix).

Now, when I try the same run config, I get a different error:

[image: image.png]

There is no "help -> tail console log" in the WSL instance.

However, not being ready to give up, I wondered if the "automatic" conversion, or interpretation of a Windows created run config was suspect. I created a new run config from within the WSL IntelliJ instance and it worked.

So, yes, it's a WSL path/context issue, and thanks for pointing out the error of my ways.

That said, if that (the "wsl:/" path mapping) is the only thing stopping it working, in the sense of being able to NOT open a WSL-specific inteliJ instance and rather just be able to debug shell code from the Windows intelliJ instance that's residing on the WSL volume, that it would be amazingly cool if that "just worked".

Thanks again.

-Bruce

On Sun, Oct 6, 2024 at 12:39 PM Joachim Ansorg @.***> wrote:

This is very likely a problem with the //wsl.localhost/ path prefix. This should have been remapped to an actual path because bashdb won't understand it otherwise.

Is you project located inside a WSL container or on a Windows drive like c:?

Is you IDE running inside WSL or as a regular Windows application? The content of Help>About would be helpful, if ypu don't mind.

— Reply to this email directly, view it on GitHub https://github.com/BashSupport-Pro/bashsupport-pro/issues/180#issuecomment-2395557971, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADZ45IBVMWLJIU4YFYEIQDZ2GGXNAVCNFSM6AAAAABPOTBSQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGU2TOOJXGE . You are receiving this because you authored the thread.Message ID: @.***>

jansorg commented 1 month ago

Hi Bruce, thanks for the feedback.

My question about the location wasn't to discourage opening a project from WSL. Debugging is supposed to work with all possible setups of the IDE.

I failed to reproduce the error when debugging a WSL project. But at first I had weird problems with existing run configurations. Could you post a screenshot of the run config settings of the failing configuration in your WSL project, please?

The image you posted in your last reply doesn't show on GitHub. Could you post it again?

bedge commented 1 month ago

Here's the original run cfg from a Windows instance pointing at the WSL volume: [image: image.png]

Here's the same run cfg as viewed from a remote WSL connected Intellij instance:

[image: image.png]

Let me know if you need anything else.

-Bruce

On Mon, Oct 7, 2024 at 11:21 PM Joachim Ansorg @.***> wrote:

Hi Bruce, thanks for the feedback.

My question about the location wasn't to discourage opening a project from WSL. Debugging is supposed to work with all possible setups of the IDE.

I failed to reproduce the error when debugging a WSL project. But at first I had weird problems with existing run configurations. Could you post a screenshot of the run config settings of the failing configuration in your WSL project, please?

The image you posted in your last reply doesn't show on GitHub. Could you post it again?

— Reply to this email directly, view it on GitHub https://github.com/BashSupport-Pro/bashsupport-pro/issues/180#issuecomment-2398949509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADZ45KOFQRSLVXEXM7SEL3Z2N2YFAVCNFSM6AAAAABPOTBSQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJYHE2DSNJQHE . You are receiving this because you authored the thread.Message ID: @.***>

bedge commented 1 month ago

... and the XML, just in case:

❯ cat .idea/runConfigurations/gh_cli_test_sh.xml
<component name="ProjectRunConfigurationManager">
<configuration default="false" name="gh-cli-test.sh"
type="BashProRunConfiguration">
<envs>
<env name="AWS_PROFILE" value="up-dev-ops" />
</envs>
<target name="WSL - Ubuntu" />
<option name="scriptParameters"
value="logs/gaw-10-6-gaw-1a-fail.log-11204000876" />
<option name="scriptPath" value="$PROJECT_DIR$/github/gh-cli-test.sh" />
<option name="workingDirectory" value="$PROJECT_DIR$/../virtuoso/" />
<RunnerSettings bashdbVersion="Automatic" bashPathMapper="Automatic"
RunnerId="pro.bashsupport.shDebugRunner" />
<method v="2" />
</configuration>
</component>

On Wed, Oct 9, 2024 at 5:25 AM Bruce Edge @.***> wrote:

Here's the original run cfg from a Windows instance pointing at the WSL volume: [image: image.png]

Here's the same run cfg as viewed from a remote WSL connected Intellij instance:

[image: image.png]

Let me know if you need anything else.

-Bruce

On Mon, Oct 7, 2024 at 11:21 PM Joachim Ansorg @.***> wrote:

Hi Bruce, thanks for the feedback.

My question about the location wasn't to discourage opening a project from WSL. Debugging is supposed to work with all possible setups of the IDE.

I failed to reproduce the error when debugging a WSL project. But at first I had weird problems with existing run configurations. Could you post a screenshot of the run config settings of the failing configuration in your WSL project, please?

The image you posted in your last reply doesn't show on GitHub. Could you post it again?

— Reply to this email directly, view it on GitHub https://github.com/BashSupport-Pro/bashsupport-pro/issues/180#issuecomment-2398949509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADZ45KOFQRSLVXEXM7SEL3Z2N2YFAVCNFSM6AAAAABPOTBSQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJYHE2DSNJQHE . You are receiving this because you authored the thread.Message ID: @.***>

jansorg commented 1 month ago

@bedge Sorry, GitHub doesn't seem to show images submitted with an email reply :disappointed: I'll go with the xml and will let you know if I need a screenshot...

bedge commented 1 month ago

Windows: image

WSL: image

jansorg commented 1 month ago

Ah, I think I know what's causing this. The working directory \\wsl.localhost\... is not remapped to the path inside the container. I'll get that fixed for the next update...

jansorg commented 1 month ago

@bedge I think that I fixed this bug. If you don't mind to test a preview, which major version are you using?

jansorg commented 1 month ago

@bedge If you'd like to test the fix, I've uploaded preview builds in the eap channel, https://plugins.jetbrains.com/plugin/13841-bashsupport-pro/versions/eap

bedge commented 1 month ago

@bedge I think that I fixed this bug. If you don't mind to test a preview, which major version are you using?

I bounce back and forth between EAP and latest, depending on which I find least annoying at the time :)

bedge commented 1 month ago

Got further. I updated the EAP and plugins and started a debug session from windows -> WSL filesystem without the WSL remote instance proxy. Was able to start debugger and step through a few lines. after a bit it hung up and I thought that perhaps I didn't pick up the new version you just posted.

From the trace log:

2024-10-10 17:46:46,621 [ 534659]   WARN - #bashpro.debug - no target environment path available for //wsl.localhost/Ubuntu/home/edgeb1/git/upp/upp-gh-actions/github/gh-cli-test.sh
2024-10-10 17:46:46,700 [ 534738]   WARN - #bashpro.debug - failed to set breakpoint at //wsl.localhost/Ubuntu/home/edgeb1/git/upp/upp-gh-actions/github/gh-cli-test.sh:31, error: ** File "" not found in read-in files.\r\n** See 'info files' for a list of known files and\r\n** 'load' to read in a file.
pro.bashsupport.shell.m4: failed to set breakpoint at //wsl.localhost/Ubuntu/home/edgeb1/git/upp/upp-gh-actions/github/gh-cli-test.sh:31, error: ** File "" not found in read-in files.\r\n** See 'info files' for a list of known files and\r\n** 'load' to read in a file.
    at pro.bashsupport.shell.zy.A(zy.java:28)
    at pro.bashsupport.shell.hz.invokeSuspend(hz.java)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)

Then I got a popup IDE error:

Unhandled exception in java.util.concurrent.ThreadPoolExecutor@5abd98c4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 12]

java.io.IOException: Closed stdout
    at com.pty4j.windows.conpty.WinHandleOutputStream.write(WinHandleOutputStream.java:33)
    at java.base/java.io.OutputStream.write(OutputStream.java:124)
    at pro.bashsupport.shell.av.invokeSuspend(av.java:107)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)
    Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelled}@1675d2d1, java.util.concurrent.ThreadPoolExecutor@5abd98c4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 12]]

This was with 4.3.0.243 and Build #IU-243.18137.10, built on October 1, 2024

From my uneducated POV it appears that you fixed the path translation in the initial startup, but there's more than one place that needs the remapping.

jansorg commented 1 month ago

Oh, I'm sorry for being unclear.

The fixed version is 4.3.1 and it's either available for 2024.3 eap by default or as a plugin preview for <=2024.2, which needs to be installed manually.

The plugin preview for 2024.2 is at https://plugins.jetbrains.com/plugin/13841-bashsupport-pro/versions/eap/617305 To install, you need to download the plugin zip and then install it via Settings>Plugin>gear wrench icon>Install from disk

For 2024.3 eap you definitely need 4.3.1 because debugging would be completely broken with the latest JetBrains EAP of this week. But that's another bug...

You bug will only manifest for breakpoints not on the first line of code. I just hope that I squashed it with 4.3.1 😁

jansorg commented 1 month ago

Version 4.3.2 includes the fix and is available now. Please let me know if this release has not fixed it for you.