Closed Bug 812647 Opened 12 years ago Closed 11 years ago

Startup error: Could not open any libc. (osfile_unix_allthreads.jsm)

Categories

(Toolkit Graveyard :: OS.File, defect)

x86
macOS
defect
Not set
critical

Tracking

(firefox19 fixed, firefox20 fixed)

RESOLVED FIXED
mozilla20
Tracking Status
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: metasieben, Assigned: dustin)

Details

Attachments

(1 file)

Yesterdays and todays Nightly show this error on start-up:

Timestamp: 11/16/12 11:08:46 PM
Error: Error: Could not open any libc.
Source File: resource://gre/modules/osfile/osfile_unix_allthreads.jsm
Line: 56

at that point it looks like startup is halted, session-restore doesn't bring up any tabs.

the build from the 13th works fine 1b0226622e94
wfm with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/19.0 Firefox/19.0
Built from http://hg.mozilla.org/mozilla-central/rev/58ebb638a7ea
Build platform i386-apple-darwin11.2.0

Or do you mean that "only" session restore fails and the browser is useable ?
well, the browser is _useable_, however there is no (working) back-button. history seems to be recorded fine.

but since i tried this with a newly created profile, i'm at a loss.


more information:

OpenGL LayerManager Initialized Succesfully.
Version: 2.1 APPLE-8.6.22
Vendor: Intel Inc.
Renderer: Intel HD Graphics 4000 OpenGL Engine
FBO Texture Target: TEXTURE_2D

Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64 i386 Macmini6,2 Darwin

--

after the libc-error:

Timestamp: 11/17/12 3:20:10 PM
Error: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: <TOP_LEVEL> :: line 11073"  data: no]
Source File: chrome://browser/content/tabbrowser.xml
Line: 388

Timestamp: 11/17/12 3:20:10 PM
Error: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: BrowserOnAboutPageLoad :: line 9483"  data: no]
Source File: chrome://browser/content/tabbrowser.xml
Line: 404
You use a 64bit OS while I'm using 32bit. That could make a difference.
Todays Nightly-debug build yields the same result:

1353173520586	Marionette	INFO	MarionetteComponent loaded
1353173520592	Marionette	INFO	marionette not enabled
++DOCSHELL 0x105847e70 == 1 [id = 1]
++DOMWINDOW == 1 (0x105852310) [serial = 1] [outer = 0x0]
++DOMWINDOW == 2 (0x100161fb0) [serial = 2] [outer = 0x105852290]
++DOCSHELL 0x10d512b60 == 2 [id = 2]
++DOMWINDOW == 3 (0x10d517030) [serial = 3] [outer = 0x0]
++DOMWINDOW == 4 (0x10d51aa60) [serial = 4] [outer = 0x10d516fb0]
++DOCSHELL 0x10de1c950 == 3 [id = 3]
++DOMWINDOW == 5 (0x10de1ef10) [serial = 5] [outer = 0x0]
++DOCSHELL 0x10de21760 == 4 [id = 4]
++DOMWINDOW == 6 (0x10de227b0) [serial = 6] [outer = 0x0]
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file ../../../../content/base/src/nsFrameLoader.cpp, line 387
++DOCSHELL 0x10ee5c080 == 5 [id = 5]
++DOMWINDOW == 7 (0x10ee5dba0) [serial = 7] [outer = 0x0]
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file ../../../../content/base/src/nsFrameLoader.cpp, line 387
++DOMWINDOW == 8 (0x10eec8f80) [serial = 8] [outer = 0x10ee5db20]
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file ../../../docshell/base/nsDocShell.cpp, line 8201
WARNING: NS_ENSURE_TRUE(mTextInputHandler) failed: file ../../../widget/cocoa/nsChildView.mm, line 3850
2012-11-17 18:32:01.590 firefox-bin[11365:707] invalid drawable
WARNING: Subdocument container has no frame: file ../../../layout/base/nsDocumentViewer.cpp, line 2400
++DOMWINDOW == 9 (0x11924a320) [serial = 9] [outer = 0x10de1ee90]
WARNING: Subdocument container has no frame: file ../../../layout/base/nsDocumentViewer.cpp, line 2400
++DOMWINDOW == 10 (0x119251e50) [serial = 10] [outer = 0x10de22730]
++DOMWINDOW == 11 (0x11925cbf0) [serial = 11] [outer = 0x10ee5db20]
JS Component Loader: ERROR resource://gre/modules/osfile/osfile_unix_allthreads.jsm:56
                     Error: Could not open any libc.
nsSessionStore could not be initialized: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: <TOP_LEVEL> :: line 8340"  data: no]
WARNING: NS_ENSURE_TRUE(mTextInputHandler) failed: file ../../../widget/cocoa/nsChildView.mm, line 3850
++DOMWINDOW == 12 (0x10eeee7e0) [serial = 12] [outer = 0x10ee5db20]
WARNING: attempt to modify an immutable nsStandardURL: file ../../../../netwerk/base/src/nsStandardURL.cpp, line 1210
WARNING: NS_ENSURE_TRUE(editor) failed: file ../../../../editor/libeditor/base/nsEditorCommands.cpp, line 549
--DOMWINDOW == 11 (0x10eec8f80) [serial = 8] [outer = 0x10ee5db20] [url = about:blank]
--DOMWINDOW == 10 (0x11925cbf0) [serial = 11] [outer = 0x10ee5db20] [url = about:blank]


code changed in osfile_unix_allthreads.jsm:

*working*
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/osfile/osfile_unix_allthreads.jsm?rev=04fa7fd1c588

*not working*
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/osfile/osfile_unix_allthreads.jsm
looks like i'm the only one having this problem.

latest nightly NOT working with new profile:
(1) Darwin Kernel Version 12.2.1: Thu Oct 18 16:32:48 PDT 2012; root:xnu-2050.20.9~2/RELEASE_X86_64 x86_64 i386 MacBookPro9,1 Darwin
(2) Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64 i386 Macmini6,2 Darwin

(1) 15" 2012 macbook pro without retina and OS X 10.8.2 (12C3006)
(2) 2012 macmini server with OS X 10.8.2 (12C2034)


however working here:
(*) Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 i386 Macmini5,2 Darwin
(*) 2011 macmini with OS X 10.8.2 (12C60)
Component: General → Session Restore
That's weird. As the name implies, it seems that OS.File cannot open libc. Could you try the following and tell me the results?

- Open a tab at about:about
- Open the Web console
- Input the following:
 Components.utils.import("resource://gre/modules/ctypes.jsm");
 ctypes.open("libSystem.B.dylib");
Component: Session Restore → OS.File
Product: Firefox → Toolkit
thx for looking into this.
here's the output:

({close:function close() {
    [native code]
}, declare:function declare() {
    [native code]
}})
just tried running todays Nightly on 10.8.1(12B2080), the version this macmini shipped with.

(*) Darwin admins-Mac-mini.local 12.1.1 Darwin Kernel Version 12.1.1: Fri Aug 10 16:12:30 PDT 2012; root:xnu-2050.15.57~1/RELEASE_X86_64 x86_64

still no luck.

moreover since yesterdays uplift i'm getting the same error on my work-machine running Aurora.
Found the problem!

As i'm using a case-sensitve filesystem the camelcase in the libc_candidates - array does matter.

libsystem.B.dylib != libSystem.B.dylib

although i'm not sure how this has happened, as i have always been running a case-sensitve filesystem. maybe apple changed something in the combo-update(10.8.2)
This has been affecting in secret all OS X users with case-sensitive filesystems, and is only coming to light due to sessionstore's move to using OS.File.
Attachment #695082 - Flags: review?(dteller)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 695082 [details] [diff] [review]
Fix OS.File's failure to find libc on case-sensitive OS X filesystems.

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

Wow, that's something I would never have guessed. Thanks for the patch.
Attachment #695082 - Flags: review?(dteller) → review+
David: Can you take care of the checkin ?
(In reply to Matthias Versen (Matti) from comment #13)
> David: Can you take care of the checkin ?

I haven't requested landing rights yet, so not yet.
>although i'm not sure how this has happened, as i have always been running a 
>case-sensitve filesystem. maybe apple changed something in the combo-update(10.8.2)

Yoric:
Shouldn't we search for both variants if Apple really changed something ?
Maybe we should check the filename on for example OSX10.6.
https://hg.mozilla.org/mozilla-central/rev/63f38c1cf053
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Is this going to be put in Firefox 19 as well?

It doesn't affect me, but someone contacted me and said my Add-on wasn't working and I saw this error in his logs.  He's using Firefox 19 beta 1, which also has the same incorrect line.

http://mxr.mozilla.org/mozilla-beta/source/toolkit/components/osfile/osfile_unix_allthreads.jsm#42
Comment on attachment 695082 [details] [diff] [review]
Fix OS.File's failure to find libc on case-sensitive OS X filesystems.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): OS.File for Unix, combined with unusual MacOS X file system.
User impact if declined: Some MacOS X users will have a buggy experience.
Testing completed (on m-c, etc.): The patch has been on m-c since December 23.
Risk to taking this patch (and alternatives if risky): I can't think of any risk.
String or UUID changes made by this patch: None.
Attachment #695082 - Flags: approval-mozilla-beta?
(In reply to Matthias Versen [:Matti] from comment #16)
> >although i'm not sure how this has happened, as i have always been running a 
> >case-sensitve filesystem. maybe apple changed something in the combo-update(10.8.2)
> 
> Yoric:
> Shouldn't we search for both variants if Apple really changed something ?
> Maybe we should check the filename on for example OSX10.6.

As far as I can tell, Apple hasn't changed the capitalization of the file, just the fact that some file systems are case sensitive. So just fixing capitalization should be fine.
Reopening for the lift to 19.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to David Rajchenbach Teller [:Yoric] from comment #19)
> Comment on attachment 695082 [details] [diff] [review]
> Fix OS.File's failure to find libc on case-sensitive OS X filesystems.
> 
> [Approval Request Comment]
> Bug caused by (feature/regressing bug #): OS.File for Unix, combined with
> unusual MacOS X file system.
> User impact if declined: Some MacOS X users will have a buggy experience.
> Testing completed (on m-c, etc.): The patch has been on m-c since December
> 23.
> Risk to taking this patch (and alternatives if risky): I can't think of any
> risk.
> String or UUID changes made by this patch: None.

I am curious to know what bug regressed this ? Are versions prior to Fx19 affected as well ?
Comment on attachment 695082 [details] [diff] [review]
Fix OS.File's failure to find libc on case-sensitive OS X filesystems.

Very low risk fix for case sensitive file systems, and seen in the wild. Approving for Beta.
Attachment #695082 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Keywords: checkin-needed
Whiteboard: [uplift to beta]
(In reply to bhavana bajaj [:bajaj] from comment #22)
> I am curious to know what bug regressed this ? Are versions prior to Fx19
> affected as well ?

I'm pretty sure that this issue has always been present. We only realized it once both the library became more widely used and entered in contact with a file system that does not match MacOS X's usual conventions.
(In reply to David Rajchenbach Teller [:Yoric] from comment #21)
> Reopening for the lift to 19.

Please don't, FWIW. I only look for resolved bugs to uplift.

https://hg.mozilla.org/releases/mozilla-beta/rev/c8758d96c354
Keywords: checkin-needed
Whiteboard: [uplift to beta]
ok
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → FIXED
Could not reproduce the error from comment 0 in 2012-11-16 Nightly for both Mac OS X 10.7.5 and 10.8.

I searched for the error in Firefox 19.0 beta 2 and beta 3 and I could not find any for both Mac OS X 10.7.5 and 10.8 using the 64 and 32 bit mode while opening the browsers from Terminal. 

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130123083802

Anything else I could help here or I can move this to verified for Firefox 19.0?
I'm sorry to report that this is exactly what's happening on m-c at the moment.

I will come back with a regression range...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Permanent, right on startup. It's hard to get a regression window, because I think I need to clobber each time (I checked out earlier revs from way back and that did not yield a working build :( )

Burped output:

System JS : ERROR resource://gre/modules/osfile/osfile_unix_allthreads.jsm:60
                     Error: Could not open system library: no libc
WARNING: Cannot create startup observer : service,@mozilla.org/datareporting/service;1: file /Users/mdeboer/Projects/mozilla-central/embedding/components/appstartup/src/nsAppStartupNotifier.cpp, line 81
*** ERROR addons.xpi: Failed to process extension changes at startup: Error: Could not open system library: no libc (resource://gre/modules/osfile/osfile_unix_allthreads.jsm:60)
System JS : ERROR resource://gre/modules/osfile/osfile_unix_allthreads.jsm:60
                     Error: Could not open system library: no libc
*************************
A coding exception was thrown and uncaught in a Task.

Full message: ReferenceError: OS is not defined
Full stack: _openFile@resource://gre/modules/services-common/log4moz.js:603
TaskImpl_run@resource://gre/modules/Task.jsm:233
TaskImpl@resource://gre/modules/Task.jsm:182
Task_spawn@resource://gre/modules/Task.jsm:152
@resource://gre/modules/services-common/log4moz.js:609
@resource://gre/modules/services-common/log4moz.js:614
@resource://gre/modules/services-common/log4moz.js:630
@resource://gre/modules/services-common/log4moz.js:670
App_append@resource://gre/modules/services-common/log4moz.js:443
@resource://gre/modules/services-common/log4moz.js:284
@resource://gre/modules/services-common/log4moz.js:298
MarionetteComponent@file:///Users/mdeboer/Projects/mozilla-central/obj-x86_64-apple-darwin12.5.0/dist/NightlyDebug.app/Contents/MacOS/components/marionettecomponent.js:45
@resource://gre/modules/XPCOMUtils.jsm:271

*************************
Alright, I found the cause of this issue.

I had a terminal window open in which I continuously (mach) build & run m-c. Then, while having the tab open, I upgraded Xcode to 5.0 (latest) and returned to the terminal window.

I pulled & updated m-c, another build & run resulted in the error I dumped in comment 30.

The fix: close your terminal window, open a new one and run your build. The error will be gone like magic. The problem seems to lie in updated env variables due to the libs update that comes with Xcode 5. Refreshing your profile seems to put everything back into order.

I hope ppl find this comment before they waste as many hours as I did on this. Bah.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Hi,

I'm hitting this issue with Firefox 26 on Linux/ia64 [1]. This is currently the only Firefox that can successfully be built on ia64 since ESR 10 (ESR 17 and ESR 24 all failed to build) [2].

With or without the patch proposed in attachment #695082 [details] [diff] [review], the result is the same for me. And I'm even less lucky than original reporter as I can't go beyond the homepage so can't try the debugging steps proposed in comment #6: opening a new tab in about:about and hitting Enter or click the Go button has no effect and the following is displayed in console:

A coding exception was thrown and uncaught in a Task.
Full message: TypeError: Services.search is undefined
Full stack: getShortcutOrURIAndPostData/<@chrome://browser/content/browser.js:10805
TaskImpl_run@resource://gre/modules/Task.jsm:233
TaskImpl@resource://gre/modules/Task.jsm:182
Task_spawn@resource://gre/modules/Task.jsm:152
getShortcutOrURIAndPostData@chrome://browser/content/browser.js:10792
_canonizeURL/<@chrome://browser/content/urlbarBindings.xml:408
TaskImpl_run@resource://gre/modules/Task.jsm:233
TaskImpl@resource://gre/modules/Task.jsm:182
Task_spawn@resource://gre/modules/Task.jsm:152
_canonizeURL@chrome://browser/content/urlbarBindings.xml:411
handleCommand/<@chrome://browser/content/urlbarBindings.xml:274
TaskImpl_run@resource://gre/modules/Task.jsm:233
TaskImpl@resource://gre/modules/Task.jsm:182
Task_spawn@resource://gre/modules/Task.jsm:152
handleCommand@chrome://browser/content/urlbarBindings.xml:349
anonymous@chrome://global/content/bindings/autocomplete.xml:417
onTextEntered@chrome://global/content/bindings/autocomplete.xml:224
onKeyPress@chrome://global/content/bindings/autocomplete.xml:477
onxblkeypress@chrome://global/content/bindings/autocomplete.xml:561

Is there something else I can try to go further? Is it because libc cannot be found that I'm getting errors as above and Firefox is nearly unworking or is it completely unrelated and the above error must be reported separately?

Thanks,

     Emeric


[1] https://bugs.gentoo.org/show_bug.cgi?id=497516
[2] https://bugs.gentoo.org/show_bug.cgi?id=497514
Your stack doesn't mention libc at all and doesn't seem related to the other stacks mentioned so far. What makes you think that it's the same bug?
Flags: needinfo?(emeric.maschino)
(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #33)
> Your stack doesn't mention libc at all and doesn't seem related to the other
> stacks mentioned so far. What makes you think that it's the same bug?

I was meaning the stack of my original bug report, in Gentoo BTS [1]. Here's it again, that looks very similar to comment #30:

*** ERROR addons.xpi: Failed to process extension changes at startup: Error: Could not open system library: no libc (resource://gre/modules/osfile/osfile_unix_allthreads.jsm:60)
A coding exception was thrown and uncaught in a Task.
Full message: ReferenceError: OS is not defined
Full stack: _openFile@resource://gre/modules/services-common/log4moz.js:603
TaskImpl_run@resource://gre/modules/Task.jsm:233
TaskImpl@resource://gre/modules/Task.jsm:182
Task_spawn@resource://gre/modules/Task.jsm:152
@resource://gre/modules/services-common/log4moz.js:609
@resource://gre/modules/services-common/log4moz.js:614
@resource://gre/modules/services-common/log4moz.js:630
@resource://gre/modules/services-common/log4moz.js:670
App_append@resource://gre/modules/services-common/log4moz.js:443
@resource://gre/modules/services-common/log4moz.js:284
@resource://gre/modules/services-common/log4moz.js:298
MarionetteComponent@resource://gre/components/marionettecomponent.js:43
@resource://gre/modules/XPCOMUtils.jsm:271

The other stack I was also reporting in comment #32 was only there to ask whether it's showing because of failure to locate libc or is completely unrelated and should thus be reported as well. I only wanted to prevent flooding Mozilla BTS with errors like this if there are all due to failure to locate libc.

    Émeric

[1] https://bugs.gentoo.org/show_bug.cgi?id=497516
Flags: needinfo?(emeric.maschino)
Could you try applying the patch of bug 878791 and see if it changes anything?
(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #35)
> Could you try applying the patch of bug 878791 and see if it changes
> anything?

This did the trick: replying from a working Firefox 26 binary :-)

And the other callstack that I've reported in comment #32 when clicking on the Enter key or the Go button is also gone, so failure to locate libc was also the root cause.

Many thanks,

     Émeric
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: