Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 1/4] New test for removing socket file in gdb.trace/strace.exp.
Date: Fri, 15 Jun 2012 19:00:00 -0000	[thread overview]
Message-ID: <4FDB862E.60404@redhat.com> (raw)
In-Reply-To: <201206142239.28343.yao@codesourcery.com>

On 06/14/2012 03:39 PM, Yao Qi wrote:

> On Tuesday 12 June 2012 22:50:49 Pedro Alves wrote:
>>> +    set test "socket file exists"
>>> +    set socket_file "/tmp/gdb_ust${pid}"
>>> +    if { [file exists $socket_file] } {
>>> +     pass $test
>>> +    } else {
>>> +     fail $test
>>> +    }
>>
>> This won't work with remote host testing.  This file is really a
>> file on the target.  Why not use "remote_file target exists" ?
>>
> 
> Yes, we should use "remote_file XXX exits", however, I find "remote_file XXX
>  exists" always return 0 for socket file because it uses "[ -f $file ]" to check
>  whether file exists.  I work around this limitation in this way,
> 


Bummer.  :-(

>     set exists ""
>     if [is_remote target] {
>        set status [remote_exec target "sh -c \"exit `\\\[ -S $socket_file `\""]
>        set exists [expr [lindex $status 0] == 0]
>     } else {
>        set exists [file exists $socket_file]
>     }
> 
> b.t.w, the quote on tcl and bash makes crazy :)


:-)

In general, there are plenty of targets where we can't assume
a posix shell on the target.  But in this case, since this functionality
is implemented on GNU/Linux, we can go with it.  I think -S is a
bash extension, but again, it may be okay in this case.  I tried ksh,
and dash, and both accept it.

I don't understand how the else branch works for you with remote host
native testing, as you're checking for a file on the build machine, not
the host (where GDB runs) (unless you're sharing /tmp between
build and host machines, but you're probably not.)

Is there anything preventing using "remote_exec target" bits always,
getting rid of the else branch?

> 
>>> +
>>> +    send_gdb "${action}\n"
>>> +    gdb_expect {
>>> +     -re "A debugging session is active.\r\n.*\r\nQuit anyway\\? \\(y or
>>> n\\) $" { +         send_gdb "y\n"
>>> +     }
>>> +     -re "Detaching .*, process .*$" {
>>> +     }
>>> +     -re "Continuing.*$" {
>>> +     }
>>> +    }
>>
>> gdb_test_multiple ?
> 
> When I tried gdb_test_multiple, I'll get an extra fail, so I use
>  send_gdb/gdb_expect,
> 
>   FAIL: gdb.trace/strace.exp: remove_socket_after_quit: quit (got interactive prompt)
> 
> This new test is tested on native on local host, native-gdbserver, and native
>  on remote host.  


> I saw some problems when running test on remote host.  They are

> not related to this patch series, so I'd like to defer them to follow up
> fix later.


Thanks, that mode tends to rot a bit.

> 
> gdb/testsuite:
> 
> 2012-06-14  Yao Qi  <yao@codesourcery.com>
> 
> 	PR gdb/14161.
> 	* gdb.trace/strace.exp (strace_remove_socket): New proc to test
> 	the socket file is removed.


The uses of the new function should be mentioned as well.

> +proc strace_remove_socket { action } {


> +    sleep 5


We have 3 calls to this function, adding up to 15 seconds.

We could do things a bit differently to try to avoid always
sleeping, or sleeping so much.  For instance, with something like this
pseudo code:

 detach
 $exists=true
 for i in 0..4 {
     if ! socket exists
        $exists=false
        break
     sleep 1
 }
 if $exists
   fail $test
 else
   pass $test

IOW, check if the socket exists or not immediately after detaching.  Only
sleep if we find it still exists.  With luck, expect will be slow enough, and
we'll find the socket is gone on the first iteration, avoiding the sleep.
If not, we'll wait one second, then re-check, etc.

-- 
Pedro Alves


  reply	other threads:[~2012-06-15 19:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-09 12:47 [PATCH 0/4] PR14161: a partial fix Yao Qi
2012-06-09 12:47 ` [PATCH 4/4] gdb: kfail for PR14161 Yao Qi
2012-06-12 16:21   ` Pedro Alves
2012-06-14 15:01     ` Yao Qi
2012-06-15 19:33       ` Pedro Alves
2012-06-20 13:55         ` Yao Qi
2012-06-09 12:47 ` [PATCH 3/4] New agent command 'kill' and used by gdbserver Yao Qi
2012-06-09 13:11   ` Eli Zaretskii
2012-06-12 16:14   ` Pedro Alves
2012-06-14 14:50     ` Yao Qi
2012-06-14 16:37       ` Eli Zaretskii
2012-06-15 19:25       ` Pedro Alves
2012-06-20 13:49         ` Yao Qi
2012-06-21 16:05           ` Pedro Alves
2012-06-09 12:47 ` [PATCH 2/4] Remove socket file at exit Yao Qi
2012-06-12 15:14   ` Pedro Alves
2012-06-14 14:44     ` Yao Qi
2012-06-15 19:02       ` Pedro Alves
2012-06-09 12:47 ` [PATCH 1/4] New test for removing socket file in gdb.trace/strace.exp Yao Qi
2012-06-12 14:51   ` Pedro Alves
2012-06-14 14:39     ` Yao Qi
2012-06-15 19:00       ` Pedro Alves [this message]
2012-06-20 13:46         ` Yao Qi
2012-06-21 15:56           ` Pedro Alves
2012-06-27  3:55             ` Yao Qi
2012-07-27  8:19 ` [committed] : [PATCH 0/4] PR14161: a partial fix Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDB862E.60404@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox