LLDB Windows: strange symbol offset of 0x1000? (original) (raw)

Hi LLDB folks,

When trying to symbolicate textual crash logs that we receive occasionaly I’m now making use of LLDB (16.0.6) on Windows. It works like a charm, but only after I resolved an unexpected symbol offset (of 0x1000).

This is for a DLL (x86_64) loaded at address 0x2e290000, looking up a well known symbol with cdb/kd:

0:000> x /v MelodyneCore_5_3_1_018!GNCondition::waitForSignal
prv func   00000000`**2f975fd0**   4f MelodyneCore_5_3_1_018!GNCondition::waitForSignal (double)

This is the address as resolved via LLDB:

target modules load --file "MelodyneCore-5.3.1.018.dll" .text 0x2e290000 
section '.text' loaded at 0x2e290000
(lldb) image lookup -n GNCondition::waitForSignal 
1 match found in C:\Users\celemony\Downloads\pdbs\MelodyneCore-5.3.1.018.dll:
        Address: MelodyneCore-5.3.1.018.dll[0x00000001816e5fd0] (MelodyneCore-5.3.1.018.dll..text **+ 24006608**)
        Summary: …

… where 0x2e290000 + 24006608 = 0x2F974FD0 (instead of the expected 0x2F975FD0).
Is this a known bug or am I missing something?

Thanks in advance,
Marcus

znek August 3, 2023, 4:07pm 2

After making some more tests, I guess I do have an answer now. The problem doesn’t lie with LLDB at all.

When you load a crash dump into kd/cdb:

PS C:\Users\znek> & 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\kd.exe' -z C:\Users\znek\AppData\Local\CrashDumps\TestCrash.exe.696.dmp -i C:\Users\znek\Downloads\TestCrash.exe  -y C:\Users\znek\Downloads\
…
!analyze -v
…
0:000> lm
start             end                 module name
00007ff6`679a0000 00007ff6`679a7000   TestCrash C (private pdb symbols)  c:\users\znek\downloads\TestCrash.pdb
00007ffa`95120000 00007ffa`9513b000   VCRUNTIME140   (deferred)
00007ffa`99ec0000 00007ffa`99f51000   apphelp    (deferred)
00007ffa`9c850000 00007ffa`9cb22000   KERNELBASE   (export symbols)       KERNELBASE.dll
00007ffa`9ccb0000 00007ffa`9cdb0000   ucrtbase   (deferred)
00007ffa`9e3c0000 00007ffa`9e47f000   kernel32   (export symbols)       kernel32.dll
00007ffa`9ef90000 00007ffa`9f188000   ntdll      (export symbols)       ntdll.dll
0:000> x /v TestCrash!main
prv func   00007ff6`679a1000    6 TestCrash!main (void)

kd claims the load address of the dmp is at 0x679a0000, but note that main() is at 0x679a1000 - the mysterious 0x1000 offset.

Whereas in lldb:

PS C:\Users\znek> lldb
(lldb) target create --no-dependents -arch=x86_64 "C:\Users\znek\Downloads\TestCrash.exe"
(lldb) Current executable set to 'C:\Users\znek\Downloads\TestCrash.exe' (x86_64).
(lldb) target modules load --file "TestCrash.exe" .text 0x679a0000
section '.text' loaded at 0x679a0000
(lldb) image lookup -n main
1 match found in C:\Users\znek\Downloads\TestCrash.exe:
        Address: TestCrash.exe[0x0000000140001000] (TestCrash.exe..text + 0)
        Summary: TestCrash.exe`main at TestCrash.c:12

0x1000 = 4096 which is a common memory page size.

No less mysterious why it wouldn’t be there. Is it just this one symbol, maybe if there are more like it you could spot some pattern to it.