Matt's Homepage

I just spent an hour or two tracking down the last 16-byte memory leak in a project that I was working on. What it turned out to be was actually something EXPLICITLY cited in the Microsoft reference manual as having been fixed.  Yet it turned out not to be.

I had finished instrumenting my program for CRT memory reporting. CRT memory leak reporting is normally very handy as it tells you exactly what lines of code are the source of the leak, how many bytes, and dumps the data that’s leaking. All it requires is that you instrument your headers as described here <http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx>

// this goes before ANY other includes in ALL your headers
#define _CRTDBG_MAP_ALLOC
#include <blah>
#include <blah>
...
 main()
{
    _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); // tells leak detector to dump report at any program exit
    _CrtSetBreakAlloc(18); // set breakpoint on a specific allocation number
}

With all this done you can run the program and then see the results of the report in the Visual studio output window when the program exits:

Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18}
normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

If you use the _CrtSetBreakAlloc() with the allocation number ({18}in this case), when the program starts up in debug mode the debugger will automatically stop on that allocation. You can then look at the call stack and get a great idea of whats leaking and why. Overall, it’s very handy and helped me track down all my leaks.

Well, the problem was that I fixed all the leaks but 2 in my particular program.  I reduced the code down until I was down to just main() that dumped the memory report and exited.   The problem was that it STILL reported a leak! I added a fake leak, and the very first allocation (that was leaking) in the program had a higher allocation number than the allocations that were supposedly leaking.  This implied quite strongly that the leak is happening BEFORE I actually even get into the program. How is that possible?

Well, there are a few things that get allocated for you before your program starts. Fixed-sized arrays, (int array[10];) string literals, and static variables are all objects are allocated on the stack (as opposed to the heap) are usually allocated at load time. When I looked at all the static allocations in my program, I saw this:

class Bar
{
    ...
private:
    static std::string m_name;
    static std::string m_value;
}

Do you see any problem?  I didn’t – at first. The problem is that std::string is a STL object that has a constructor.  Statics are usually allocated at load time. Which means their constructors are likely being called during load time BEFORE the main() is hit. We assume that the corresponding destructors are called after main exits. Apparently, the CRT memory tracking starts right as the program starts but is supposed to ignore any CRT allocations (ones made by the standard C libraries).  Apparently these static allocations by STL objects are captured.  Since we report leaks BEFORE we hit the program exit, we haven’t actually hit those ‘hidden’ destructors for those static strings yet.  Those allocations are still reported as active – and hence ‘leaked’.  I only caught this because I’d initialized those strings with string literals.  The leak dumped the memory and I recognized the strings. So a good way to test if this is happening to you is set your object data to something unique and make sure those unique values appear in the leak report memory dump.

Yet another clue is that the value of an uninitialized string consists of a number that appears to be a memory address (while the addresses change each run, other allocations in that run have roughly the same addresses), and a bunch of zeros. This likely corresponds to a pointer to the character buffer, and an int that indicates size. This is further confirmed by the fact the leaks are 8 bytes each in x86 build, and 16 bytes on a x64 build. This corresponds to the sizeof(int)+sizeof(void*) sizes on the respective builds.

Solution:
The solution is to ignore what is (likely) a false report, or change the static std::string objects to non-static or static std::string* pointers. Then make an appropriate initializer/destructor that creates/destroys those string objects. This means the memory is allocated/deallocated on the heap in the scope of the program run. The other thing you do is file a bug with Microsoft and put a few comments on the documentation website that indicates the statics are still leaking and they haven’t really fixed it yet. 🙂

Links:
MS article about CRT memory debug operations that says this bug had been fixed (but it has not as of VS2012)

http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

So, I am working on something that requires I programmatically know what’s in a DX11 shader file.  One of the cool things you can use to figure out how many constant buffers, get string names from position streams, etc – is the DirectX Shader Reflection system.  It gives you the ability to query a loaded shader blob for names/types/etc.  However, it’s not quite as straightforward as one might expect to use.  The docs were pretty incomplete up until the DX11 version.  But here’s the basics of the ID3D11ShaderReflection system:

1. Load your vertex/pixel shaders.  Get the actual shader blob – or extract it from the FX system if you used that.
2. Bind it to a shader reflection object using D3DReflect:
   

   pd3dDevice->CreatePixelShader( pPixelShaderBuffer->GetBufferPointer(), pPixelShaderBuffer->GetBufferSize(), g_pPSClassLinkage, &g_pPixelShader );
   ID3D11ShaderReflection* pReflector = NULL;
   D3DReflect( pPixelShaderBuffer->GetBufferPointer(), pPixelShaderBuffer->GetBufferSize(), IID_ID3D11ShaderReflection, (void**) &pReflector);

