Log in

No account? Create an account
'Twas brillig, and the slithy toves did gyre and gimble in the wabe [entries|archive|friends|userinfo]

[ website | Beware the Jabberwock... ]
[ deviantArt | the-boggyb ]
[ FanFiction | Torkell ]
[ Tumblr | torkellr ]

[Random links| BBC news | Vulture Central | Slashdot | Dangerous Prototypes | LWN | Raspberry Pi]
[Fellow blogs| a Half Empty Glass | the Broken Cube | The Music Jungle | Please remove your feet | A letter from home]
[Other haunts| Un4seen Developments | Jazz 2 Online | EmuTalk.net | Feng's shui]

Why debugging core/memory dumps on Windows is much more civilised than debugging on Linux [Wednesday 18th May 2011 at 9:01 pm]


Reason #1: I can open a core/memory dump without having the corresponding executable.

Reason #2: I can get a complete library list from a core/memory dump without having the corresponding executable.

Reason #3: I can analyse a core/memory dump that came from a different system with different libraries without having to first get those symbols. In fact, I can analyse a core/memory dump without having to get *any* symbols.

Reason #4: I can specify an actual symbol path, that works, without having exactly match the directory structure on the system the core dump came from

Reason #5: Symbol servers. I don't even have to get the symbols myself - I can just tell Windbg "go grab symbols on-demand from these locations" and it Just Works.

Add all these reasons together, and it means that I can take a memory dump from a Windows 2003 server, open it in Windbg on my Windows XP desktop, and immediately be able to examine it. But I can't take a core dump from a Linux server running some random version and get anything remotely sane out of gdb on my Linux desktop.
Link | Previous Entry | Share | Next Entry[ Penny for your thoughts? ]