Re: MI failures related to string printing

Re: MI failures related to string printing

[Vladimir Prus]

Nick Roberts wrote:

>  > I think the whole idea of doing string comparisons for C (or C++)
>  > "char *" pointers is flawed.  There is no guarantee that a "char *"
>  > actually points to a null-terminated as the test shows.  You should
>  > not treat "char *" any different from other pointers like "int *", at
>  > least not by default.  You could implement a way for the user to
>  > specify that a "char *" is actually a pointer to a string instead of a
>  > single character.  But otherwise I think the string comparison should
>  > only do for languages that have a genuine string type, such as Pascal.
> 
> It's unfortunate you didn't express this opinion earlier.  There are no
> gauarantees but generally if you are watching a "char *" type it points to
> something useful, or you learn something if it doesn't.  Without string
> comparison you can't `watch' the contents of a string change.  I think
> it's better to focus on such practical issues than pathological cases in
> the testsuite.

Is there any chance you'll robustify the testsuite?

Thanks,
Volodya
 

Re: MI failures related to string printing

[Nick Roberts]

 > Is there any chance you'll robustify the testsuite?

If your just talking about the one FAIL in mi-var-child.exp, why not just mark
it as an XFAIL?  I see that the other XFAIL actually passes (for me, at least).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI failures related to string printing

[Vladimir Prus]

On Tuesday 16 January 2007 08:50, Nick Roberts wrote:
>  > Is there any chance you'll robustify the testsuite?
> 
> If your just talking about the one FAIL in mi-var-child.exp, why not just mark
> it as an XFAIL?  I see that the other XFAIL actually passes (for me, at least).

Why should it be an XFAIL? The test was working fine before your change,
and I see no reason why the test cannot be modified to always pass. 

- Volodya

Re: MI failures related to string printing

[Nick Roberts]

 > > If your just talking about the one FAIL in mi-var-child.exp, why not just
 > > mark it as an XFAIL?  I see that the other XFAIL actually passes (for me,
 > > at least).

I mean when "FIXME" is removed from the output string.

 > Why should it be an XFAIL? The test was working fine before your change,
 > and I see no reason why the test cannot be modified to always pass. 

