list command fails in some projects

[isbobbydigitalak]

I reported that the list command does not work when running in cli interface on simple small (single class, just a few lines in main) projects in #112. That appears to have been fixed in the latest release.

However when I attempt to use it on the project we have at work I still have not been able to get it to work the way it should or be useful even a single time unfortunately.

A small demonstration:

$ netcoredbg --version
NET Core debugger 2.2.1-9 (db69338, Release)
#....

$ uname -a
Linux minibobby 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux

$ netcoredbg --interpreter=cli -- dotnet Company.Thing.Api.dll

ncdb> set just-my-code 0
ncdb> b Main
 Breakpoint 1 at Main() --pending, warning: No executable code of the debugger's target code type is associated with this line.
ncdb> r
^running

library loaded: /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.19/System.Private.CoreLib.dll
no symbols loaded, base address: 0x7fccda0f0000, size: 10607616(0xa1dc00)

thread created, id: 303260

library loaded: /home/isak/src/company.thing-api/Company.Thing.Api/bin/Debug/net6.0/Company.Thing.Api.dll
symbols loaded, base address: 0x7fccc98a1000, size: 346112(0x54800)
breakpoint modified,  Breakpoint 1 at Main()

library loaded: /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.19/System.Runtime.dll
no symbols loaded, base address: 0x7fccd8008000, size: 32256(0x7e00)

library loaded: /home/isak/src/company.thing-api/Company.Thing.Api/bin/Debug/net6.0/Company.Thing.Worker.dll
symbols loaded, base address: 0x7fccc986a000, size: 223744(0x36a00)
breakpoint modified,  Breakpoint 1 at Main()

library loaded: /usr/share/dotnet/shared/Microsoft.AspNetCore.App/6.0.19/Microsoft.Extensions.Hosting.Abstractions.dll
no symbols loaded, base address: 0x7fccdac70000, size: 231424(0x38800)

library loaded: /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.19/netstandard.dll
no symbols loaded, base address: 0x7fccc9853000, size: 91136(0x16400)

library loaded: /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.19/System.Collections.dll
no symbols loaded, base address: 0x7fccdacf0000, size: 455168(0x6f200)

library loaded: /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.19/System.Linq.dll
no symbols loaded, base address: 0x7fccdad60000, size: 726016(0xb1400)

library loaded: /home/isak/src/company.thing-api/Company.Thing.Api/bin/Debug/net6.0/Company.Thing.Core.dll
symbols loaded, base address: 0x7fccc928a000, size: 1531392(0x175e00)
breakpoint modified,  Breakpoint 1 at Main()

stopped, reason: breakpoint 1 hit, thread id: 303260, stopped threads: all, times= 0, frame={Company.Thing.Api.Program.Main() at /home/isak/src/company.thing-api/Company.Thing.Api/Program.cs:28}

ncdb> l // <<< prints nothing
ncdb> l 0
   1    using Company.Thing.Core.Extensions; // note the digit "1" at the start! It is not in the source file
    /// the rest of the entire  (!) source file
    // It also doesn't have the caret `>` indicating the current line 

Running l 1 through l 6 prints the same entire source file in the same way, with 1 inserted at the start of the code, with no location indicator shown. However if I run l 7 I get no output. Same if I run l N where N >= 7 for a few sampled random numbers. Doing the range thing of listing source from line 5,15 like l 5,15 gives no output. Running l 1,N where N >= 1 prints the same as above. Also starting with 0 gives output. However if i run l 2,N I get no output at all. Stepping forward a few steps with n doesn't change the situation. If I set the breakpoint in another file, for example the Startup file in ConfigureServices, I get the same behavior, just that it will print the entire Startup.cs instead of Program.cs. Again prefixed by three spaces, a digit '1', and a tab character.

Bad news

I haven't (yet) figured out how to reliably reproduce this, I haven't been able to see this on any other test project than the project at my job, and I can't just provide you with that one. I plan to try to do some divide and conquer stuff, or at least copy the .csproj file and make a test project that has the exact same dependencies to see if that works when I have time. But I thought for now I should at least report it with what I have got so far. Hopefully the strange behavior of printing all of the source with 1 at the beginning offers some hint at least.

One thing I did try was to set the Sdk in the test project csproj to be the same <Project Sdk="Microsoft.NET.Sdk.Web"> as this job project but that didn't seem to make a difference (which is to say, the debugger works on the small test project).

Maybe something else I could eventually try is to run netcoredbg in gdb or something to see what is up. Maybe a version built from source would work too, that is something I have not tried yet. A strange thing though is that I can debug this project with the visual studio code debugger which is just using netcoredbg anyway, but with a different protocol for communicating with the editor. So maybe the issue is located specifically in the cli mode?

Thanks!

[gbalykov]

Thanks for reporting this, we'll take a look. We also plan to make new release this week, when it's available please check whether problem reproduces or not.

[isbobbydigitalak]

Will do! Looking forward to it.

[gbalykov]

@isbobbydigitalak New release is a bit delayed, please try to build netcoredbg with this patch in the mean time:

diff --git a/src/protocols/sourcestorage.cpp b/src/protocols/sourcestorage.cpp
index 2342fdbb..631e43a2 100644
--- a/src/protocols/sourcestorage.cpp
+++ b/src/protocols/sourcestorage.cpp
@@ -63,9 +63,15 @@ namespace netcoredbg
         for(char* bufptr = sf->text; bufptr < sf->text + fileLen; )
         {
             sf->lines.push_back(bufptr);
-            while(*bufptr != '\r')
+            while(*bufptr != '\r' && *bufptr != '\n' && *bufptr != '\0')
                 bufptr++;
-            *bufptr++ = '\0';
+            if (*bufptr == '\0')
+            {
+                bufptr++;
+                continue;
+            }
+            if (*bufptr == '\r')
+                *bufptr++ = '\0';
             if (*bufptr == '\n')
                 *bufptr++ = '\0';
         }

[gbalykov]

This might be fixed in latest release, please take a look

[isbobbydigitalak]

Hey!

I was on vacation so sorry about the late response. Just gave it a test run and it seems to be showing the source finally, amazing!

Thank you so much!