New issue
Advanced search Search tips

Issue 817130 link

Starred by 2 users

Issue metadata

Status: Verified
Owner: ----
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Fuchsia
Pri: 1
Type: Bug

Blocking:
issue 798851



Sign in to add a comment

Dynamic library loading (dlopen()) from within packages returns ZX_ERR_NOT_FOUND

Project Member Reported by kmarshall@chromium.org, Feb 27 2018

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.
 
Blocking: 798851
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.
Cc: scottmg@chromium.org
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).
(Oh sorry, you likely knew all that already, I didn't know that we were already trying to supply a different loader.)
Status: Verified (was: Untriaged)

Sign in to add a comment