Closed Bug 177587 Opened 23 years ago Closed 23 years ago

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

Categories

(Camino Graveyard :: Bookmarks, defect)

Product:
Camino Graveyard
Component:
Bookmarks
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Camino0.7

People

(Reporter: milsf, Assigned: ccarlen)

References

Details

(Keywords: crash, qawanted, regression)

Crash Data

Attachments

(3 files)

console.log showing app startup
1.92 KB, text/plain
Details
Navigator.crash.log for last crash
3.48 KB, text/plain
Details
patch
3.85 KB, patch
Details | Diff | Splinter Review
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 patch — — Splinter 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: 23 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: