Bug 17109 - gdb 7.7 crashes when issuing mi command: -trace-frame-collected
Summary: gdb 7.7 crashes when issuing mi command: -trace-frame-collected
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: mi (show other bugs)
Version: 7.7
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-02 22:26 UTC by hochby
Modified: 2014-07-15 20:29 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
Project(s) to access:
ssh public key:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hochby 2014-07-02 22:26:12 UTC
gdb 7.7 crashes when issuing mi command: -trace-frame-collected
steps:

1. target remote (to an embedded system with gdb stub that supports tracepoints).
2. define a trace point with collection actions
3. experiment runs... frames are created...
4. tstop
5. tfind start
6. issue: interpreter-exec mi "-trace-frame-collected"
=> gdb crash

This happens 100% of the times.
Comment 1 Yao Qi 2014-07-03 01:59:08 UTC
I can't reproduce it on gdb 7.7 with gdbserver:

(gdb) trace start
Tracepoint 1 at 0x8048483: file ../../../../git/gdb/testsuite/gdb.trace/read-memory.c, line 28.
(gdb) actions 
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect testglob
>collect constglob
>end
(gdb) b end
Breakpoint 2 at 0x8048488: file ../../../../git/gdb/testsuite/gdb.trace/read-memory.c, line 32.
(gdb) tstart 
(gdb) c
Continuing.

Breakpoint 2, end () at ../../../../git/gdb/testsuite/gdb.trace/read-memory.c:32
32      {}
(gdb) tstop 
(gdb) tfind start
Found trace frame 0, tracepoint 1
#0  start () at ../../../../git/gdb/testsuite/gdb.trace/read-memory.c:28
28      {}
(gdb) interpreter-exec mi "-trace-frame-collected"
^done,explicit-variables=[{name="testglob",value="1"},{name="constglob",value="10000"}],computed-expressions=[],registers=[{number="8",value="0x8048483"}],tvars=[],memory=[{address="0x08048574",length="4"},{address="0x0804a020",length="4"}]

The backtrace of GDB when it crashes would be helpful.
Comment 2 David Taylor 2014-07-10 23:36:13 UTC
I don't know why Yigal wouldn't provide a backtrace.  Here is one.

Program terminated with signal 11, Segmentation fault.
#0  0x0812ad04 in mi_cmd_trace_frame_collected (
    command=0xb049170 "trace-frame-collected", argv=0xb049200, argc=0)
    at ../../gdb/mi/mi-main.c:2844
2844	    for (i = 0; VEC_iterate (int, tinfo->tvars, i, tvar); i++)
(gdb) p i
$1 = 0
(gdb) p tinfo
$2 = (struct traceframe_info *) 0x0
(gdb) where
#0  0x0812ad04 in mi_cmd_trace_frame_collected (
    command=0xb049170 "trace-frame-collected", argv=0xb049200, argc=0)
    at ../../gdb/mi/mi-main.c:2844
#1  0x08129837 in mi_cmd_execute (parse=0xae12b78)
    at ../../gdb/mi/mi-main.c:2215
#2  0x08128f5a in captured_mi_execute_command (uiout=0xb040960, 
    context=0xae12b78) at ../../gdb/mi/mi-main.c:1950
#3  0x08129320 in mi_execute_command (cmd=0xb049140 "-trace-frame-collected", 
    from_tty=1) at ../../gdb/mi/mi-main.c:2078
#4  0x0812443d in mi_execute_command_wrapper (
    cmd=0xb049140 "-trace-frame-collected") at ../../gdb/mi/mi-interp.c:291
#5  0x081242ba in mi_interpreter_exec (data=0xa59cec8, 
    command=0xb049140 "-trace-frame-collected") at ../../gdb/mi/mi-interp.c:205
#6  0x081fe26f in interp_exec (interp=0xa440de0, 
    command_str=0xb049140 "-trace-frame-collected") at ../../gdb/interps.c:356
#7  0x081fe45e in interpreter_exec_cmd (
    args=0xa52b1a1 "mi \"-trace-frame-collected\"", from_tty=1)
    at ../../gdb/interps.c:430
#8  0x0811364f in do_cfunc (c=0xa42a9c0, 
    args=0xa52b1a1 "mi \"-trace-frame-collected\"", from_tty=1)
    at ../../gdb/cli/cli-decode.c:107
#9  0x08115e47 in cmd_func (cmd=0xa42a9c0, 
    args=0xa52b1a1 "mi \"-trace-frame-collected\"", from_tty=1)
    at ../../gdb/cli/cli-decode.c:1882
#10 0x082ec0b3 in execute_command (p=0xa52b1bb "\"", from_tty=1)
    at ../../gdb/top.c:468
#11 0x08206782 in command_handler (
    command=0xa52b190 "interpreter-exec mi \"-trace-frame-collected\"")
    at ../../gdb/event-top.c:435
#12 0x08206c9e in command_line_handler (
    rl=0xb043fc8 "\335//\b\305//\b55/\bZ//\b\253\065/\b\373\065/\b(0/\b\370S\377\ne-co\031") at ../../gdb/event-top.c:632
#13 0x08206df3 in gdb_readline2 (client_data=0x0) at ../../gdb/event-top.c:713
#14 0x082066ac in stdin_event_handler (error=0, client_data=0x0)
    at ../../gdb/event-top.c:375
#15 0x0820578a in handle_file_event (data=...) at ../../gdb/event-loop.c:768
#16 0x08204ece in process_event () at ../../gdb/event-loop.c:342
#17 0x08204f92 in gdb_do_one_event () at ../../gdb/event-loop.c:406
#18 0x08204fe4 in start_event_loop () at ../../gdb/event-loop.c:431
#19 0x08206384 in cli_command_loop (data=0x0) at ../../gdb/event-top.c:179
#20 0x081fe1cb in current_interp_command_loop () at ../../gdb/interps.c:327
#21 0x081feab6 in captured_command_loop (data=0x0) at ../../gdb/main.c:267
#22 0x081fc888 in catch_errors (func=0x81feaa1 <captured_command_loop>, 
    func_args=0x0, errstring=0x8604e9e "", mask=RETURN_MASK_ALL)
    at ../../gdb/exceptions.c:524
#23 0x081ffd3d in captured_main (data=0xff8b7690) at ../../gdb/main.c:1067
#24 0x081fc888 in catch_errors (func=0x81fed03 <captured_main>, 
    func_args=0xff8b7690, errstring=0x8604e9e "", mask=RETURN_MASK_ALL)
    at ../../gdb/exceptions.c:524
#25 0x081ffd73 in gdb_main (args=0xff8b7690) at ../../gdb/main.c:1076
#26 0x080a0d53 in main (argc=6, argv=0xff8b7754) at ../../gdb/gdb.c:34
(gdb)
Comment 3 David Taylor 2014-07-15 20:29:17 UTC
In mi_cmd_trace_frame_collected we find the line:

  tinfo = get_traceframe_info ();

Now, get_traceframe_info can legitimately return NULL.

And, since this is a remote target to a stub that does not
support the qXfer:traceframe-info:read message, it DOES
return NULL.

Later in the function we find the line:

	for (i = 0; VEC_iterate (int, tinfo->tvars, i, tvar); i++)

There is no guard to check that tinfo is non NULL, so this produces the
core dump.