__dl_get_mappable_length(dlopen("libmozglue.so", ...)) fails

NEW
Assigned to

Status

()

5 years ago
5 years ago

People

(Reporter: jseward, Assigned: glandium)

Tracking

Trunk
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
ReadSymbolData_ANDROID() in local_debug_info_symbolizer.cc contains a
kludge that special-cases the path for libmozglue.so, when reading
unwind info.  This has an unfortunate side effect of causing the subsequent
dlclose to run finalisers even though the object is already loaded
(presumably under a different path name, though).

Removing the kludge per MH's instructions causes  __dl_get_mappable_length
to fail, though:

E/Profiler(10659): 2013-06-27 07:22:18: local_debug_info_symbolizer.cc:128: INFO: ReadSymbolData_APK: Unable to get size for ELF file 'libmozglue.so'

hence symbol loading fails for this file.
(Reporter)

Comment 1

5 years ago
If this is problematic to fix, another possibility (at least from the
SPS side) is to change the faulty.lib interface, so that the handle
to be given to __dl_get_mappable_length and __dl_mmap is obtained not
from dlopen but from some other function (offered by faulty.lib) that
merely produces a handle but does not process (relocate, run initialisers
and finalisers) the underlying file in any way.  Just treats it as an
uninterpreted bunch of bytes.

That would also make the interface more general, in that it would be
possible to use it to access any file in the apk rather than just 
files that can be dlopened.
(Assignee)

Comment 2

5 years ago
That would use more memory. Although in your case you're not mapping things that would be mapped by the linker, and you're unmapping quickly, too.
But I'm sick of doing hacks on top of hacks on top of hacks for the sake of fixing things quickly.

Also, it wouldn't solve the problem with system libraries that you don't know where they are.
You need to log in before you can comment on or make changes to this bug.