Conditional jump or move depends on uninitialised value(s) in header_func
Steps to reproduce:
- Close all currently running instances of GNOME To Do, e.g. using
gnome-todo --quit
- Open GNOME To Do through valgrind with a command line like this:
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --track-origins=yes --vgdb=full --vgdb-error=0 gnome-todo
- Start gdb
gdb gnome-todo
- Attach gdb to valgrind as you are told by valgrind (or just by executing
target remote | vgdb
in gdb given that you have no other valgrind instance running at the same time
What I expect to happen
No messages from valgrind
What happens:
Before actually starting the GUI, you will see this message from valgrind:
==18432== Conditional jump or move depends on uninitialised value(s)
==18432== at 0x4BD9C52: gtk_style_context_add_class (gtkstylecontext.c:683)
==18432== by 0x155F89: create_label.lto_priv.0.lto_priv.0 (gtd-all-tasks-panel.c:178)
==18432== by 0x157905: header_func (gtd-all-tasks-panel.c:236)
==18432== by 0x1464DC: UnknownInlinedFun (gtd-task-list-view.c:559)
==18432== by 0x1464DC: internal_header_func (gtd-task-list-view.c:537)
==18432== by 0x4B45CCB: gtk_list_box_update_header.part.0.lto_priv.0 (gtklistbox.c:2272)
==18432== by 0x4B464FB: UnknownInlinedFun (gtklistbox.c:2251)
==18432== by 0x4B464FB: gtk_list_box_insert (gtklistbox.c:2734)
==18432== by 0x4B46724: gtk_list_box_bound_model_changed.lto_priv.0 (gtklistbox.c:3666)
==18432== by 0x538CC2E: g_closure_invoke (gclosure.c:830)
==18432== by 0x53A9055: signal_emit_unlocked_R (gsignal.c:3742)
==18432== by 0x53AA919: g_signal_emit_valist (gsignal.c:3497)
==18432== by 0x53AAB32: g_signal_emit (gsignal.c:3553)
==18432== by 0x538CC2E: g_closure_invoke (gclosure.c:830)
==18432== Uninitialised value was created by a stack allocation
==18432== at 0x157800: header_func (gtd-all-tasks-panel.c:213)
I've attached a shortened backtrace (bt
in gdb) and a full backtrace (bt full
in gdb). Please note that in this debugging case, the variables on the stack are pre-initialized with 0x0
, which is not the case outside a debugger. Outside the debugger, any access to the variable at that time may or may not lead to a crash.
Investigation
I think what happens is that in
That is nonsense.internal_header_func
, the variable GtdTask *before_task;
is allocated on the stack but not initialized in every case, i.e. not initialized if the parameter to internal_header_func
, GtkListBoxRow *before
is NULL
(which is expected according to the documentation of ListBoxUpdateHeaderFunc. In this case, an unitialized before_task
is passed through until valgrind stumbles over it.
Potential solution
As far as I understand, initializing GtdTask *before_task
to NULL
should solve the issue.
Design Tasks
-
design tasks
Development Tasks
-
development tasks
QA Tasks
-
qa (quality assurance) tasks