Dynamic library loading (dlopen()) from within packages returns ZX_ERR_NOT_FOUND |
|||
Issue description
It appears that dlopen() doesn't work from packages just yet.
dlopen("libosmesa.so") fails with ZX_ERR_NOT_FOUND:
[3:364727959:0227/233158.953765:977193023:ERROR:gl_implementation.cc(292)] Failed to load libosmesa.so: Error loading shared library libosmesa.so: ZX_ERR_NOT_FOUND
[3:364727959:0227/233158.953866:977193122:FATAL:gl_surface_test_support.cc(81)] Check failed: init::InitializeGLOneOffImplementation( impl, fallback_to_software_gl, gpu_service_logging, disable_gl_drawing, init_extensions).
#00: StackTrace at ../../base/debug/stack_trace_fuchsia.cc:174
#01: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::endl<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) at ../../buildtools/third_party/libc++/trunk/include/ostream:1001
(inlined by) std::__1::basic_ostream<char, std::__1::char_traits<char> >::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >& (*)(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)) at ../../buildtools/third_party/libc++/trunk/include/ostream:195
(inlined by) ~LogMessage at ../../base/logging.cc:582
#02: ~__vector_base at ../../buildtools/third_party/libc++/trunk/include/vector:439
(inlined by) gl::(anonymous namespace)::InitializeOneOffHelper(bool) at ../../ui/gl/test/gl_surface_test_support.cc:82
#03: content::ContentTestSuite::Initialize() at ../../content/test/content_test_suite.cc:90
#04: base::TestSuite::Run() at ../../base/test/test_suite.cc:261
#05: base::RepeatingCallback<int ()>::Run() const & at ../../base/callback.h:124
(inlined by) base::(anonymous namespace)::LaunchUnitTestsInternal(base::RepeatingCallback<int ()> const&, unsigned long, int, bool, base::RepeatingCallback<void ()> const&) at ../../base/test/launcher/unit_test_launcher.cc:225
#06: base::LaunchUnitTests(int, char**, base::RepeatingCallback<int ()> const&) at ../../base/test/launcher/unit_test_launcher.cc:576
#07: main at ../../content/test/run_all_unittests.cc:20
#08: pc 0x551a047bd3ae (libc.so,0x133ae)
I confirmed that the library exists by walking through /pkg via FileEnumerator (aka readdir):
[3:364727959:0227/233158.950844:977190103:ERROR:gl_implementation_osmesa.cc(37)] Contents of pkg:
[3:364727959:0227/233158.953182:977192438:ERROR:gl_implementation_osmesa.cc(46)] /pkg/lib/libosmesa.so
I have tried loading other variants of the path, including "/pkg/lib/libosmesa.so", and "lib/libosmesa.so". Nothing works. It might be an issue in Chrome or it might be in Fuchsia.
,
Feb 28 2018
The next investigation step would be to add logging to Fuchsia to see what's providing the loader service. We want it to be "appmgr". If it's "fshost", which serves libraries from /system/lib, then it's probably a bug in appmgr giving our process the wrong loader service.
,
Feb 28 2018
I'm not sure if it's different for packages, but one upstream bug for this is ZX-1619. We could probably make our dlopen wrapper call dlopen_vmo (which takes a vmo of the file) as I'm assuming the regular file open would find the .so. Crashpad currently copies all .so files to /boot/lib during deploy, which is one place the loader can find .so files (as long as you don't dlopen with a path).
,
Feb 28 2018
(Oh sorry, you likely knew all that already, I didn't know that we were already trying to supply a different loader.)
,
Apr 19 2018
|
|||
►
Sign in to add a comment |
|||
Comment 1 by kmarshall@chromium.org
, Feb 27 2018