Category Archives: Debugging

.NET, C++, Debugging, Rant, Uncategorized

Heisenmemory

Leave a comment

I am sick of non-deterministic memory management. So sick. This was the big promise of .NET wasn’t it, way back in the 00s? No more having to worry about reference counting, double-frees or leaks. Well all we’ve done is switched it for worrying about event handlers, garbage collector pauses and weak dictionaries.

If you don’t have to worry about memory in .NET applications, then why are there so many commercial tools for solving memory-related problems? I’m starting to yearn for the days of being able to put an instance on the stack for the length of a curly-bracketed scope, and knowing that after that, it’s gone.
Continue reading Heisenmemory →

Debugging, iOS, Software Development

iOS OpenGL ES compatibility gotcha

Leave a comment

Oh man, I just wasted too many hours of my life trying to figure out why calls to glBlitFramebuffer in my iOS app were returning GL_INVALID_OPERATION. I was targeting iOS 7, so I should’ve been able to use OpenGL ES 3.0 calls, and after all, I’d built against the v3 headers and everything else was compiling and working… right?

Wrong. Well, I really should’ve RTFM. It turns out that ES 3.0 use is not determined just by the OS version, but by the hardware. So even if you’re running iOS 7, you can only use ES 3.0 if you’re on the latest gen: iPhone 5S, iPad Air etc. Check out the full compatibility matrix here.

Here are a few extra tips to help you avoid wasting your time like I did if you’re explicitly targeting OpenGL ES 3.0:

  • As well as running on the right hardware, you can also use the simulator, which supports emulation of v3.0.
  • Call glGetString(GL_VERSION) to get a report of which version you’re actually running.
  • Pass the appropriate parameter to EAGLContext initWithAPI, if you’re using it.
    e.g.

     self.context = [[EAGLContext alloc] initWithAPI:
    kEAGLRenderingAPIOpenGLES3];

It’s pretty frustrating that you get no indication that the function’s not supported, as opposed to just having being passed bad state. But I guess that’s par-for-the-course with a bare-bones, down-to-the-metal API like Open GL.

Sigh.

Debugging, Software Development, Visual Studio, WinDbg

Examining PDB files with DBH

2 Comments

Wow, it’s been a ridiculously long time since I’ve blogged. I think it’s time I put something up just to break the curse, and this seemed like a good, and hopefully useful, place to start. Time to polish some of these dusty drafts into published gems.

Ever been in that situation where you (or someone else) finds that Visual Studio just won’t set a breakpoint in some source code that you’re sure should be being used? You’ll see the hollow breakpoint icon and something like ‘The breakpoint will not currently be hit. No symbols have been loaded for this document’.
Continue reading Examining PDB files with DBH →

.NET, Debugging, Windows

.NET DLLs Loaded Twice

4 Comments

If, like me, you’re still squeezing yourself into 32-bit Windows processes, you’re probably, also like me, constantly keeping an eye on the virtual address space usage of your application. If you happen to have used something like vmmap to take a peek at your memory contents, maybe you’ve noticed something strange with some .NET assemblies: they’re loaded twice! What’s going on…?
Continue reading .NET DLLs Loaded Twice →

.NET, Debugging, Visual Studio, WinDbg, Windows

Am I being called from DllMain?

Leave a comment

Lock; literal images 'r' us
Lock; literal images 'r' us
While Googling for an obscure Windows function the other day, I came across this fantastically useful repository of undocumented WinAPI functions, put together by Geoff Chappell. I’m not sure how I hadn’t discovered it before.

One of the functions that immediately caught my eye was LdrLockLoaderLock. I’d previously spent quite a few frustrating hours trying to figure out how to determine whether some code was being executed from DllMain, i.e. while in the loader lock, so I could avoid doing anything dodgy – or indeed, anything at all.

The case I was looking at was some logging library code that was used, amongst other things, to record the fact that DLLs were being unloaded. Unfortunately when this was called from DllMain, it sometimes caused a deadlock, for all the reasons we already know about. The library code was called from lots of DLLs, so it wasn’t feasible to fix all of the call sites, instead I had to make the logging a no-op when it’s not safe.
Continue reading Am I being called from DllMain? →

.NET, COM, Debugging, WinDbg, Windows

.NET 4.0 Type Equivalence causes BadImageFormatException

6 Comments

I recently discovered a nasty backward compatibility problem with the new type equivalence feature in .NET 4.0. Luckily it’s relatively difficult to hit it if you’re in a pure-C# environment, but if you happen to generate any assemblies directly using IL, you should watch out. Read on for all the gory details.
Continue reading .NET 4.0 Type Equivalence causes BadImageFormatException →

Debugging, Software Development, WinDbg, Windows

Modifying the VC runtime to get better heap allocation stack traces

3 Comments

Today I was trying to track down some – how can I put this politely – “unusual” memory usage in some unmanaged code running inside Excel. I broke out WinDbg and tried the usual suspects to get an idea of how memory was being used. Unfortunately, the way that msvcr80.dll is built stopped me from getting decent stack traces for the allocations, so I decided to try and rebuild it with a fix to remedy the situation.
Continue reading Modifying the VC runtime to get better heap allocation stack traces →

.NET, COM, Debugging, Software Development, WinDbg

Beware of using stack-based COM objects from .NET

4 Comments

There are all sorts of nasty things to be aware of if you’re mixing reference-counted COM objects with garbage-collected .NET. For instance, if you’re implementing COM objects in C++ then you’re free to allocate them anywhere you like; on the heap or perhaps on the stack if you know they’re only used in some specific scope.

But what happens if during the lifetime of that stack based COM object, it gets used from .NET? A runtime callable wrapper (RCW) will be created around the object. And this RCW expects to be able to keep the underlying object alive by incrementing its reference count. Of course, the stack-based object will soon go out of scope, and regardless of its reference count the object will be destroyed and the pointer that the RCW contains will no longer be valid. It points into the stack, so when the RCW gets cleaned-up, the CLR will call via this pointer into memory that contains garbage and you’ll get something nasty like an access violation or illegal instruction exception.

Continue reading Beware of using stack-based COM objects from .NET →

Debugging, Software Development, Uncategorized, Windows

Don’t do anything in DllMain… Please

Leave a comment

Novice Windows programmers can often think that DllMain is a good place to get that one-time set-up and tear-down work done. It seems to offer an ideal opportunity to know when your DLL has just been loaded, and when it’s about to be unloaded. What better place to add all that expensive, complicated initialisation…? STOP! WAIT! Before you add anything in DllMain, make sure you understand what state the process will be in when it gets called. Once you know that, you may well change your mind…
Continue reading Don’t do anything in DllMain… Please →