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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
