ls -l is broken

ls -l is broken

[John David Anglin]

I just noticed that ls -l is broken:

dave@mx3210:~/gnu/gcc/gcc$ ls -l ltsugar.m4
ls: ltsugar.m4: Operation not supported
-rw-r--r-- 1 dave dave 4122 Mar 16 16:50 ltsugar.m4

dave@mx3210:~/gnu/gcc/gcc$ dpkg -l coreutils libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  coreutils      6.10-3         The GNU core utilities
ii  libc6          2.7-6          GNU C Library: Shared libraries
dave@mx3210:~/gnu/gcc/gcc$ uname -a
Linux mx3210 2.6.22.19 #4 SMP Tue Apr 1 19:24:18 EDT 2008 parisc64 GNU/Linux

coreutils 6.10 works on hpux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: ls -l is broken

[Matthew Wilcox]

On Sun, Apr 06, 2008 at 06:28:12PM -0400, John David Anglin wrote:
> I just noticed that ls -l is broken:
> 
> dave@mx3210:~/gnu/gcc/gcc$ ls -l ltsugar.m4
> ls: ltsugar.m4: Operation not supported
> -rw-r--r-- 1 dave dave 4122 Mar 16 16:50 ltsugar.m4

If you strace it, what syscall returns -EOPNOTSUPP?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: ls -l is broken

[John David Anglin]

> If you strace it, what syscall returns -EOPNOTSUPP?

strace is broken and quits before the relevant syscall.  Think I
mentioned this before is a different context.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: ls -l is broken

[John David Anglin]

> If you strace it, what syscall returns -EOPNOTSUPP?

Just wondering if this has something to do with the following:

 (ENOTSUP and EOPNOTSUPP have the same value  on  Linux,
  but  according  to POSIX.1 these error values should be
  distinct.)

Doing a google on the subject, it seems that this is a known debian bug.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: ls -l is broken

[Kyle McMartin]

On Sun, Apr 06, 2008 at 06:28:12PM -0400, John David Anglin wrote:
> I just noticed that ls -l is broken:
> 
> dave@mx3210:~/gnu/gcc/gcc$ ls -l ltsugar.m4
> ls: ltsugar.m4: Operation not supported
> -rw-r--r-- 1 dave dave 4122 Mar 16 16:50 ltsugar.m4
> 
> dave@mx3210:~/gnu/gcc/gcc$ dpkg -l coreutils libc6
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
> ||/ Name           Version        Description
> +++-==============-==============-============================================
> ii  coreutils      6.10-3         The GNU core utilities
> ii  libc6          2.7-6          GNU C Library: Shared libraries
> dave@mx3210:~/gnu/gcc/gcc$ uname -a
> Linux mx3210 2.6.22.19 #4 SMP Tue Apr 1 19:24:18 EDT 2008 parisc64 GNU/Linux
> 

I'm seeing this now as well... strace seems to barf on ptrace for some
reason (but is working fine otherwise... odd)

Re: ls -l is broken

[Kyle McMartin]

On Fri, Apr 11, 2008 at 01:41:23PM -0400, Kyle McMartin wrote:
> > ii  coreutils      6.10-3         The GNU core utilities
> > ii  libc6          2.7-6          GNU C Library: Shared libraries
> > dave@mx3210:~/gnu/gcc/gcc$ uname -a
> > Linux mx3210 2.6.22.19 #4 SMP Tue Apr 1 19:24:18 EDT 2008 parisc64 GNU/Linux
> 
> I'm seeing this now as well... strace seems to barf on ptrace for some
> reason (but is working fine otherwise... odd)
>

This must be a bug in the new glibc in sid... I'm seeing it on machines
with old kernels upgraded to sid (and, obviously, on machines with brand
new kernels.)

Either that or some glibc change is exposing a bug in our syscalls. I'll
try to puzzle out why ptrace is broken this weekend.

--Kyle 

Re: ls -l is broken

[Kyle McMartin]

On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > If you strace it, what syscall returns -EOPNOTSUPP?
> 
> strace is broken and quits before the relevant syscall.  Think I
> mentioned this before is a different context.
> 

Ok, I've fixed up ptrace. The failing syscall was lgetxattr, which, I
presume is failing because selinux is disabled, or something.

So, I assume that it's really just a warning.

regards, Kyle

Re: ls -l is broken

[Kyle McMartin]

On Tue, Apr 15, 2008 at 01:16:50AM -0400, Kyle McMartin wrote:
> On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > > If you strace it, what syscall returns -EOPNOTSUPP?
> > 
> > strace is broken and quits before the relevant syscall.  Think I
> > mentioned this before is a different context.
> > 
> 
> Ok, I've fixed up ptrace. The failing syscall was lgetxattr, which, I
> presume is failing because selinux is disabled, or something.
> 

Nevermind, it's failing because you don't have XATTRs enabled on ext3.

Re: ls -l is broken

[John David Anglin]

> Nevermind, it's failing because you don't have XATTRs enabled on ext3.

That sounds right.  I remember now that there's also an issue with
ls --full-time support on some file systems.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: ls -l is broken

[Kyle McMartin]

On Wed, Apr 16, 2008 at 01:15:52PM -0400, John David Anglin wrote:
> > Nevermind, it's failing because you don't have XATTRs enabled on ext3.
> 
> That sounds right.  I remember now that there's also an issue with
> ls --full-time support on some file systems.
> 

The problem is, this seems to be causing failures on the buildds, which
probably need XATTRs enabled as well. I've added lamont to the CC list,
hopefully he can shed a bit of light on this.

Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > If you strace it, what syscall returns -EOPNOTSUPP?
> 
> strace is broken and quits before the relevant syscall.  Think I
> mentioned this before is a different context.
> 

