bug-gnucap
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: LdBeth
Subject: Segment fault at exit when compiled with Clang and libc++
Date: Wed, 31 Jan 2024 22:40:10 -0600
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (x86_64-apple-darwin20.6.0) MULE/6.0 (HANACHIRUSATO)

I'm trying to compile the gnucap-20240130-dev release on macOS (I
guess right now I'm the only person doing this, if that matters my
system version is 12.7.3, on an Intel based MacBook Pro) and noticed
signal segmentation fault happens whenever gnucap or gnucap-modelgen
exits, although most features seems works.

I think the problem is only reproducible with clang and libc++,
because the segment fault is not reproduced when I compile the same
release on Linux with GCC.

Compiling the library with debug info can gives the backtrace.
Actually, there are two places cause the segfault. Their backtraces
leads to C++ std::less(), but I don't found that very helpful, so
I tried my best to isolate the problem.


(lldb) target create "./gnucap-modelgen"
Current executable set to 
'/Users/ldbeth/Downloads/gnucap-20240130-dev/modelgen/O/gnucap-modelgen' 
(x86_64).
(lldb) run
Process 12511 launched: 
'/Users/ldbeth/Downloads/gnucap-20240130-dev/modelgen/O/gnucap-modelgen' 
(x86_64)
Process 12511 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x2c)
    frame #0: 0x0000000100384cbc libgnucap.dylib`CKT_BASE::~CKT_BASE() 
[inlined] std::__1::less<void const*>::operator(this=<unavailable>, 
__x=<unavailable>, __y=0x000000000000002c)(void const* const&, void const* 
const&) const at operations.h:487:21 [opt]
   484  #endif
   485      _LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
   486      bool operator()(const _Tp& __x, const _Tp& __y) const
-> 487          {return __x < __y;}
   488  };
   489  
   490  #if _LIBCPP_STD_VER > 11
Target 0: (gnucap-modelgen) stopped.
warning: libgnucap.dylib was compiled with optimization - stepping may behave 
oddly; variables may not be available.

(lldb) target create "./gnucap-modelgen"
Current executable set to 
'/Users/ldbeth/Downloads/gnucap-20240130-dev/modelgen/O/gnucap-modelgen' 
(x86_64).
(lldb) run
Process 12570 launched: 
'/Users/ldbeth/Downloads/gnucap-20240130-dev/modelgen/O/gnucap-modelgen' 
(x86_64)
Process 12570 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x2c)
    frame #0: 0x0000000100385a22 libgnucap.dylib`CARD::~CARD() [inlined] 
std::__1::less<void const*>::operator(this=<unavailable>, 
__x=0x000000000000002c, __y=<unavailable>)(void const* const&, void const* 
const&) const at operations.h:487:21 [opt]
   484  #endif
   485      _LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
   486      bool operator()(const _Tp& __x, const _Tp& __y) const
-> 487          {return __x < __y;}
   488  };
   489  
   490  #if _LIBCPP_STD_VER > 11
Target 0: (gnucap-modelgen) stopped.
warning: libgnucap.dylib was compiled with optimization - stepping may behave 
oddly; variables may not be available.


One is in e_card.cc

void CARD::purge()
{
  // this line below
  // _attribs.erase(reinterpret_cast<bool*>(this)-net_nodes(), 
reinterpret_cast<bool*>(this)+param_count()); 
   CKT_BASE::purge();
}

Another is in e_base.cc

CKT_BASE::~CKT_BASE()
{ 
  trace1("~CKT_BASE", _probes);
  if (_probes == 0) {
  }else if (!_probe_lists) {untested();
  }else if (!_sim) {untested();
  }else{
    _probe_lists->purge(this);
  }
  trace1("", _probes);
  assert(_probes==0);
  /* This entire block causes the segfault
  if (_attribs.count(this) > 0) {untested();
    _attribs.erase(this, this);
  }else{
  }
  assert(_attribs.count(this)==0); */
}

It seems accessing _attribs causes the segfault. As I am no expert in
C++ I'm not certain if that's because a GCC specific feature has been
used in the new code.

If you need more information to trouble shoot, please let me know.

---
LdBeth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]