Posts Tagged ‘Debugging’

Debugging Windows Azure (without Intellitrace)

03/14/2012 Leave a comment

If you have, or have access to, a workstation with an x64 version of Visual Studio, you can configure Azure diagnostics to collect and copy the crash dumps to Blob Storage:

// Must be called after diagnostic monitor starts.

You can then download them (using a tool like Azure Storage Explorer) and debug them locally.

Troubleshooting Bonjour Networking for the iPhone

01/17/2010 15 comments

Debugging good code running in a stable environment is hard enough.  Debugging code that responds to outside events, well, that’s even harder.  If you are an iPhone developer working with NSNetService or GKSession, then you already know this.  Despite a glut of excellent documentation on how to write code that uses these powerful classes, there is a dearth of documentation on how to troubleshoot and debug that code.  Here are my notes on lessons that I have learned along the way.  If you have a problem with your code and are stuck, hopefully they will point you in the right direction.

Still with me?  Then let’s dig in!

Read more…

Mysterious CALayer Object Proliferation Caused By Core Animation?!

07/15/2009 Leave a comment

I have been reviewing some UI code that I just completed. It’s my regular practice to check for leaks, etc., so that I can verify that my code is doing what I think it’s doing. I typically fire up Instruments running the Leaks monitor, and not only review any leaks that are found, but also review Object Allocation behavior.

I plugged a couple of leaks that sprang up, but I still could not figure out why object allocations were growing to infinity (albeit at a snail’s pace). I could launch my app and just let it sit idle and CALayer objects were just proliferating. I narrowed the problem down to a simple background [UIView animation] block. Surely Core Animation didn’t leak, right?

Turns out, the answer is: not really. Thanks to Apple Devforum poster Rincewind, we now know:

You are probably seeing a bug in ObjectAlloc. You can confirm this in one of two ways

1) Examine the memory address of these “leaked” objects – they will probably all be the same (or a small set of addresses).

2) Add the Memory Monitor instrument from the library and watch your application’s Real Memory – this is generally a far better indicator of how much memory your application is using in total anyway.

Sure enough, he was right! The objects pouring into the list on Instruments all clustered around the same few memory addresses. Watching the physical memory confirmed that, despite the ever-growing heap in Object Allocations, physical memory was holding steady.

Whew! But Grrr! Hopefully you can avoid the frustration (until it’s patched).

Happy Debugging!