New test failures - observer.exp, sigaltstack.exp, siginfo.exp

New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Daniel Jacobowitz]

These new tests are all failing on my i686-pc-linux-gnu system.

sigaltstack.exp fails like this:

finish
Run till exit from #0  catcher (signal=26) at /opt/src/gdb/src/gdb/testsuite/gdb.base/sigaltstack.c:71
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0xffffe420: Input/output error.
(gdb) FAIL: gdb.base/sigaltstack.exp: finish from catch LEAF

The problem is that the signal trampoline is read-only.  We can't set
software breakpoints there.  I suspect there is no way to do this portably.
Should we skip it instead, i.e. finish right to the place where the signal
was raised?

siginfo.exp fails like this:
(gdb) PASS: gdb.base/siginfo.exp: continue to stepi handler
bt
#0  handler (sig=26, info=0xbfffeda0, context=0xbfffee20) at /opt/src/gdb/src/gdb/testsuite/gdb.base/siginfo.c:31
#1  <signal handler called>
#2  main () at /opt/src/gdb/src/gdb/testsuite/gdb.base/siginfo.c:66
(gdb) PASS: gdb.base/siginfo.exp: backtrace for nexti
step
32      } /* handler */
1: x/i $pc  0x8048411 <handler+13>:     pop    %ebp
(gdb) step

Program exited normally.
(gdb) FAIL: gdb.base/siginfo.exp: step out of handler

I don't know if this is currently expected, or what.  It seems like a
bug.

observer.exp fails like this:

call observer_notify_normal_stop ()
too few arguments in function call
(gdb) PASS: gdb.gdb/observer.exp: sending notification (one observer)

Then all the counters are wrong, since the function call didn't happen. 
That's definitely a problem in the test script, since observer_notify_normal_stop
takes an argument; is this not a fatal condition on some other target?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Daniel Jacobowitz]

On Fri, Apr 16, 2004 at 11:12:43AM -0400, Daniel Jacobowitz wrote:
> siginfo.exp fails like this:
> (gdb) PASS: gdb.base/siginfo.exp: continue to stepi handler
> bt
> #0  handler (sig=26, info=0xbfffeda0, context=0xbfffee20) at /opt/src/gdb/src/gdb/testsuite/gdb.base/siginfo.c:31
> #1  <signal handler called>
> #2  main () at /opt/src/gdb/src/gdb/testsuite/gdb.base/siginfo.c:66
> (gdb) PASS: gdb.base/siginfo.exp: backtrace for nexti
> step
> 32      } /* handler */
> 1: x/i $pc  0x8048411 <handler+13>:     pop    %ebp
> (gdb) step
> 
> Program exited normally.
> (gdb) FAIL: gdb.base/siginfo.exp: step out of handler
> 
> I don't know if this is currently expected, or what.  It seems like a
> bug.

Oh, easy: this is backtrace/1613.  I hadn't caught up on gdb-prs yet.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Joel Brobecker]

> observer.exp fails like this:
> 
> call observer_notify_normal_stop ()
> too few arguments in function call
> (gdb) PASS: gdb.gdb/observer.exp: sending notification (one observer)
> 
> Then all the counters are wrong, since the function call didn't happen. 
> That's definitely a problem in the test script, since observer_notify_normal_stop
> takes an argument; is this not a fatal condition on some other target?

I am working on this part. I will send a couple of patches soon.

-- 
Joel

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Andrew Cagney]

(assume I managed to get them to pass on at least one system :-)

> sigaltstack.exp fails like this:
> 
> finish
> Run till exit from #0  catcher (signal=26) at /opt/src/gdb/src/gdb/testsuite/gdb.base/sigaltstack.c:71
> Warning:
> Cannot insert breakpoint 0.
> Error accessing memory address 0xffffe420: Input/output error.
> (gdb) FAIL: gdb.base/sigaltstack.exp: finish from catch LEAF
> 
> The problem is that the signal trampoline is read-only.  We can't set
> software breakpoints there.  I suspect there is no way to do this portably.
> Should we skip it instead, i.e. finish right to the place where the signal
> was raised?

Kernel bug.  Two fixes:

- the kernel gets fixed to allow writes to this page -> it should be no 
different to other read-only text sections

- we modify GDB to, when it can't set a return breakpoint, single-step 
out of the problem

> siginfo.exp fails like this:
> (gdb) PASS: gdb.base/siginfo.exp: continue to stepi handler
> bt
> #0  handler (sig=26, info=0xbfffeda0, context=0xbfffee20) at /opt/src/gdb/src/gdb/testsuite/gdb.base/siginfo.c:31
> #1  <signal handler called>
> #2  main () at /opt/src/gdb/src/gdb/testsuite/gdb.base/siginfo.c:66
> (gdb) PASS: gdb.base/siginfo.exp: backtrace for nexti
> step
> 32      } /* handler */
> 1: x/i $pc  0x8048411 <handler+13>:     pop    %ebp
> (gdb) step
> 
> Program exited normally.
> (gdb) FAIL: gdb.base/siginfo.exp: step out of handler
> 
> I don't know if this is currently expected, or what.  It seems like a
> bug.

This worked on my test PPC system, I'll kfail it conditional on 
GNU/Linux i386.

> observer.exp fails like this:
> 
> call observer_notify_normal_stop ()
> too few arguments in function call
> (gdb) PASS: gdb.gdb/observer.exp: sending notification (one observer)
> 
> Then all the counters are wrong, since the function call didn't happen. 
> That's definitely a problem in the test script, since observer_notify_normal_stop
> takes an argument; is this not a fatal condition on some other target?

Unfortunatly my PPC observer tests were already failing, joel's fixed it :-(

Andrew

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Daniel Jacobowitz]

On Tue, Apr 20, 2004 at 12:33:17PM -0400, Andrew Cagney wrote:
> (assume I managed to get them to pass on at least one system :-)

Naturally - just not mine :)

> >sigaltstack.exp fails like this:
> >
> >finish
> >Run till exit from #0  catcher (signal=26) at 
> >/opt/src/gdb/src/gdb/testsuite/gdb.base/sigaltstack.c:71
> >Warning:
> >Cannot insert breakpoint 0.
> >Error accessing memory address 0xffffe420: Input/output error.
> >(gdb) FAIL: gdb.base/sigaltstack.exp: finish from catch LEAF
> >
> >The problem is that the signal trampoline is read-only.  We can't set
> >software breakpoints there.  I suspect there is no way to do this portably.
> >Should we skip it instead, i.e. finish right to the place where the signal
> >was raised?
> 
> Kernel bug.  Two fixes:
> 
> - the kernel gets fixed to allow writes to this page -> it should be no 
> different to other read-only text sections

Good luck - I don't think the kernel maintainers will buy it.

> - we modify GDB to, when it can't set a return breakpoint, single-step 
> out of the problem

I wonder if we can mark the particular solib as unwriteable and avoid
the failing writes... otherwise, at least handle the error silently.
I'll investigate someday; in the mean time do you mind if I KFAIL the
above output?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Andrew Cagney]

>>- the kernel gets fixed to allow writes to this page -> it should be no 
>>> different to other read-only text sections
> 
> 
> Good luck - I don't think the kernel maintainers will buy it.

Who needs luck?  I'm told the page is now marked COW (copy on write) in 
at least fedora core.

Andrew

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Daniel Jacobowitz]

On Mon, May 03, 2004 at 03:21:38PM -0400, Andrew Cagney wrote:
> >>- the kernel gets fixed to allow writes to this page -> it should be no 
> >>>different to other read-only text sections
> >
> >
> >Good luck - I don't think the kernel maintainers will buy it.
> 
> Who needs luck?  I'm told the page is now marked COW (copy on write) in 
> at least fedora core.

Could you point me at whoever implemented that for Fedora, so we can
see about getting the fix into normal Linux sources?  I'm not helped by
any GDB test failures fixed in distro-specific kernels.

-- 
Daniel Jacobowitz

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Daniel Jacobowitz]

