Testsuite FAIL which isn't a FAIL in chng-syms.exp

Testsuite FAIL which isn't a FAIL in chng-syms.exp

[Corinna Vinschen]

Hi,

I'm looking for a good while into this testsuite FAIL.  What happens
is, that the testsuite generates a FAIL which is not correct.  The
expression in chng-syms.exp is this:

  gdb_run_cmd
  gdb_expect {
      -re "Error in re-setting .*No symbol .var1..*Program exited normally.*" {
	  pass "running with invalidated bpt condition after executable changes"
      }
      timeout {
	  fail "(timeout) running with invalidated bpt condition after executable changes"
      }

The output from the gdb.log file looks like this:

  `/build/sh-elf/gdb/testsuite/gdb.base/chng-syms' has changed; re-reading symbols.^M
  Error in re-setting breakpoint 1:^M
  No symbol "var1" in current context.^M
  Starting program: /build/sh-elf/gdb/testsuite/gdb.base/chng-syms ^M
  ^M
  Program exited normally.^M
  (gdb) FAIL: gdb.base/chng-syms.exp: (timeout) running with invalidated bpt condition after executable changes

Does anybody understand why that's failing?  The regular expression
looks right to me.  I tried to change it to get it working but everything
I tried failed, except for ".*Program exited normally.*" which is not
exactly helpful. :-(


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

Re: Testsuite FAIL which isn't a FAIL in chng-syms.exp

[Daniel Jacobowitz]

On Thu, Feb 26, 2004 at 05:15:43PM +0100, Corinna Vinschen wrote:
> Hi,
> 
> I'm looking for a good while into this testsuite FAIL.  What happens
> is, that the testsuite generates a FAIL which is not correct.  The
> expression in chng-syms.exp is this:
> 
>   gdb_run_cmd
>   gdb_expect {
>       -re "Error in re-setting .*No symbol .var1..*Program exited normally.*" {
> 	  pass "running with invalidated bpt condition after executable changes"
>       }
>       timeout {
> 	  fail "(timeout) running with invalidated bpt condition after executable changes"
>       }
> 
> The output from the gdb.log file looks like this:
> 
>   `/build/sh-elf/gdb/testsuite/gdb.base/chng-syms' has changed; re-reading symbols.^M
>   Error in re-setting breakpoint 1:^M
>   No symbol "var1" in current context.^M
>   Starting program: /build/sh-elf/gdb/testsuite/gdb.base/chng-syms ^M
>   ^M
>   Program exited normally.^M
>   (gdb) FAIL: gdb.base/chng-syms.exp: (timeout) running with invalidated bpt condition after executable changes
> 
> Does anybody understand why that's failing?  The regular expression
> looks right to me.  I tried to change it to get it working but everything
> I tried failed, except for ".*Program exited normally.*" which is not
> exactly helpful. :-(

Take a look at gdb_run_cmd:
    gdb_expect 60 {
        -re "The program .* has been started already.*y or n. $" {
            send_gdb "y\n"
            exp_continue
        }
        -re "Starting program: \[^\r\n\]*" {}
    }

It eats everything up to "Starting program" so the error has been
hidden.  I'm not sure quite why this passes for me... aha, yes I am:

`/opt/src/binutils/x86-as/gdb/testsuite/gdb.base/chng-syms' has changed; re-reading symbols.
Error in re-setting breakpoint 1:
No symbol "var1" in current context.
Starting program:
/opt/src/binutils/x86-as/gdb/testsuite/gdb.base/chng-syms 
Error in re-setting breakpoint 1:
No symbol "var1" in current context.
Error in re-setting breakpoint 1:
No symbol "var1" in current context.
Error in re-setting breakpoint 1:
No symbol "var1" in current context.

The other copies of the message come at the shared library breakpoint
when we try to reset shlib_disabled breakpoints.  You're probably
running an embedded target that doesn't have a shared library event
breakpoint.

Not sure what the best fix is.  Might work as a hack to add -notransfer
to gdb_run_cmd:

        -notransfer -re "Starting program: \[^\r\n\]*" {}

That will leave the "Starting program" in the buffer, and anything else
transfered for that match.  I'm not sure if this will break any other
tests.

As an aside, in the original test:

>       -re "Error in re-setting .*No symbol .var1..*Program exited normally.*" {

is not a safe pattern; never suffix a pattern with .*.  The end should
always be anchored, usually to "$gdb_prompt $".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Testsuite FAIL which isn't a FAIL in chng-syms.exp

[Corinna Vinschen]

Hi Daniel,

On Feb 26 11:32, Daniel Jacobowitz wrote:
> Take a look at gdb_run_cmd:
>     gdb_expect 60 {
>         -re "The program .* has been started already.*y or n. $" {
>             send_gdb "y\n"
>             exp_continue
>         }
>         -re "Starting program: \[^\r\n\]*" {}
>     }
> 
> It eats everything up to "Starting program" so the error has been
> hidden.  I'm not sure quite why this passes for me... aha, yes I am:
> 
> `/opt/src/binutils/x86-as/gdb/testsuite/gdb.base/chng-syms' has changed; re-reading symbols.
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
> Starting program:
> /opt/src/binutils/x86-as/gdb/testsuite/gdb.base/chng-syms 
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
> Error in re-setting breakpoint 1:
> No symbol "var1" in current context.
> 
> The other copies of the message come at the shared library breakpoint
> when we try to reset shlib_disabled breakpoints.  You're probably
> running an embedded target that doesn't have a shared library event
> breakpoint.

Yes, that's right and...

> Not sure what the best fix is.  Might work as a hack to add -notransfer
> to gdb_run_cmd:
> 
>         -notransfer -re "Starting program: \[^\r\n\]*" {}

...this actually fixes it.

> That will leave the "Starting program" in the buffer, and anything else
> transfered for that match.  I'm not sure if this will break any other
> tests.

True, that looks a bit dangerous :-) 

> As an aside, in the original test:
> 
> >       -re "Error in re-setting .*No symbol .var1..*Program exited normally.*" {
> 
> is not a safe pattern; never suffix a pattern with .*.  The end should
> always be anchored, usually to "$gdb_prompt $".

Yes, I tried that as one of the first measurements against the FAIL but
it's clear now why that had no effect.

Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

Re: Testsuite FAIL which isn't a FAIL in chng-syms.exp

[Daniel Jacobowitz]

On Thu, Feb 26, 2004 at 06:07:04PM +0100, Corinna Vinschen wrote:
> > Not sure what the best fix is.  Might work as a hack to add -notransfer
> > to gdb_run_cmd:
> > 
> >         -notransfer -re "Starting program: \[^\r\n\]*" {}
> 
> ...this actually fixes it.
> 
> > That will leave the "Starting program" in the buffer, and anything else
> > transfered for that match.  I'm not sure if this will break any other
> > tests.
> 
> True, that looks a bit dangerous :-) 

Well, if it works for a native testsuite run (more of the tests run
that way), then I think it's a plausible change.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Testsuite FAIL which isn't a FAIL in chng-syms.exp

[Corinna Vinschen]

On Feb 26 14:08, Daniel Jacobowitz wrote:
> On Thu, Feb 26, 2004 at 06:07:04PM +0100, Corinna Vinschen wrote:
> > > Not sure what the best fix is.  Might work as a hack to add -notransfer
> > > to gdb_run_cmd:
> > > 
> > >         -notransfer -re "Starting program: \[^\r\n\]*" {}
> > 
> > ...this actually fixes it.
> > 
> Well, if it works for a native testsuite run (more of the tests run
> that way), then I think it's a plausible change.

I tested once more against Linux and sh-elf target and in the first
case I had no changes in the testsuite results, while in the second
case there's just this FAIL which disappears.

Are you going to submit this to gdb-patches?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.