Laurens

Last night and this morning I continued working on this and I have some more information that hopefully can give some insights. Using LLDB and after running `map2pdb.exe -exclude:system*;dx*;cx* -bind Tester.map` I see that the stacktrace in my code always looks the same:

(lldb) thread backtrace 1
  thread #1
    frame #0: 0x7565113c win32u.dll`NtUserWaitMessage + 12
    frame #1: 0x00a605e6 Tester.exe`__dbk_fcall_wrapper + 2927526
    frame #2: 0x00a5f5b8 Tester.exe`__dbk_fcall_wrapper + 2923384
    frame #3: 0x02791c90 Tester.exe`__dbk_fcall_wrapper + 33538640
    frame #4: 0x02791cf7 Tester.exe`__dbk_fcall_wrapper + 33538743
    frame #5: 0x03e092d2 Tester.exe`__dbk_fcall_wrapper + 57096338
    frame #6: 0x03e0931f Tester.exe`__dbk_fcall_wrapper + 57096415
    frame #7: 0x05753071 Tester.exe`Tester + 93
    frame #8: 0x76d07d59 kernel32.dll`BaseThreadInitThunk + 25
    frame #9: 0x779ab74b ntdll.dll`RtlInitializeExceptionChain + 107
    frame #10: 0x779ab6cf ntdll.dll`RtlClearBits + 191

LLDB always refers to `__dbk_fcall_wrapper`, but not to the actual method. I also noticed that running the same program in WinDBG, gives no stackstrackes at all. Running in WinDBG with a DBG-file created with `map2dbg` gives stacktraces with correct method references. (Although the sourcecode references do not work yet).

I really love to use LLDB (from VS Code, because the editor performs so much better for large projects than the Delphi IDE) and I think we can get close to get it working, but correct callstacks and method/source references are absolute necessary for this. I hope someone can put me in the right direction.

This is a really nice topic and the first PDB-tool I have found that works fast. I am trying to get debugging working in VS Code for Win32 using LLDB. The debugger runs, but does not shows the correct callstack/symbols and I hoped to fix this using the PDB-output from this tool. However, I cannot get it working yet. Has anybody here tried this?

Ok, that is unfortunately. Then I will just add the specific `mmdep`-files to the repo for now. Thanks!

Hi @Uwe Raabe, I try to do the same. However, `MMT_UDA` expects a mmdep-file (which can be generated using the UI), but is there also a way to generate the mmdep-file using the commandline so I can also integrate this in our CI-pipeline?

On 9/23/2021 at 4:40 PM, Stefan Glienke said:

No, I took the state from SourceForge years ago and removed all the cruft that I did not need and refactored some things. Also due to the fragmentation of the project it was kinda hard to see what is actually the most recent one. I just learned that probably your fork is.

Correct, the fork on GitHub (https://github.com/DelphiCodeCoverage/DelphiCodeCoverage) is the most recent one.

On 9/23/2021 at 4:35 PM, Fr0sT.Brutal said:

The test involved my wrapper for createprocess with threads, IO pipes etc, it's somewhat complex to extract MRE. I have it in my backlog but hardly will put my hands on it in near future...

I would really appreciate if you send your example to me in a PM if you have one (or create an issue in the GitHub project) so we can fix it as soon as you put your hands on the issue.

On 8/31/2021 at 11:22 AM, Stefan Glienke said:

Working on some better integration and result format that can be consumed by state of the art tooling such as https://github.com/danielpalme/ReportGenerator or https://github.com/marketplace/codecov but thats a side project that I don't spend much time on.

Also still fighting some spurious crashes with DelphiCodeCoverage that result from it putting its breakpoints where it really should not (I suspect some incorrect debug information from the map file).

Are you using a recent release? In march this year I have fixed an issue with spurious crashes in multi-threaded code where the breakpoint was not correctly cleared (and could cause the CPU to execute a NOP where a real instruction should be).

On 8/31/2021 at 1:36 PM, Fr0sT.Brutal said:

I also experienced crashes on a code that runs CreateProcess but didn't investigate that yet. Alas, the coverage doesn't check multiple branches sharing the same line so its results aren't 100% reliable. Moreover, Delphi compiler strips out unused functions even in full debug mode so untested lines seem identical to ignored ones.

I have seen the same result once, but several years ago, do you a minimal workable example? If so, I would appreciate if you create an issue so we can investigate and fix it.

The DelphiCodeCoverage tool is a good tool to start with. I prefer to integrate it to more common tools like SonarQube. We use this for analyzing our Delphi, C# and TypeScript code in one tool.