Re: Invalid program counters and unwinding

[Florian Weimer <fweimer@redhat.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