2.0.2 and GConf

[Mark Johnson]

David Hampton wrote:

>On Wed, 2006-11-29 at 14:23 -0700, Mark Johnson wrote: 
>  
>
>>...
>>
>>#6  0xb7529807 in gnc_gconf_remove_notification (object=0x814d940, 
>>section=0x0, whoami=0x809aeb0 "\030Ý\t\b\017")
>>    at gnc-gconf-utils.c:867
>>#7  0xb7e3410b in gnc_main_window_destroy (object=0x814d940) at 
>>gnc-main-window.c:1817
>>    
>>
>
>The #6 call frame shouldn't be possible.  The calling function passes a
>constant string to gnc_gconf_remove_notification as the section name,
>and has done so since that argument was added to the function.  You're
>also showing garbage for the whoami argument, another a constant string.
>Any chance you have another copy of gnucash on your system, or didn't
>get a complete compile of the tree?
>
>David
>  
>
Interesting.  Wouldn't #6 & #7 be in the same binary file (i.e. 
gnucash-bin)?  I don't understand how an incomplete compile would lead 
to this problem, unless the two functions were in a different binary and 
I had two installs of gnucash.

I checked there are no other copies of gnucash-bin on either of my 
systems.  So far as I know, each system has only a single install of 
gnucash.

My first thought was that something had corrupted the memory containing 
the constant string.  Once I found that this constant string is define 
as a #define macro, I thought perhaps the stack was being corrupted.  So 
I tried another run with gdb.  Here it is:
(gdb) break gnc-main-window.c:1817
Breakpoint 1 at 0xb7da50e1: file gnc-main-window.c, line 1817.
(gdb) cont
Continuing.
[Switching to Thread -1230575392 (LWP 28819)]

Breakpoint 1, gnc_main_window_destroy (object=0x814d940) at 
gnc-main-window.c:1817
1817              gnc_gconf_remove_notification(G_OBJECT(window), 
GCONF_GENERAL,
(gdb) print GCONF_GENERAL
No symbol "GCONF_GENERAL" in current context.
(gdb) help next
Step program, proceeding through subroutine calls.
Like the "step" command as long as subroutine calls do not happen;
when they do, the call is treated as one instruction.
Argument N means do this N times (or till program stops for another reason).
(gdb) help step
Step program until it reaches a different source line.
Argument N means do this N times (or till program stops for another reason).
(gdb) step
gnc_gconf_remove_notification (object=0x814d940, section=0x814d940 " 
Ä\024\b\003",
    whoami=0xb7de2378 "GncMainWindow") at gnc-gconf-utils.c:855
855             g_return_if_fail(G_IS_OBJECT(object));
(gdb) print *section
$1 = 32 ' '
(gdb) print *whoami
$2 = 71 'G'

I find this disturbing.  I did one single step, from call frame #7 in 
the original backtrace to #6.  Note that object and section point to the 
same memory location!!!!

Also, the value of section on the previous run was 0x0 at the time of 
the failure.  So I try again:

(gdb) cont
Continuing.
[Switching to Thread -1230882592 (LWP 1142)]

Breakpoint 1, gnc_main_window_destroy (object=0x814d940) at gnc-main-window.c:1817
1817              gnc_gconf_remove_notification(G_OBJECT(window), GCONF_GENERAL,
(gdb) step
gnc_gconf_remove_notification (object=0x814d940, section=0x814d940 "", whoami=0xb7d97378 "GncMainWindow")
    at gnc-gconf-utils.c:855
855             g_return_if_fail(G_IS_OBJECT(object));
(gdb) print section
$1 = (const gchar *) 0x814d940 ""
(gdb) n
850     {
(gdb) print section
$2 = (const gchar *) 0x814d940 ""
(gdb) n
855             g_return_if_fail(G_IS_OBJECT(object));
(gdb) print section
$3 = (const gchar *) 0x814d940 ""
(gdb) n
856             g_return_if_fail(whoami != NULL);
(gdb) print section
$4 = (const gchar *) 0x1 <Address 0x1 out of bounds>

Now, I find this really puzzling.  Any suggestions?  (I am assuming 
g_return_if_fail is a macro that does what its name suggests.)

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.

Mark