Adding support for "Live Kernel Memory" dump type (0x6)

[hugsy]

Description

This PR adds support for "Live Kernel Memory" dump type (0x6), including Python API, and tests.

As indicated here such dump can be generated as such:

But is actually processed the same way as regular bmp dump:

As a result, this PR only implements the type itself, and binds it to the "normal" BMP routine (i.e. BuildPhysmemBMPDump).

Fixes #26

[0vercl0k]

Hell yeah! I am guessing at least some of the tests are failing because the new dump isn't part of the testdatas? Send it my way and I'll add it up 🙏🏽

Thanks again man!

[0vercl0k]

All right, I added the file to the testdatas, re-running the tests to see what is left to address..

[0vercl0k]

Okay, most parsers get built properly now - just OSX to figure out. Not sure what's going on with the binding targets yet though 🤔

[0vercl0k]

Lol, while compiling with latest compiler 😅

(249c.599c): Access violation - code c0000005 (!!! second chance !!!)
c1xx!GetQualifiedIdForMember+0x1e:
00007fff`7623d4de f7421000000400  test    dword ptr [rdx+10h],40000h ds:00000000`00000010=????????

[0vercl0k]

All right, making progress - we just need to figure out what's the deal with OSX and how do we work around the MSVC bug on Windows 😅

[0vercl0k]

Okay so the osx-large is actually only usable for paying customers 🤦🏽‍♂️

[0vercl0k]

Okay - have a look whenever you have some time @hugsy and let me know what you think.

The OSX part is annoying as I don't know how easy it'd be to port / have all the bindings etc work properly on ARM64 🤷🏽‍♂️

For Windows, maybe you have a better idea; I can also file a bug to make sure to update the CI back to windows-latest when the frontend doesn't crash anymore 😔

Cheers

[hugsy]

Regarding windows-2022, the bug is reported on both sides (vs & nb) and known:

• [BUG]: Internal compiler error with MSVC 2022 when building nb_func.h wjakob/nanobind#613
• https://developercommunity.visualstudio.com/t/Internal-compiler-error-w-nanobind-v19/10662883?sort=newest

I've also pinned the rest of runner images so that everything should keep working for future updates and we can introduce newer runner as they become more stable.

[0vercl0k]

Okay I think we're good to go, merging - thank you again @hugsy!

[0vercl0k]

All right - this took a while but I finally fixed the way I was generating wheels for Linux so that it doesn't break anymore.

What happens for the 0.7.3 release is that we were generating them 'manually' and it turns out their names has meaning to pypi. I tried to upload them and the Linux ones were rejected. I decided to rename the package to make it happy and they did get uploaded, but the package were actually broken. Once downloaded a checksum wouldn't match and installation would fail. Note that this whole thing only affected Linux packages (as far as I know; at least Windows ones were fine).

To fix this, you are apparently to build wheels using the cibuildwheels project which I now use (see #32).

v.0.7.4 should now work on both Windows & Linux:

(base) c:\Users\over\Downloads>pip install --upgrade kdmp_parser
...
Installing collected packages: kdmp_parser
  Attempting uninstall: kdmp_parser
    Found existing installation: kdmp-parser 0.7.3
    Uninstalling kdmp-parser-0.7.3:
      Successfully uninstalled kdmp-parser-0.7.3
Successfully installed kdmp_parser-0.7.4

(base) c:\Users\over\Downloads>ipython3
...
In [1]: import kdmp_parser

In [2]: kdmp_parser.KernelDumpParser("fulllivekernelmemory.dmp")
Out[2]: KernelDumpParser(fulllivekernelmemory.dmp, 6)

over@panther:/mnt/c/Users/over/Downloads$ pip install --upgrade kdmp_parser
...
Installing collected packages: kdmp_parser
Successfully installed kdmp_parser-0.7.4

over@panther:/mnt/c/Users/over/Downloads$ ipython3
...
In [1]: import kdmp_parser

In [2]: kdmp_parser.KernelDumpParser("fulllivekernelmemory.dmp")
Out[2]: KernelDumpParser(fulllivekernelmemory.dmp, 6)

Sorry for the lag on this, and thank you again!