3. Query the reflection object for whatever constant buffer, input/output stream, or other info you want using the many methods available.  It’s a GREAT way to test your shaders at load time so you don’t get cryptic runtime errors later when you try to actually draw objects.

Now, the gotcha’s:

1. You must also include this:

   #include <D3DCompiler.h>

   Or you’ll get a compile error with D3DReflect() – despite the fact the official Microsoft docs seem to say you should (only) include:

   #include <D3DShader.h>

2. Finally, you MUST have the DirectX SDK include directory listed before the windows include directory in the Visual Studio compiler include directory list or you’ll get compile errors in D3DShader.h. This is apparently because the windows headers that come with Visual Studio actually have a few DX definitions in them that conflict with the DX SDK header definitions.  
   In Visual Studio, check: Tools/Options -> Project and Solutions -> VC++ Directories and make sure Windows SDK include & library paths appear AFTER DirectX include & library paths.  See here for the thread.

From the wayback machine…

I found a half-completed post on when I was first learning to program on the iPhone.  I think these things are all still valid…
So, I’ve embarked on an ambitious programming project.  One that is now 1/3 of the way complete (first third was the ‘heaviest lifting’ part of the project – took about a month of outsourced grunt work).  The next 1/3 involves programming an app on the iPhone/iTouch.  I thought that would be the easy part, but as it turns out – there is a substantial learning curve that one should be aware of before starting this endeavor.  Here are some of the learnings I’ve found so far after having just got the bare bones of my own app up and running.

1. Apple’s documentation is very robust – but frustratingly ‘useless’ at times.  They provide many very detailed and excellent vertical stacks of information.  Want to learn about pooled allocators?  They have a document that gives you all the information you could ever want.  But not in the context of how you’d actually use them – or why you hit various problems you hit.   You’ll find yourself sifting around from document to document trying to find out why your NSString object is throwing an exception when returning from a function – only to find the real reason is buried in the memory management section of the Cocoa programming guide – not anywhere near the NSString documentation or their samples. 
2. You need to learn Objective C and Cocoa. – and learn them in THAT order.  It’s annoying, but try to find a good Objective C book first.  There aren’t many of them.  There are lots of bad ones though.  Learn how to write a class, add functions with multiple calling parameters, how to make calls to classes, and how allocation works.  That last one is key.  Really spend time learning why:
   [[NSString alloc] init]
   is the right way to allocate and initialize an object and then learn why:
   NSString *s = [[NSString alloc] initFromString:@”hello”];
   [s appendString:@”this string now leaks”];
   leaks memory.  And how the autoAllocator pools work/don’t work.  This is all huge and the first biggest gotcha’s your get hit with right off the bat.
3. You’ll struggle to get even a 5 line program working at first.  Your first Objective C/Cocoa programs will be very painful.  The simplest things will feel like fighting a brick wall.  I tried to do a simple enum, and kept getting burned by an invalid class definition.  Wha?  The objective C compiler on the iPhone requires you typedef your enums and structs:
   enum newEnum { a, b, c, d }; (NOPE – will cause a compiler error in whatever line follows this definition)
   typedef enum { a, b, c, d } newEnum; (yes – works)
   Just millions of little things like that.  Again, logical if you put your old C/gcc hat on, but it’s been a bit since I last had that hat on and it had some dust on it…
4. The GUI IDE is great – if you do things they way THEY want them and only for straight-forward designs.  The interfaces for GUI controls holds very much like Win32/X programming philosophies, albeit the syntax is very different.  X Code comes with it’s own WYSIWYG GUI editor, but I found it very limited if you’re going to come up with any kind of innovative interface.  If you just want some standard buttons/etc – you’re probably fine.  But if you want to have some interesting scrolling effects/etc – you best be ready to spend another few days learning how the UI control systems work underneath and experimenting.  The built-in GUI editor reminds me of the old VS2005 GUI editor that you could drag-n-drop controls, compile, and you’d see the results.  If you want any dynamic elements – I haven’t found a way to do that using their gui editor.  And if you want to embed controls on scrolling panels and some other more modern effects – you’ll be tossing the GUI editor altogether.  Trouble is, you spend a good bit of time learning how the built-in GUI system works, find out it won’t do the thing you need without tons of digging through forums and ‘tricking’ the thing to do what you want, then give up and have to learn a bunch of NEW stuff when you give up and decide to just dynamically/hand-generate the controls yourself.  Frustrating.

I was working on a good write-up on how to use SQLite in C# (since the most popular package install for SQLite on C# is kinda broken in Visual Studio 2010), but thought this might be a good data point for folks.

