gEDA-dev: Autosave timeout bug.. more info

[Peter Clifton]

Hi,

Chasing the autosave crash, I have a potentially useful trace output
from valgrind.

(I turned up the autosave timeout by removing the * 1000 - seconds to
milliseconds in the code, so I can set a save timeout of 100ms from the
gschemrc file. This ought to catch the bug more often).

==18659== Invalid read of size 4
==18659==    at 0x405196C: s_page_autosave (s_page.c:546)
==18659==    by 0x43C0ACC: g_timeout_dispatch (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x43BC9B2: g_main_dispatch (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x43BF10F: g_main_context_iterate (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x43BF499: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x4581714: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.800.19)
==18659==    by 0x8059F00: main_prog (gschem.c:355)
==18659==    by 0x40BE819: scm_boot_guile (in /usr/lib/libguile.so.12.3.0)
==18659==    by 0x805A0DD: main (gschem.c:382)
==18659==  Address 0x4CC73E0 is 33,800 bytes inside a block of size 34,188 free'd
==18659==    at 0x401C66F: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==18659==    by 0x43C65A3: g_free (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x4055B1F: s_toplevel_delete (s_toplevel.c:491)
==18659==    by 0x808AB22: x_window_close (x_window.c:1036)
==18659==    by 0x8079DAF: exit_dialog_ok (x_dialog.c:1660)
==18659==    by 0x436EB75: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x4356F68: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x436D590: signal_emit_unlocked_R (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x436E4C3: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x436E785: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x4484751: gtk_real_button_released (in /usr/lib/libgtk-x11-2.0.so.0.800.19)
==18659==    by 0x436EB75: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==
==18659== Invalid read of size 4
==18659==    at 0x4051976: s_page_autosave (s_page.c:553)
==18659==    by 0x43C0ACC: g_timeout_dispatch (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x43BC9B2: g_main_dispatch (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x43BF10F: g_main_context_iterate (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x43BF499: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x4581714: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.800.19)
==18659==    by 0x8059F00: main_prog (gschem.c:355)
==18659==    by 0x40BE819: scm_boot_guile (in /usr/lib/libguile.so.12.3.0)
==18659==    by 0x805A0DD: main (gschem.c:382)
==18659==  Address 0x4CBF0EC is 276 bytes inside a block of size 34,188 free'd
==18659==    at 0x401C66F: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==18659==    by 0x43C65A3: g_free (in /usr/lib/libglib-2.0.so.0.1000.3)
==18659==    by 0x4055B1F: s_toplevel_delete (s_toplevel.c:491)
==18659==    by 0x808AB22: x_window_close (x_window.c:1036)
==18659==    by 0x8079DAF: exit_dialog_ok (x_dialog.c:1660)
==18659==    by 0x436EB75: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x4356F68: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x436D590: signal_emit_unlocked_R (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x436E4C3: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x436E785: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==    by 0x4484751: gtk_real_button_released (in /usr/lib/libgtk-x11-2.0.so.0.800.19)
==18659==    by 0x436EB75: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1000.3)
==18659==


So, the toplevel is being free'd as the window closes, and the autosave timer is sometimes hitting after that.

I'm not 100% sure that this is the only case in which the auto-save timer causes a crash, but its the main one I've been able to reproduce occasionally. I think I've also seen it crash out there whilst gschem is just sitting before now, and the immediate cause is a corrupt toplevel pointer, or page linked list.
(Its usually a page it can't access in the linked list, but this may be as the toplevel is wrong, a wild-goosechase along a random linked list ensues until it hits a bad memory pointer.

Peter Clifton