Last Comment Bug 417037 - mozStorage chokes on databases over AFP
: mozStorage chokes on databases over AFP
Status: RESOLVED FIXED
: fixed1.9.1, regression, relnote, verified1.9.0.1
Product: Toolkit
Classification: Components
Component: Storage (show other bugs)
: Trunk
: All Mac OS X
: P2 major with 5 votes (vote)
: mozilla1.9.1b2
Assigned To: Shawn Wilsher :sdwilsh
:
: Marco Bonardo [::mak]
Mentors:
: 437313 439706 440044 440159 440244 440502 442749 444776 445460 455704 (view as bug list)
Depends on: 449443
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-12 10:53 PST by Tim Steiner
Modified: 2010-09-18 03:56 PDT (History)
40 users (show)
mbeltzner: blocking1.9.1+
mbeltzner: blocking1.9.0.1+
sdwilsh: in‑litmus?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Initial browser window after creating a fresh profile while using an AFP home directory. (16.12 KB, image/png)
2008-02-13 08:02 PST, Tim Steiner
no flags Details
v1.0 (1.09 KB, patch)
2008-06-12 13:17 PDT, Shawn Wilsher :sdwilsh
benjamin: review+
mbeltzner: approval1.9.0.1+
Details | Diff | Splinter Review

Description Tim Steiner 2008-02-12 10:53:57 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3

Starting with no ~/Library/Application Support/Firefox directory (where ~ is on an AFP share),  I can launch Firefox and type into the address and search bars, but nothing happens when I hit Enter.  It is also notable that the browser window is initially very small (just tall enough to see the toolbars), and no default web sites are loaded.

The bookmark bar did have a single "Home" link which went to a google search page.  From there, I could browse normally via links.

By simply making ~/Library/Application Support/Firefox a symbolic link to /tmp/Firefox (a local directory), everything seems to work fine (but the profile is no longer stored on the network).

Reproducible: Always

Steps to Reproduce:
1. Launch Firefox with a profile on an AFP directory
2. Enter text into the address or search bar
3. Hit Enter
Actual Results:  
Nothing happens at all.  Its as if the enter key were never pressed.

Expected Results:  
The requested URL or search page should be loaded.

Both the workstation and AFP server are running Mac OS X 10.5
Comment 1 Tim Steiner 2008-02-13 08:02:10 PST
Created attachment 303047 [details]
Initial browser window after creating a fresh profile while using an AFP home directory.
Comment 2 Dan Stillman 2008-05-24 13:57:33 PDT
I can confirm this:

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 :: file:///Applications/Minefield.app/Contents/MacOS/components/nsBrowserGlue.js :: bg__initPlaces :: line 386"  data: no]
Source File: file:///Applications/Minefield.app/Contents/MacOS/components/nsBrowserGlue.js
Line: 386

The error is in initializing Places. I suspect this is due to needing the SQLITE_ENABLE_LOCKING_STYLE SQLite macro uncommented in sqlite.c on OS X. See http://www.mail-archive.com/sqlite-users@sqlite.org/msg21123.html for details.

We're seeing this in our mozStorage-backed extension as well, with openDatabase() throwing NS_ERROR_FILE_IS_LOCKED. Latest SQLite command-line client also doesn't work over AFP without that macro.

mozStorage seemed to work over AFP in Firefox 2, so this is a regression.
Comment 3 Dan Stillman 2008-05-24 14:27:44 PDT
SQLite changelog lists "Get the SQLITE_ENABLE_LOCKING_STYLE macro working again on MacOSX" for 3.5.7, so I don't know what effect it would have in 3.5.4.2 (which appears to be Fx3's version).
Comment 4 Roger Dodd 2008-06-04 09:45:46 PDT
I can confirm this bug with AFP mounted profile directories. At my place of work our home directories (and therefore firefox profiles) are AFP mounted and Firefox 3 is broken as described by Tim Steiner. This will be a complete show-stopper for us if we upgrade and suddenly everyone's browsers no longer work. As such, I would regard this as absolutely critical to be fixed prior to release.
Comment 5 Dietrich Ayala (:dietrich) 2008-06-05 09:28:58 PDT
confirming, from the multiple independent confirmations above.
Comment 6 philippe (part-time) 2008-06-06 00:02:40 PDT
*** Bug 437313 has been marked as a duplicate of this bug. ***
Comment 7 Shawn Wilsher :sdwilsh 2008-06-06 06:45:51 PDT
This may be fixable, but might be a bit slower too - see http://www.mail-archive.com/sqlite-users@sqlite.org/msg34473.html
Comment 8 Mike Beltzner [:beltzner, not reading bugmail] 2008-06-09 16:53:17 PDT
Will relnote this, but won't block the release on it. This is something we need to address in a branch update, though.
Comment 9 Bill Shirley 2008-06-12 12:15:30 PDT
I'm having the same show-stopping issue for Firefox 3 RC 2, OS X 10.5.3
It makes me sad - we just went to AFP mounted home directories, and I've lost the FireFox i've been running solidly in beta for months.
Comment 10 Shawn Wilsher :sdwilsh 2008-06-12 13:11:03 PDT
Lovely - the version of sqlite that is in the tree does not compile with the AFP support.  We'll need a newer version of sqlite on branch (bug 435414) if we want to try this).
Comment 11 Shawn Wilsher :sdwilsh 2008-06-12 13:17:39 PDT
Created attachment 324848 [details] [diff] [review]
v1.0

This enables AFP on the mac.  Note, the library on the system that Apple uses also has this enabled.

I also cleaned up the Makefile a bit since I was in the area.
Comment 12 Mike Beltzner [:beltzner, not reading bugmail] 2008-06-13 00:42:13 PDT
(relnote added)
Comment 13 Tim Steiner 2008-06-17 14:13:43 PDT
I created a build from the official 3.0 sources with the patch from this bug and the patches from bug 435414 and the issue seems to be resolved!
Comment 14 Shawn Wilsher :sdwilsh 2008-06-17 14:27:18 PDT
I hope to push this to mozilla-central tomorrow, and then make an argument for drivers that we should take this for 3.0.1.
Comment 15 philippe (part-time) 2008-06-17 23:13:34 PDT
*** Bug 439706 has been marked as a duplicate of this bug. ***
Comment 16 Greg Smith 2008-06-18 07:37:35 PDT
This same behavior exists when the home folder is a SMB based share. We utilize the ability of the Mac to use our existing Windows Domain with home folders and the release version firefox 3 does not work with the home folders operating off of the domain resource.
Comment 17 Shawn Wilsher :sdwilsh 2008-06-18 08:39:12 PDT
Pushed to mozilla-central:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/c9b5882bf6f6

(In reply to comment #16)
> This same behavior exists when the home folder is a SMB based share. We utilize
> the ability of the Mac to use our existing Windows Domain with home folders and
> the release version firefox 3 does not work with the home folders operating off
> of the domain resource.
Can you possibly test to see if this patch solves your issue?  It'll be in tomorrows nighlies for 3.1.
Comment 18 Al Billings [:abillings] 2008-06-18 11:11:36 PDT
*** Bug 440044 has been marked as a duplicate of this bug. ***
Comment 19 philippe (part-time) 2008-06-18 22:07:55 PDT
*** Bug 440244 has been marked as a duplicate of this bug. ***
Comment 20 philippe (part-time) 2008-06-18 22:20:22 PDT
*** Bug 440159 has been marked as a duplicate of this bug. ***
Comment 21 Roger Dodd 2008-06-19 07:16:31 PDT
FYI - I have tested the nightly for 080619 and this patch has solved the problems with AFP-mounted profile directories on our systems. Thanks for your help with fixing the issue.
Comment 22 Greg Smith 2008-06-19 07:59:09 PDT
FYI, the nightly build seems to have resolved the same issue on systems using smb-mounted profiles as well.

Thanks for the community's quick turn around on this bug. Any ETA on getting it integrated into the current version 3 as a point release?
Comment 23 Ryan VanderMeulen [:RyanVM] 2008-06-19 08:02:34 PDT
Assuming that the SQLite 3.5.9 update sticks, I believe the aim is to get this fixed for Firefox 3.0.1.
Comment 24 Shawn Wilsher :sdwilsh 2008-06-19 08:16:44 PDT
(In reply to comment #23)
> Assuming that the SQLite 3.5.9 update sticks, I believe the aim is to get this
> fixed for Firefox 3.0.1.
That is the going plan - still waiting on blocking status for sqlite and this bug.
Comment 25 Shawn Wilsher :sdwilsh 2008-06-19 08:17:13 PDT
verified per comment 21 and comment 22

Thanks guys.
Comment 26 Heath Roberts 2008-06-19 12:01:45 PDT
*** Bug 440502 has been marked as a duplicate of this bug. ***
Comment 27 Shawn Wilsher :sdwilsh 2008-06-29 13:36:04 PDT
I'd *really* like to see this get in for 3.0.1.  This fix has been landed in mozilla-central for a little more than ten days, with no noticeable performance regressions.  The fix has been verified to fix the issues with *both* AFP and smb-mounted profile folders (comment 21 and comment 22 respectively).

I have a red-eye flight tonight, so I don't know how much I'm going to be around tomorrow.  If I'm not, can a driver please make sure someone else lands this if I'm not around?
Comment 28 Matthias Versen [:Matti] 2008-06-30 14:29:03 PDT
*** Bug 442749 has been marked as a duplicate of this bug. ***
Comment 29 Mike Beltzner [:beltzner, not reading bugmail] 2008-06-30 22:37:59 PDT
Comment on attachment 324848 [details] [diff] [review]
v1.0

a=beltzner, sorry for losing track of this
Comment 30 Reed Loden [:reed] (use needinfo?) 2008-06-30 23:21:27 PDT
Checking in db/sqlite3/src/Makefile.in;
/cvsroot/mozilla/db/sqlite3/src/Makefile.in,v  <--  Makefile.in
new revision: 1.36; previous revision: 1.35
done
Comment 31 Tony Chung [:tchung] 2008-07-02 15:50:32 PDT
updating status whiteboard to verified per comment 25
Comment 32 Shawn Wilsher :sdwilsh 2008-07-08 07:17:26 PDT
Had to back this out for bug 442949
Comment 33 Matthias Versen [:Matti] 2008-07-11 11:28:02 PDT
*** Bug 444776 has been marked as a duplicate of this bug. ***
Comment 34 Matthias Versen [:Matti] 2008-07-16 03:40:15 PDT
*** Bug 445460 has been marked as a duplicate of this bug. ***
Comment 35 Shawn Wilsher :sdwilsh 2008-07-16 08:48:48 PDT
We can try this again when we upgrade to the latest sqlite...
Comment 36 Florian von Kurnatowski 2008-07-17 06:58:14 PDT
Made me back-out the migration to server-based home directories for our Mac network. :-(
Comment 37 Jim 2008-07-17 07:03:02 PDT
v3.0.1 release appears to resolve issue on SMB network volumes.
Comment 38 Ryan VanderMeulen [:RyanVM] 2008-07-17 07:06:46 PDT
Yes, the updated SQLite was only backed out of the trunk (Firefox 3.1). It was left on the Firefox 3.0.x branch.
Comment 39 Mike Beltzner [:beltzner, not reading bugmail] 2008-08-14 12:17:42 PDT
Adding keywords; this is fixed on the 3.0.x branch (as in, it the sqlite upgrade wasn't backed out there) so we need to reflect that.
Comment 40 Jon Carlyon 2008-08-22 11:59:46 PDT
Issue unresolved on 10.4 ppc 10.5 intel connecting to OSX 10.4 afp server and 10.5 afp server using nightly release 3.1a2pre. Can regularly reproduce small window that fails to respond, get "Another copy of FF is currently open", or goes directly to Mozilla Bug Report. After deleting all FF application support as well as removing the .parentlock file the errors continue to reoccur and ultimately after multiple failures mentioned above FireFox fails to respond at all. We are a school district maintaining network home directories for more than 2000 users half of which depend on FF. Please update status.
Comment 41 Shawn Wilsher :sdwilsh 2008-08-22 13:43:08 PDT
(In reply to comment #40)
> Issue unresolved on 10.4 ppc 10.5 intel connecting to OSX 10.4 afp server and
> 10.5 afp server using nightly release 3.1a2pre. Can regularly reproduce small
> window that fails to respond, get "Another copy of FF is currently open", or
> goes directly to Mozilla Bug Report. After deleting all FF application support
> as well as removing the .parentlock file the errors continue to reoccur and
> ultimately after multiple failures mentioned above FireFox fails to respond at
> all. We are a school district maintaining network home directories for more
> than 2000 users half of which depend on FF. Please update status.
You shouldn't be using alpha or nightly builds for more than 2000 users.  This is fixed in 3.0.x, but not in 3.1.x.  Had you read the bug, you wouldn't need me to update the status for you.
Comment 42 Jon Carlyon 2008-08-22 14:33:08 PDT
I'm sorry that I left out the fact that we are experiencing the error on 10.4 and 10.5 intel and ppc clients connected to home directories on OSX 10.4 and 10.5 afp servers using FF 3.0.1. I tried your alpha as a Hail Mary last resort on a single machine with a single user. FF 3.0.1 is the current version on 1500 computers and we are still experiencing the issues the update claims to have resolved.
Comment 43 Jon Carlyon 2008-08-22 14:44:29 PDT
UPDATE COMMENT #40

ISSUE UNRESOLVED! On either a 10.4 ppc 10.5 intel computer connecting to either a OSX 10.4 afp or 10.5 afp server using FF 3.0.1. I also tried FF 3.1a2pre on a single client with a single user without success. We had the parentlock issue with 2.x but this is MUCH WORSE AND IS A CRITICAL ISSUE!

Using 3.0.1 I can regularly reproduce the small window that fails to respond. I get "Another copy of FF is currently open", or it goes directly to the Mozilla Bug Report. After deleting all FF application support as well as removing the .parentlock file the errors continue to reoccur and ultimately after multiple failures mentioned above FireFox fails to respond at all. 

We are a school district maintaining network home directories for more than 2800 users who depend on FF. PLEASE HELP!! Please reopen the ticket.

Thanks
Comment 44 Marty Sachs 2008-08-22 15:00:14 PDT
While I did have this issue with FF 3.0.0, FF 3.0.1 seems to work fine for us using OS X 10.5.4 on both PPC and Intel clients with home directories on an Intel XServe running OS X Server 10.5.4. 
Comment 45 Tim Riley [:timr] 2008-08-22 15:49:22 PDT
Marcia  can help reproduce the problem in c44.  But she  needs some help from IT to setup AFP.  Matthew-  Can someone from your team help with this?
Comment 46 matthew zeier [:mrz] 2008-08-22 15:50:20 PDT
Sean, can you help out here?
Comment 47 Henrik Skupin (:whimboo) 2008-08-22 16:23:25 PDT
I run a test on my two machines at home with 

To get it to work I shared my public folder on my Mac Mini via AFP. After that I created a fresh profile on my MacBook and selected the connected AFP-folder as target. Starting Minefield afterwards results in an immediately shutdown. Opening the folder only shows following files:

lrwxr-xr-x@  1 henrik  staff   14 23 Aug 01:13 .parentlock -> 127.0.0.1:2570
-rw-r--r--@  1 henrik  staff    0 23 Aug 01:12 127.0.0.1:2555
-rw-r--r--@  1 henrik  staff    0 23 Aug 01:13 127.0.0.1:2570

This happens for each version of Firefox (Fx2, Gran Paradiso, Minefield). Is this another issue which should be filed as its own bug? Due to this issue I'm not able to follow the given STR. Or do I have to place the whole OS X user profile on a AFP share? 
Comment 48 Shawn Wilsher :sdwilsh 2008-08-22 16:25:24 PDT
Hmm, that seems like it is a different issue (I'd expect more files there by default).  Maybe that's what comment 43 is hitting?
Comment 49 Devin Davis 2008-08-23 11:04:20 PDT
As #43 stated, this is a critical issue for us and basically makes FF unusable.  Another piece of information that he forgot to give you is that backgrading to 2.x, didn't resolve the problem even though we hadn't seen the current "can't fix it by deleted the parentlock problem" until we upgraded to 3.0.  Last year we had a lot of problems with FF as the students forgot to close the application before logging off the computer.  This action would abort the session with the server will FF was still open thus creating the firefox is already open problem.  The resolution for this was to log on the server and use Onyx to find the parent lock folder, delete, and then the user was good, (at least until they did it again).  To counter that problem we developed a script for the Macs that forces a shutdown of all applications on log off and that seemed to work very well.  This year we were having some problems with another application and were requested by the vendor to upgrade FF to 3.x and thus the new set of problems occurred.

SO, in our attempts to clear off the references to FF in the student directory we are obviously missing something otherwise we could at least temporarily fix the problem.  If possible, please respond with all of the user based files that we should be looking for in our attempts to clear out and start over.
<end>

I'm not able to create a profile at least. Only the given files are
located there. Does that also happen on your side or do you have a
running profile and are all necessary files are stored on the AFP
share?

Thanks,
Henrik

<end>

Henrik,

When using Apple home directories, all of the user based information including the profile is located on the file server but the actual application is still located on the local computer.
Comment 50 Thomas Shaw 2008-09-17 14:14:18 PDT
*** Bug 455704 has been marked as a duplicate of this bug. ***
Comment 51 Shawn Wilsher :sdwilsh 2008-09-26 08:13:18 PDT
Pushed to mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/b2d48e54c537
Comment 52 Shawn Wilsher :sdwilsh 2008-09-26 12:42:38 PDT
We have to backout bug 449443 because we have to backout bug 456910 because of a Tp regression, which means we need to back this out :(
Comment 53 Bill McGonigle (not currently reading bugmail; please contact directly) 2008-09-30 11:49:57 PDT
Does the truncate journal mode patch in 3.6.4 address this issue, or is a separate solution required?  Even if a config option were necessary, all the schools I work with would gladly jump through the hoop and take the performance penalty to be able to use Firefox (it's effectively unusable in an OSX Server shop).
Comment 54 Shawn Wilsher :sdwilsh 2008-09-30 13:12:32 PDT
(In reply to comment #53)
> Does the truncate journal mode patch in 3.6.4 address this issue, or is a
> separate solution required?  Even if a config option were necessary, all the
> schools I work with would gladly jump through the hoop and take the performance
> penalty to be able to use Firefox (it's effectively unusable in an OSX Server
> shop).
If by this issue you mean this bug, upgrading will allow us to enable it.  If you are on Firefox 3.0.x though, you already have this fix and you should file another bug about any issue you might be having.
Comment 55 Shawn Wilsher :sdwilsh 2008-10-24 15:48:22 PDT
http://hg.mozilla.org/mozilla-central/rev/fafaf721f03d
Comment 56 Alex Tirrell 2008-12-16 23:45:53 PST
I know it's been a few months, but this bug is not completely fixed in similar server/profile environments.

Our Macs run in a similar way to AFP--we use a Windows Server and Active Directory. A SMB connection is used for accessing the user's system profile live over the network.

Before this bug fix was implemented, we had the exact same problem as AFP users. Non-functional FF. After the bugfix was implemented, FF would work for the first run, or a new profile, but after logging out and logging back in, Firefox would forget its Bookmarks and other personal settings, and the back/forward buttons would sometimes be nonfunctional.

I have been forced to revert back to Firefox 2--I would assume that either nobody is really using Firefox in an SMB-hosted profile environment, or there is another unresolved bug that I can't find.
Comment 57 Shawn Wilsher :sdwilsh 2008-12-17 06:58:02 PST
(In reply to comment #56)
> Before this bug fix was implemented, we had the exact same problem as AFP
> users. Non-functional FF. After the bugfix was implemented, FF would work for
> the first run, or a new profile, but after logging out and logging back in,
> Firefox would forget its Bookmarks and other personal settings, and the
> back/forward buttons would sometimes be nonfunctional.
It sounds to me like your file system is not releasing the lock when we (sqlite) tell it to.  We can't really do anything about that it turns out.
Comment 58 Henrik Skupin (:whimboo) 2008-12-26 05:51:11 PST
(In reply to comment #56)
> Our Macs run in a similar way to AFP--we use a Windows Server and Active
> Directory. A SMB connection is used for accessing the user's system profile
> live over the network.

Alex, you should have a look at bug 309323.
Comment 59 Henrik Skupin (:whimboo) 2009-01-15 14:47:02 PST
Devin or any other one, who had problems with AFP, can you please give us feedback if the given patch has been resolved your issue? Thanks!
Comment 60 Tony Chung [:tchung] 2009-01-15 15:26:23 PST
sorry for the inconvenience.  i meant to detect any bugs before the branch merge that were still RESO fixed, but had a verified1.9.1 keyword next to them.
Comment 61 Tony Chung [:tchung] 2009-01-15 15:38:07 PST
this should be marked fixed1.9.1 and still needs to be verified on 1.9.1branch
Comment 62 Bob 2009-03-05 10:49:57 PST
This status should be changed to "open"  I've just tested 3.0.7 and can confirm that the issue is NOT resolved.  This issue is very hard to track in our environment because it is inconsistent where one user will have this problem and another will not.
Comment 63 Shawn Wilsher :sdwilsh 2009-03-05 10:52:52 PST
(In reply to comment #62)
> This status should be changed to "open"  I've just tested 3.0.7 and can confirm
> that the issue is NOT resolved.  This issue is very hard to track in our
> environment because it is inconsistent where one user will have this problem
> and another will not.
You should file a new bug with the details of the issue you are seeing because this bug has been verified as fixed, and the code has not changed.
Comment 64 BCoe 2009-04-21 11:49:47 PDT
(In reply to comment #63)
> (In reply to comment #62)
> > This status should be changed to "open"  I've just tested 3.0.7 and can confirm
> > that the issue is NOT resolved.  This issue is very hard to track in our
> > environment because it is inconsistent where one user will have this problem
> > and another will not.
> You should file a new bug with the details of the issue you are seeing because
> this bug has been verified as fixed, and the code has not changed.

(In reply to comment #63)
> (In reply to comment #62)
> > This status should be changed to "open"  I've just tested 3.0.7 and can confirm
> > that the issue is NOT resolved.  This issue is very hard to track in our
> > environment because it is inconsistent where one user will have this problem
> > and another will not.
> You should file a new bug with the details of the issue you are seeing because
> this bug has been verified as fixed, and the code has not changed.

I have a related problem in FF 3.0.8 and Beta. See Bug 489227.
Comment 65 Marty Sachs 2009-06-12 06:46:55 PDT
I've found a similar issue upgrading from 3.0.10 to 3.0.11 (See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=497792">Bug 497792</a>).
Comment 66 Tim Steiner 2009-06-12 07:33:17 PDT
Confirmed.  Firefox 3.0.11 is showing the same behavior that I originally created this report for.
Comment 67 Shawn Wilsher :sdwilsh 2009-06-12 08:34:16 PDT
The particular issue this bug was to fix was fixed and verified.  Please open a *new* bug if you are still seeing issues over the network as it's not this bug.
Comment 68 Marty Sachs 2009-06-12 08:41:23 PDT
OK, I thought so. Which is why a new bug was opened.  See: Bug 497792

Note You need to log in before you can comment on or make changes to this bug.