search

davidmalcolm / gcc-python-plugin

GCC plugin that embeds CPython inside the compiler
GNU General Public License v3.0
199 stars 58 forks source link

false reports due to gdb's exception mechanism #56

Open davidmalcolm opened 7 years ago

davidmalcolm commented 7 years ago

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 commented 7 years ago

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

davidmalcolm commented 7 years ago

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 :-(