The aim of the testsuite is to test GDB and not just get 100% pass rate (except
when we're on performance related pay!).  The test presumably has value on
systems where it passes.  I'm sure it can be modified to always pass but that's
only worthwhile if it remains a meaningful test.  I don't know how to devise
such a test because it doesn't fail for me now.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI failures related to string printing

[Vladimir Prus]

Nick Roberts wrote:

>  > > If your just talking about the one FAIL in mi-var-child.exp, why not
>  > > just
>  > > mark it as an XFAIL?  I see that the other XFAIL actually passes (for
>  > > me, at least).
> 
> I mean when "FIXME" is removed from the output string.
> 
>  > Why should it be an XFAIL? The test was working fine before your
>  > change, and I see no reason why the test cannot be modified to always
>  > pass.
> 
> The aim of the testsuite is to test GDB and not just get 100% pass rate
> (except
> when we're on performance related pay!).  The test presumably has value on
> systems where it passes.  

Don't you think that a test that randomly fails depending on compiler version
and the address at which the binary happens to load is completely useless.
If I see it fail, how do I know if it signifies a bug in my (new) code, or not?

> I'm sure it can be modified to always pass but 
> that's
> only worthwhile if it remains a meaningful test.  I don't know how to
> devise such a test because it doesn't fail for me now.

You just need to make sure the testcase never uses char* values that point
to a single char, by making all single-char value char arrays of size 2
where the second element is zero, or by any other approach.

- Volodya

 

Re: MI failures related to string printing

[Nick Roberts]

 > Don't you think that a test that randomly fails depending on compiler
 > version and the address at which the binary happens to load is completely
 > useless.  

It has value because it doesn't fail for everyone.

 >           If I see it fail, how do I know if it signifies a bug in my (new)
 > code, or not?

By keeping the previous results and comparing them.  I always get many fails
when I run the testsuite.

 > > I'm sure it can be modified to always pass but that's only worthwhile if
 > > it remains a meaningful test.  I don't know how to devise such a test
 > > because it doesn't fail for me now.
 > 
 > You just need to make sure the testcase never uses char* values that point
 > to a single char, by making all single-char value char arrays of size 2
 > where the second element is zero, or by any other approach.

I'm not sure that this would work and anyway I couldn't test it, but you could.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI failures related to string printing

[Daniel Jacobowitz]

On Wed, Jan 17, 2007 at 01:59:23PM +1300, Nick Roberts wrote:
>  > Don't you think that a test that randomly fails depending on compiler
>  > version and the address at which the binary happens to load is completely
>  > useless.  
> 
> It has value because it doesn't fail for everyone.

Sorry, Vladimir is correct.  A test which fails intermittently (and
even if it's consistent for some people that doesn't change the fact
that this is a fundamentally intermittent problem) is not a good test.

> By keeping the previous results and comparing them.  I always get many fails
> when I run the testsuite.

I am working on eliminating every single one of those failures; please

do not add more.
-- 
Daniel Jacobowitz
CodeSourcery

Re: MI failures related to string printing

[Nick Roberts]

 > >  > Don't you think that a test that randomly fails depending on compiler
 > >  > version and the address at which the binary happens to load is
 > >  > completely useless.
 > > 
 > > It has value because it doesn't fail for everyone.
 > 
 > Sorry, Vladimir is correct.  A test which fails intermittently (and
 > even if it's consistent for some people that doesn't change the fact
 > that this is a fundamentally intermittent problem) is not a good test.

I'm not saying it is a good test, just that it's not completely useless.  If
someone who can see the fail fixes it, then clearly that's an improvement.

 > > By keeping the previous results and comparing them.  I always get many
 > > fails when I run the testsuite.
 > 
 > I am working on eliminating every single one of those failures; please
 > do not add more.

I've just eliminated six fails in mi-basics.exp and mi2-basics.exp that had
been around for years.  No-one seemed that worried about them.  I think we need
a balanced approach in these matters.  I certainly won't knowingly add any new
failures.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI failures related to string printing

[Mark Kettenis]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 16 Jan 2007 18:50:29 +1300
> 
>  > Is there any chance you'll robustify the testsuite?
> 

> If your just talking about the one FAIL in mi-var-child.exp, why not
> just mark it as an XFAIL?  I see that the other XFAIL actually
> passes (for me, at least).

The very fact that we're even having this discussion means that you
did something wrong Nick; you either didn't check for regressions or
ignored them.

Turning a regression test from a PASS into a FAIL, means you've
changed behaviour.  Now that change could be intentional, but then you
should have said so when you submitted the patch, and you should have
adjusted the test.

I'm still not convinced the change is ok.  Having 'char *' point to a
buffer that's not null-terminated is not uncommon.  We have a lot of
those in gdb itself.

Mark

Re: MI failures related to string printing

[Nick Roberts]

 > > If your just talking about the one FAIL in mi-var-child.exp, why not
 > > just mark it as an XFAIL?  I see that the other XFAIL actually
 > > passes (for me, at least).
 > 
 > The very fact that we're even having this discussion means that you
 > did something wrong Nick; you either didn't check for regressions or
 > ignored them.

Neither, it doesn't fail for me.  Presumably this has something to do with
the compiler/OS and where the variable values are stored.

 > Turning a regression test from a PASS into a FAIL, means you've
 > changed behaviour.  Now that change could be intentional, but then you
 > should have said so when you submitted the patch, and you should have
 > adjusted the test.

The nature of the patch was discussed at length and if there was no change in
behaviour then the patch would be pointless.  If the test had failed for me, I
would have tried to adjust it.  When is it appropriate to use an XFAIL, if
not here?

 > I'm still not convinced the change is ok.  Having 'char *' point to a
 > buffer that's not null-terminated is not uncommon.  We have a lot of
 > those in gdb itself.

There's still time to revert it but I think we should identify a real situation
i.e when GDB is used with a frontend, where it causes a problem first.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI failures related to string printing

[Daniel Jacobowitz]

On Wed, Jan 17, 2007 at 10:45:47AM +1300, Nick Roberts wrote:
> would have tried to adjust it.  When is it appropriate to use an XFAIL, if
> not here?

XFAIL are expected failures due to limitations of the environment.
Something which broke because your OS kernel version doesn't support
it, or because no version of GCC emits good information, is a
legitimate XFAIL.

>  > I'm still not convinced the change is ok.  Having 'char *' point to a
>  > buffer that's not null-terminated is not uncommon.  We have a lot of
>  > those in gdb itself.

Hi Mark,

We already use the equivalent of "print" to pass the value to the front
end when it asks for the variable's value.  What Nick's change did was
to use the same code when it asks if the variable's "value" has
changed.  I think it's an improvement on that basis alone.

If we wanted printing a char * which doesn't point to a string to stop
after one character, we'd need some way to identify strings, which
C doesn't really give us.  As long as it's convenient for "print"
to dump out the string, I suspect MI ought to too.  Just my opinion,
though - and I hope to be doing some more talking about data
representations this year...

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI failures related to string printing

[Mark Kettenis]

> Date: Wed, 17 Jan 2007 01:05:52 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, ghost@cs.msu.su,
>         gdb-patches@sources.redhat.com
> Mail-Followup-To: Nick Roberts <nickrob@snap.net.nz>,
> 	Mark Kettenis <mark.kettenis@xs4all.nl>, ghost@cs.msu.su,
> 	gdb-patches@sources.redhat.com
> Content-Disposition: inline
> X-XS4ALL-DNSBL-Checked: mxdrop9.xs4all.nl checked 66.93.172.17 against DNS blacklists
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: 0.0 () DK_POLICY_SIGNSOME
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis@xs4all.nl
> X-UIDL: 1169013955._smtp.mxdrop9.92459,S=2839
> 
> On Wed, Jan 17, 2007 at 10:45:47AM +1300, Nick Roberts wrote:
> > would have tried to adjust it.  When is it appropriate to use an XFAIL, if
> > not here?
> 
> XFAIL are expected failures due to limitations of the environment.
> Something which broke because your OS kernel version doesn't support
> it, or because no version of GCC emits good information, is a
> legitimate XFAIL.
> 
> >  > I'm still not convinced the change is ok.  Having 'char *' point to a
> >  > buffer that's not null-terminated is not uncommon.  We have a lot of
> >  > those in gdb itself.
> 
> Hi Mark,
> 
> We already use the equivalent of "print" to pass the value to the front
> end when it asks for the variable's value.  What Nick's change did was
> to use the same code when it asks if the variable's "value" has
> changed.  I think it's an improvement on that basis alone.
> 
> If we wanted printing a char * which doesn't point to a string to stop
> after one character, we'd need some way to identify strings, which
> C doesn't really give us.  As long as it's convenient for "print"
> to dump out the string, I suspect MI ought to too.

Agreed, at least if you explicitly ask for it.  However, the testsuite
does something like "-var-update *", which does not seem very explicit
to me.  Or am I missing something.

Mark

Re: MI failures related to string printing

[Daniel Jacobowitz]

On Wed, Jan 17, 2007 at 10:44:13PM +0100, Mark Kettenis wrote:
> > We already use the equivalent of "print" to pass the value to the front
> > end when it asks for the variable's value.  What Nick's change did was
> > to use the same code when it asks if the variable's "value" has
> > changed.  I think it's an improvement on that basis alone.
> > 
> > If we wanted printing a char * which doesn't point to a string to stop
> > after one character, we'd need some way to identify strings, which
> > C doesn't really give us.  As long as it's convenient for "print"
> > to dump out the string, I suspect MI ought to too.
> 
> Agreed, at least if you explicitly ask for it.  However, the testsuite
> does something like "-var-update *", which does not seem very explicit
> to me.  Or am I missing something.

It's already asked for a varobj for that particular variable, of type
"char *" - I think the closest analogy is "info locals" here, which
would show the same output.

-- 
Daniel Jacobowitz
CodeSourcery