GDB crashing on gdb.python/py-linetable.exp

GDB crashing on gdb.python/py-linetable.exp

[Jan Kratochvil]

Hi Phil,

at least on CentOS-6.5 x86_64 with -lmcheck I get the following crash.

I have seen the crash also once on Fedora Rawhide x86_64 but I do not have it
reproducible there.  But it suggests to me it does not have to be necessarily
just CentOS-6 specific.  I have not tried real RHEL.


Regards,
Jan


$ runtest gdb.python/py-linetable.exp 
Running ./gdb.python/py-linetable.exp ...
ERROR: Process no longer exists
ERROR: Couldn't send python print len(lt.line(20)) to GDB.
[...]
$ gdb ../gdb ./core.*
Program terminated with signal 11, Segmentation fault.
#0  0x00007f4d77642b1f in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>)
    at Python/ceval.c:952
952	        f->f_lasti = INSTR_OFFSET();
(gdb) bt
#0  in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:952
#1  in PyEval_EvalCodeEx (co=0x7f4d78731468, globals=<value optimized out>, locals=<value optimized out>, args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3044
#2  in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>) at Python/ceval.c:545
#3  in run_mod (mod=<value optimized out>, filename=<value optimized out>, globals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, locals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, flags=<value optimized out>, arena=<value optimized out>) at Python/pythonrun.c:1358
#4  in PyRun_StringFlags (str=0x3cbe3a7 "print len(lt.line(42))", start=257, globals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, locals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, flags=0x0) at Python/pythonrun.c:1321
#5  in PyRun_SimpleStringFlags (command=0x3cbe3a7 "print len(lt.line(42))", flags=0x0) at Python/pythonrun.c:974
#6  in python_command (arg=0x3cbe3a7 "print len(lt.line(42))", from_tty=1) at ./python/python.c:477
#7  in do_cfunc (c=0x3f53ae0, args=0x3cbe3a7 "print len(lt.line(42))", from_tty=1) at ./cli/cli-decode.c:107
#8  in cmd_func (cmd=0x3f53ae0, args=0x3cbe3a7 "print len(lt.line(42))", from_tty=1) at ./cli/cli-decode.c:1886
#9  in execute_command (p=0x3cbe3bc ")", from_tty=1) at top.c:458
#10 in command_handler (command=0x3cbe3a0 "python print len(lt.line(42))") at event-top.c:435
#11 in command_line_handler (rl=0x4683160 "\320%2\004") at event-top.c:632
#12 in rl_callback_read_char () at callback.c:220
#13 in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:164
#14 in stdin_event_handler (error=0, client_data=0x0) at event-top.c:375
#15 in handle_file_event (data=...) at event-loop.c:768
#16 in process_event () at event-loop.c:342
#17 in gdb_do_one_event () at event-loop.c:394
#18 in start_event_loop () at event-loop.c:431
#19 in cli_command_loop (data=0x0) at event-top.c:179
#20 in current_interp_command_loop () at interps.c:327
#21 in captured_command_loop (data=0x0) at main.c:266
#22 in catch_errors (func=0x7636f8 <captured_command_loop>, func_args=0x0, errstring=0x1037fe4 "", mask=RETURN_MASK_ALL) at exceptions.c:524
#23 in captured_main (data=0x7fffd2f237b0) at main.c:1054
#24 in catch_errors (func=0x7639d1 <captured_main>, func_args=0x7fffd2f237b0, errstring=0x1037fe4 "", mask=RETURN_MASK_ALL) at exceptions.c:524
#25 in gdb_main (args=0x7fffd2f237b0) at main.c:1062
#26 in main (argc=5, argv=0x7fffd2f238b8) at gdb.c:33
(gdb) _

Re: GDB crashing on gdb.python/py-linetable.exp

[Phil Muldoon]

On 06/02/14 21:30, Jan Kratochvil wrote:
> Hi Phil,
>
> at least on CentOS-6.5 x86_64 with -lmcheck I get the following crash.
>
> I have seen the crash also once on Fedora Rawhide x86_64 but I do not have it
> reproducible there.  But it suggests to me it does not have to be necessarily
> just CentOS-6 specific.  I have not tried real RHEL.
>

I've tried most of the morning to reproduce this on Fedora 19, with
-lmcheck and after several thousand test runs I can't reproduce.  Is
there access to a machine where I can reproduce this?

> $ gdb ../gdb ./core.*
> Program terminated with signal 11, Segmentation fault.
> #0  0x00007f4d77642b1f in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>)
>     at Python/ceval.c:952
> 952            f->f_lasti = INSTR_OFFSET();
> (gdb) bt
> #0  in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:952
> #1  in PyEval_EvalCodeEx (co=0x7f4d78731468, globals=<value optimized out>, locals=<value optimized out>, args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3044
> #2  in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>) at Python/ceval.c:545
> #3  in run_mod (mod=<value optimized out>, filename=<value optimized out>, globals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, locals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, flags=<value optimized out>, arena=<value optimized out>) at Python/pythonrun.c:1358
> #4  in PyRun_StringFlags (str=0x3cbe3a7 "print len(lt.line(42))", start=257, globals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, locals={'__builtins__': <module at remote 0x7f4d787d4868>, 'GdbRemoveReadlineFinder': <classobj at remote 0x7f4d78728590>, 'lt': <gdb.LineTable at remote 0x7f4d7871b138>, 'list_lines': <function at remote 0x7f4d78731578>, '__package__': None, 'sys': <module at remote 0x7f4d787d4c20>, 'gdb': <module at remote 0x7f4d787431a0>, '__name__': '__main__', '__doc__': None}, flags=0x0) at Python/pythonrun.c:1321
> #5  in PyRun_SimpleStringFlags (command=0x3cbe3a7 "print len(lt.line(42))", flags=0x0) at Python/pythonrun.c:974

I suspect the linetable information in GDB is not what this test
expects it to be.

The method that causes this crash just uses:

pcs = find_pcs_for_symtab_line (symtab, py_line, &best_entry);

But as this is happening in the C evaluation part of the code in
Python I can't tell if this happened earlier and screwed up Python, or
if there is something wrong with the Python tuple holding the line
table data.

Cheers

Phil

[patch] [python] Re: GDB crashing on gdb.python/py-linetable.exp

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Fri, 07 Feb 2014 11:45:04 +0100, Phil Muldoon wrote:
> I've tried most of the morning to reproduce this on Fedora 19, with
> -lmcheck and after several thousand test runs I can't reproduce.

Due to the requirement of specific stack layout I found it is reproducible for
me on Fedora 20 x86_64 with (it sure could be reduced):

CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic" LDFLAGS="-static-libstdc++ -static-libgcc -Wl,-z,relro" ./configure --with-system-readline;make
(ulimit -c unlimited;/usr/bin/runtest gdb.python/py-linetable.exp)

The fix is obvious, I will check it in.

-  int py_line;
+  gdb_py_longest py_line;
[...]



Regards,
Jan

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 831 bytes --]

gdb/
2014-02-07  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix Python stack corruption.
	* python/py-linetable.c (ltpy_get_pcs_for_line, ltpy_has_line): Use
	gdb_py_longest.

diff --git a/gdb/python/py-linetable.c b/gdb/python/py-linetable.c
index e83d46d..8b5362b 100644
--- a/gdb/python/py-linetable.c
+++ b/gdb/python/py-linetable.c
@@ -168,7 +168,7 @@ static PyObject *
 ltpy_get_pcs_for_line (PyObject *self, PyObject *args)
 {
   struct symtab *symtab;
-  int py_line;
+  gdb_py_longest py_line;
   struct linetable_entry *best_entry = NULL;
   linetable_entry_object *result;
   VEC (CORE_ADDR) *pcs = NULL;
@@ -200,7 +200,7 @@ static PyObject *
 ltpy_has_line (PyObject *self, PyObject *args)
 {
   struct symtab *symtab;
-  int py_line;
+  gdb_py_longest py_line;
   int index;
 
   LTPY_REQUIRE_VALID (self, symtab);

[commit+7.7] [patch] [python] Re: GDB crashing on gdb.python/py-linetable.exp

[Jan Kratochvil]

On Fri, 07 Feb 2014 18:17:01 +0100, Jan Kratochvil wrote:
> The fix is obvious, I will check it in.

Checked in:
	2a081c592cf727c5103808374834c4915e83521a
And for gdb-7.7-branch:
	e661fce02d46838124aa94618c4b87b59d922ab3


Jan

Re: [commit+7.7] [patch] [python] Re: GDB crashing on gdb.python/py-linetable.exp

[Joel Brobecker]

Hi Jan,

> Checked in:
> 	2a081c592cf727c5103808374834c4915e83521a
> And for gdb-7.7-branch:
> 	e661fce02d46838124aa94618c4b87b59d922ab3

Sorry to be a pest, but when we discussed how to document fixes
in the branch after the first release, we request PR numbers.
See the 7.6 branch management page.

I agree the page layout for this release isn't really all that
great, so I'll try adjust it to make it easier to read.

Thank you!
-- 
Joel

Re: [commit+7.7] [patch] [python] Re: GDB crashing on gdb.python/py-linetable.exp

[Jan Kratochvil]

Hi Joel,

On Mon, 10 Feb 2014 03:08:51 +0100, Joel Brobecker wrote:
> See the 7.6 branch management page.

I tried to search gdb, gdb-patches and wiki and I cannot find this page.

I hope I have modified it as expected
	https://sourceware.org/gdb/wiki/GDB_7.7_Release?action=diff&rev2=118&rev1=117
	https://sourceware.org/bugzilla/show_bug.cgi?id=16547


Thanks,
Jan

Re: [commit+7.7] [patch] [python] Re: GDB crashing on gdb.python/py-linetable.exp

[Joel Brobecker]

> I tried to search gdb, gdb-patches and wiki and I cannot find this page.

Sorry, I should have been clearer. That's the wiki page we used
to manage the GDB 7.6 branch:
https://sourceware.org/gdb/wiki/GDB_7.6_Release

(those pages are accessible from the wiki main page under "GDB
Releases").

Regardless, ...

> I hope I have modified it as expected
> 	https://sourceware.org/gdb/wiki/GDB_7.7_Release?action=diff&rev2=118&rev1=117
> 	https://sourceware.org/bugzilla/show_bug.cgi?id=16547

This is perfect. Thank you!

-- 
Joel