false reports due to gdb's exception mechanism

[davidmalcolm]

This report is incorrect:

../../archer/gdb/python/python.c: In function ‘gdbpy_parameter’: ../../archer/gdb/python/python.c:358:12: error: dereferencing uninitialized pointer: cmd.93->var at ../../archer/gdb/python/python.c:358 [-Werror]

I believe this happens because 'cmd' is initialized in a TRY_CATCH in gdb.

gdb has its own exception-handling system based on longjmp. TRY_CATCH is a tricky macro that expands to a doubly-nested loop; the loop will either exit via an exception (which in the function above we check for afterwards) or normally. However, there is no way to explain this invariant to the checker, which (I believe) assumes that the outer loop might run 0 times, causing it to think there are more code paths than are actually possible.

One idea for fixing this would be to let us provide a plugin to the plugin, to teach it about odd, program-specific situations like this.

[davidmalcolm]

Imported from trac issue 16. Created by tromey on 2012-01-04T16:14:31, last modified: 2012-01-05T13:19:41

[davidmalcolm]

Trac comment by tromey on 2012-01-05 13:19:41:

Actually, the situation for gdb is even worse than what I described above. gdb also installs cleanups which are run when an exception is thrown; or explicitly run (or discarded) on normal exit. These cleanups are just a function and user-data argument. So, e.g., make_cleanup_py_decref(obj) makes a new cleanup that, when run, will call Py_DECREF(obj).

So, for this checker to work properly on gdb, we'd also have to teach it about cleanups. This is nontrivial :-(