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