Re: Segment fault at exit when compiled with Clang and libc++
Felix Salfelder <[email protected]> Thu, 1 Feb 2024 17:40:30 +0100
| Newsgroups | gmane.comp.gnu.gnucap.bugs |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Feb 01, 2024 at 09:40:58AM -0600, LdBeth wrote: > >>>>> In <[email protected]> > >>>>> LdBeth <[email protected]> wrote: > >>>>> In <[email protected]> > >>>>> LdBeth <[email protected]> wrote: > ldb> Compiling the library with debug info can gives the backtrace. > ldb> Actually, there are two places cause the segfault. Their backtraces > ldb> leads to C++ std::less(), but I don't found that very helpful, so > ldb> I tried my best to isolate the problem. > > > ldb> I found the cause is this method in `l_indirect.h` > > ldb> size_t erase(void* b, void* e) { > ldb> size_t c=0; > ldb> assert(b <= e); > ldb> for (void* i=b; i<=e; i=reinterpret_cast<bool*>(i)+1) { > ldb> c += _map.erase(i); > ldb> } > ldb> return c; > ldb> } > > I spend this morning to exclude the possibility that segfault was generate > by pointer casting and seems I found the exact cause: Thanks for your investigation, and reaching out to us. I have noticed that llvm produces more fragile code earlier (see modelgen-verilog/BUGS), but I have not observed the crash you described. Indeed there is a bug in indirect, or in one if its uses in gnucap (no need for modelgen-verilog). It does not lead to a crash when using gcc, but valgrind flags it... My guess is that some of the indirect objects are left to the generic garbage collector, which doesn't know about the intended destruction order. There's not much more I can say right now, but I will try to fix this asap. best wishes felix