I had a trinity process get stuck last overnight.
The reason for it getting stuck is my bug (I think), but
there's an odd unrelated thing I noticed while debugging this..
$ strace -p 20966
strace: Process 20966 attached
strace: [ Process PID=20966 runs in x32 mode. ]
So I don't use that new-fangled x32 stuff.
I don't even have CONFIG_X86_X32 compiled in.
Is this strace getting confused, or did we somehow screw
up the syscall entry code ?
Dave
On Fri, Mar 25, 2016 at 8:48 AM, Dave Jones <[email protected]> wrote:
> I had a trinity process get stuck last overnight.
> The reason for it getting stuck is my bug (I think), but
> there's an odd unrelated thing I noticed while debugging this..
>
> $ strace -p 20966
> strace: Process 20966 attached
> strace: [ Process PID=20966 runs in x32 mode. ]
>
> So I don't use that new-fangled x32 stuff.
> I don't even have CONFIG_X86_X32 compiled in.
>
> Is this strace getting confused, or did we somehow screw
> up the syscall entry code ?
>
> Dave
>
I think you're just seeing an oddity of how x32 works. Unlike
"compat", x32-ness of the current syscall isn't a special magic state
variable; it's just but 31 in the syscall nr. So trying to do an x32
syscall on a non-x32 syscall should still show bit 31 set to ptracers,
and the strace probably decodes this as being in x32 mode.
--Andy
On Fri, Mar 25, 2016 at 08:51:39AM -0700, Andy Lutomirski wrote:
> On Fri, Mar 25, 2016 at 8:48 AM, Dave Jones <[email protected]> wrote:
> > I had a trinity process get stuck last overnight.
> > The reason for it getting stuck is my bug (I think), but
> > there's an odd unrelated thing I noticed while debugging this..
> >
> > $ strace -p 20966
> > strace: Process 20966 attached
> > strace: [ Process PID=20966 runs in x32 mode. ]
> >
> > So I don't use that new-fangled x32 stuff.
> > I don't even have CONFIG_X86_X32 compiled in.
> >
> > Is this strace getting confused, or did we somehow screw
> > up the syscall entry code ?
> >
> > Dave
> >
>
> I think you're just seeing an oddity of how x32 works. Unlike
> "compat", x32-ness of the current syscall isn't a special magic state
> variable; it's just but 31 in the syscall nr. So trying to do an x32
> syscall on a non-x32 syscall should still show bit 31 set to ptracers,
> and the strace probably decodes this as being in x32 mode.
But this is an x86-64 binary, and it's the main process, not one of the fuzzing
child processes. It shouldn't be even trying to do anything weird.
It creates a bunch of fd's, then enters a loop forking/reaping children.
(In this case it actually hung while creating the fd's)
Trinity doesn't actually have any knowledge of x32 at all, mostly because
it's been irrelevant to me (and most other people).
Dave
On Fri, Mar 25, 2016 at 8:58 AM, Dave Jones <[email protected]> wrote:
> On Fri, Mar 25, 2016 at 08:51:39AM -0700, Andy Lutomirski wrote:
> > On Fri, Mar 25, 2016 at 8:48 AM, Dave Jones <[email protected]> wrote:
> > > I had a trinity process get stuck last overnight.
> > > The reason for it getting stuck is my bug (I think), but
> > > there's an odd unrelated thing I noticed while debugging this..
> > >
> > > $ strace -p 20966
> > > strace: Process 20966 attached
> > > strace: [ Process PID=20966 runs in x32 mode. ]
> > >
> > > So I don't use that new-fangled x32 stuff.
> > > I don't even have CONFIG_X86_X32 compiled in.
> > >
> > > Is this strace getting confused, or did we somehow screw
> > > up the syscall entry code ?
> > >
> > > Dave
> > >
> >
> > I think you're just seeing an oddity of how x32 works. Unlike
> > "compat", x32-ness of the current syscall isn't a special magic state
> > variable; it's just but 31 in the syscall nr. So trying to do an x32
> > syscall on a non-x32 syscall should still show bit 31 set to ptracers,
> > and the strace probably decodes this as being in x32 mode.
>
> But this is an x86-64 binary, and it's the main process, not one of the fuzzing
> child processes. It shouldn't be even trying to do anything weird.
> It creates a bunch of fd's, then enters a loop forking/reaping children.
> (In this case it actually hung while creating the fd's)
>
> Trinity doesn't actually have any knowledge of x32 at all, mostly because
> it's been irrelevant to me (and most other people).
>
Hmm. Do you have the next couple lines of strace output by any
chance? I'm wondering if this is a classic bug/misfeature/confusion
in the way that orig_ax works.
FWIW, the way that strace detects 32-bit mode is bogus, and I don't
actually know how strace detects x32 mode.
> Dave
>
>
--
Andy Lutomirski
AMA Capital Management, LLC
On Thu, Apr 07, 2016 at 05:20:50PM -0700, Andy Lutomirski wrote:
> > > > I had a trinity process get stuck last overnight.
> > > > The reason for it getting stuck is my bug (I think), but
> > > > there's an odd unrelated thing I noticed while debugging this..
> > > >
> > > > $ strace -p 20966
> > > > strace: Process 20966 attached
> > > > strace: [ Process PID=20966 runs in x32 mode. ]
> > > >
> > > > So I don't use that new-fangled x32 stuff.
> > > > I don't even have CONFIG_X86_X32 compiled in.
> > > >
> > > > Is this strace getting confused, or did we somehow screw
> > > > up the syscall entry code ?
> > > >
> > > > Dave
> > > >
> > >
> > > I think you're just seeing an oddity of how x32 works. Unlike
> > > "compat", x32-ness of the current syscall isn't a special magic state
> > > variable; it's just but 31 in the syscall nr. So trying to do an x32
> > > syscall on a non-x32 syscall should still show bit 31 set to ptracers,
> > > and the strace probably decodes this as being in x32 mode.
> >
> > But this is an x86-64 binary, and it's the main process, not one of the fuzzing
> > child processes. It shouldn't be even trying to do anything weird.
> > It creates a bunch of fd's, then enters a loop forking/reaping children.
> > (In this case it actually hung while creating the fd's)
> >
> > Trinity doesn't actually have any knowledge of x32 at all, mostly because
> > it's been irrelevant to me (and most other people).
> >
>
> Hmm. Do you have the next couple lines of strace output by any
> chance? I'm wondering if this is a classic bug/misfeature/confusion
> in the way that orig_ax works.
I don't. That box got rebooted a couple dozen times since then.
FWIW, I've not seen this happen since. Very strange.
Dave