Re: Invalid program counters and unwinding

[Florian Weimer <fweimer at redhat dot com>]

On 06/28/2018 04:18 PM, Jeff Law wrote:
> On 06/28/2018 06:30 AM, Florian Weimer wrote:
> > On 06/28/2018 04:16 AM, Jeff Law wrote:
> > > > Previous discussions:
> > > >
> > > > https://gcc.gnu.org/ml/gcc/2013-05/msg00253.html
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
> > > > https://sourceware.org/ml/libc-alpha/2016-07/msg00613.html
> > > >     (patch with a spread lock, still not async-signal-safe)
> >
> > > You might also want to look at RH BZ 1293594 which I think has pointers
> > > back to an issue from 2008 :(
> >
> > Interesting.  That does suspiciously look like a concurrent dlclose.
> > It's just that the crash handler crashes, after the application crash. I
> > think this one is really NOTABUG, both technically and from user impact:
> > we do not cause the crash, we just react poorly to the application
> > triggering undefined behavior.
> >
> > In the bug, you mentioned this code fragment for x86-64:
> >
> > 42        unsigned char *pc = context->ra;
> > 43        struct sigcontext *sc;
> > 44        long new_cfa;
> > 45
> > 46        /* movq __NR_rt_sigreturn, %rax ; syscall  */
> > 47        if (*(unsigned char *)(pc+0) == 0x48
> > 48            && *(unsigned long *)(pc+1) == 0x050f0000000fc0c7)
> >
> > I'm not sure I agree that it is “dumb”, but I think it proves
> > conclusively that you cannot feed random addresses to the unwinder. 8-)

> I believe "dumb" is referring to the fact that we're already in a bit of
> a weird state as evidenced by the NULL FDE.  Blindly trying to read the
> contents of the PC that we couldn't map to an FDE is, IMHO, dumb.

I think the code derives from i386, where historically it was necessary 
to unwind with the frame pointer only.  I suspect we still need this 
code there at least, to support legacy binaries.

For x86-64, we should probably not to attempt without tables at all, but 
I have no idea whether that's feasible.

Thanks,
Florian