154815 - Second Launch Crashes Chimera

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[James]

The latest nightly, 6-28, downloaded via
ftp.mozilla.org/pub/chimera/nightly/latets-trunk/Chimera.dmg.gz crashes upon
second launch.

Step to reproduce:
1) Launch Navigator
2) Quit
3) Relaunch Navigator
4) Should quit

This even happens with a fresh profile, dragging ~/Library/Chimera to the
desktop and having Chimera build a new one.

Comment 1

[James]

Attachment: Crashlog showing the crash

Crashlog showing the crash

Comment 2

[Winnie Lam]

Attachment: crash log

I am having this problem with the 6-28 build as well.  I crashed while
performing the steps in bug 154701.  

After that, I was not able to use chimera at all.  
1.  Attempted to open 6-28 chimera build.
2.  Splash screen appears for a few seconds.  Crash occurs.
3.  Attempted to open 6-27 chimera build.
4.  Splash screen appears for a few seconds.  Crash occurs.
5.  Attempted to open 6-10 chimera build.  
6.  Splash screen appears for a few seconds.  Crash occurs.
7.  Reboot machine.
8.  Attempted to open 6-28 chimera build.
9.  Splash screen appears.  Crash occurs.
10. Moved profiles to desktop from .mozilla/Profiles/Chimera and
~/Library/chimera
11. Attempted to open 6-28 chimera build.
12.  Splash screen appears.  Crash occurs.
13.  Reboot machine.
14.  Attempted to open 6-28 chimera build.
15.  Splash screen apperas.  Crash occurs.

Comment 3

[Greg K.]

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

Comment 4

[Simon Fraser [no longer active]]

Crashing in bookmarks stuff.

Comment 5

[Simon Fraser [no longer active]]

        nsCOMPtr<nsIFile> profileDir;
        NS_GetSpecialDirectory(NS_APP_USER_PROFILE_50_DIR,
getter_AddRefs(profileDir));
        profileDir->Append(NS_LITERAL_STRING("bookmarks.xml"));

We end up with a null profileDir here. Conrad?

Comment 6

[Chris McAfee]

I am seeing this on the tboxes as well, deleting the whole tree
and then restarting, the build will be green the first time
and then it starts failing.

Comment 7

[Conrad Carlen (not reading bugmail)]

> profileDir->Append(NS_LITERAL_STRING("bookmarks.xml"));

> We end up with a null profileDir here. Conrad?

Yes - there should be a null-check there.

Comment 8

[Simon Fraser [no longer active]]

Taking.

Comment 9

[Simon Fraser [no longer active]]

This turned out to be a gcc codegen bug here:

::PtrToHand(decodedData, &(Handle)aliasH, aliasSize)

In optimized builds, aliasH ended up with null. The fix was to leave the cast
until later:

Handle newHandle;
::PtrToHand(decodedData, &newHandle, aliasSize)
...
::FSResolveAlias(nsnull, (AliasHandle)newHandle, ...)

Fix checked into the CHIMERA_M1_0_BRANCH. Should it go onto the trunk?

Comment 10

[Brian Ryner (not reading)]

dbaron tells me this could probably also be fixed by changing

::PtrToHand(decodedData, &(Handle)aliasH, aliasSize)

to

::PtrToHand(decodedData, (Handle)&aliasH, aliasSize)

Comment 11

[Conrad Carlen (not reading bugmail)]

Making this block bug 118203 so I am reminded to incorporate this when that goes
onto the trunk.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The approach bryner mentioned in comment 10 is the same one that I used to fix
bug 108585.  Based on my reading of the following statements in the C++
standard, the existing code should not even compile, since the result of a cast
is an rvalue and the unary & operator requires an lvalue.  I'm thinking of
filing a gcc bug...

5.4, clause 1 (cast notation):

  The result of the expression (T) cast-expression is of type T. The
  result is an lvalue if T is a reference type, otherwise the result is
  an rvalue.

(Note that 5.2.9, clause 1, says the same thing for static_cast.)

5.3.1, clause 2:

  The result of the unary & operator is a pointer to its operand. The
  operand shall be an lvalue or a qualified-id. In the first case, if
  the type of the expression is ``T,'' the type of the result is
  ``pointer to T.'' In particular, the address of an object of type ``cv
  T'' is ``pointer to cv T,'' with the same cv-qualifiers. For a
  qualified-id, if the member is a static member of type ``T'', the type
  of the result is plain ``pointer to T.'' If the member is a nonstatic
  member of class C of type T, the type of the result is ``pointer to
  member of class C of type T.''

Comment 13

[Simon Fraser [no longer active]]

Did you mean:

::PtrToHand(decodedData, (Handle*)&aliasH, aliasSize)

?

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yes, he did.  (bryner mentioned that typo to me when he mentioned this bug to me.)

Comment 15

[Winnie Lam]

Marking verified with 07-01 build.  Second launch no longer crashes chimera.