On Tue, May 04, 2004 at 03:46:28PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 03, 2004 at 03:21:38PM -0400, Andrew Cagney wrote:
> > >>- the kernel gets fixed to allow writes to this page -> it should be no 
> > >>>different to other read-only text sections
> > >
> > >
> > >Good luck - I don't think the kernel maintainers will buy it.
> > 
> > Who needs luck?  I'm told the page is now marked COW (copy on write) in 
> > at least fedora core.
> 
> Could you point me at whoever implemented that for Fedora, so we can
> see about getting the fix into normal Linux sources?  I'm not helped by
> any GDB test failures fixed in distro-specific kernels.

Ping?  As of 2.6.8-rc2 this is still not the case in the standard Linux
kernel.

-- 
Daniel Jacobowitz

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

[Reply-to: set to fedora-devel-list@]

Hello,

Can anyone help Daniel here?

Andrew

[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 3612 bytes --]

From: Daniel Jacobowitz <drow@false.org>
To: Andrew Cagney <cagney@gnu.org>, gdb@sources.redhat.com
Subject: Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp
Date: Sun, 8 Aug 2004 17:41:39 -0400
Message-ID: <20040808214139.GA22430@nevyn.them.org>

On Tue, May 04, 2004 at 03:46:28PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 03, 2004 at 03:21:38PM -0400, Andrew Cagney wrote:
> > >>- the kernel gets fixed to allow writes to this page -> it should be no 
> > >>>different to other read-only text sections
> > >
> > >
> > >Good luck - I don't think the kernel maintainers will buy it.
> > 
> > Who needs luck?  I'm told the page is now marked COW (copy on write) in 
> > at least fedora core.
> 
> Could you point me at whoever implemented that for Fedora, so we can
> see about getting the fix into normal Linux sources?  I'm not helped by
> any GDB test failures fixed in distro-specific kernels.

Ping?  As of 2.6.8-rc2 this is still not the case in the standard Linux
kernel.

-- 
Daniel Jacobowitz

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Andrew Cagney]

> These new tests are all failing on my i686-pc-linux-gnu system.
> 
> sigaltstack.exp fails like this:
> 
> finish
> Run till exit from #0  catcher (signal=26) at /opt/src/gdb/src/gdb/testsuite/gdb.base/sigaltstack.c:71
> Warning:
> Cannot insert breakpoint 0.
> Error accessing memory address 0xffffe420: Input/output error.
> (gdb) FAIL: gdb.base/sigaltstack.exp: finish from catch LEAF
> 
> The problem is that the signal trampoline is read-only.  We can't set
> software breakpoints there.  I suspect there is no way to do this portably.
> Should we skip it instead, i.e. finish right to the place where the signal
> was raised?

Which exact kernel version?  As I mentioned in another post, this works 
for me ....

Andrew

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Daniel Jacobowitz]

On Fri, Apr 23, 2004 at 02:02:30PM -0400, Andrew Cagney wrote:
> >These new tests are all failing on my i686-pc-linux-gnu system.
> >
> >sigaltstack.exp fails like this:
> >
> >finish
> >Run till exit from #0  catcher (signal=26) at 
> >/opt/src/gdb/src/gdb/testsuite/gdb.base/sigaltstack.c:71
> >Warning:
> >Cannot insert breakpoint 0.
> >Error accessing memory address 0xffffe420: Input/output error.
> >(gdb) FAIL: gdb.base/sigaltstack.exp: finish from catch LEAF
> >
> >The problem is that the signal trampoline is read-only.  We can't set
> >software breakpoints there.  I suspect there is no way to do this portably.
> >Should we skip it instead, i.e. finish right to the place where the signal
> >was raised?
> 
> Which exact kernel version?  As I mentioned in another post, this works 
> for me ....

2.6.5.  If you're using a 2.4-era kernel, it probably does not place
the sigreturn trampoline in the vsyscall DSO area.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: New test failures - observer.exp, sigaltstack.exp, siginfo.exp

[Andrew Cagney]

> 2.6.5.  If you're using a 2.4-era kernel, it probably does not place
> the sigreturn trampoline in the vsyscall DSO area.

That's the answer I was expecting, good.

Andrew