(lldb) stop reason = EXC_BAD_ACCESS

[yossarin]

Upon starting erlkaf in the lldb I sometimes get random Segmentation faluts.

When I run the beam machine with lldb this is where I get stopped over and over again.

* thread #5, name = '1_scheduler', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000010033ad80 beam.debug.smp`erts_dlc_create_lock(dlc=0x000000014383e078, name=0x0000000000000000) at erl_dyn_lock_check.c:170:5
   167 	    erts_aint_t i, n = erts_atomic_read_nob(&n_lock_types);
   168 	    int name_len;
   169 	
-> 170 	    for (i = 0; name[i]; i++) {
   171 	        if (name[i] == '[')
   172 	            break;
   173 	    }
Target 0: (beam.debug.smp) stopped.

When I do a backtrace:

(lldb) bt
* thread #5, name = '1_scheduler', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010033ad80 beam.debug.smp`erts_dlc_create_lock(dlc=0x000000014383e078, name=0x0000000000000000) at erl_dyn_lock_check.c:170:5
    frame #1: 0x0000000100384549 beam.debug.smp`erl_drv_mutex_create(name=0x0000000000000000) at erl_drv_thread.c:171:5
    frame #2: 0x00000001003a6325 beam.debug.smp`enif_mutex_create(name=0x0000000000000000) at erl_nif.c:2131:53
    frame #3: 0x00000001484615c7 erlkaf_nif.so`QueueCallbacksDispatcher::QueueCallbacksDispatcher() [inlined] CriticalSection::CriticalSection(this=0x0000000100d18880) at critical_section.h:11:34 [opt]
    frame #4: 0x00000001484615c0 erlkaf_nif.so`QueueCallbacksDispatcher::QueueCallbacksDispatcher() [inlined] CriticalSection::CriticalSection(this=0x0000000100d18880) at critical_section.h:11 [opt]
    frame #5: 0x00000001484615c0 erlkaf_nif.so`QueueCallbacksDispatcher::QueueCallbacksDispatcher(this=0x0000000100d18880) at queuecallbacksdispatcher.cc:11 [opt]
    frame #6: 0x0000000148464407 erlkaf_nif.so`on_nif_load(env=<unavailable>, priv_data=0x000000014383c4e0, load_info=<unavailable>) at erlkaf_nif.cc:56:27 [opt]
    frame #7: 0x00000001003acb6f beam.debug.smp`erts_load_nif(c_p=0x00000001438b0268, I=0x000000014981e8b0, filename=0x14364c169 "/Users/y/sportening/we-api-user-account/_build/test/lib/erlkaf/priv/erlkaf_nif", args=0xf 0) at erl_nif.c:4653:16
    frame #8: 0x0000000100032056 beam.debug.smp`beam_jit_load_nif(c_p=0x00000001438b0268, I=0x000000014981e8b0, reg=0x0000700008932dc0) at beam_jit_common.c:154:18

I do not understand how this can be correct, passing NULL to the enif_mutex_create function:

# critical_section.h
CriticalSection() { mutex_ = enif_mutex_create(NULL);}

Name becomes a NULL pointer (name=0x0000000000000000) and obviously accessing name[i] fails

[silviucpp]

I'm using the library in lot of projects and never faced the problem you are getting. Sending name as NULL is totally correct as it's not required.

enif_mutex_create it's calling erl_drv_mutex_create and if you look into source code name being NULL is valid.

https://github.com/erlang/otp/blob/40922798411c2d23ee8a99456f96d6637c62b762/erts/emulator/beam/erl_drv_thread.c#L152

Please come up with more details on : what OS, what VM and some config /code you are using to replicate the problem

Silviu

[silviucpp]

I see the problem. You are running the VM compiled in DEBUG mode. In debug mode seems the VM is using ERTS_ENABLE_LOCK_CHECK which cause this call to be executed (which is not in release mode):

#ifdef ERTS_DYN_LOCK_CHECK
erts_dlc_create_lock(&dmtx->dlc, name);
#endif

And here seems a VM bug because they are using variable name instead dmtx->name which in case name is NULL it's value is equal with no_name which basically is equal with string "unknown".

Yes simple fix will be to put a valid name there. But probably will be nice and fair will be to open also a bug to OTP team

[silviucpp]

Please test last master I provided a name for when creating a mutex to bypass this. Let me know if it's ok with this change

[silviucpp]

Please reopen if you still can replicate on master.

[yossarin]

I confirm, it works now, thank you!