This is the mail archive of the gdb-patches@sourceware.org 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 v2] Fix failure to detach if threads exit while detaching on linux


Pedro Alves writes:

> On 06/03/2016 04:32 PM, Antoine Tremblay wrote:
>>>> >> +	#Don't try to exit gdbserver see above comment.
>>>> >> +	set gdbserver_reconnect_p 1
>>> >
>>> > I don't understand this one.  It shouldn't be needed.
>>> >
>> This one is needed since on the teardown of the .exp test gdb_exit is
>> called and calls monitor_exit which fails with a timeout this avoids
>> this and the original gdb_exit is called.
>
> Then that strikes me as the wrong thing to do.  We should instead
> expect that gdbserver exits cleanly, and then clear server_spawn_id.
>
> E.g.:
>
> proc test_server_exit {} {
>   global server_spawn_id
>   if ![info exists server_spawn_id] {
>     return
>   }
>   
>   set test "server exits"
>   gdb_expect {
>      -i $server_spawn_id
>      eof {
>         pass $test
> 	wait -i $server_spawn_id
>         unset server_spawn_id
>      }
>      timeout {
>        fail "$test (timeout)"
>      }
>    }
>   }
> }
>
> and then:
>
>     -re "Detaching from .*, process $decimal\r\nEnding remote debugging\.\r\n$gdb_prompt $" {
>         # This is what you get with "target remote".
>         pass $test
>         # If testing with gdbserver, make sure it manages to exit.
>         test_server_exit
>     }
>

Thanks does seems much better !

However, testing it it triggers the test_server_exit timeout case, I'm
guessing because eof already happened and we're waiting for nothing ?

I'm tempted just to unset the var... but ideas are welcome..

Regards,
Antoine


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