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] btrace: avoid tp != NULL assertion

On 03/03/2015 02:44 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Pedro Alves []
>> Sent: Tuesday, March 3, 2015 3:03 PM
>> To: Metzger, Markus T
>> Cc:
>> Subject: Re: [PATCH] btrace: avoid tp != NULL assertion
>>>>> No, that wasn't the reason for replacing the assert.  There are no such
>>>>> errors in the gdb.btrace suite (which is mostly single-threaded) with my
>>>>> patch and I have not seen any such errors otherwise, either.
>>>> Then it sounds like we're either lacking basic tests, or the threaded tests
>>>> are somehow not running correctly when gdb is a 32-bit program.  I think
>>>> that if you step any non-leader thread, you should see it happen.
>>>> Grepping the tests, I think gdb.btrace/multi-thread-step.exp should have
>>>> caught it.  My machine doesn't do btrace, so I can't try it myself...
>>>> BTW, did any existing test in the testsuite catch the assertion we're
>>>> fixing?
>>> Almost all of them when run on 32-bit systems; -m32 on 64-bit systems
>> does
>>> not catch this.
>> Right, that's why I said "when gdb is a 32-bit program".  Sounds like
>> no existing test tries a "step" when not replaying then.  It'd be very
>> nice to have one.  Can I convince you to add one?  :-)
> The multi-thread-step.exp test does not catch it because it uses "cont",
> which works fine.  When I add a "step" before the "cont", I get the
> "No thread" error when using my old patch instead of your new patch.
> Or I get the assert when using neither my old nor your new patch.
> But then, I got the assert already on other tests.
> With my patch dropped and your patch committed, what is the new
> test expected to catch?

You're getting me confused...

The test was expected to catch the assertion, given that apparently
no other test was catching it -- from the dialog above, one understands
no test would be catching this before (that's what I explicitly
asked), but now you're saying the opposite.

If indeed there are already tests that triggered the
error/internal-error before the fix, then I agree a new
test is not necessary.

Pedro Alves

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