So, the short answer?  Yes, you can build SQLite databases on Windows, copy them across to your Mac, and then use them in iPhone applications without any issues.
You should open the database with the proper character formatting  ( sqlite3_open([dbPath UTF8String], &database)),
but other than that the SQL files can be just copied straight across the devices from Win 7->Mac->iPhone and the same select/delete/etc commands work like a champ.

How do I know?  I did it last night. 🙂

So, your machine is bluescreen-ing on a semi-regular basis.  It’s annoying the @#$% out of you, but you can’t find anything in the system logs that indicates what’s causing it.  Maybe (like in my case) the computer in question is your DVR box and sometime during the night Media Center is waking up, trying to update a program guide, and then blue-screening.  Nothing helpful is left in the logs, but you did get a minidump file.  If you get a minidump, my friend, you are in business!

1. Make sure you have a minidump file with your bluescreen.  You should see a numbered file with the .dmp extension with the date/time for the bluescreen located in  C:\Windows\Minidump
2. Download a handy free tool called BlueScreenView by Nirsoft.  This handy tool will automatically decipher a minidump file and you can verify that it matched what you saw on the blue-screen.  It won’t give you everything you need, but it will tell you if you have the right mini-dump for the crash you saw. It also shows you the codes thrown so you don’t have to write them down by hand at the bluescreen.  You’ll note that often BlueScreenView reports a source of the error (ntkrnl.exe in my case) but this is usually NOT the real root cause.  As we’ll soon find out, the high-level source it cites isn’t always the real problem, but was a module loaded BY that source or the module in which the source was loaded.
3. Do these one-time setup steps.  In order to make sense of the minidumps, you need some tools provided by Microsoft:
   1. Download and install the Debugging Tools for Windows pack.  Make sure it gives you the right version for your OS (win7 x64, vista x32, etc).  This pack contains the kernel debugging tools you’ll need.
   2. windbg.exe will likely be installed in c:\program files\Debugging Tools for Windows (x64) (or whatever x32/x64 you have)
   3. Open a command prompt as administrator, CD to the windbg.exe directory
   4. run:
      windbg.exe -IA
      windbg will start up, and inform you that it is now the registered file association handler for all dump files. Close windbg.exe
   5. Restart windbg, and go to file->Symbol File Path
   6. Enter:
      SRV*C:\Development\SymCache*http://msdl.microsoft.com/download/symbols
      You can set the local directory ('C:\Development\symcache' in my case) to whatever you want, but everything following the rest must be exact.  This instructs windbg to load the needed symbols from Microsoft’s internet site (release modules usually don’t have symbols, and letting you recompile your own kernel by giving the source out isn’t something MS usually lets you do. :)) Whenever you debug something and windbg needs the symbols, it checks your cache location first and downloads the needed symbols if they are not found and stores them in the cache.  So the more you debug the more symbols you build up and faster future debugging will go.  Exit windbg and save the settings.
4. Open windbg.exe (again), and do a file->open dump and open the minidump in c:\windows\minidump that corresponds to the bluescreen you’re trying to debug.  You might need to be administrator when starting windbg.
5. Windbg will automatically start downloading symbols, and doing some basic analysis.  It may look like it’s done/just sitting there sometimes, but don’t do anything until you see it’s ‘diagnosis’.  Usually looking like this:
   Use !analyze -v to get detailed debugging information.
BugCheck 9F, {3, fffffa800af7f440, fffff80000b9c4d8, fffffa800745f860}
Probably caused by : usbhub.sys
6. But don’t take this as the final word on the crash source and send nasty letters to the usbhub.sys driver writer!  Type !analyze -v as it suggest, and you’ll likely get a more detailed analysis, like this:
DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa800af7f440, Physical Device Object of the stack
Arg3: fffff80000b9c4d8, Functional Device Object of the stack
Arg4: fffffa800745f860, The blocked IRP
Debugging Details:
------------------
DRVPOWERSTATE_SUBCODE: 3 IMAGE_NAME: usbhub.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bcc2d
MODULE_NAME: usbhub
FAULTING_MODULE: fffff8800767a000 usbhub
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x9F
PROCESS_NAME: System
CURRENT_IRQL: 2


