https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So I guess the primary question would be, are threads involved in the
reproducer or not?
All the backtraces don't include start_thread, so the crashes are from the
initial thread, but that doesn't mean other threads weren't registering or
deregistering unwind info frames concurrently.
unwind-dw2-fde.c:719 is fairly simple:
for (; ! last_fde (ob, this_fde); this_fde = next_fde (this_fde))
where last_fde is:
static inline int
last_fde (const struct object *obj __attribute__ ((__unused__)), const fde *f)
{
#ifdef DWARF2_OBJECT_END_PTR_EXTENSION
return f == (const fde *) obj->fde_end || f->length == 0;
#else
return f->length == 0;
#endif
}
and next_fde is:
static inline const fde *
next_fde (const fde *f)
{
return (const fde *) ((const char *) f + f->length + sizeof (f->length));
}
So, I guess the primary question is what the LLVM JIT is calling the function
with,
if begin is a proper chain of valid .eh_frame CIEs and FDEs and if it is
properly 0 terminated. DWARF2_OBJECT_END_PTR_EXTENSION is Darwin only.
Also, __register_frame_info_bases requires the controlling struct object to be
preserved by the caller until it is deregistered, is that the case? Also, does
something change
the FDEs or CIEs which have been registered before they are deregistered again?
