pnoltes commented on PR #588: URL: https://github.com/apache/celix/pull/588#issuecomment-1633210986
> The crash of `CelixFrameworkUtilsErrorInjectionTestSuite.testIsBundleUrlValid` is very interesting. > > https://github.com/apache/celix/actions/runs/5525141973/jobs/10078372242 > > ```shell > [2023-07-11T21:47:10] AddressSanitizer[ error] [celix_framework] [celix_framework_utils_resolveFileBundleUrl:96] Failed(No such file or directory) to resolve bundle location 'non-existing.zip', taking into account the cwd and Celix bundle path 'bundles'. > :DEADLYSIGNAL > ================================================================= > [2023-07-11T21:47:10] [ error] [celix_framework] [celix_framework_utils_locateEmbeddedBundle:147] Framework exception(0x11177): "Failed to locate embedded bundle symbols for bundle 'embedded://simple_test_bundle1'."; > Cause: Inject dl error > [2023-07-11T21:47:10] [ error] [celix_framework] [celix_framework_utils_locateEmbeddedBundle:147] Cannot allocate memory(0xc): "Failed to locate embedded bundle symbols for bundle 'embedded://simple_test_bundle1'."; > Cause: Cannot allocate memory > [2023-07-11T21:47:10] [ error] [celix_framework] [celix_framework_utils_locateEmbeddedBundle:147] Cannot allocate memory(0xc): "Failed to locate embedded bundle symbols for bundle 'embedded://simple_test_bundle1'."; > Cause: Cannot allocate memory > ==35135==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f1cd907e839 bp 0x7f1cd3cfe9c0 sp 0x7f1cd3cfe128 T13) > ==35135==The signal is caused by a READ memory access. > ==35135==Hint: address points to the zero page. > #0 0x7f1cd907e838 in __sanitizer::internal_strnlen(char const*, unsigned long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_libc.cc:212 > #1 0x7f1cd8fce234 in __interceptor_strndup ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:379 > #2 0x559452ee5d88 in serviceRegistration_createInternal /home/runner/work/celix/celix/libs/framework/src/service_registration.c:54 > #3 0x559452ee5a6e in serviceRegistration_create /home/runner/work/celix/celix/libs/framework/src/service_registration.c:35 > #4 0x559452ee86b1 in serviceRegistry_registerServiceInternal /home/runner/work/celix/celix/libs/framework/src/service_registry.c:194 > #5 0x559452eec2f4 in celix_serviceRegistry_registerService /home/runner/work/celix/celix/libs/framework/src/service_registry.c:734 > #6 0x559452ed07ed in fw_handleEventRequest /home/runner/work/celix/celix/libs/framework/src/framework.c:1374 > #7 0x559452ed1225 in fw_handleEvents /home/runner/work/celix/celix/libs/framework/src/framework.c:1432 > #8 0x559452ed28a9 in fw_eventDispatcher /home/runner/work/celix/celix/libs/framework/src/framework.c:1597 > #9 0x7f1cd8414608 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8608) > #10 0x7f1cd7fed132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132) > ``` > > It was caused by `celix_utils_strdup` failure in one of `celix_framework_registerServiceAsync` calls introduced by this PR. > > Of course, `CELIX_EI_UNKNOWN_CALLER` should be avoided at the first place. This crash tells us more: an unexpected service registration together with corresponding events process could interact with tests more subtly than we thought. > > If we remove "components.ready" for now, adding `celix_framework_waitForEmptyEventQueue` after a framework instance is created should protect us from most hazards in tests. In production, we shall never do that since it will hurt startup speed. > > If we keep "components.ready", this will be more difficult to fix. Yeah indeed interesting and good that you already analyzed the root cause. I did introduce a "CELIX_FRAMEWORK_CONDITION_SERVICES_ENABLED" config property so that the condition services can be disabled when testing. But this is a warning that we should be careful with timing sensitive actions in the framework, especially in combination with error injection test suites. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