STACK_TEXT:
fffff800`00b9c488 fffff800`02ef3273 : 00000000`0000009f 00000000`00000003 fffffa80`0af7f440 fffff800`00b9c4d8 : nt!KeBugCheckEx
fffff800`00b9c490 fffff800`02e9029e : fffff800`00b9c5c0 fffff800`00b9c5c0 00000000`00000001 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x292b0
fffff800`00b9c530 fffff800`02e8fdd6 : fffff800`03034700 00000000`00146bde 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x66
fffff800`00b9c5a0 fffff800`02e904be : 00000030`9c591870 fffff800`00b9cc18 00000000`00146bde fffff800`03002e48 : nt!KiProcessExpiredTimerList+0xc6
fffff800`00b9cbf0 fffff800`02e8fcb7 : 00000010`31b602c1 00000010`00146bde 00000010`31b602f2 00000000`000000de : nt!KiTimerExpiration+0x1be
fffff800`00b9cc90 fffff800`02e8ceea : fffff800`02ffee80 fffff800`0300cc40 00000000`00000002 fffff880`00000000 : nt!KiRetireDpcList+0x277
fffff800`00b9cd40 00000000`00000000 : fffff800`00b9d000 fffff800`00b97000 fffff800`00b9cd00 00000000`00000000 : nt!KiIdleLoop+0x5a
STACK_COMMAND: kb
FOLLOWUP_NAME: MachineOwner
FAILURE_BUCKET_ID: X64_0x9F_3_AiCharger_IMAGE_usbhub.sys
BUCKET_ID: X64_0x9F_3_AiCharger_IMAGE_usbhub.sys

Now we see the whole story.  We see that in the usbhub.sys device driver, something listed in it’s ‘DPC’ table failed to respond in time to some request the usbhub.sys made.  That process was put on the timer expiration list which threw the bluescreen.  Since usbhub.sys is a hub with many things plugged into it, odds are good that the DPC list is the list of device drivers for each device plugged into the hub, a list of events that need handling, or a list of devices themselves.  When we look at the ‘failure bucket’ we see the AiCharger_IMAGE_usbhub.sys device was the source of the failure.  Odds are good the usbhub.sys is loading ‘images’ that contain the device’s driver for each of the devices plugged into the hub; and the one that failed in this case has the name AiCharger.   If I look in my Device Manager in Windows, I find a driver called AiCharger.sys – under the USB devices.  Ah ha!  A quick Google reveals this is a driver that enables smart/high-speed USB charging of iPhone/iPod devices on my Asus motherboard. If I go one step further, I can speculate that the bug is in the portion of the driver that is supposed to respond to sleep/wake/power events and that somehow the call to wake up the iPhone I have plugged in isn’t responding.  Dang – Asus owes me a donut for doing all the work for them.

So, now you know who’s really responsible.  You send a bug note to Asus with the dump results and un-install the AiCharger tool/stop leaving your iPhone connected at night to the machine when it’s asleep until they get a fix for AiCharger.  You also find out that someone else already had the same problem…
There are many other debugging commands you can also use, and those are all outlined here.  Hopefully this will help YOU out the next time some crazy bluescreen you can’t figure out; and you won’t be re-installing the OS to get rid of it.

Protips: 99% of the time, bluescreens are usually a driver and not something in the actual Windows system.  Especially if they are repeatable.  Always get the latest drivers first.
When the crashes are wake/sleep/resume/power related, often you should go to the device driver in the Device Manager and uncheck any ‘allow system to turn off the power of this device’ as a second step if the latest driver doesn’t solve it.  This prevents Windows from making calls into possibly faulty driver code.  Power mangament issues are very common with drivers still.
If you get dumps and the crashes are different places every time or random in timing – then you might have bad memory or a bad motherboard that’s corrupting things.  Check heat sinks or temps and possibly change ram/mb’s.

Other resources:
-The official Microsoft list of bluescreen failure codes with documentation on each one:
http://msdn.microsoft.com/en-us/library/ff542347%28v=VS.85%29.aspx

-Another list of the various bluescreen failure codes and their plaintext sub-code descriptions with some notes from external folks:
http://www.faultwire.com/solutions_index/fatal_error-1.html#IssueList

-Microsoft Answers forum that has really responsive and informative threads on just about every blue-screen investigation ever done.  These guys chew up minidumps all day and can help you track down just about anything that’s going on (if just searching the forum doesn’t do it for you automatically):
http://social.answers.microsoft.com/Forums/en-US/w7repair/threads

-Another Microsoft forum that seems to do a fair amount of this kind of debug work:
http://social.technet.microsoft.com/Forums/en/w7itproperf/threads

You might already know this, but this is for those of you that want to compile extra-fast on your multi-core beast.  Bet you didn’t know that by default, most versions of Visual Studio do NOT use multi-core compiling.  So, to turn it on, do this in visual studio:

Tools > Options > Projects and Solutions > Build and Run > maximum number of parallel project builds

Set this to the number of cores you have (or the number of cores you have -1 if you want to do things on your desktop while compiling extra-big things).

To see if it’s working, when you compile, in the compiler output window at the bottom you should see each line prefixed by a number like this:
1>blahblah
4>blahblah
3>blahblah

Those prefix numbers tell you which ‘core’ the message is coming from.  I find this speeds up your compile times dramatically – especially on large projects.  Give it a try!