Sometimes I met the following failure.

2019-02-15 07:00:34,309 - oe-selftest - INFO - ======================================================================
2019-02-15 07:00:34,310 - oe-selftest - INFO - FAIL: test_bmap_long (wic.Wic2)
2019-02-15 07:00:34,310 - oe-selftest - INFO - ----------------------------------------------------------------------
2019-02-15 07:00:34,310 - oe-selftest - INFO - Traceback (most recent call last):
  File "/buildarea5/chenqi/SWAT/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
    return func(*args, **kwargs)
  File "/buildarea5/chenqi/SWAT/poky/meta/lib/oeqa/selftest/cases/wic.py", line 540, in test_bmap_long
    runCmd(cmd)
  File "/buildarea5/chenqi/SWAT/poky/meta/lib/oeqa/utils/commands.py", line 194, in runCmd
    raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
AssertionError: Command 'wic create wictestdisk -e core-image-minimal --bmap -o /buildarea5/chenqi/SWAT/poky/build-selftest/wic-tmp/' returned non-zero exit status 1:
INFO: Building wic-tools...

ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/buildarea5/chenqi/SWAT/poky/build-selftest/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 28374 at 2019-02-15 06:22:12.487122 ---
Entering server connection loop
Accepting [<socket.socket fd=7, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0, laddr=bitbake.sock>] ([])
[snip]
Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion `_dl_debug_initialize (0, args->nsid)->r_state == RT_CONSISTENT' failed!

The key error message is this dl-open.c assertion failure.

Please see some additional information here. Hope it would be helpful.
I googled and found the following commit in glibc:
commit ccdb048df457d581f6ac7ede8b0c7a593a891dfa
Author: Carlos O'Donell <carlos@systemhalted.org>
Date:   Wed Jan 21 01:51:10 2015 -0500

    Fix recursive dlopen.
    
    The ability to recursively call dlopen is useful for malloc
    implementations that wish to load other dynamic modules that
    implement reentrant/AS-safe functions to use in their own
    implementation.
    
    Given that a user malloc implementation may be called by an
    ongoing dlopen to allocate memory the user malloc
    implementation interrupts dlopen and if it calls dlopen again
    that's a reentrant call.
    
    This patch fixes the issues with the ld.so.cache mapping
    and the _r_debug assertion which prevent this from working
    as expected.
    
    See:
    https://sourceware.org/ml/libc-alpha/2014-12/msg00446.html

The commit seems related. But our glibc has included this commit. And we are using glibc from uninative-tarball.

The current glibc's codes still have a _dl_debug_initialize assertion in dl_open_worker.
  /* It was already open.  */
  if (__glibc_unlikely (new->l_searchlist.r_list != NULL))
    {
      /* Let the user know about the opencount.  */
      if (__glibc_unlikely (GLRO(dl_debug_mask) & DL_DEBUG_FILES))
        _dl_debug_printf ("opening file=%s [%lu]; direct_opencount=%u\n\n",
                          new->l_name, new->l_ns, new->l_direct_opencount);

      /* If the user requested the object to be in the global namespace
         but it is not so far, add it now.  */
      if ((mode & RTLD_GLOBAL) && new->l_global == 0)
        (void) add_to_global (new);

      assert (_dl_debug_initialize (0, args->nsid)->r_state == RT_CONSISTENT);

      return;
    }