Why doesn't windbg command !heap show all process heaps? - windbg

I create a new heap using HeapCreate function, then check that that heap is returned from GetProcessHeaps (it is ok), but the windbg command !heap does not show new created heap. Moreover, !heap shows twice less than function GetProcessHeaps. Why is it happening and how to display all heaps by WinDbg?

Related

How to pinpoint where in the program a crash happened using .dmp and WinDbg?

I have a huge application (made in PowerBuilder) that crashes every once in a while so it is hard to reproduce this error. We have it set up so that when a crash like this occurs, we recieve a .dmp file.
I used WinDbg to analyze my .dmp file with the command !analyze -v. From this I can deduct that the error that occured was an Access Violation C0000005. Based on the [0] and [1] parameters, it attempted to dereference a null pointer.
WinDbg also showed me STACK_TEXT consisting of around 30 lines, but I am not sure how to read it. From what I have seen I need to use some sort of symbols.
First line of my STACK_TEXT is this:
00000000`00efca10 00000000`75d7fa46 : 00000000`10df1ae0 00000000`0dd62828 00000000`04970000 00000000`10e00388 : pbvm!ob_get_runtime_class+0xad
From this, my goal is to analyze this file to figure out where exactly in the program this error happened or which function it was in. Is this something I will be able to find after further analyzing the stack trace?
How can I pinpoint where in the program a crash happened using .dmp and WinDbg so I can fix my code?
If you analyze a crash dump with !analyze -v, the lines after STACK TEXT is the stack trace. The output is equivalent to kb, given you set the correct thread and context.
The output of kb is
Child EBP
Return address
First 4 values on the stack
Symbol
The backticks ` tell you that you are running in 64 bit and they split the 64 bit values in the middle.
On 32 bit, the first 4 parameters on the stack were often equivalent to the first 4 parameters to the function, depending on the calling convention.
On 64 bit, the stack is not so relevant any more, because with the 64 bit calling convention, parameters are passed via registers. Therefore you can probably ignore those values.
The interesting part is the symbol like pbvm!ob_get_runtime_class+0xad.
In front of ! is the module name, typically a DLL or EXE name. Look for something that you built. After the ! and before the + is a method name. After the + is the offset in bytes from the beginning of the function.
As long as you don't have functions with thousands of lines of code, that number should be small, like < 0x200. If the number is larger than that, it typically means that you don't have correct symbols. In that case, the method name is no longer reliable, since it's probably just the last known (the last exported) method name and a faaaar way from there, so don't trust it.
In case of pbvm!ob_get_runtime_class+0xad, pbvm is the DLL name, ob_get_runtime_class is the method name and +0xad is the offset within the method where the instruction pointer is.
To me (not knowing anything about PowerBuilder) PBVM sounds like the PowerBuilder DLL implementation for Virtual Memory. So that's not your code, it's the code compiled by Sybase. You'd need to look further down the call stack to find the culprit code in your DLL.
After reading Wikipedia, it seems that PowerBuilder does not necessarily compile to native code, but to intermediate P-Code instead. In this case you're probably out of luck, since your code is never really on the call stack and you need a special debugger or a WinDbg extension (which might not exist, like for Java). Run it with the -pbdebug command line switch or compile it to native code and let it crash again.

Does adding breakpoint in a matlab m file make it run slower?

I have a matlab m file that basically has two sections
The first section contains a large loop that does operations on arrays of size 64, with the loop itself running about 2000 times
After this loop is finished, the second section contains code that isn't much computationally expensive
I need to invoke a breakpoint ( I do this by clicking on the left margin on the editor window) after the first section finishes, but whenever I set a breakpoint the first section of the program takes significantly longer to execute
I am not changing anything in the program itself. The breakpoint is never in the first section. The program runs really fast when there is no breakpoint (less than 10 seconds) as opposed to when I set a breakpoint after the first section (about 60 seconds)
Is this expected behaviour? Why is having a breakpoint causing the program to run slower? Is there a way to fix this?
MATLAB Version 7.9.0.529 (R2009b) 64 bit on Windows 10 64 bit Home edition
"Does adding breakpoint in a matlab m file make it run slower?": Yes.
In all languages*, debugging mode is slower because it requires extra power to be able to stop the code, and disables most of the optimization that the interpreter/compiler does.
Nothing really you can do against it (well, not debug, but that defeats the purpose hehe).
[*]: I know about

MATLAB not throwing OutOfMemoryExceptions or Maximum variable size errors

In a previous version of MATLAB (7.6), I used to get OutOfMemoryErrors that I thought were kind of annoying. But since I upgraded to 7.11, for some reason it's not throwing the errors anymore.
This means that when I accidentally try to make a variable that's way too large, the MATLAB shell will try to create the variable and bring my machine to a halt.
I'd really like to have these errors get thrown, so that I can exit out gracefully or debug my code, but I can't find the solution anywhere.
Possibly useful details:
I'm using OSX 10.5 on a 64-bit machine, with 4GB of RAM.
In MATLAB 7.6:
$ rand(50000);
??? Error using ==> rand
Maximum variable size allowed by the program is exceeded.
In MATLAB 7.11:
$ rand(50000);
(hang)
Between version 7.6 and 7.11 the Macintosh version of MATLAB switched from a 32-bit application to a 64-bit application. So now instead of running out of address space MATLAB thrashes.
Matlab doesn't hang. It's just paging, which takes forever. Try assigning a large array, open the Activity Monitor, and see the 'Virtual Memory' grow and grow.
If you reduce the page file size on your system, you can avoid that issue.

In windbg, how do I get a heap header address from !heap -l results?

I am playing around with windbg's !heap command, particular the "-l" switch which detects memory leaks.
When -l does detect a leak, I am having problems navigating from its results to a stack trace for the source of the leak.
Here is a snippet of the results from !heap -l. Formatting has been changed to make the output more readable.
0:066> !heap -l
Searching the memory for potential unreachable busy blocks.
Entry User Heap Segment
0324b500 0324b508 01580000 03230000
0324b520 0324b528 01580000 03230000
(Size, PrevSize, Unused, and Flags columns omitted for simplicity.)
Windbg's documentation for !heap tells me to use dt _DPH_BLOCK_INFORMATION with the header address, followed by dds with the blocks' StackTrace field. But the output for !heap -l doesn't specify a header address! It's only specififying Entry, User, Heap, and Segment. I've racked my brain looking over the other commands but can't figure out how to get the header address from any of these fields. Can someone help?
Did you enable the needed debug options with AppVerifier or Gflags ? Memory blocks will have a _DPH_BLOCK_INFORMATION only if pageheap option is enabled, and you will be able to display the stack backtrace if that option is also enabled. To display the stack trace of a block, you can use !heap -p -a <block address>.
Be aware that !heap -l may display lots of false positives if not used at application exit time. You could also try umdh (also included in Debugging Tools for Windows), or DebugDiag.

Xcode/Instruments' "Gather leaked memory contents" gives me a useless hex-only dump

When using the "Gather Leaked Memory Contents" of the Leaks Instrument, it seems to give me only the hex contents of an object, rather than showing me the ASCII string beside it (like every other hex dump in the world ever). Worse still, this box is un-selectable, I cannot even copy it into a decent hex editor for a string view.
Is there a reason for such insanity?
One way to find the contents is by running leaks from the command-line. Find the process name of your running app (you can use a tool such as from Activity Monitor or top), then in Terminal run:
leaks myprocessname
It should print out not only the address, size, and type of data, but the contents as well if it can. You can also, of course, copy the result from there into whatever hex editor you fancy.
Because the point of the Leaks instrument is to show you where things are being leaked, which is far more useful than what. When you know where and when things are leaked, go back to Xcode, set breakpoints, and step through. If what's being leaked is important to why, then you can see that in the debugger in real time, rather than in Instruments after the fact in aggregate.