aboutsummaryrefslogtreecommitdiff
path: root/gdb/python
diff options
context:
space:
mode:
authorTom Tromey <tromey@redhat.com>2013-11-14 11:09:14 -0700
committerTom Tromey <tromey@redhat.com>2013-11-14 11:09:14 -0700
commit918229560ce9db307532592047066eac0674190d (patch)
treed93d534ee7e04d5c093678fb53679fc333c09e1c /gdb/python
parent57460bcf82df9e5e335be84ecc9bdef33dddc934 (diff)
downloadgdb-918229560ce9db307532592047066eac0674190d.zip
gdb-918229560ce9db307532592047066eac0674190d.tar.gz
gdb-918229560ce9db307532592047066eac0674190d.tar.bz2
off-by-one fix for py-linetable.c
While digging into a different memory corruption error, I happened to notice one coming from the linetable code. In a couple of spots, the wrong termination condition was used in a loop, leading gdb to read one element past the end of the linetable. Built and regtested on x86-64 Fedora 18. Also verified using valgrind. I'm checking this in. 2013-11-14 Tom Tromey <tromey@redhat.com> * python/py-linetable.c (ltpy_has_line) (ltpy_get_all_source_lines): Fix loop termination condition.
Diffstat (limited to 'gdb/python')
-rw-r--r--gdb/python/py-linetable.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/gdb/python/py-linetable.c b/gdb/python/py-linetable.c
index 8c01a0ee..e0449a6 100644
--- a/gdb/python/py-linetable.c
+++ b/gdb/python/py-linetable.c
@@ -215,7 +215,7 @@ ltpy_has_line (PyObject *self, PyObject *args)
return NULL;
}
- for (index = 0; index <= LINETABLE (symtab)->nitems; index++)
+ for (index = 0; index < LINETABLE (symtab)->nitems; index++)
{
struct linetable_entry *item = &(symtab->linetable->item[index]);
if (item->line == py_line)
@@ -252,7 +252,7 @@ ltpy_get_all_source_lines (PyObject *self, PyObject *args)
if (source_dict == NULL)
return NULL;
- for (index = 0; index <= LINETABLE (symtab)->nitems; index++)
+ for (index = 0; index < LINETABLE (symtab)->nitems; index++)
{
item = &(LINETABLE (symtab)->item[index]);