2.0.2 and GConf

[Mark Johnson]

Derek Atkins wrote:

>Mark Johnson <mrj001 at shaw.ca> writes:
>
>  
>
>>Mark Johnson wrote:
>>
>>    
>>
>>>This does not look like the sort of thing that occurs when debugging
>>>optimized code, but I am going to try a build without optimization
>>>anyway.
>>>
>>>
>>>
>>>      
>>>
>>Obviously, the optimization was interfering with debugging.  Here is the 
>>gnucash terminal output:
>>mj at ds9:~$ gnucash --g-fatal-warnings
>>
>>GConf-CRITICAL **: file gconf-listeners.c: line 444 (ltable_remove): 
>>assertion `node != NULL' failed
>>aborting...
>>    
>>
>
>This would seem to imply that we're trying to remove a listener
>a second time, when the listener has already been removed.  At
>least that's my reading of the message.
>  
>
I've been working on this in my spare time. (You'd think I'd have more 
of that since I'm on leave from work, but....)

Setting a breakpoint at gnc-gconf-utils.c:867 indicates that this is not 
being called twice. I also set a breakpoint at gnc-main-window.c:2692 
where the notification is added. I noted the id that was stored in the 
GObject under notify_tag (in gnc_gconf_add_notification). When gnucash 
tried to release this listener (in gnc_gconf_remove_notification), the 
id value had changed (I confirmed that the object pointer was the same 
as before).

This raises two possibilities:
1. Gnucash is changing it. (I expect this would be a bug.)
2. "Something else" is trashing it. (Someone else's bug)

As no one else seems to be having this problem (or at least no one else 
has said "me too"), my favoured theory is #2. I've compiled a version of 
glib with debugging information intact (and no optimization :-). Soon, 
I'll install it, and set a watch to find out exactly what is changing 
this memory.

Also as a consequence of no one else reporting this, I suspect I would 
be the best person to chase this down. Let me know if anything above 
indicates I am lost...

>-derek
>
>  
>
Mark