13182 2019-02-15 02:19:36 +0000 Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion xxx failed 2024-03-07 16:28:42 +0000 1 1 10 QA/Testing Functional (self) Testing oe-selftest 2.7 x86 Multiple RESOLVED OBSOLETE Medium+ normal Future 1 Qi.Chen unassigned jatedev randy.macleod --- --- Don't know oldest_to_newest 83013 0 Qi.Chen 2019-02-15 02:19:36 +0000 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; } 83062 1 randy.macleod 2019-02-21 15:38:50 +0000 Qi, we've left this defect with you. Can you summarize to the list and CC Khem who may have some ideas on how to proceed. Thanks. 85574 2 randy.macleod 2019-11-19 16:29:03 +0000 Seems to be a rare bug so it's not urgent. Set target to M3. 92675 3 jatedev 2022-02-25 15:37:20 +0000 I saw this error message on dunfell 3.1.3. It seemed to go away after I changed some build settings, so I did not investigate further. It was intermittent. The environment was ubuntu 16.04 under docker. 98426 4 randy.macleod 2024-03-07 16:28:42 +0000 Not seen in a long time. Obsolete.