[Bug gdb/14971] New: Failures in gdb.base/longjmp.exp

[Bug gdb/14971] New: Failures in gdb.base/longjmp.exp

[dblaikie at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

             Bug #: 14971
           Summary: Failures in gdb.base/longjmp.exp
           Product: gdb
           Version: HEAD
            Status: NEW
          Keywords: testsuite
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: dblaikie@gmail.com
    Classification: Unclassified
              Host: Ubuntu (Lucid)
            Target: x86_64


Long jump testing seems to be incorrect - possibly due to both test and product
bugs. In ToT (using git) and 7.5 using both Clang (ToT) and GCC (4.7 & 4.4).
The failures I'm seeing are:

FAIL: gdb.base/longjmp.exp: next over longjmp(1)
FAIL: gdb.base/longjmp.exp: next over call_longjmp (2)

In the first case, when 'next'ing over a longjmp call, gdb stops on the first
line of the else block (from an "if (setjmp(...) == 0)") when the test was
expecting to jump to the line that calls & tests setjmp.

In the second case, when 'next'ing over a call to a function that longjmps
across function boundaries, gdb stops at the next breakpoint, not at the next
statement of or after the setjmp call.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> 2013-01-03 11:26:47 UTC ---
Lucid is 10.04, right?

This is due to glibc's jmpbuf pointer mangling.

Recent glibc's have sdt probes in setjmp/longjmp which gdb makes use of to
reliably step over a longjmp.  10.04 is too old to have them.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[dblaikie at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #2 from David Blaikie <dblaikie at gmail dot com> 2013-01-03 19:37:29 UTC ---
That's correct, I'm running Ubuntu 10.04, glibc 2.10-1 if I'm using my package
manager correctly.

Is there any way we could modify the test to correctly detect the minimum glibc
version required for this test & otherwise have it log 'untested'? (if it's not
simply/easy, I'll just leave my current local workaround in place or upgrade my
test machines - might be worth adding a comment to the test and/or the failures
to explain that it might be necessary to upgrade libc to get this feature)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #3 from Pedro Alves <palves at redhat dot com> 2013-01-16 18:45:28 UTC ---
Off hand, I'm not thinking of a way to do that.  Any ideas?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #4 from Tom Tromey <tromey at redhat dot com> 2013-01-17 04:48:15 UTC ---
The test could look for the probes with "info probes"
after the program has started.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #5 from Tom Tromey <tromey at redhat dot com> 2013-01-17 17:27:49 UTC ---
(In reply to comment #4)
> The test could look for the probes with "info probes"
> after the program has started.

It occurs to me now that this isn't totally reliable.
I think the longjmp tests are expected to work ok on some platforms
that don't do pointer mangling.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #6 from Pedro Alves <palves at redhat dot com> 2013-01-17 17:45:31 UTC ---
Yeah, other platforms that have a gdbarch_get_longjmp_target hook should pass
this test.  Only a few archs do pointer mangling (well, I only know of x86). 
Even x86 glibc before pointer mangling was added should pass.  I wrote the
original test such a glibc in 2008, w/ the Ubuntu that was current at the time,
and it passed then.  We probably don't care much about those anymore though.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #7 from Tom Tromey <tromey at redhat dot com> 2013-01-17 17:59:00 UTC ---
I think most glibc ports mangle, but what is unusual
about x86 is that LD_POINTER_GUARD=0 doesn't work:
http://sourceware.org/bugzilla/show_bug.cgi?id=9832

I tend to think it isn't too bad to live with a spurious
FAIL or two.  This is pretty much the normal state for
the gdb test suite anyway.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #8 from Pedro Alves <palves at redhat dot com> 2013-01-17 18:08:03 UTC ---
Ah, yeah.  I knew ARM didn't support it, and wrongly inferred from that
other didn't either.  I now see that ARM, MIPS, m68k and hppa in don't
do mangling, with things like:

/* Pointer mangling is not yet supported for ARM.  */
#define PTR_MANGLE(var) (void) (var)
#define PTR_DEMANGLE(var) (void) (var)

> I tend to think it isn't too bad to live with a spurious
> FAIL or two.  This is pretty much the normal state for
> the gdb test suite anyway.

Yeah...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[dblaikie at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #9 from David Blaikie <dblaikie at gmail dot com> 2013-01-17 19:05:20 UTC ---
> I tend to think it isn't too bad to live with a spurious
> FAIL or two.  This is pretty much the normal state for
> the gdb test suite anyway.

Some backstory:

I'm currently running a modified version of the GDB 7.5 suite against Clang in
a buildbot. Apart from two flakey tests (tls.exp and funcargs.exp) I seem to
have it pretty much stable. Failures are generally actionable & appropriately
blamed, etc.

I'm now trying to upstream the appropriate changes (things like the patches
I've already sent to gdb and gcc) and get to the point where I can run a
buildbot using GDB ToT and Clang ToT. I'll only be able to do this if I can get
stable red/green results - a few spurious failures are going to block that
effort. So, one way or another, I will be trying to find a way to resolve these
failures. While upgrading glibc on my build slaves may be one solution, I was
hoping for a solution that would scale better to other machines/users (so that
developers of GDB or Clang attempting to reproduce failures or just running the
suite on a new change to avoid committing regressions wouldn't see spurious
extra failures that could lead them down the wrong path)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #10 from Tom Tromey <tromey at redhat dot com> 2013-01-17 19:17:18 UTC ---
(In reply to comment #9)

> I'm now trying to upstream the appropriate changes (things like the patches
> I've already sent to gdb and gcc) and get to the point where I can run a
> buildbot using GDB ToT and Clang ToT. I'll only be able to do this if I can get
> stable red/green results - a few spurious failures are going to block that
> effort. So, one way or another, I will be trying to find a way to resolve these
> failures. While upgrading glibc on my build slaves may be one solution, I was
> hoping for a solution that would scale better to other machines/users (so that
> developers of GDB or Clang attempting to reproduce failures or just running the
> suite on a new change to avoid committing regressions wouldn't see spurious
> extra failures that could lead them down the wrong path)

I think you need to establish a baseline of failing tests and go from there.
Some tests are racy.  On my machine I see a handful of tests that always
fail (many not applicable in the clang case: ada, fortran, ...).
I believe Jan disables some tests on his own tester due to flakiness.


For this particular test maybe you can find a way to see whether the
test is run against glibc without probes and kfail it there.
It seems tricky though.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[macro@linux-mips.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14971

Maciej W. Rozycki <macro@linux-mips.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64                      |x86_64-linux-gnu,
                   |                            |i686-linux-gnu,
                   |                            |mips-linux-gnu,
                   |                            |powerpc-linux-gnu
                 CC|                            |macro@linux-mips.org

--- Comment #11 from Maciej W. Rozycki <macro@linux-mips.org> ---
I can also see these failures with i686-linux-gnu, mips-linux-gnu and
powerpc-linux-gnu targets, as follows.  The version of glibc used is
2.18, and GCC is 4.8.1 in all the cases.

-------------------------------------------------------------------------
i686 log:

(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0xd840b016

0xb7e55bd1 in __libc_siglongjmp (env=0x8049ae0 <env>, val=1) at longjmp.c:28
28        longjmps++;
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)

and:

(gdb) PASS: gdb.base/longjmp.exp: next over setjmp (2)
next
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0xd8402416

0xb7e55bd1 in __libc_siglongjmp (env=0x8049ae0 <env>, val=1) at longjmp.c:28
28        longjmps++;
(gdb) FAIL: gdb.base/longjmp.exp: next over call_longjmp (2)

and:

(gdb) PASS: gdb.base/longjmp.exp: continue to breakpoint at pattern 3 start
next
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0xd8432c16

0xb7e55bd1 in __libc_siglongjmp (env=0x8049ae0 <env>, val=1) at longjmp.c:28
28        longjmps++;
(gdb) FAIL: gdb.base/longjmp.exp: next over patt3

-------------------------------------------------------------------------
MIPS log, n32 only (o32 and n64 ABIs work all right):

(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x0

0x77db3c64 in __libc_siglongjmp (env=0x10010c50 <env>, val=1) at longjmp.c:28
28        longjmps++;
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)

and:

(gdb) PASS: gdb.base/longjmp.exp: next over setjmp (2)
next
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x0

0x77db3c64 in __libc_siglongjmp (env=0x10010c50 <env>, val=1) at longjmp.c:28
28        longjmps++;
(gdb) FAIL: gdb.base/longjmp.exp: next over call_longjmp (2)

and:

(gdb) PASS: gdb.base/longjmp.exp: continue to breakpoint at pattern 3 start
next
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x0

0x77db3c64 in __libc_siglongjmp (env=0x10010c50 <env>, val=1) at longjmp.c:28
28        longjmps++;
(gdb) FAIL: gdb.base/longjmp.exp: next over patt3

-------------------------------------------------------------------------
PowerPC log:

(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next
57            resumes++;
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)

and:

(gdb) PASS: gdb.base/longjmp.exp: next over setjmp (2)
next

Breakpoint 5, main () at .../gdb/testsuite/gdb.base/longjmp.c:73
73        i = 2; /* miss_step_2 */
(gdb) FAIL: gdb.base/longjmp.exp: next over call_longjmp (2)

-------------------------------------------------------------------------
x86-64 log (for a reference):

(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next
56            resumes++;
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)

and:

(gdb) PASS: gdb.base/longjmp.exp: next over setjmp (2)
next

Breakpoint 5, main () at .../gdb/testsuite/gdb.base/longjmp.c:72
72        i = 2; /* miss_step_2 */
(gdb) FAIL: gdb.base/longjmp.exp: next over call_longjmp (2)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #12 from Pedro Alves <palves at redhat dot com> ---
> I can also see these failures with i686-linux-gnu, mips-linux-gnu and
> powerpc-linux-gnu targets, as follows.  The version of glibc used is
> 2.18, and GCC is 4.8.1 in all the cases.

Was that glibc configured with --enable-systemtap ?  See:

 https://sourceware.org/gdb/wiki/DistroAdvice

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14971] Failures in gdb.base/longjmp.exp

[tromey at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14971

--- Comment #13 from Tom Tromey <tromey at redhat dot com> ---
(In reply to Pedro Alves from comment #12)
> > I can also see these failures with i686-linux-gnu, mips-linux-gnu and
> > powerpc-linux-gnu targets, as follows.  The version of glibc used is
> > 2.18, and GCC is 4.8.1 in all the cases.
> 
> Was that glibc configured with --enable-systemtap ?  See:
> 
>  https://sourceware.org/gdb/wiki/DistroAdvice

Note that nobody has ported the gdb side of stap probes to MIPS.
You can get an idea of which ports work by grepping for "set_gdbarch_stap_".

-- 
You are receiving this mail because:
You are on the CC list for the bug.