Re: [PATCH] Fix tracepoint tstart again get gdb_assert

[Hui Zhu <teawater at gmail dot com>]

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


Thanks,
Hui

On Thu, Dec 8, 2011 at 07:50, Stan Shebs <stanshebs@earthlink.net> wrote:
> On 12/6/11 8:08 PM, Yao Qi wrote:
>>
>> On 12/06/2011 11:56 PM, Hui Zhu wrote:
>>>
>>> Hi,
>>>
>>> I use a gdb tstart again in a section an got:
>>>
>>> (gdb) tstart
>>> (gdb) tstop
>>> (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)
>>>
>> Thanks for this patch! ?It is related to my previous commit
>>
>> ? [patch 4/8] Download tracepoint locations and track its status
>> ? http://sourceware.org/ml/gdb-patches/2011-11/msg00337.html
>>
>>> The reason is:
>>> start_tracing:
>>> ? ? ? for (loc = b->loc; loc; loc = loc->next)
>>> ? ? ? ?{
>>> ? ? ? ? ?/* Since tracepoint locations are never duplicated, `inserted'
>>> ? ? ? ? ? ? flag should be zero. ?*/
>>> ? ? ? ? ?gdb_assert (!loc->inserted);
>>>
>>> ? ? ? ? ?target_download_tracepoint (loc);
>>>
>>> ? ? ? ? ?loc->inserted = 1;
>>> ? ? ? ?}
>>>
>>> But in stop_tracing and trace_status_command don't have code to set
>>> inserted back to 0.
>>>
>> Right, I agree that loc->inserted should be cleared on stop_tracing.
>> However, I don't know why we have to clear loc->inserted in
>> trace_status_command. ?A few comments below.
>>
>>
>
> I agree, stop_tracing should clear loc->inserted, and tstatus should not; in
> general an information-reading/displaying command should not be making state
> changes. ?If the assert triggers without the tstatus patch, then we should
> understand how and why. ?(We might be missing a reconnection case or some
> such?)
>
> Also, I notice that while the testsuite has lots of tstart/tstop sequences,
> it normally starts a fresh GDB each time, so it was unable to catch this
> failure. ?The patch to fix should add a sequence of a couple trace runs in a
> row to one of the existing test files.
>
> Stan
>
>
>