Fixed & updated strace available at
http://people.debian.org/~kyle/strace/

cheers, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > > If you strace it, what syscall returns -EOPNOTSUPP?
> > 
> > strace is broken and quits before the relevant syscall.  Think I
> > mentioned this before is a different context.
> > 
> 
> Fixed & updated strace available at
> http://people.debian.org/~kyle/strace/

lgetxattr("strace_4.5.16-1_hppa.deb", "security.selinux"..., 0x2c768, 255) = -1 EOPNOTSUPP 
(Operation not supported)

This is probably the correct return but the manpage for lgetxattr says
it should return ENOTSUP.  Possibly, the problem occurs on hppa because
ENOTSUP and EOPNOTSUPP are different codes.  In any case, the current
version of ls only checks for ENOTSUP.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Mon, Aug 04, 2008 at 03:39:57PM -0400, John David Anglin wrote:
> > On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > > > If you strace it, what syscall returns -EOPNOTSUPP?
> > > 
> > > strace is broken and quits before the relevant syscall.  Think I
> > > mentioned this before is a different context.
> > > 
> > 
> > Fixed & updated strace available at
> > http://people.debian.org/~kyle/strace/
> 
> lgetxattr("strace_4.5.16-1_hppa.deb", "security.selinux"..., 0x2c768, 255) = -1 EOPNOTSUPP 
> (Operation not supported)
> 
> This is probably the correct return but the manpage for lgetxattr says
> it should return ENOTSUP.  Possibly, the problem occurs on hppa because
> ENOTSUP and EOPNOTSUPP are different codes.  In any case, the current
> version of ls only checks for ENOTSUP.
> 

Ah, it's wrong.

ls.c should be checking for -EOPNOTSUP, which is the only thing any of
the kernel codepaths return for failing xattr calls. You're correct in
diagnosing that this is only problematic on parisc, because we're the
only folks who use a different value for EOPNOTSUP and ENOTSUP.

cheers, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> ls.c should be checking for -EOPNOTSUP, which is the only thing any of
> the kernel codepaths return for failing xattr calls. You're correct in
> diagnosing that this is only problematic on parisc, because we're the
> only folks who use a different value for EOPNOTSUP and ENOTSUP.

It is my understanding that Jim Meyering is addressing the ls issue.
HP-UX is also theoretically affected but the code paths are different.

The manpages are still wrong.  This probably led to the confusion in
the first place.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

Hi Kyle,

> On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > > If you strace it, what syscall returns -EOPNOTSUPP?
> > 
> > strace is broken and quits before the relevant syscall.  Think I
> > mentioned this before is a different context.
> > 
> 
> Fixed & updated strace available at
> http://people.debian.org/~kyle/strace/

strace is either broken again or debian didn't pick up your fix.  The link
to your updated version is broken.

This happens when tracing sshd during a connection attempt with -f option:

strace -f -p 2390
Process 2390 attached - interrupt to quit
_newselect(7, [3 4], NULL, NULL, NULL
...
[pid  5627] open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
upeek: ptrace(PTRACE_PEEKUSER,5627,4294967292,0): Input/output error
Process 5627 detached
<... _newselect resumed> )              = 1 (in [6])

Trying to figure out why sshd sometimes does wierd stuff.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Sat, May 02, 2009 at 06:34:59PM -0400, John David Anglin wrote:
> Hi Kyle,
> 
> > On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > > > If you strace it, what syscall returns -EOPNOTSUPP?
> > > 
> > > strace is broken and quits before the relevant syscall.  Think I
> > > mentioned this before is a different context.
> > > 
> > 
> > Fixed & updated strace available at
> > http://people.debian.org/~kyle/strace/
> 
> strace is either broken again or debian didn't pick up your fix.  The link
> to your updated version is broken.
> 
> This happens when tracing sshd during a connection attempt with -f option:
> 
> strace -f -p 2390
> Process 2390 attached - interrupt to quit
> _newselect(7, [3 4], NULL, NULL, NULL
> ...
> [pid  5627] open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
> upeek: ptrace(PTRACE_PEEKUSER,5627,4294967292,0): Input/output error
> Process 5627 detached
> <... _newselect resumed> )              = 1 (in [6])
> 
> Trying to figure out why sshd sometimes does wierd stuff.
> 

I'll take a look, the strace link is broken because sadly the debian
people didn't migrate the entirety of the people machine when they
brought in a new one.

regards, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[Mike Frysinger]

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

On Saturday 02 May 2009 19:43:48 Kyle McMartin wrote:
> On Sat, May 02, 2009 at 06:34:59PM -0400, John David Anglin wrote:
> > Hi Kyle,
> >
> > > On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > > > > If you strace it, what syscall returns -EOPNOTSUPP?
> > > >
> > > > strace is broken and quits before the relevant syscall.  Think I
> > > > mentioned this before is a different context.
> > >
> > > Fixed & updated strace available at
> > > http://people.debian.org/~kyle/strace/
> >
> > strace is either broken again or debian didn't pick up your fix.  The
> > link to your updated version is broken.
> >
> > This happens when tracing sshd during a connection attempt with -f
> > option:
> >
> > strace -f -p 2390
> > Process 2390 attached - interrupt to quit
> > _newselect(7, [3 4], NULL, NULL, NULL
> > ...
> > [pid  5627] open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT
> > (No such file or directory) upeek:
> > ptrace(PTRACE_PEEKUSER,5627,4294967292,0): Input/output error Process
> > 5627 detached
> > <... _newselect resumed> )              = 1 (in [6])
> >
> > Trying to figure out why sshd sometimes does wierd stuff.
>
> I'll take a look, the strace link is broken because sadly the debian
> people didn't migrate the entirety of the people machine when they
> brought in a new one.

