Closed Bug 201506 Opened 21 years ago Closed 19 years ago

Missing profile causes crash while trying to access bookmarks [@ -[BookmarksDataSource outlineView:numberOfChildrenOfItem:]]

Categories

(Camino Graveyard :: Bookmarks, defect, P2)

Product:
Camino Graveyard
Component:
Bookmarks
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino1.0

People

(Reporter: dana.kashubeck, Assigned: sfraser_bugs)

References

Details

(Keywords: crash, fixed1.8)

Crash Data

Attachments

(5 files)

Crash Log
3.62 KB, text/plain
Details
Crash Log (Jag)
5.99 KB, text/plain
Details
Crash logs
12.22 KB, text/plain
Details
Crash log
5.97 KB, text/plain
Details
Crash Log (Talkback ID TB275142Y)
3.77 KB, text/plain
Details 
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.
Attached file Crash Log — 
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.
Keywords: crash
Summary: Crash while trying to access bookmarks → Crash while trying to access bookmarks [@ -[BookmarksDataSource outlineView:numberOfChildrenOfItem:]]
Attached file Crash Log (Jag) — 
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.
Attached file Crash logs — 
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Still seeing it in build ID 2003060204.  See Talkback ID TB275047Z.
Attached file Crash log — 
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.
Assignee: sfraser → ccarlen
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?
Summary: Crash while trying to access bookmarks [@ -[BookmarksDataSource outlineView:numberOfChildrenOfItem:]] → Missing profile causes crash while trying to access bookmarks [@ -[BookmarksDataSource outlineView:numberOfChildrenOfItem:]]
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.
Assignee: ccarlen → sfraser_bugs
Priority: -- → P2
Target Milestone: --- → Camino1.0
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
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.
Crash Signature: [@ -[BookmarksDataSource outlineView:numberOfChildrenOfItem:]]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: