Closed Bug 966154 Opened 6 years ago Closed 6 years ago

(HTC One 4.4, CodefireX) - java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__fork" referenced by "libmozglue.so"

Categories

(Firefox for Android :: General, defect, critical)

27 Branch
ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Firefox 32
Tracking Status
firefox26 --- wontfix
firefox27 --- wontfix
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
firefox32 --- fixed
b2g-v1.4 --- fixed
fennec 30+ ---

People

(Reporter: randomdude786, Assigned: snorp)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Linux; Android 4.4.3; One Build/JZO54K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.99 Mobile Safari/537.36

Steps to reproduce:

Tapped icon to launch app


Actual results:

Received a "Firefox has stopped working" screen. Firefox did not open. 


Expected results:

Firefox should have opened.
Can you attach a logcat from your device when capturing your attempt to launch the browser and attach it to this bug?
How would I go about doing so? (In reply to Aaron Train [:aaronmt] from comment #1)
> Can you attach a logcat from your device when capturing your attempt to
> launch the browser and attach it to this bug?
Attached file Logcat
I think I attached the contents of a logcst successfully. Please let me know if more info is needed. (In reply to Aaron Train [:aaronmt] from comment #1)
> Can you attach a logcat from your device when capturing your attempt to
> launch the browser and attach it to this bug?
That is excellent thanks.

01-30 23:39:38.961   661   956 I ActivityManager: Start proc org.mozilla.firefox_beta for activity org.mozilla.firefox_beta/.App: pid=30564 uid=10127 gids={50127, 3003, 1028, 1015}
01-30 23:39:39.071 30564 30564 D dalvikvm: Trying to load lib /data/app-lib/org.mozilla.firefox_beta-1/libmozglue.so 0x423de858
01-30 23:39:39.071 30564 30564 E dalvikvm: dlopen("/data/app-lib/org.mozilla.firefox_beta-1/libmozglue.so") failed: dlopen failed: cannot locate symbol "__fork" referenced by "libmozglue.so"...
01-30 23:39:39.071 30564 30564 D AndroidRuntime: Shutting down VM
01-30 23:39:39.071 30564 30564 W dalvikvm: threadid=1: thread exiting with uncaught exception (group=0x41f1b788)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: FATAL EXCEPTION: main
01-30 23:39:39.071 30564 30564 E AndroidRuntime: Process: org.mozilla.firefox_beta, PID: 30564
01-30 23:39:39.071 30564 30564 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__fork" referenced by "libmozglue.so"...
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at java.lang.Runtime.loadLibrary(Runtime.java:364)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at java.lang.System.loadLibrary(System.java:579)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at org.mozilla.gecko.mozglue.GeckoLoader.loadMozGlue(GeckoLoader.java:253)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at org.mozilla.gecko.GeckoApplication.onCreate(GeckoApplication.java:101)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1007)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4415)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:547)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(Native Method)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.app.ActivityThread.access$1500(ActivityThread.java:145)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1273)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:102)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:136)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:5088)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at java.lang.reflect.Method.invokeNative(Native Method)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Method.java:515)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:772)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:126)
01-30 23:39:39.071 30564 30564 E AndroidRuntime: 	at dalvik.system.NativeStart.main(Native Method)
01-30 23:39:39.081   661   968 W ActivityManager:   Force finishing activity org.mozilla.firefox_beta/.App
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
OS: Linux → Android
Hardware: Other → ARM
Which custom rom is this?
(In reply to Aaron Train [:aaronmt] from comment #6)
> Which custom rom is this?

CodefireX. Attempting to attach screenshot of my About Phone screen in attachments.
(In reply to Random Düde from comment #7)
> (In reply to Aaron Train [:aaronmt] from comment #6)
> > Which custom rom is this?
> 
> CodefireX. Attempting to attach screenshot of my About Phone screen in
> attachments.

About screen of phone with ROM name and Android version http://imgur.com/sqJru6T
Summary: Firefox (both Beta and regular) fail to open on HTC One running Android 4.4.3.2. Upon attempt to launch browser, user is greeted with a "Firefox has stopped" message. → (HTC One 4.4, CodefireX) - java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__fork" referenced by "libmozglue.so"
Looks like they fuck around with syscalls, and their band-aid patch either doesn't work or got dropped.

http://review.codefirex.com/D21
Reporter, best to use a different ROM for time being.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Thanks guys. I'll look into another ROM for the time being.
this bug should be reopened and fixed. __fork is gone from AOSP and will be gone in a future Android release.

__fork was removed in this change: https://android.googlesource.com/platform/bionic/+/1195207%5E%21/#F1

yes. you should assume that anything that starts "__" is a private
implementation detail. sometimes these things change behavior,
sometimes they go away. (for LP64 i'm going to try to make sure such
symbols actually have hidden visibility.)

looks like the mozilla bug that caused you to introduce this bug was:
https://bugzilla.mozilla.org/show_bug.cgi?id=799805

really you should be using different code for old Android releases
and just using fork on newer releases. i worry about your assumption
that only the posix timers need the atfork support --- that's another
implementation detail that can and does change. (pretty much anywhere
the c library has a data structure protected by a lock we're likely to
need an atfork handler.)

i don't think you should be doing this at all -- especially not on newer
release -- but you have a few choices for fixing this. the first one,
which you shouldn't do because it just moves you over to another private
symbol, is what i did internally:

-  int result = __fork();
+  int result = __clone(SIGCHLD, NULL, NULL, NULL, NULL);

the second, which you also shouldn't do because kernels for new
architectures (like aarch64) don't have a fork syscall, is:

  syscall(SYS_fork)

the third, which is probably the best choice (other than stopping this
madness :-) ), is:

  syscall(SYS_clone, SIGCHLD, NULL, NULL, NULL, NULL)
Status: RESOLVED → REOPENED
tracking-fennec: --- → ?
Resolution: INVALID → ---
(In reply to enh from comment #12)
> this bug should be reopened and fixed. __fork is gone from AOSP and will be
> gone in a future Android release.
> 
> __fork was removed in this change:
> https://android.googlesource.com/platform/bionic/+/1195207%5E%21/#F1

Thanks for the heads up! We'll certainly stop using it if we can.

> 
> yes. you should assume that anything that starts "__" is a private
> implementation detail. sometimes these things change behavior,
> sometimes they go away. (for LP64 i'm going to try to make sure such
> symbols actually have hidden visibility.)
> 
> looks like the mozilla bug that caused you to introduce this bug was:
> https://bugzilla.mozilla.org/show_bug.cgi?id=799805
> 
> really you should be using different code for old Android releases
> and just using fork on newer releases.

We have one APK for all Android versions, so unless there is some runtime detection that doesn't rely on Dalvik, I think we'll have to make due. Right now we support Android 2.2+.

> i worry about your assumption
> that only the posix timers need the atfork support --- that's another
> implementation detail that can and does change. (pretty much anywhere
> the c library has a data structure protected by a lock we're likely to
> need an atfork handler.)

I think the folks on that bug understand that, they were just trying to get b2g 1.0 working. With all b2g builds now being built on a modern (ish?) bionic, they can probably just stop wrapping pthread_atfork. We're still hosed on Android, though.

> 
> i don't think you should be doing this at all -- especially not on newer
> release -- but you have a few choices for fixing this. the first one,
> which you shouldn't do because it just moves you over to another private
> symbol, is what i did internally:
> 
> -  int result = __fork();
> +  int result = __clone(SIGCHLD, NULL, NULL, NULL, NULL);
> 
> the second, which you also shouldn't do because kernels for new
> architectures (like aarch64) don't have a fork syscall, is:
> 
>   syscall(SYS_fork)
> 
> the third, which is probably the best choice (other than stopping this
> madness :-) ), is:
> 
>   syscall(SYS_clone, SIGCHLD, NULL, NULL, NULL, NULL)

Thanks, that looks reasonable. If you have any suggestions for handling multiple bionic versions, that would be helpful too.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #13)
> I think the folks on that bug understand that, they were just trying to get
> b2g 1.0 working. With all b2g builds now being built on a modern (ish?)
> bionic, they can probably just stop wrapping pthread_atfork. We're still
> hosed on Android, though.
> 

Yeah, B2G doesn't use this hack anymore on JB and up.
Attachment #8412860 - Flags: review?(mwu) → review?(mh+mozilla)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #13)
> Thanks, that looks reasonable. If you have any suggestions for handling
> multiple bionic versions, that would be helpful too.

the usual way would be to pass the android.os.Build.VERSION.SDK_INT down to the code you use to initialize your native code. if you do this in the Java static initializer that calls System.loadLibrary, you can ensure that no one's calling your native methods before this is set. (equivalently, if you have a JNI_OnLoad you could have that call up to read android.os.Build.VERSION.SDK_INT.)

i have thought about having a global variable (or two) in bionic that hold both the system's version number and the current app's "targetSdkVersion" -- so that any time we need to fix a bug where fixing the bug breaks a lot of existing code that assumes the broken behavior, we can have run-time checks in bionic to decide which behavior to exhibit -- but there's no such thing at the moment, and since android.os.Build has been public API since forever, apps are probably better off using that anyway.
Comment on attachment 8412860 [details] [diff] [review]
Don't use __fork, it's gone in newer bionic

Review of attachment 8412860 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm.
Attachment #8412860 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/dbd7271872f7
Assignee: nobody → snorp
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
James - What's the desire to uplift? What's the risk? We should consider getting this all the way to Beta (Fx30)
Flags: needinfo?(snorp)
(In reply to Mark Finkle (:mfinkle) from comment #20)
> James - What's the desire to uplift? What's the risk? We should consider
> getting this all the way to Beta (Fx30)

Yeah, we should get it into Beta. It's pretty low risk, IMO, and we want to be ready for the next Android version.
Flags: needinfo?(snorp)
Comment on attachment 8412860 [details] [diff] [review]
Don't use __fork, it's gone in newer bionic

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Changes in Android
User impact if declined: Crashes on newer Android versions
Testing completed (on m-c, etc.): m-c for one day
Risk to taking this patch (and alternatives if risky): Low
String or IDL/UUID changes made by this patch: None
Attachment #8412860 - Flags: approval-mozilla-beta?
Attachment #8412860 - Flags: approval-mozilla-aurora?
Attachment #8412860 - Flags: feedback?
Attachment #8412860 - Flags: approval-mozilla-beta?
Attachment #8412860 - Flags: approval-mozilla-beta+
Attachment #8412860 - Flags: approval-mozilla-aurora?
Attachment #8412860 - Flags: approval-mozilla-aurora+
tracking-fennec: ? → 30+
Comment on attachment 8412860 [details] [diff] [review]
Don't use __fork, it's gone in newer bionic

Big fingers. Removing the unwanted feedback flag.
Attachment #8412860 - Flags: feedback?
You need to log in before you can comment on or make changes to this bug.