On 12/08/2011 11:40 AM, Hui Zhu wrote:
> Hi guys,
> 
> I am sorry that I didn't talk clear about the issue of tstatus.
> When we use tstatus, it can auto set the tracepoint back to stop when
> it full or got error.  Then user can use tstart without tstop that set
>  loc->inserted.  So we will still meet that issue if we just set
> loc->inserted in tstop.
> 
> For examp:
> This gdb is just set  loc->inserted in tstop but not tstatus.
> (gdb) tstart
> (gdb) tstop
> (gdb) tstart
> (gdb) tstop
> (gdb) tstart
> xxx
> xxx
> (gdb) tstatus
> Trace stopped because the buffer was full.
> Buffer contains 0 trace frames (of 49072 created total).
> Trace buffer has 908408 bytes of 10414080 bytes free (91% full).
> Trace will stop if GDB disconnects.
> Not looking at any trace frame.
> (gdb) tstart
> ../../src/gdb/tracepoint.c:1770: internal-error: start_tracing:
> Assertion `!loc->inserted' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) n
> 
> ../../src/gdb/tracepoint.c:1770: internal-error: start_tracing:
> Assertion `!loc->inserted' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) n

This internal-error is caused by two consequent `tstart' commands, and
`inserted' flag is not cleared before calling start_tracing for the 2nd
`tstart' command.

My patch (on base of Hui's version) fixes this problem by 1) clearing
`inserted' flag at stop_tracing, and 2) calling stop_tracing in
start_tracing when existing tracing is still running.

There is no existing test case fit for this test, so I create a new test
case gdb.trace/tstart.exp.

Patch is tested on x86_64-linux, OK for mainline and 7.4 branch?

-- 
Yao (齐尧)