On second thought, although the ref count might be the easiest way to fix this, it would be totally reasonable to say "no function that's registered as a stonith notify callback should ever free the stonith_t object."

I need to verify this, but here's what I think is happening:

1. Mainloop destroys stonith API connection, calling stonith_connection_destroy() on the stonith client.
2. The stonith client sends out T_STONITH_NOTIFY_DISCONNECT notifications via foreach_notify_entry() -> stonith_send_notification().
3. One notification triggers crm_mon.c:mon_st_callback_display() (or event()), which calls mon_cib_connection_destroy().
4. mon_cib_connection_destroy() calls stonith_api_delete(), which calls stonith_api_free() and destroys the entire client object.
5. Control returns to stonith_send_notification() and foreach_notify_entry().
6. One of the further attempts to access members of the stonith client object causes a segfault, since the object and all the members that it owns have been freed.

I've reproduced this on 2.1.0, 2.1.2, and 2.1.7, so it doesn't appear to be a regression. Additionally, it only happens at shutdown, so there's no tangible impact except that it won't reconnect when the cluster starts back... which is not great.