I do actually get a number of notifications that way. But at some point the application does crash. The stack trace shows it is crashing with EXC_BAD_ACCESS in realizeClass, which from my experience does indicate that something gets called after its deallocation. My observing object however still is alive, its deallocator has not been called (yet).

Next thing I tried was setting a breakpoint towards -[NSNotificationCenter postNotification:] and then run po {NSNotification *}($ebp+16) inside the gdb-console whenever my breakpoint is trapped. That did reveal a few notifications but not all that I am expecting/hoping for. For example, my application does handle orientation-changes properly but I do not see any notifications being trapped when reorienting the device (in the simulator).

What am I missing?
Is there a way (e.g. a tool) for reliably observing a NSNotificationCenter?

Thanks for any hint.

Answers:

The only solution I got to work was using breakpoints.

I added a breakpoint at __CFXNotificationPost_old (CoreFoundation) and bundled that with a Debugger Command po {NSNotification *}($ebp+12). All of this is nicely doable within the Xcode GUI:

click on “Run” on the Xcode application menu (top of the screen)

select “Debugger”

within the Debugger window click on “Show-Breakpoints”

click on the “Enter Symbol-Name”-line and enter “__CFXNotificationPost_old”

click on the “+” on the very right side

select “Debugger Command” on that dropdown-list

enter “po {NSNotification *}($ebp+12)

(you may also want to activate logging by checking the “Log” checkbox at the bottom)

run your app in a simulator-debug-session from within Xcode

The app will stop its execution whenever a NSNotification is posted and display it within the gdb-console.

I did try to create a tracepoint within gdb but failed because the tracepoint actions within Xcode gdb seem to buggy – or maybe I am just too stoopid to get them working.

I also tried to create a custom Instruments Dtrace script, but failed as my Dtrace Karate just isnt strong enough.

If you manage to get any of the latter options to work, please go ahead and post them as an alternative answer – I will upvote and mark them as the favored one.

UPDATE

Ages after this question, I found the right way of trapping all notifications on the CoreFoundation level.

I actually feel a little ashamed that I did not look closer at CoreFoundation’s interface before.

Questions:

Answers:

Hey Till—I use notifications a lot, and I had some serious problems debugging them as well. I recently released an app called the Spark Inspector (http://sparkinspector.com/) that makes the process a bit easier. You add a framework to your app, and it swizzles NSNotificationCenter so you can see a table of all of the notifications sent and received in y our app, with the stack traces where they were sent and the list of all the methods that observed them. I know it’s about three years late, but it may help!

Questions:

Answers:

I know the posted question is old, but I figured I’d respond with a couple lines of code. You can see all the notifications posted while your app is running via this block:

For debugging purposes, I find that a breakpoint is actually better than adding code to the project. However, @Till’s solution didn’t seem to work for me. I found another solution online, and tweaked it a bit.

I use .length == 0 instead of .location == NSNotFound because NSNotFound seems to evaluate to a different value (-1 or (NSUInteger)18446744073709551615) than the returned value in this breakpoint (9223372036854775807).