This is the mail archive of the mailing list for the GDB 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]

Re: [PATCH] Fix tracepoint tstart again get gdb_assert

On 12/6/11 8:08 PM, Yao Qi wrote:
On 12/06/2011 11:56 PM, Hui Zhu wrote:

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

The reason is:
       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.


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