if said fix could actually get posted to the strace devel list at sf.net, 
that'd be even better ...

probably related:
http://bugs.gentoo.org/250631
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Mon, May 04, 2009 at 11:46:09PM -0400, Mike Frysinger wrote:
> 
> if said fix could actually get posted to the strace devel list at sf.net, 
> that'd be even better ...
> 

It was, when I fixed it, several years ago...

> probably related:
> http://bugs.gentoo.org/250631
> -mike

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Tue, May 05, 2009 at 11:37:23AM -0400, Kyle McMartin wrote:
> On Mon, May 04, 2009 at 11:46:09PM -0400, Mike Frysinger wrote:
> > 
> > if said fix could actually get posted to the strace devel list at sf.net, 
> > that'd be even better ...
> > 
> 
> It was, when I fixed it, several years ago...
> 
> > probably related:
> > http://bugs.gentoo.org/250631
> > -mike
> 

Huh, maybe it bounced. In any event, the old people.debian.org is still
accessible, so I've copied the fixed 4.5.16-1 to the new people, so it
should be accessible again.

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Mon, May 04, 2009 at 11:46:09PM -0400, Mike Frysinger wrote:
> if said fix could actually get posted to the strace devel list at sf.net, 
> that'd be even better ...
> 
> probably related:
> http://bugs.gentoo.org/250631

http://userweb.kernel.org/~kyle/strace-add-hppa-syscalls.diff
http://userweb.kernel.org/~kyle/strace-fix-hppa-syscalls.diff

Apply against upstream strace cvs. I'll poke Roland about it.

cheers, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Sat, May 02, 2009 at 06:34:59PM -0400, John David Anglin wrote:
> Hi Kyle,
> 
> > On Sun, Apr 06, 2008 at 07:09:59PM -0400, John David Anglin wrote:
> > > > If you strace it, what syscall returns -EOPNOTSUPP?
> > > 
> > > strace is broken and quits before the relevant syscall.  Think I
> > > mentioned this before is a different context.
> > > 
> > 
> > Fixed & updated strace available at
> > http://people.debian.org/~kyle/strace/
> 
> strace is either broken again or debian didn't pick up your fix.  The link
> to your updated version is broken.
> 
> This happens when tracing sshd during a connection attempt with -f option:
> 
> strace -f -p 2390
> Process 2390 attached - interrupt to quit
> _newselect(7, [3 4], NULL, NULL, NULL
> ...
> [pid  5627] open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
> upeek: ptrace(PTRACE_PEEKUSER,5627,4294967292,0): Input/output error
> Process 5627 detached
> <... _newselect resumed> )              = 1 (in [6])
> 

Hmm, I'm seeing strace (4.5.18-1) segfault on sys_rt_sigaction. Rather
confused as to why though,

(gdb) 
#0  0x0002b3ec in __canonicalize_funcptr_for_compare ()
#1  0x00026010 in sys_rt_sigaction (tcp=0x4e060) at ../signal.c:1886
#2  0x00017b10 in trace_syscall (tcp=0x4e060) at ../syscall.c:2553
#3  0x00016c98 in main (argc=<value optimized out>, argv=0xbff8202c)
    at ../strace.c:2475

which is:

                if (sa.__sigaction_handler.__sa_handler == SIG_ERR)
                        tprintf("{SIG_ERR, ");

where:

struct new_sigaction
{
        union
        {
                __sighandler_t __sa_handler;
                void (*__sa_sigaction) (int, siginfo_t *, void *);
        }
        __sigaction_handler;

which isn't materially different from upstream (just the union...)

regards, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> (gdb) 
> #0  0x0002b3ec in __canonicalize_funcptr_for_compare ()
> #1  0x00026010 in sys_rt_sigaction (tcp=0x4e060) at ../signal.c:1886
> #2  0x00017b10 in trace_syscall (tcp=0x4e060) at ../syscall.c:2553
> #3  0x00016c98 in main (argc=<value optimized out>, argv=0xbff8202c)
>     at ../strace.c:2475
> 
> which is:
> 
>                 if (sa.__sigaction_handler.__sa_handler == SIG_ERR)
>                         tprintf("{SIG_ERR, ");

Is __canonicalize_funcptr_for_compare choking on SIG_ERR?  This is
a special value (-1).  The plabel bit is set.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Tue, May 05, 2009 at 02:17:49PM -0400, John David Anglin wrote:
> > (gdb) 
> > #0  0x0002b3ec in __canonicalize_funcptr_for_compare ()
> > #1  0x00026010 in sys_rt_sigaction (tcp=0x4e060) at ../signal.c:1886
> > #2  0x00017b10 in trace_syscall (tcp=0x4e060) at ../syscall.c:2553
> > #3  0x00016c98 in main (argc=<value optimized out>, argv=0xbff8202c)
> >     at ../strace.c:2475
> > 
> > which is:
> > 
> >                 if (sa.__sigaction_handler.__sa_handler == SIG_ERR)
> >                         tprintf("{SIG_ERR, ");
> 
> Is __canonicalize_funcptr_for_compare choking on SIG_ERR?  This is
> a special value (-1).  The plabel bit is set.
> 

Ahh, brilliant. Casting to long fixed it.

cheers, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> On Tue, May 05, 2009 at 02:17:49PM -0400, John David Anglin wrote:
> > > (gdb) 
> > > #0  0x0002b3ec in __canonicalize_funcptr_for_compare ()
> > > #1  0x00026010 in sys_rt_sigaction (tcp=0x4e060) at ../signal.c:1886
> > > #2  0x00017b10 in trace_syscall (tcp=0x4e060) at ../syscall.c:2553
> > > #3  0x00016c98 in main (argc=<value optimized out>, argv=0xbff8202c)
> > >     at ../strace.c:2475
> > > 
> > > which is:
> > > 
> > >                 if (sa.__sigaction_handler.__sa_handler == SIG_ERR)
> > >                         tprintf("{SIG_ERR, ");
> > 
> > Is __canonicalize_funcptr_for_compare choking on SIG_ERR?  This is
> > a special value (-1).  The plabel bit is set.
> > 
> 
> Ahh, brilliant. Casting to long fixed it.

Probably, the cast should be to int.  __canonicalize_funcptr_for_compare
isn't used in the 64-bit runtime.

Still, I'm not sure why this fixed the problem as
__canonicalize_funcptr_for_compare checks for -1.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Tue, May 05, 2009 at 03:09:50PM -0400, John David Anglin wrote:
> Probably, the cast should be to int.  __canonicalize_funcptr_for_compare
> isn't used in the 64-bit runtime.
> 
> Still, I'm not sure why this fixed the problem as
> __canonicalize_funcptr_for_compare checks for -1.
> 

If we cast both sides to int, then we don't generate a call there...

--Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> On Tue, May 05, 2009 at 03:09:50PM -0400, John David Anglin wrote:
> > Probably, the cast should be to int.  __canonicalize_funcptr_for_compare
> > isn't used in the 64-bit runtime.
> > 
> > Still, I'm not sure why this fixed the problem as
> > __canonicalize_funcptr_for_compare checks for -1.
> > 
> 
> If we cast both sides to int, then we don't generate a call there...

That will certainly fix the problem but I'd really like to know
why we get a segv.  I suspect we are not handling a deferred function
pointer correctly.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Mike Frysinger]

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

On Tuesday 05 May 2009 11:37:23 Kyle McMartin wrote:
> On Mon, May 04, 2009 at 11:46:09PM -0400, Mike Frysinger wrote:
> > if said fix could actually get posted to the strace devel list at sf.net,
> > that'd be even better ...
>
> It was, when I fixed it, several years ago...

devel was pretty dead then ... but if you post it to the mailing list, people 
should pick it up now as Roland isnt the only one watching it with commit 
access
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Tue, May 05, 2009 at 03:46:57PM -0400, John David Anglin wrote:
> > On Tue, May 05, 2009 at 03:09:50PM -0400, John David Anglin wrote:
> > > Probably, the cast should be to int.  __canonicalize_funcptr_for_compare
> > > isn't used in the 64-bit runtime.
> > > 
> > > Still, I'm not sure why this fixed the problem as
> > > __canonicalize_funcptr_for_compare checks for -1.
> > > 
> > 
> > If we cast both sides to int, then we don't generate a call there...
> 
> That will certainly fix the problem but I'd really like to know
> why we get a segv.  I suspect we are not handling a deferred function
> pointer correctly.
> 

At a guess, you're probably right, the faulting insn is a load:

0x0002b3a8 <__canonicalize_funcptr_for_compare+48>:	bb,>= r26,1e,0x2b394 <__canonicalize_funcptr_for_compare+28>
0x0002b3ac <__canonicalize_funcptr_for_compare+52>:	copy r26,r3
0x0002b3b0 <__canonicalize_funcptr_for_compare+56>:	addil L%800,dp,r1
0x0002b3b4 <__canonicalize_funcptr_for_compare+60>:	ldw 294(r1),ret1
0x0002b3b8 <__canonicalize_funcptr_for_compare+64>:	depwi 0,31,2,r3
0x0002b3bc <__canonicalize_funcptr_for_compare+68>:	ldw 0(r3),r26

god knows I can't recall how DEP*I work, but I guess this is clearing
the bottom two bits of %r3 if bit 31 is set in %r26?

(gdb) p/x $r3 
$3 = 0x407d2f18
(gdb) p/x $r26
$4 = 0x407d2f1a

This looks like the sigaction handler, (it appears __canon..._compare
detects -1 already.)

regards, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> On Tue, May 05, 2009 at 03:46:57PM -0400, John David Anglin wrote:
> > > On Tue, May 05, 2009 at 03:09:50PM -0400, John David Anglin wrote:
> > > > Probably, the cast should be to int.  __canonicalize_funcptr_for_compare
> > > > isn't used in the 64-bit runtime.
> > > > 
> > > > Still, I'm not sure why this fixed the problem as
> > > > __canonicalize_funcptr_for_compare checks for -1.
> > > > 
> > > 
> > > If we cast both sides to int, then we don't generate a call there...
> > 
> > That will certainly fix the problem but I'd really like to know
> > why we get a segv.  I suspect we are not handling a deferred function
> > pointer correctly.
> > 
> 
> At a guess, you're probably right, the faulting insn is a load:
> 
> 0x0002b3a8 <__canonicalize_funcptr_for_compare+48>:	bb,>= r26,1e,0x2b394 <__canonicalize_funcptr_for_compare+28>
> 0x0002b3ac <__canonicalize_funcptr_for_compare+52>:	copy r26,r3
> 0x0002b3b0 <__canonicalize_funcptr_for_compare+56>:	addil L%800,dp,r1
> 0x0002b3b4 <__canonicalize_funcptr_for_compare+60>:	ldw 294(r1),ret1
> 0x0002b3b8 <__canonicalize_funcptr_for_compare+64>:	depwi 0,31,2,r3
> 0x0002b3bc <__canonicalize_funcptr_for_compare+68>:	ldw 0(r3),r26
> 
> god knows I can't recall how DEP*I work, but I guess this is clearing
> the bottom two bits of %r3 if bit 31 is set in %r26?
> 
> (gdb) p/x $r3 
> $3 = 0x407d2f18
> (gdb) p/x $r26
> $4 = 0x407d2f1a
> 
> This looks like the sigaction handler, (it appears __canon..._compare
> detects -1 already.)

This all seems correct.  r3 should be pointing to a function descriptor
for the sigaction handler (plabel bit is set).  What is the interruption
generated by the ldw at 0x0002b3bc?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Wed, May 06, 2009 at 12:19:37PM -0400, John David Anglin wrote:
> > On Tue, May 05, 2009 at 03:46:57PM -0400, John David Anglin wrote:
> > > > On Tue, May 05, 2009 at 03:09:50PM -0400, John David Anglin wrote:
> > > > > Probably, the cast should be to int.  __canonicalize_funcptr_for_compare
> > > > > isn't used in the 64-bit runtime.
> > > > > 
> > > > > Still, I'm not sure why this fixed the problem as
> > > > > __canonicalize_funcptr_for_compare checks for -1.
> > > > > 
> > > > 
> > > > If we cast both sides to int, then we don't generate a call there...
> > > 
> > > That will certainly fix the problem but I'd really like to know
> > > why we get a segv.  I suspect we are not handling a deferred function
> > > pointer correctly.
> > > 
> > 
> > At a guess, you're probably right, the faulting insn is a load:
> > 
> > 0x0002b3a8 <__canonicalize_funcptr_for_compare+48>:	bb,>= r26,1e,0x2b394 <__canonicalize_funcptr_for_compare+28>
> > 0x0002b3ac <__canonicalize_funcptr_for_compare+52>:	copy r26,r3
> > 0x0002b3b0 <__canonicalize_funcptr_for_compare+56>:	addil L%800,dp,r1
> > 0x0002b3b4 <__canonicalize_funcptr_for_compare+60>:	ldw 294(r1),ret1
> > 0x0002b3b8 <__canonicalize_funcptr_for_compare+64>:	depwi 0,31,2,r3
> > 0x0002b3bc <__canonicalize_funcptr_for_compare+68>:	ldw 0(r3),r26
> > 
> > god knows I can't recall how DEP*I work, but I guess this is clearing
> > the bottom two bits of %r3 if bit 31 is set in %r26?
> > 
> > (gdb) p/x $r3 
> > $3 = 0x407d2f18
> > (gdb) p/x $r26
> > $4 = 0x407d2f1a
> > 
> > This looks like the sigaction handler, (it appears __canon..._compare
> > detects -1 already.)
> 
> This all seems correct.  r3 should be pointing to a function descriptor
> for the sigaction handler (plabel bit is set).  What is the interruption
> generated by the ldw at 0x0002b3bc?
> 

The tombstone is:

do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
vm_start = 0x4068d000, vm_end = 0x4068f000

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001011 Not tainted
r00-03  000000ff0004ff0b 0000000000040aec 0000000000025fef
00000000407d2f18
r04-07  0000000000000004 000000000004e060 000000000004b0c0
0000000000040aec
r08-11  00000000bff84254 000000000004b0b8 0000000000040300
0000000000040db8
r12-15  0000000000042aec 0000000000042eec 0000000000040aec
000000000004b0b0
r16-19  000000000004b0a8 0000000000040db0 0000000000042dec
000000004068af74
r20-23  0000000000000000 00000000405bf940 0000000000000000
00000000bff84608
r24-27  0000000000000004 00000000bff84588 00000000407d2f1a
00000000000402ec
r28-31  0000000000000fff 0000000000040d70 00000000bff845c0
000000004061033f
sr00-03  0000000007acc800 00000000003ee000 0000000000000000
0000000007acc800
sr04-07  0000000007acc800 0000000007acc800 0000000007acc800
0000000007acc800

IASQ: 0000000007acc800 0000000007acc800 IAOQ: 000000000002b3bf
000000000002b3c3
 IIR: 0c60109a    ISR: 0000000007acc800  IOR: 00000000407d2f18
 CPU:        3   CR30: 000000007da88000 CR31: fffffff0f0e098e0
 ORIG_R28: 00000000bff84608
 IAOQ[0]: 000000000002b3bf
 IAOQ[1]: 000000000002b3c3
 RP(r2): 0000000000025fef


cheers, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> The tombstone is:
> 
> do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> vm_start = 0x4068d000, vm_end = 0x4068f000

So, the pointer passed to __canonicalize_funcptr_for_compare is outside
the vm range.

Maybe "info sharedlib" will show something.  Need to find out why the
address of the function descriptor is outside the vm range.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Wed, May 06, 2009 at 01:39:49PM -0400, John David Anglin wrote:
> > The tombstone is:
> > 
> > do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> > vm_start = 0x4068d000, vm_end = 0x4068f000
> 
> So, the pointer passed to __canonicalize_funcptr_for_compare is outside
> the vm range.
> 
> Maybe "info sharedlib" will show something.  Need to find out why the
> address of the function descriptor is outside the vm range.
> 

405c0000-405c2000 rwxp 405c0000 00:00 0 

is the output of /proc/maps there... No idea wtf this is. :/

regards, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> On Wed, May 06, 2009 at 01:39:49PM -0400, John David Anglin wrote:
> > > The tombstone is:
> > > 
> > > do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> > > vm_start = 0x4068d000, vm_end = 0x4068f000
> > 
> > So, the pointer passed to __canonicalize_funcptr_for_compare is outside
> > the vm range.
> > 
> > Maybe "info sharedlib" will show something.  Need to find out why the
> > address of the function descriptor is outside the vm range.
> > 
> 
> 405c0000-405c2000 rwxp 405c0000 00:00 0 

The function pointer address is also outside this range.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Thu, May 07, 2009 at 01:41:03PM -0400, John David Anglin wrote:
> > On Wed, May 06, 2009 at 01:39:49PM -0400, John David Anglin wrote:
> > > > The tombstone is:
> > > > 
> > > > do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> > > > vm_start = 0x4068d000, vm_end = 0x4068f000
> > > 
> > > So, the pointer passed to __canonicalize_funcptr_for_compare is outside
> > > the vm range.
> > > 
> > > Maybe "info sharedlib" will show something.  Need to find out why the
> > > address of the function descriptor is outside the vm range.
> > > 
> > 
> > 405c0000-405c2000 rwxp 405c0000 00:00 0 
> 
> The function pointer address is also outside this range.
> 

Sorry, this was with a rebuilt binary, and it lies within this range.

cheers, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> On Thu, May 07, 2009 at 01:41:03PM -0400, John David Anglin wrote:
> > > On Wed, May 06, 2009 at 01:39:49PM -0400, John David Anglin wrote:
> > > > > The tombstone is:
> > > > > 
> > > > > do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> > > > > vm_start = 0x4068d000, vm_end = 0x4068f000
> > > > 
> > > > So, the pointer passed to __canonicalize_funcptr_for_compare is outside
> > > > the vm range.
> > > > 
> > > > Maybe "info sharedlib" will show something.  Need to find out why the
> > > > address of the function descriptor is outside the vm range.
> > > > 
> > > 
> > > 405c0000-405c2000 rwxp 405c0000 00:00 0 
> > 
> > The function pointer address is also outside this range.
> > 
> 
> Sorry, this was with a rebuilt binary, and it lies within this range.

It's marked rwxp, so why the fault?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[James Bottomley]

On Thu, 2009-05-07 at 14:41 -0400, John David Anglin wrote:
> > On Thu, May 07, 2009 at 01:41:03PM -0400, John David Anglin wrote:
> > > > On Wed, May 06, 2009 at 01:39:49PM -0400, John David Anglin wrote:
> > > > > > The tombstone is:
> > > > > > 
> > > > > > do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> > > > > > vm_start = 0x4068d000, vm_end = 0x4068f000
> > > > > 
> > > > > So, the pointer passed to __canonicalize_funcptr_for_compare is outside
> > > > > the vm range.
> > > > > 
> > > > > Maybe "info sharedlib" will show something.  Need to find out why the
> > > > > address of the function descriptor is outside the vm range.
> > > > > 
> > > > 
> > > > 405c0000-405c2000 rwxp 405c0000 00:00 0 
> > > 
> > > The function pointer address is also outside this range.
> > > 
> > 
> > Sorry, this was with a rebuilt binary, and it lies within this range.
> 
> It's marked rwxp, so why the fault?

That's a bit fascinating ... it means we got into the bad_area: goto of
do_page_fault() somehow even though the vma apparently allowed the fault
and we should have been able to page it in.  Something like this might
explain a lot of our stability problems.

James

Re: Fixed strace [ was Re: ls -l is broken ]

[Kyle McMartin]

On Thu, May 07, 2009 at 09:06:44PM +0000, James Bottomley wrote:
> On Thu, 2009-05-07 at 14:41 -0400, John David Anglin wrote:
> > > On Thu, May 07, 2009 at 01:41:03PM -0400, John David Anglin wrote:
> > > > > On Wed, May 06, 2009 at 01:39:49PM -0400, John David Anglin wrote:
> > > > > > > The tombstone is:
> > > > > > > 
> > > > > > > do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> > > > > > > vm_start = 0x4068d000, vm_end = 0x4068f000
> > > > > > 
> > > > > > So, the pointer passed to __canonicalize_funcptr_for_compare is outside
> > > > > > the vm range.
> > > > > > 
> > > > > > Maybe "info sharedlib" will show something.  Need to find out why the
> > > > > > address of the function descriptor is outside the vm range.
> > > > > > 
> > > > > 
> > > > > 405c0000-405c2000 rwxp 405c0000 00:00 0 
> > > > 
> > > > The function pointer address is also outside this range.
> > > > 
> > > 
> > > Sorry, this was with a rebuilt binary, and it lies within this range.
> > 
> > It's marked rwxp, so why the fault?
> 
> That's a bit fascinating ... it means we got into the bad_area: goto of
> do_page_fault() somehow even though the vma apparently allowed the fault
> and we should have been able to page it in.  Something like this might
> explain a lot of our stability problems.
> 

Sadly, I can't seem to reproduce this right now, because strace is dying
with the ptrace issue JDA brought up earlier. I'll poke at it more
tonight, but I want to get caught up on the merging first.

cheers, Kyle

Re: Fixed strace [ was Re: ls -l is broken ]

[Randolph Chung]

> Sadly, I can't seem to reproduce this right now, because strace is dying
> with the ptrace issue JDA brought up earlier. I'll poke at it more
> tonight, but I want to get caught up on the merging first.
>
> cheers, Kyle
>   
Kyle suggested I mention atrace to the strace developers. Maybe others 
here are interested:

http://sourceforge.net/mailarchive/forum.php?thread_name=4A04EB4A.5030204%40tausq.org&forum_name=strace-devel

For all I know, atrace is also horribly broken, but at least it seems to 
be able to trace "ls -l"   :-)

