With the accounts tree visible, I select an account.  I click the open button on the toolbar to open an account register.  Once that opens, I click the close button on the account register's toolbar.  I get the following errors printed:
(gnucash:19101): GConf-CRITICAL **: file gconf-listeners.c: line 444 (ltable_remove): assertion `node != NULL' failed

(gnucash:19101): GConf-CRITICAL **: file gconf-listeners.c: line 444 (ltable_remove): assertion `node != NULL' failed



In file src/gnome-utils/gnc-main-window.c, we have the following lines:
2692 gnc_gconf_add_notification(G_OBJECT(window), GCONF_GENERAL,
2693 gnc_main_window_gconf_changed,
2694 GNC_MAIN_WINDOW_NAME);
2695 gnc_gconf_add_notification(G_OBJECT(window), DESKTOP_GNOME_INTERFACE,
2696 gnc_main_window_gconf_changed,
2697 GNC_MAIN_WINDOW_NAME);
(The numbers are line numbers and not part of the file, of course.)

Now gnc_gconf_add_notification, stores an id in the object under the key notify_tag. notify_tag is made up of two components - the whoami argument to the function and a fixed string NOTIFY_TAG ("GncMainWindow-notify_id" in both cases). 

I traced into the first call and set a watch point on the memory containing the id.  The second call triggered my watch point for finding out when the notify-tag was overwritten.

Note in the above two calls to gnc_gconf_add_notification that the whoami and object parameters are the same. This causes the second call's storing of the id value in the notify_tag key of the object to overwrite that of the first call. Thus, when the notify removal is later attempted in src/gnome-utils/gnc-main-window.c:
1815 gnc_gconf_remove_notification(G_OBJECT(window), DESKTOP_GNOME_INTERFACE,
1816 GNC_MAIN_WINDOW_NAME);
1817 gnc_gconf_remove_notification(G_OBJECT(window), GCONF_GENERAL,
1818 GNC_MAIN_WINDOW_NAME);

The second call fails and prints my GConf fatal warning, since it has just tried to remove the same notification that the first call removed. Naturally, this has lead to one notification being removed and the other being lost.

There were no further triggers of my watchpoint after line 2695 above. So nothing else changed the id value.

I am using Gnucash 2.0.2, and this error did not occur in Gnucash 2.0.1.