This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[python] Something rotten in exception cleanup


Greetings,

There is something rotten in Python cleanup of exceptions:

$ ./gdb
GNU gdb (GDB) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) py gdb.parameter("foof")
Traceback (most recent call last):
  File "<string>", line 1, in ?
RuntimeError: could not find parameter `foof'
Segmentation fault

Here is what valgrind has to say about it:

(gdb) py gdb.parameter("foof")
Traceback (most recent call last):
  File "<string>", line 1, in ?
RuntimeError: could not find parameter `foof'
==16843== Invalid write of size 8
==16843==    at 0x4DC682: throw_exception ../../gdb/exceptions.c:236
==16843==    by 0x4DCA8F: throw_it ../../gdb/exceptions.c:396
==16843==    by 0x4DCAB7: throw_verror ../../gdb/exceptions.c:402
==16843==    by 0x40AC63: error ../../gdb/utils.c:796
==16843==    by 0x4677EC: python_command ../../gdb/python/python.c:149
==16843==    by 0x44BBBF: do_cfunc ../../gdb/cli/cli-decode.c:63
==16843==    by 0x44E714: cmd_func ../../gdb/cli/cli-decode.c:1700
==16843==    by 0x408263: execute_command ../../gdb/top.c:457
==16843==    by 0x4E45C5: command_handler ../../gdb/event-top.c:514
==16843==    by 0x4E4C85: command_line_handler ../../gdb/event-top.c:739
==16843==    by 0x5CC7A4: rl_callback_read_char ../../readline/callback.c:205
==16843==    by 0x4E3BE0: rl_callback_read_char_wrapper
../../gdb/event-top.c:178
==16843==  Address 0x7fefff600 is not stack'd, malloc'd or (recently) free'd

It looks like there are cleanup routines, that refer to stack
locations already popped off.

I'll try to debug this further, but posting just in case someone
can spot the problem right away.

Thanks,
-- 
Paul Pluzhnikov


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]