Re: [PATCH master+7.12 v2 3/3] Add test for user context selection sync

[Pedro Alves <palves at redhat dot com>]

On 09/16/2016 03:01 AM, Simon Marchi wrote:
> On 2016-09-14 15:31, Pedro Alves wrote:
>> Hi Simon,
>>
>> I didn't try to understand everything in detail, but overall
>> it looks very nice now.  Thank you very much.  A few comments below.
> 
> Oops, while trying to rerun the full testsuite, I noticed that it leaves
> "-ex \"set non-stop 1\"" in the GDBFLAGS... that's not good.  You can
> see it easily if you swap the order of the "all-stop" and "non-stop"
> variations.  Can you spot why the save_vars isn't working as intended? 
> When I use a temporary variable instead, it works as intended...

Did you ever figure this out?

>> Did you try using barriers and breakpoints?  Several tests use that
>> to make sure threads are past a point.
> 
> I tried, but the issue is that depending on the scheduling, the threads
> might still be in the pthread_barrier_wait function when you stop.
> 
> Consider this pseudo-code:
> 
> thread_function:
>   barrier_wait
>   infinite_loop # This is where I want the threads to be stopped.
> 
> main_thread ():
>   initialize_barrier with n = 3
>   spawn_thread (thread_function)
>   spawn_thread (thread_function)
>   barrier_wait
>   breakpoint
> 
> Once the main thread hits the breakpoint, we have the assurance that the
> threads have started, but we don't know where they are.  They might not
> have exited the barrier_wait function, or they might be in the infinite
> loop.  Adding a sleep before the breakpoint in the main thread is the
> only way to be reasonnably sure (assuming 1 second is enough...) that
> both threads will have reached the infinite loop.
> 
> Actually, it might work by putting thread-specific breakpoints on the
> single-line infinite loop, then doing two "continue".  This way I think
> we would be guaranteed that the two threads stop exactly at that line. 
> With a regular breakpoint it might not work, since a thread could hit
> the breakpoint twice while the other still hasn't reached it.

What I've done in the past is something very much like your breakpoints
idea.  Though, instead of a thread-specific breakpoint, I used a normal
breakpoint + "set scheduler-locking on" to control which thread got to
the breakpoint.  See multiple-step-overs.exp, for example.
Using a thread-specific breakpoint maybe makes that a little simpler,
worth a try.

>> Hmm, looks like this version of the test still runs forever.
> 
> I don't think so, the main thread sets the quit flag which unblocks the
> threads.  If you run the executable you'll see it exits in ~2 seconds.

Ah, OK.

>> gdb_test_multiple ?
> 
> Like this?
> 
>     set test "interrupt thread $inf.2"
> 
>     send_gdb "interrupt\n"
>     gdb_test_multiple "" $test {
>         -re "Thread.*2.*stopped" {
>             pass $test
>         }
>     }

No need for the separate send_gdb call:

     set test "interrupt thread $inf.2"
     gdb_test_multiple "interrupt" $test {
         -re "Thread.*2.*stopped" {
             pass $test
         }
     }


>>> +    with_spawn_id $gdb_main_spawn_id {
>>> +        # TODO: it doesn't work as of now.
>>> +        # match_re_or_ensure_not_output "$cli_re\r\n"
>>> "-thread-select, event on cli"
>>> +    }
>>
>> Is there a plan here?
> 
> I think that will go in the same basket as the fact that any MI command
> with --thread currently changes the selected thread silently (without
> any =thread-selected event).  Currently, --thread changes the thread tot
> he desired one, then when the mi_cmd_thread_select tries to change the
> thread, it thinks that it was already the current thread, so that an
> event isn't necessary.  This should get fixed in the next iteration,
> when we split the concepts of user-selected-ptid and
> internally-selected-ptid.  Specifying --thread won't mess with the
> user-selected-ptid, but if you do "-thread-select --thread 2 2", then
> mi_cmd_thread_select will change the user-selected-ptid, generating an
> event.
> 
> It's not pretty to leave it like this in the test though.  Should I
> create a bug right now and kfail it?  Leave it commented out but put a
> better description?

There's no right or wrong answer, but since you've already written the 
bits, I'd be inclined to file bug and kfail.

Thanks,
Pedro Alves