pnoltes commented on PR #657: URL: https://github.com/apache/celix/pull/657#issuecomment-1734215064
> Whew! I have fixed these leaks lurking in our tests for a very long time. Note that to debug such issue, linux ASLR should be turned off by `echo 0 | sudo tee /proc/sys/kernel/randomize_va_space` so that we can ask debugger which shared object these leakers reported by ASAN belong to at a appropriate time when the offending shared object is still in address space. > > IMHO, we should **warn our users very loudly in our documentation** of these shared object initialization/de-initialization pitfalls. Also, it should be pointed out to our users that the standard place to deal with these is a customized launcher. Last but not the lease, `libffi` is very special in that there is no way to clean its global allocation (correct me if I were wrong), thus it should be kept in address space if possible (by linking it to the executable). Keep loading and unloading libffi will wreak a havoc. > > WDYT? @pnoltes @rlenferink I agree, both in warning for init/deinit library requirements in the documentation and that this should be solved in a custom launcher. An alternative to consider is to provided init/deinit libs that use the `__attribute__((constructor))` / `__attribute__((destructor))` to initialize / deinitialize libraries. These library then needs to be linked against the generated launcher. But IMO it is clearer to do this in the launcher. Maybe some effort can be made to make it possible that a custom launcher can easily use the `PROPERTIES` provided in the `add_celix_container` (as is currently done in the generated main.c/main.cc file). -- 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
