Closed Bug 177587 Opened 22 years ago Closed 22 years ago

Chimera crashes, unable to init prefs for network-based user at startup [@ BookmarksService::ReadBookmarks]

Categories

(Camino Graveyard :: Bookmarks, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
Camino0.7

People

(Reporter: milsf, Assigned: ccarlen)

References

Details

(Keywords: crash, qawanted, regression)

Crash Data

Attachments

(3 files)

On startup, Chimera is unable to create prefs in the ~/Library/Application Support/
Chimera/Profiles/default/<random>.slt/ folder. Bookmarks.xml and chrome are created, 
then the app crashes. Deleting the Chimera folder and org.mozilla.plist file doesn't help. 
I've also restarted several times.

The app works and creates the prefs files normally for local based users but fails 
everytime for users with network based homedirs. Interestingly enough, the 0.5.0 binanry 
no longer works either. I've also tried to take the prefs generated by a local account and 
move them to the correct spot on the network account - no luck. Attached is a snippet 
from console.log during app startup, and the Navigator.crash.log (last crash)

Local OS: OSX 10.2.1
Server OS: OSX 10.1.5
Build: 2002103004 and 2002102904
Reassigning to Bookmarks.
Assignee: saari → sfraser
Component: General → Bookmarks
Keywords: crash
QA Contact: winnie → sairuh
Summary: Crash- Unable to init prefs for network-based user at startup → Chimera crashes, unable to init prefs for network-based user at startup [@ BookmarksService::ReadBookmarks]
How exactly are you setting up network-based home dirs?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Should have indicated that the server OS was OSX Server and not just OSX. The 
homedir was setup using the standard Server Admin in the /root shared NetInfo domain. I 
should have also stated that I could run the 2002102704 build fine. I had the same 
problems with builds in late September and stopped using Chimera after having used .4 
and .5 w/o problem. Came back a few weeks ago. Mozilla 1.2b is fine. Just ran 
2002103104 and crashed with the same stack.
The release notes for 0.6.0 mention a parse file for bookmark loading related errors. Would these files be relevant to the resolution of this bug? If so, where would it be located? (Full Circle?) 
No, I think it dies before trying to read boomarks.

What would help me most here is for someone to describe how to set up a
network-based home directory, using 2 standard Mac OS 10.2 boxes, so that I can
repro this and fix it.
This is a very new regression. I did a quick test of the nightlies.
2002-10-28-04 is the last nightly to start correctly. Nightlies starting with
2002-10-29-04 and newer fail with this bug.

What was checked in on the 28th?
This was bryner's fcntl change, I bet. Bug 176608.
Assignee: sfraser → bryner
Status: ASSIGNED → NEW
Which was my suggestion though :-(

So, if we go back to symlink profile locking, which does work on a remote
server, we get back the bugs associated with that. If locking via fcntl is not
available on server volumes (or at least this one) and we can tell that by the
value of errno, we could just run anyway - we couldn't certainly get a lock but
then, we don't know that the dir was locked by another user. The symlink locking
is less certain on remote machines also - it has no way of knowing whether the
owner of the lock is alive.
As far as locking goes, the ~/Library folder (and its directory tree) is by default no access (drwx------). INAP, but the only scenario I can think of for another user could having a lock on the dir is root, and then probably only if viewed at the server itself. FYI, the volume is being served by OSXS 10.1.5. 10.2 may allow locking via fcntl. Not sure if this matters, but the user homedirs are on an external RAID 5 connected via U160 SCSI.
grrr.. if one of the Netscape guys could edit my last two posts and add breaks.
OmniWeb doesn't seem to play nice with Bugzilla - sorry.
I have exactly the same problem with the same setup (10.2.1 client, 10.1.5 X server) - 
same trace etc. The home dir is mounted automatically via afp. I'm not sure if the setup 
can be reproduced with two regular OS X boxes. The mounting is done by evaluating 
network NetInfo db and is set up by the Mac Manager which comes with the OS X server 
only (afaik). 

The mount entry looks like this:
afp_0TRsF80V0oOy10Fh5v0Xh8ER-1 on /private/Network/Servers/jetta/Volumes/Data/
Library/NetBoot/NetBootSP1 (nodev, nosuid, automounted, mounted by urbaneks)

It may be possible to try the regular public file sharing that is available on every OS X, but 
I'm not sure if the same mechanism is used. I'd really appreciate the bug being fixed 
since I have to fall back to IE now which sucks :P.
*** Bug 178912 has been marked as a duplicate of this bug. ***
FYI: I've got the same problem when Home directory is located on a volume
mounted via NFS (served by a Linux box). (crash, no change when deleting
prefs/chimera directories etc.).
Attached patch patchSplinter Review
This patch makes it so that errors from fcntl other than those which tell us
that somebody else holds the profile lock return an error code which is not
actually a failure and the profile gets set and the app launches.
BTW, if there is somebody with a net-based home dir who can apply patches and
build, testing would be very helpful.
While I don't have the source tree on my systems I'd be more than happy to test
it if someone could do a build with the patch applied.
Lemme see if I can get Chimera building...
I'm kinda puzzled - I was about to rebuild Chimera with the patch, but the building 
process went through all stages before I could patch it - and it works. So in plain text: the 
latest Chimera CVS as of now works for me (compiled with debugging support). I looked 
at the sources and the above mentioned patch was NOT applied. So maybe fixes of 
something else fixed this probelm as well?

(I didn't change my config - i.e. I'm still using remote home - except that I updated to 
10.2.2, but old builds like 0.6 release still crash, so it was not fixed by the 10.2.2 update. 
Plain text: 0.6 release crashes as described, current CVS works flawlessly)
build # 2002111204 works fine for me, too. The problem which this bug describes (crash 
on startup if home directory was on a network file system) is not an issue with this build.
The bookmarks service was fixed to not crash when there is no profile. That's
good but you still have no profile, so bookmarks, history, cache, etc., are not
being used.
Simon, thanks for building it to test. Without the patch, you should notice that
nothing is being saved to your profile. With the patch, it should. Can you check
that while you have this build?
Conrad, you're right. I'm not using bookmarks etc. much so I didn't really notice (since I 
delete the Prefs too often I guess ;)). Chimera (off CVS) crashes when I try to add a 
bookmark. (I could add a crash-log if it's of interest..)

I'll try the patched version. Compiling the sources takes few hours, so I guess I'll have the 
results early tomorrow. 
Conrad, you're a gem :) With your patch Chimera really reads and writes 
preferences correctly and doesn't crash either! As far as I could see 
everything works (bookmarks can be added and are retained upon restart...). 
Big thanks for the patch!
I had this crash too and deleted my prefs, and still couldn't launch the app with my 
NetInfo based user (it is fine if I log into a local account).
With the nightly build (Nov 14 2002), it no longer crashes at startup but no bookmarks are 
loaded (I expected to see the default ones at least). Any attempt to alter the bookmarks 
results in a crash (e.g. trying to bring up the sidebar, or adding a page to bookmarks):

(from clicking on the Sidebar icon):

 #0   0x00038880 in -[BookmarksDataSource outlineView:numberOfChildrenOfItem:]
 #1   0x9323c36c in -[NSOutlineView _expandItemEntry:expandChildren:]
 #2   0x9323e034 in -[NSOutlineView numberOfRows]
 #3   0x932cfaf4 in -[NSTableView _verifySelectionIsOK]
 #4   0x932cfd00 in -[NSTableView tile]
 #5   0x932cfefc in -[NSTableView reloadData]
 #6   0x9323d204 in -[NSOutlineView reloadData]
 #7   0x00036be8 in -[BookmarksDataSource ensureBookmarks]
 #8   0x0000e6ac in -[BrowserWindowController 
addBookmarkExtended:isFolder:URL:title:]
 #9   0x930cfe2c in -[NSApplication sendAction:to:from:]
 #10  0x9320fd18 in -[NSMenu performActionForItemAtIndex:]
 #11  0x9310a164 in -[NSCarbonMenuImpl 
performActionWithHighlightingForItemAtIndex:]
 #12  0x9308122c in _NSHandleCarbonMenuEvent
 #13  0x930824d4 in _DPSNextEvent
 #14  0x930ccf84 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
 #15  0x930ca500 in -[NSApplication run]
 #16  0x930d2598 in NSApplicationMain
 #17  0x00005200 in _start
 #18  0x00005080 in start

Is what I'm seeing this bug or a related bug? The booksmarks.xml file that is created is 
not blank - it just doesn't seem to want to read from that directory.
Perhaps I'll try my hand at downloading the source & compiling with the patch for the first 
time...
It is good news that there is a fix for this bug!  How do I get the fixed version of Chimera?
Thanks.
for what it is worth i'm seeing the same results as in comment #26... same
bookmark.xml, etc. I have a home directory shared from 10.2.2 server onto a
10.2.2 client via AFP, fwiw.
Once again: Conrad's patch solves the original bug (crash on startup) as well as
the later bug (crash on add-bookmark). Rebuild Chimera with Conrad's patch and
you'll be fine. If you don't want to wait for the next official build containig
the patch, you can d/l my build (latest CVS as of yesterday) with the patch from
http://b-q-c.com/Chimera-patched.dmg.gz (ca.10MB) - it as an inoffical build
though (no warranties etc.)
Hi--just want to note that I have tried the patched version of Chimera Simon
posted (http://b-q-c.com/Chimera-patched.dmg.gz) twice now with no success. My
Home directory is on a secondary hard drive (i.e., it's not networked, but it's
not the root drive). Chimera 0.6 doesn't start (as you know); the patched
version starts but can't find ~/Library and crashes when I try to add a
bookmark. I'm dying to use Chimera on my desktop as well as my laptop, but until
this bug is really fixed, I'm stuck.

Thanks for all your hard work, folks. . . .
Elliot - can you start Chimera 0.5 in that same environment? Wondering if this
is the same bug.
No, Chimera 0.5.0 won't even launch. (I can see the expanding box outlines that
show it's trying to open, but nothing further happens.)
Then it's not this bug. The change which caused this regression wasn't in 0.5. 

BTW, do other programs run with your home dir on another drive? I assume so but,
I'll ask just in case ;-) I set up such an account to test this and, not only
did Chimera not launch, nothing did. In copying the home dir from its initial
location to the other drive (with sudo cp -r ...), it didn't end up with the
right permissions. Once I fixed that, Chimera launched, added bookmarks, etc.
Hmmm. . . I notice the description for this bug mentions 0.5 no longer working.
But if you believe this to be a different issue, should I file a new bug report?
Or since you got 0.6 to run with a non-root Home dir, should I assume the
problem is at my end?

To answer your question: Yes, everything runs fine. I think I used "ditto
-rsrcFork" instead of "cp" when moving my Home dir off the root drive; that
preserves permissions. Then I used NetInfo Manager to change my Home dir
location and deleted the old Home dir.

I'm using Mozilla 1.1 right now, for example, with no problems.

Thanks for responding so quickly!
-> me
Assignee: bryner → ccarlen
Target Milestone: --- → Chimera1.0
Target Milestone: Chimera1.0 → Chimera0.7
Fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Is the fixed code supposed to be in build 2002120305? If so
the bug isn't quite fixed. Still unable to init prefs and crash on bookmark
add like comment #30. Will try again with tomorrow's build. I have logs
if needed.
yeah, the fix for this was checked in today --so the next verification build to
have it will be tomorrow's.
since i don't have this kind of configuration, if someone who does could verify
this with a recent build (eg, today's), that'd be great!
Keywords: verifyme
I tried it on my NetInfo based home directory - it crashed when opening up the Sidebar - 
then I deleted the '/Library/Application Support/Chimera' folder, and restarts - all is well 
again (except I had to reenter all my settings, of course).
Wahoo.... the fix worked fine for me..

My setup is G4 (10.2.2) getting my home directory from another G4 (10.2.2
Server) and I just checked and opening the sidebar didn't crash anything for me.

It's great to be back in the 'up to date' world once again!

Dave
(Original Poster) Works good for me. Able to add and delete bookmarks, prefs
save, etc. I think we can verify/close if there are no dissenters? I'll keep d/l
dailies to check against regression. Unable to verify comment #40 as I'd already
moved that folder prior to install. After an open/quit cycle, I was able to
overwrite the bookmarks.xml file with my saved version.
Yes, trashing the old /Application Support/Chimera folder and installing today's
build has fixed everything for me too. Thanks so much!
thanks to all for checking this out with newer builds! marking verified.
Status: RESOLVED → VERIFIED
Keywords: verifyme
*** Bug 179035 has been marked as a duplicate of this bug. ***
Crash Signature: [@ BookmarksService::ReadBookmarks]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: