User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7 Build Identifier: http://ftp.mozilla.org/pub/camino/nightly/latest/ Mac OS X 10.1.5 (Build 5S66) System: PowerMac G4 Since the addition of the Bookmark Manager, I have not been able to access any of my bookmarks, either through the menu (Import Bookmarks, Manage Bookmarks), the Sidebar, or the Bookmarks Toolbar, which appears blank although there should be some bookmarks there. I've tried removing the ~/Application Support/Chimera directory before launching a new build, but still no success. I am only able to use the 2003030613 build of Camino with my bookmarks. Reproducible: Always Steps to Reproduce: 1.Download latest Camino build (or any build containing the Bookmark Manager) 2.Launch Camino (Bookmarks Toolbar is blank) 3.Try to import bookmarks (Menu item) 4.Select bookmarks file - OR - 3. Select the Manage Bookmarks menu item - OR - 3. Click on the "Show/Hide Sidebar" button Actual Results: Immediate Crash Expected Results: Access to bookmarks and bookmarks should appear in the Bookmark Toolbar. I've sent several Talkback crash reports, but unfortunately I don't have the crash IDs available. One thing that may be a factor is that my user directory is on an NFS mount. Also, when looking at the crash log, it appears as if the problem occurs while the NSOutlineView is trying to find out how many children to display. I've attached a crash report.

Crash log as promised.

i think the bookmark import may be the issue here, since it seems the data source is confused (that's where the crash is) and i didn't touch that code too much. can this be reproduced with the 0.7 release build?

I believe that the browser I'm using is the 0.7 release build (I have the latest stable version) and I'm not experiencing any problems at all. I have full access to my bookmarks. I did try deleting my preferences before launching the more recent builds, thus allowing Camino to create a brand-new profile with a new bookmarks.xml file, which it does. But the crash happens even when trying to access the new bookmarks.xml file.

I was curious to see if this was a problem on OS X 10.1.x or if it happened on Jag as well. I got my answer! This was with the 4/16 nightly.

Same problem here. Home dir on NFS again. Talkback IDs TB245594X, TB245601E. Build ID 2003042705. 0.7 release build (ID 2003030613) works fine.

These correspond to TalkBack IDs TB245594X and TB245601E.

*** Bug 207263 has been marked as a duplicate of this bug. ***

Marking New as a carry over from the dupe. Anyone still seeing this crash?

Still seeing it in build ID 2003060204. See Talkback ID TB275047Z.

Crash log from build 2003060204, TB275047Z.

I'm also still seeing the crash with build 2003060204 (see Talkback ID TB275142Y and attachment).

Crash log with build 2003060204

In the file BookmarksDataSource.mm, the method, - (int)outlineView:(NSOutlineView *)outlineView numberOfChildrenOfItem:(id)item has code similar to: if (!item) BookmarksService::GetRootContent(getter_AddRefs(content)); else content = [item contentNode]; if( !content ) { NS_WARNING( "[BookmarksDataSource outlineView:numberOfChildrenOfItem:] content must not be NULL pointer" ); return 0; }; content->ChildCount(childCount); I think that the crash in this bug arises becase there is no guarantee that the return value of the method contentNode is not null. It fact this occurs whenever gBookmarksDocument is null. I suggest that some people (myself included) happen to have a profile from which gBookmarksDocument cannot be initialised. As you can guess, the crash does not occur if we check that 'content' is not null before using it.

ok, i checked in a guard for the crash (so in theory i could mark it FIXED), but the real question is why are we in this state to begin with. Why can't we get a content node? Ben, can you attach your bookmarks file so we can see what's wrong with it? Do bookmarks show up for you at all, like in the menu?

It is not fixed for the reason that you gave. On my system, with sources modified to provide quite a bit more error checking, I get these attached lines in the log. A lot of files are not being found (I have tried to attach my log, but bugzilla repeatedly asks for my password and tells me that I have not attached a file, when in fact I have)

There are many 'bookmarks.html' on my system. I believe that the relevant one is on the path: bfowler:Library:Mozilla:Profiles:default:9osdd5lw.slt:bookmarks.html and was installed by Netscape. I think that it is relevant that gBookmarksDocument is null, and it might be useful to understand how it came about that this global does not get initialised.

the bookmarks will be xml, not html, and won't be in your mozilla profile. try ~/Library/Application Support/Chimera/.... i'm confused, what log messages are you getting? i couldn't understand if some of your last post was supposed to be those messages.

one more thing, now that i checked in that safeguard for the crash, what is the behavior when you add a bookmark? does it just fail? does it still crash? what happens when you try to show bookmarks? do you get any? does it crash? what happens when you access the bookmarks menu? do you have any? sorry, i'm lacking details here.

I was really excited to see that you've checked in a fix, so I downloaded the latest nightly right away. However, Camino crashes before it completely launches. Here's what's in my console (sorry -- it didn't get far enough for a crash log or TalkBack): dyld: /Applications/Camino.app/Contents/MacOS/Camino Undefined symbols: /Applications/Camino.app/Contents/MacOS/Camino undefined reference to .objc_class_name_NSNetServiceBrowser expected to be defined in Cocoa If this is unrelated, I'll file another bug.

separate issue

1. My bookmarks are at -rw-r--r-- 1 bfowler staff 3539 Mar 6 21:02 /Users/bfowler/Library/Application Support/Chimera/Profiles/default/r85q3cle.slt/bookmarks.xml and this looks like a standard set of bookmarks (id est, nothing wrong with it). 2. The bookmarks do not show up at all. (I am probably not even opening the bookmarks file) 3. I have not quoted any of my logs. 4. I have added to my sources many printf statements and guards, so my log may not resemble yours closely. 5. I have not tried adding a bookmark. I will let you know what happens when I do. 6. When I try to show bookmarks I get a blank but functional page. 7. FWIW, I still think that the key to this is failure to open the bookmarks file and/or failure to open the prefs. Ben

Do people seeingl this crash have odd disk setups -- Users on a different partition from System, or on network volumes?

Home directory is on an NFS mount.

When I try to add a bookmark, I get these log messages BookmarksService::GetRootContent gBookmarksDocument was null 2003-06-12 18:13:02.370 Camino[437] [NSPlaceholderString initWithString:]: nil string (or other) argument I have this relevant diff to BookmarksService.mm, which you could apply by hand if you wanted diff -r1.52 BookmarksService.mm 263a264,265 > } else { > fprintf( stderr, "BookmarksService::GetRootContent gBookmarksDocument was null\n" ); 737a740 Ben.

Running a PowerBook G4 (Titanium) Max OS X 10.2.6: I created a local user with a local home directory, then downloaded and launched the latest nightly so that it would create a new profile. I then copied my bookmarks.xml file from my network home directory to the new profile and launched Camino again. BINGO! All my bookmarks appear and the bookmark manager works flawlessly. Taking it a step further, I then copied the new profile directory from my local home directory back to my network home directory and tried the latest nightly from my PowerMac G4. Camino launched and there was no crash, but the bookmark manager was empty and so was the bookmarks toolbar.

I believe that I have traced the root of my problem to the persistent directory that is being pulled from 'Application.regs' See <URL: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=smfr-E84128.11432704072001%40virt-reader.news.rcn.net&rnum=6&prev=/groups%3Fq%3D%2B%2Balias%2Bhandle%2Bpath%2Bvolume%2Bshow%2BOR%2Bconvert%2BOR%2Bresolve%26hl%3Den%26lr%3D%26ie%3DUTF-8%26as_drrb% > As this log shows: ProfileAccess::FillProfileInfo Called with "/Users/bfowler/Library/Application Support/Chimera/Application.regs" 592 bytes of Base64 Source: AAAAAAG8AAIAAQVVc2VycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAC6XhqBSCsAAAAAACoMcjg1cTNjbGUuc2x0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK7ojNt8AAAAAAAAAAP////8AAAEAAAAAAAAAAAAAAAAAAAAAB2RlZmF1bHQAABAACAAAul4agQAAABEACAAAuiM23wAAAAEAGAAAACoAAAApAAAAJwAAACYAAAAkAAAAFQACAE9Vc2VyczpiZm93bGVyOkxpYnJhcnk6QXBwbGljYXRpb24gU3VwcG9ydDpDaGltZXJhOlByb2ZpbGVzOmRlZmF1bHQ6cjg1cTNjbGUuc2x0AAAOABoADAByADgANQBxADMAYwBsAGUALgBzAGwAdAAPAAwABQBVAHMAZQByAHMAEgBKL2Jmb3dsZXIvTGlicmFyeS9BcHBsaWNhdGlvbiBTdXBwb3J0L0NoaW1lcmEvUHJvZmlsZXMvZGVmYXVsdC9yODVxM2NsZS5zbHQAEwAOL1ZvbHVtZXMvVXNlcnP//wAA nsLocalFile::SetPersistentDescriptor Target: "r85q3cle.slt" nsLocalFile::SetPersistentDescriptor Volume: "Users" nsLocalFile::SetPersistentDescriptor Path: "/Volumes/Users/bfowler/Library/Application Support/Chimera/Profiles/default/r85q3cle.slt" ProfileStruct::InternalizeMigratedFromLocation GetStringUTF8 returned 80510003 nsProfile::GetProfileDir( "" ) called nsProfile::GetProfileDir About to call GetResolvedProfileDir 2003-06-21 06:05:59.780 Camino[7029] Failed to initialize mozilla prefs nsDirectoryService::GetFile Failed to find directory for key: ProfD WARNING: nsDirectoryService::Get( "ProfD" {c8c0a080-0868-11d3-915f-d9d889d48e3c} 0xbfffe560 ) About to return NS_ERROR_FAILURE, file ../../../src/xpcom/io/nsDirectoryService.cpp, line 699 WARNING: BookmarksService::ReadBookmarks profileDirBookmarks was null, file src/bookmarks/BookmarksService.mm, line 541 2003-06-21 06:06:13.648 Camino[7029] CHBrowserService::InitEmbedding Starting up embedding. nsDirectoryService::Get About to call Set( "AppRegD", "/Users/bfowler/Library/Application Support/Chimera" ) The stored alias is looking on a volume 'Users' which does not exist. Now I have copied my development probably between four machines, but I am confident that the Chimera directory has always been on the path '~bfowler/Library/Application Support/'. It is possible that that path may once have been on a volume called Users, perhaps mounted in some way on /Users , but I don't recall this. Whilst I have nothing against storing the persistent specification as an alias, it might be an idea to always look for the Chimera directory in ~/Library and /Library, as well as asking the user for help. Arguably the present behaviour (in which the application behaves as though it were faulty/ incomplete) ought not to be accepted. For information, I enc;lose part of my current diff for xpcom/io/nsLocalFileOSX.cpp, but I can't imagine this being accepted. RCS file: /cvsroot/mozilla/xpcom/io/nsLocalFileOSX.cpp,v retrieving revision 1.18 diff -r1.18 nsLocalFileOSX.cpp 1384a1392 > AliasHandle ah = (AliasHandle)newHandle; 1387c1395 < OSErr err = ::FSResolveAlias(nsnull, (AliasHandle)newHandle, &resolvedFSRef, &changed); --- > OSErr err = ::FSResolveAlias(nsnull, ah, &resolvedFSRef, &changed); 1389a1398,1419 > > HFSUniStr255 targetName; > HFSUniStr255 volumeName; > CFStringRef pathString; > FSAliasInfoBitmap whichInfo; > FSAliasInfo info; > > err = FSCopyAliasInfo ( ah, &targetName, &volumeName, &pathString, &whichInfo, &info ); > > CFStringRef strRef = CFStringCreateWithCharacters( kCFAllocatorDefault, targetName.unicode, targetName.length ); > const char *szTarget = CFStringGetCStringPtr( strRef, kCFStringEncodingMacRoman ); > fprintf( stderr, "nsLocalFile::SetPersistentDescriptor Target: \"%s\"\n", szTarget ); > > strRef = CFStringCreateWithCharacters( kCFAllocatorDefault, volumeName.unicode, volumeName.length ); > const char *szVolume = CFStringGetCStringPtr( strRef, kCFStringEncodingMacRoman ); > fprintf( stderr, "nsLocalFile::SetPersistentDescriptor Volume: \"%s\"\n", szVolume ); > > const char *szPath = CFStringGetCStringPtr( pathString, kCFStringEncodingMacRoman ); > fprintf( stderr, "nsLocalFile::SetPersistentDescriptor Path: \"%s\"\n", szPath ); > > CFRelease( pathString ); > 2142a2206 > case nsvErr: 2147a2212 > fprintf( stderr, "MacErrorMapper( %d ) returning %d", inErr, outErr ); In short, I suspect that those of us who are getting this behaviour with the bookmarks, are getting 'no such volume' errors when trying to resolve the Mozilla prefs directory from the information in Application.regs. Ben

Nice analysis, thanks! Over to conrad.

Same problem as bug 181752.

Thanks for the compliment. Yes, I am describing the same problem as that bug and its duplicates, I didn't use Carbon Copy Cloner, but some shell scripts of my own invention. Perhaps the volume 'Users' is an artifact of the Alias manager ... If I understand correctly, the team is till considering what fix is required (I assume that some is, because this is characterised as data-loss, though the crashing appears to have been taken care of). In some cases at least if you simply remove the '/Volumes' substring from the start of the path in the Alias, then the remaining path: '/Users/username/ ... /xxxxxxxx.slt' is correct. Perhaps some fallback in the case of the Alias resolution failing with nsvErr would settle the majority of these problems

Bug 172375 looks like a dup as well

*** Bug 172375 has been marked as a duplicate of this bug. ***

what's the status on this?

This looks like it's only occuring when the bookmarks file is on NFS right? Please update the summary if that's correct.

Yes, it seems that if the profile is on an NFS mount, then there are problems. A local home directory works just fine.

AFAICT, the analysis in comment 26 shows that the problem is when the alias to the profile directory points to a volume that doesn't exist, regardless of whether that volume is NFS or not. Profiles on NFS volumes work, accrording to bug 196487. I think what should happen is that the profile directory should be stored as a path relative to the current home directory. That would solve the problem of people moving their home directory, to an NFS volume or to another machine, etc. There's a patch for this on some other bug, if I can find it...

Could some one do an update on this bug? Sounds like you guys are close but not close enough for a patch yet.

Why don't we just show an error dialog if NSInitXPCOM fails?

Is this still a problem in 2005/0.8+ nightlies? This bug is one a very few Camino bugs marked "critical"/crash but without a target.

We need some error dialogs.

I checked in code to show alerts for any fatal failures that we encounter when launching (branch and trunk), and to then terminate. I'm gonna mark this fixed. File a new bug if you encounter a launch failure.

Checkin window: http://tinyurl.com/k4uz8 CVS Blame for strings file changes: http://landfill.mozilla.org/bonsai-test/bonsai/cvsblame.cgi?file=mozilla%2Fcamino%2Fresources%2Flocalized%2FEnglish.lproj/Localizable.strings&rev=&root=%2Fhome%2Fcvsroot

(In reply to comment #41) > Checkin window: http://tinyurl.com/k4uz8 > > CVS Blame for strings file changes: > http://landfill.mozilla.org/bonsai-test/bonsai/cvsblame.cgi?file=mozilla%2Fcamino%2Fresources%2Flocalized%2FEnglish.lproj/Localizable.strings&rev=&root=%2Fhome%2Fcvsroot > Are you sure that this is the right bug you commented on ?

Ludo: Yes. We'd like this bug for Camino 0.8.5, but have some questions. So, before I try to backport the patch, I wanted to get them answered. I simply put that there so I could know what needs to be done should we decide to backport it. A question for you: The second link lists string changes that would take place if we wanted to include this in 0.8.5. How much of a problem would that be for your translators?

(In reply to comment #43) > A question for you: The second link lists string changes that would take place > if we wanted to include this in 0.8.5. How much of a problem would that be for > your translators? We would loose some languages we had in 0.8.4 because I don't have translators anymore (read Chinese) - that would be one point. The other one would be the impossibility to reuse 0.8.4 and "just changing" the version #. I thought .5 was a security release !

(In reply to comment #44) > I thought .5 was a security release ! It's a "security and stability release", but so far most of the stability fixes (for the bookmarks dataloss that was so common with 0.8.x) we've been considering have not been backportable. This one I didn't realize had string changes :-(

Per Ludo, we're not going to take this in Camino 0.8.5.