Warning: Parameter 2 to GoogleSitemapGeneratorLoader::KillFrontpagePosts() expected to be a reference, value given in /home/public/blog/wp-includes/class-wp-hook.php on line 286
Dysfunctional Programming » nsCOMPtr has never been so pretty

nsCOMPtr has never been so pretty

Jim Blandy announced his archer-mozilla pretty-printers for Spidermonkey late last year. I’ve used them a few times while working on some JS proxy bugs, and I’ve found them to be invaluable. So invaluable, in fact, that I’ve written a bunch of pretty-printers for some pain points outside of js/. If this prospect excites you so much that you can’t be bothered to read the remaining examples, you can acquire the code from its hg repo. Please note, you’ll need to be using gdb >7.2 (meaning probably trunk at the time of writing) due to dependencies on the dynamic_type feature which was recently added.

What’s supported right now:


If you print an nsCOMPtr, you’ll see one of two things:
[(nsIFoo*) 0x0]
[(nsConcreteFoo*) 0x12345678]

In addition, pretty-printers chain, so if there’s a pretty printer for nsConcreteFoo*, you’ll see that printed instead of just the pointer value. Furthermore, nsRefPtr and nsAutoPtr are also supported, and maybe nsWeakPtr (untested).


It prints the string inline, up to the limit specified by gdb. This probably only works for ascii strings at the moment; the code is a bit of a mess.


You’ll get output along the lines of [0x12345678, 0x12345678] at the moment. Like the smart pointers, each printed element will be pretty-printed if possible.


You’ll see the spec printed. This works wonderfully when you’re looking at an object with nsCOMPtr<nsIURI> foo, where foo is actually pointing to an nsStandardURL object.

Tagged reference counts

You know in cycle-collected objects when the refcount shows you mTagged = 0x8? Yeah, not any more.


I found the existing display of mBoolVal = 1 '\001' to be silly.

What’s coming up?

I’ve got a list of things that still need fixing/improving, and I’m open to suggestions/patches.

  • Auto arrays – the kinda-sorta work right now, but it looks gross.
  • COM/void/observer arrays – don’t work at all
  • Hashtables – don’t work at all right now
  • Stricter regexes for matching types – things like pointers to arrays are matched by the nsTArray printer right now
  • Auto strings – I don’t remember if they don’t work at all or semi-work
  • PRUnichar* – doesn’t work.

and so on and so forth. It’s really not difficult to write more printers, and it improves the output of gdb immensely in my opinion. Give it a shot! The instructions for how to set this up can be found in the README file. You’ll need a version of gdb > 7.2 (probably trunk, at the time of writing), since my printers rely on gdb.Type.dynamic_type.

2 Responses to “nsCOMPtr has never been so pretty”

  1. Does gdb archer work on OS X? I have a vague memory of trying it and failing, but I’m not sure.

  2. It does not, at this moment. However, I’m following a bug in which patches are being posted that allow gdb to make progress. The future is bright!

Leave a Reply