Re: Invalid program counters and unwinding

[Jeff Law <law at redhat dot com>]

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.

One might even be able to argue in this day and age that we should have
suitable descriptors for everything.  If no suitable descriptor is found
then backtracing should stop.  Lack of suitable descriptors in any code
would be considered a bug in that scenario.

jeff