673937 - Crash when using dlopen(NULL, ...)

Status: RESOLVED INVALID

(GeckoView :: General, defect)

Description

[Bryan Ashby]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122 Safari/534.30

Steps to reproduce:

Call dlopen() or dlsym() from a thread using the specialized Android/Fennec linker. This seems to happen when calling dlopen("libWhatever", ...) for a specific library or dlopen(NULL, ...) attempting to fetch the currently loaded table.

I have the patches mentioned in "Bug 647288 - Crash loading binary components bigger than 4KB"


Actual results:

Crashes


Expected results:

dlopen(), dlsym(), etc. should succeed

Comment 1

[Mike Hommey [:glandium]]

> when calling dlopen("libWhatever", ...) for a specific library

That really is what is fixed by bug 647288. Are you really sure you have the patch applied?
What happens if you install the extension from http://ted.mielczarek.org/mozilla/as.html ? (just click on the link). With Nightly and latest Aurora, it shouldn't crash. With FF5 and FF6, it should crash. If you really applied the patch, it shouldn't crash.

Comment 2

[Bryan Ashby]

Attachment: Illustration of dlopen() causing crash

Comment 3

[Bryan Ashby]

I've added a patch that illustrates the problem. This is for demonstration only, I'm not just randomly calling dlopen() in HttpBaseChannel.

With the patch, I crash without any stack trace in logcat. In my project, I call dlopen() to attempt and fetch a .so already loaded in the process. The latter will work in some threads and crashes in others (plain HTML being processed seems to go through a different thread than for e.g. chunked/gzipped; the plain HTML thread is OK; chunked/gzipped crashes). When specifying my library in dlopen() I do get a call stack but it seems to be garbage.

Some additional details:
- To validate I have the patch, here are my linker.h and .c: http://pastebin.mozilla.org/1281343, http://pastebin.mozilla.org/1281344

- Here is a non-stripped APK with dlopen(NULL, RTLD_LAZY) (Pristine trunk checkout + whats in the patch): http://www.megaupload.com/?d=Z6LZ96AT

I can provide a stack trace if it would be helpful, but only for my version of Fennec attempting to load my library due to the issues described above.

Comment 4

[Mike Hommey [:glandium]]

The crash occurs in the libc, called from find_library(). find_library() itself is most likely called from __wrap_dlopen (the other calls happen when treating a library's PT_DYNAMIC segment so they're unlikely to be related). So here is what happens:
you call dlopen(NULL, ...) which calls __wrap_dlopen(NULL, ...), which calls find_library(NULL), which calls strrchr(NULL, '/')... kaboom.

In short, dlopen(NULL, ...) is not properly supported by our linker.

Comment 5

[Bryan Ashby]

Please see Comment #3: The dlopen(NULL, ...) is only to demonstrate the issue. I am calling dlopen("myLibrary.so", RTLD_LAZY) where myLibrary.so. In this case, I get a crash + stack trace; In both cases, I only get a crash when the [forked] process (e.g. plugin-container) has been 'injected' by the custom linker.

I can provide a non-stripped APK of the version using my library if that would help as I do not know a way to debug it (since I have to turn off the custom linker to use the NDK GCC!)

Comment 6

[Mike Hommey [:glandium]]

(In reply to comment #5)
> Please see Comment #3: The dlopen(NULL, ...) is only to demonstrate the
> issue. I am calling dlopen("myLibrary.so", RTLD_LAZY) where myLibrary.so.

Then you see two different bugs.

> In
> this case, I get a crash + stack trace; In both cases, I only get a crash
> when the [forked] process (e.g. plugin-container) has been 'injected' by the
> custom linker.
> 
> I can provide a non-stripped APK of the version using my library if that
> would help as I do not know a way to debug it (since I have to turn off the
> custom linker to use the NDK GCC!)

Please do.

Comment 7

[David Lawrence [:dkl]]

Moving all open Core::Widget: Android bugs to GeckoView::General (then the triage owner of GeckoView will decide which ones are valuable and which ones should be closed).

Comment 8

[Emily Toop (:fluffyemily)]

Not applicable to GeckoView