Crash when using dlopen(NULL, ...)

UNCONFIRMED
Unassigned

Status

()

UNCONFIRMED
7 years ago
5 years ago

People

(Reporter: nuskooler, Unassigned)

Tracking

Trunk
All
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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
(Reporter)

Updated

7 years ago
See Also: → bug 647288
Summary: Crash loading binary components bigger than 4KB → Crash loading binary components bigger than 4KB via dlopen
> 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.
(Reporter)

Comment 2

7 years ago
Created attachment 548332 [details] [diff] [review]
Illustration of dlopen() causing crash
(Reporter)

Comment 3

7 years ago
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.
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.
Summary: Crash loading binary components bigger than 4KB via dlopen → Crash when using dlopen(NULL, ...)
(Reporter)

Comment 5

7 years ago
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!)
(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.
You need to log in before you can comment on or make changes to this bug.