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.
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.
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→
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→
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?→
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→
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→
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.
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→
I’ve just noticed a nice little feature in Visual Studio 2010 Beta 2: pinned DataTips. Values displayed in the debugger as you hover over a variable can now be pinned in place and remain aligned with the source. They can even have annotations added… Tasty!
I’m working in an environment with a lot of mixed managed (F#) and unmanaged (C++ COM) code. One of the big problems with this is the mix of lifetime management techniques; .NET uses garbage collection while COM relies on reference counting. Furthermore .NET garbage collection is somewhat non-deterministic, which adds further complexity.
So quite often in our mixed code-base, we find that the .NET garbage collection process doesn’t kick in when we need it to. For instance, when we’ve allocated a lot of memory in the COM code that .NET isn’t aware of. Memory exhaustion has to get pretty bad for the GC to occur at any other time than during a .NET allocation, either the system-wide low-memory event has to be signalled or an OutOfMemoryException needs to be thrown. In both of these cases it’s probably too late to do anything about it.