randolph

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> On Wed, May 06, 2009 at 01:39:49PM -0400, John David Anglin wrote:
> > > The tombstone is:
> > > 
> > > do_page_fault() pid=10205 command='strace' type=15 address=0x407d2f18
> > > vm_start = 0x4068d000, vm_end = 0x4068f000
> > 
> > So, the pointer passed to __canonicalize_funcptr_for_compare is outside
> > the vm range.
> > 
> > Maybe "info sharedlib" will show something.  Need to find out why the
> > address of the function descriptor is outside the vm range.
> > 
> 
> 405c0000-405c2000 rwxp 405c0000 00:00 0 
> 
> is the output of /proc/maps there... No idea wtf this is. :/

What are vm_start and vm_end?

Another segv last night.

Core was generated by `rm -f ada/bldtools/nmake_s/sinfo.ads ada/bldtools/nmake_s/nmake.adt ada/bldtool'.
Program terminated with signal 11, Segmentation fault.
[New process 12287]
#0  _dl_relocate_object (scope=0x40000db8, lazy=<value optimized out>, 
    consider_profiling=0) at do-rel.h:119
119	do-rel.h: No such file or directory.
	in do-rel.h

(gdb) p/x $pc
$1 = 0x402759ac

0x40275980 <_dl_relocate_object+728>:	ldw 4(ret0),r17
0x40275984 <_dl_relocate_object+732>:	ldw 4(r9),r21
0x40275988 <_dl_relocate_object+736>:	extrw,u r21,23,24,r22
0x4027598c <_dl_relocate_object+740>:	depw,z r22,27,28,r13
0x40275990 <_dl_relocate_object+744>:	ldw 0(r9),r20
0x40275994 <_dl_relocate_object+748>:	add,l r16,r13,r8
0x40275998 <_dl_relocate_object+752>:	stw r8,8(r3)
0x4027599c <_dl_relocate_object+756>:	add,l r12,r20,r10
0x402759a0 <_dl_relocate_object+760>:	ldb c(r8),ret0
0x402759a4 <_dl_relocate_object+764>:	extrw,u r21,31,8,r6
---Type <return> to continue, or q <return> to quit---
0x402759a8 <_dl_relocate_object+768>:	extrw,u ret0,27,28,ret0
0x402759ac <_dl_relocate_object+772>:	ldh,s r22(r17),r31
0x402759b0 <_dl_relocate_object+776>:	ldw 170(r11),ret1
0x402759b4 <_dl_relocate_object+780>:	cmpib,= 0,ret0,0x40275a64 <_dl_relocate_object+956>
0x402759b8 <_dl_relocate_object+784>:	copy r11,r5
End of assembler dump.
(gdb) p/x $r11
$3 = 0x40000c00
(gdb) p/x $r11 + 0xe4
$4 = 0x40000ce4
(gdb) x/x 0x40000ce4 
0x40000ce4:	0x4071e828
(gdb) x/x 0x4071e828 + 4
0x4071e82c <.LC2+200>:	0xa38cf763

(gdb) p/x $r22
$6 = 0x1

May  8 22:39:41 mx3210 kernel: do_page_fault() pid=12287 command='rm' type=15 address=0xa38cf765
May  8 22:39:41 mx3210 kernel: vm_start = 0x40724000, vm_end = 0x40726000

So, the address for ldh,s matches that in the tombstone.

...
002ae000-005f5000 rwxp 002ae000 00:00 0                                  [heap]
40000000-4000c000 rw-p 40000000 00:00 0 
4000c000-40011000 r-xp 00000000 08:03 640603                             /lib/libthread_db-1.0.so
...
4066d000-40670000 rwxp 0007a000 08:03 641636                             /lib/libm-2.9.so
40670000-4073d000 rw-p 4028d000 00:00 0 
...
40b26000-410fe000 rw-p 40b26000 00:00 0 
c0215000-c022a000 rwxp c0215000 00:00 0                                  [stack]

I don't see anything in /proc/maps that matches the vm range in the tombstone.

Comparing memory for the core dump with a normal start to main:

Core dump
(gdb) x/64x 0x4071e800
0x4071e800 <.LC2+156>:	0x6ffffffc	0x000129a8	0x6ffffffd	0x00000013
0x4071e810 <.LC2+172>:	0x0000001e	0x00000014	0x6ffffffe	0x00012c3c
0x4071e820 <.LC2+188>:	0x6fffffff	0x00000001	0x6ffffff0	0xa38cf763
0x4071e830 <.LC2+204>:	0x6ffffff9	0x00000d5b	0x00000000	0x00000000
0x4071e840 <.LC2+220>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e850 <.LC2+236>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e860 <__libc_multiple_libcs>:	0x00000001	0x00000000	0x00000000	0x00000000
0x4071e870 <__gconv_lock>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e880 <__gconv_lock+16>:	0x00000001	0x00000001	0x00000001	0x00000001
0x4071e890 <__gconv_lock+32>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e8a0 <lock.11041>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e8b0 <lock.11041+16>:	0x00000001	0x00000001	0x00000001	---Type <return> to continue, or q <return> to quit---
0x00000001
0x4071e8c0 <lock.11041+32>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e8d0 <lock>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e8e0 <lock+16>:	0x00000001	0x00000001	0x00000001	0x00000001
0x4071e8f0 <lock+32>:	0x00000000	0x00000000	0x00000000	0x00000000

Normal:
(gdb) x/64x 0x4071e800
0x4071e800 <.LC2+156>:	0x6ffffffc	0x000129a8	0x6ffffffd	0x00000013
0x4071e810 <.LC2+172>:	0x0000001e	0x00000014	0x6ffffffe	0x00012c3c
0x4071e820 <.LC2+188>:	0x6fffffff	0x00000001	0x6ffffff0	0x405ea8cc
0x4071e830 <.LC2+204>:	0x6ffffff9	0x00000d5b	0x00000000	0x00000000
0x4071e840 <.LC2+220>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e850 <.LC2+236>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e860 <__libc_multiple_libcs>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e870 <__gconv_lock>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e880 <__gconv_lock+16>:	0x00000001	0x00000001	0x00000001	0x00000001
0x4071e890 <__gconv_lock+32>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e8a0 <lock.11041>:	0x00000000	0x00000000	0x00000000	0x00000000
0x4071e8b0 <lock.11041+16>:	0x00000001	0x00000001	0x00000001

I sure looks as if memory has been stomped.  Specifically, the word that
caused the segv.  The surrounding values are the same.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Carlos O'Donell]

On Sat, May 9, 2009 at 1:18 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> 0x402759ac <_dl_relocate_object+772>: =A0 ldh,s r22(r17),r31
> 0x402759b0 <_dl_relocate_object+776>: =A0 ldw 170(r11),ret1
> 0x402759b4 <_dl_relocate_object+780>: =A0 cmpib,=3D 0,ret0,0x40275a64=
 <_dl_relocate_object+956>
> 0x402759b8 <_dl_relocate_object+784>: =A0 copy r11,r5
> End of assembler dump.
> (gdb) p/x $r11

Shouldn't you be using $r17 here?

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 1155 bytes --]

> 
> On Sat, May 9, 2009 at 1:18 PM, John David Anglin
> <dave@hiauly1.hia.nrc.ca> wrote:
> > 0x402759ac <_dl_relocate_object+772>:   ldh,s r22(r17),r31
> > 0x402759b0 <_dl_relocate_object+776>:   ldw 170(r11),ret1
> > 0x402759b4 <_dl_relocate_object+780>:   cmpib,= 0,ret0,0x40275a64 <_dl_relocate_object+956>
> > 0x402759b8 <_dl_relocate_object+784>:   copy r11,r5
> > End of assembler dump.
> > (gdb) p/x $r11
> 
> Shouldn't you be using $r17 here?

Sorry, for the confusion.  I tried to demonstrate how $r17 was loaded
from memory starting from $r11.  You can see the load earlier in the
disassembly.  The values in $r22 and $r17 were consistent with the fault
address.  The value loaded from memory into $r17 was also consistent
with what was recorded in memory in the core dump.  It appeared to me
that only a single word was corrupted.

Unfortunately, gdb dropped core on the core file, so there's nothing
more that can be looked at.  This was caused by a malloc double free
error.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Fixed strace [ was Re: ls -l is broken ]

[Grant Grundler]

On Wed, May 06, 2009 at 12:04:42PM -0400, Kyle McMartin wrote:
...
> At a guess, you're probably right, the faulting insn is a load:
> 
> 0x0002b3a8 <__canonicalize_funcptr_for_compare+48>:	bb,>= r26,1e,0x2b394 <__canonicalize_funcptr_for_compare+28>
> 0x0002b3ac <__canonicalize_funcptr_for_compare+52>:	copy r26,r3
> 0x0002b3b0 <__canonicalize_funcptr_for_compare+56>:	addil L%800,dp,r1
> 0x0002b3b4 <__canonicalize_funcptr_for_compare+60>:	ldw 294(r1),ret1
> 0x0002b3b8 <__canonicalize_funcptr_for_compare+64>:	depwi 0,31,2,r3
> 0x0002b3bc <__canonicalize_funcptr_for_compare+68>:	ldw 0(r3),r26
> 
> god knows I can't recall how DEP*I work, but I guess this is clearing
> the bottom two bits of %r3 if bit 31 is set in %r26?

Wouldn't 1e == bit 30?

And yes, "depwi 0,31,2,XX"  is clearing the bottom 2 bits of XX.

I'm a bit confused about the ">=" conditional since only one bit is tested.
So is the copy only executed on branch not taken case?

grant

Re: Fixed strace [ was Re: ls -l is broken ]

[John David Anglin]

> 
> On Wed, May 06, 2009 at 12:04:42PM -0400, Kyle McMartin wrote:
> ...
> > At a guess, you're probably right, the faulting insn is a load:
> > 
> > 0x0002b3a8 <__canonicalize_funcptr_for_compare+48>:	bb,>= r26,1e,0x2b394 <__canonicalize_funcptr_for_compare+28>
> > 0x0002b3ac <__canonicalize_funcptr_for_compare+52>:	copy r26,r3
> > 0x0002b3b0 <__canonicalize_funcptr_for_compare+56>:	addil L%800,dp,r1
> > 0x0002b3b4 <__canonicalize_funcptr_for_compare+60>:	ldw 294(r1),ret1
> > 0x0002b3b8 <__canonicalize_funcptr_for_compare+64>:	depwi 0,31,2,r3
> > 0x0002b3bc <__canonicalize_funcptr_for_compare+68>:	ldw 0(r3),r26
> > 
> > god knows I can't recall how DEP*I work, but I guess this is clearing
> > the bottom two bits of %r3 if bit 31 is set in %r26?
> 
> Wouldn't 1e == bit 30?

Yes.  This is the 'L' field in the procedure label layout.  Bit 31
is X field and reserved.

> And yes, "depwi 0,31,2,XX"  is clearing the bottom 2 bits of XX.
> 
> I'm a bit confused about the ">=" conditional since only one bit is tested.
> So is the copy only executed on branch not taken case?

The conditions for bb are unique.  The word conditions are < and >=.
The double word conditions are *< and *>=.  See Table D-15 on page D-9
in arch.

This code sequence is used for indirect calls (e.g., $$dyncall).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)