Re: Segment fault at exit when compiled with Clang and libc++

[Felix Salfelder]

On Thu, Feb 01, 2024 at 09:40:58AM -0600, LdBeth wrote:
> >>>>> In <tencent_C1D1B9070B234867D04AE4AFC28DA91BC605@qq.com> 
> >>>>> LdBeth <andpuke@foxmail.com> wrote:
> >>>>> In <tencent_59FCFE0CDC28BA531DE77AE0304E748AAC09@qq.com> 
> >>>>> LdBeth <andpuke@foxmail.com> 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