44093 - crash scrolling folder pane [@ nsXULTreeOuterGroupFrame::FindPreviousRowContent]

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[David :Bienvenu]

parentContent is null, here's the stack trace.  What happens is that I'll read a 
few messages, scroll the folder pane around a bit, and then get in a situation 
where the folder pane stops painting, so that it ends up blank. Right after 
that, I crash. Nothing interesting is displayed on the console.

nsXULTreeOuterGroupFrame::FindPreviousRowContent(int & 0x00000001, nsIContent * 
0x00000000, nsIContent * 0x00000000, nsIContent * * 0x0012f38c) line 813 + 47 
bytes
nsXULTreeOuterGroupFrame::InternalPositionChanged(nsXULTreeOuterGroupFrame * 
const 0x02838970, int 0x00000001, int 0x00000001) line 494 + 47 bytes
nsXULTreeOuterGroupFrame::PositionChanged(nsXULTreeOuterGroupFrame * const 
0x02838a24, int 0x000002c1, int 0x000002b2) line 452
nsSliderFrame::SetCurrentPosition(nsIContent * 0x033d2180, nsIFrame * 
0x028393b8, int 0x000002b2) line 692
nsSliderFrame::HandleEvent(nsSliderFrame * const 0x028392f8, nsIPresContext * 
0x02527b70, nsGUIEvent * 0x0012f8a8, nsEventStatus * 0x0012f798) line 454
PresShell::HandleEventInternal(nsEvent * 0x0012f8a8, nsIView * 0x033d96d0, 
nsEventStatus * 0x0012f798) line 3917 + 38 bytes
PresShell::HandleEvent(PresShell * const 0x02679b54, nsIView * 0x033d96d0, 
nsGUIEvent * 0x0012f8a8, nsEventStatus * 0x0012f798, int & 0x00000001) line 3837 
+ 23 bytes
nsView::HandleEvent(nsView * const 0x033d96d0, nsGUIEvent * 0x0012f8a8, unsigned 
int 0x0000001c, nsEventStatus * 0x0012f798, int & 0x00000001) line 782
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x026783c0, nsGUIEvent * 
0x0012f8a8, nsEventStatus * 0x0012f798) line 1389
HandleEvent(nsGUIEvent * 0x0012f8a8) line 69
nsWindow::DispatchEvent(nsWindow * const 0x026780b4, nsGUIEvent * 0x0012f8a8, 
nsEventStatus & nsEventStatus_eIgnore) line 560 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8a8) line 581
nsWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000) line 
3679 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000) 
line 3886
nsWindow::ProcessMessage(unsigned int 0x00000200, unsigned int 0x00000001, long 
0x01c900bf, long * 0x0012fc24) line 2779 + 24 bytes

Comment 1

[David :Bienvenu]

adding crash keyword. This seems to be new behaviour since the new tree control 
landed.

Comment 2

[David :Bienvenu]

adding crash keyword

Comment 3

[Jay Patel [:jay]]

Adding topcrash keywork, made top10 talkback crash list today.

Comment 4

[David Hyatt]

fixed.

Comment 5

[Shiva Thirumazhusai]

This crash still happens in the latest builds. Atleast 10+ crashes are reported 
in the last 10 days.

nsXULTreeOuterGroupFrame::FindPreviousRowContent
Stack Trace: 
nsXULTreeOuterGroupFrame::FindPreviousRowContent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp
nsXULTreeOuterGroupFrame::InternalPositionChanged
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp
nsXULTreeOuterGroupFrame::PositionChanged
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp
nsSliderFrame::SetCurrentPosition
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp
nsSliderFrame::HandleEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp
nsViewManager2::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp
nsWindow::DispatchEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
nsWindow::WindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp
USER32.dll + 0x1820 (0x77e71820)
0x00f9009d

nsXULTreeOuterGroupFrame::FindPreviousRowContent 1cf70567

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-24 UptimeMinutes: 165 Total: 165 
OS: Windows NT 4.0 build 1381
URL: 
Comment: Crashed when scrolling in Mail
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14725791

nsXULTreeOuterGroupFrame::FindPreviousRowContent 4907d116

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-24 UptimeMinutes: 16 Total: 68 
OS: Windows NT 5.0 build 2195
URL: 
Comment: scrolling "viciously" in the bookmarks manager (grab and drag up and
down rapidly).
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14727639

nsXULTreeOuterGroupFrame::FindPreviousRowContent a13d3555

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-24 UptimeMinutes: 37 Total: 37 
OS: Windows NT 4.0 build 1381
URL: 
Comment: crash again with deleting the last message in thread pane and then
scrolling in the folder pane. Known bug reported. 7-24 am build. win32.
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14729525

nsXULTreeOuterGroupFrame::FindPreviousRowContent 660a97b5

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-25 UptimeMinutes: 231 Total: 396 
OS: Windows NT 4.0 build 1381
URL: 
Comment: Crashed while scrolling in Mail
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14767992

nsXULTreeOuterGroupFrame::FindPreviousRowContent 6f5baa51

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072409 CrashDate: 2000-07-25 UptimeMinutes: 108 Total: 108 
OS: Windows NT 4.0 build 1381
URL: 
Comment: 
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14787009

nsXULTreeOuterGroupFrame::FindPreviousRowContent 233b26b5

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072421 CrashDate: 2000-07-25 UptimeMinutes: 54 Total: 54 
OS: Windows 98 4.10 build 67766446
URL: 
Comment: Opening IMAP "INBOX" after having selected another folder and not
waited for action to be finished.
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14835330

nsXULTreeOuterGroupFrame::FindPreviousRowContent 5747ba5a

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072509 CrashDate: 2000-07-26 UptimeMinutes: 267 Total: 267 
OS: Windows NT 4.0 build 1381
URL: www.mirc-colors.com
Comment: trying to leave the page.
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14851509

nsXULTreeOuterGroupFrame::FindPreviousRowContent eaada389

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072609 CrashDate: 2000-07-27 UptimeMinutes: 16 Total: 25 
OS: Windows NT 5.0 build 2195
URL: 
Comment: Scrolling the message pane in mail /news
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14881982

nsXULTreeOuterGroupFrame::FindPreviousRowContent 11d4e2e6

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072509 CrashDate: 2000-07-25 UptimeMinutes: 4 Total: 4 
OS: Windows 98 4.10 build 67766222
URL: 
Comment: 
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14882515

nsXULTreeOuterGroupFrame::FindPreviousRowContent cc949fc6

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsXULTre
eOuterGroupFrame.cpp
line 838
Build: 2000072509 CrashDate: 2000-07-27 UptimeMinutes: 84 Total: 87 
OS: Windows NT 4.0 build 1381
URL: 
Comment: 
Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=14889612

Comment 6

[David :Bienvenu]

FWIW, I no longer see this bug, but it only stopped happening last week, when
43374 was fixed. This would be consistent with the last talkback reports showing
this crash occuring on 7/27, when this 43374 was fixed.

Comment 7

[lchiang]

adding myself and laurel to cc: list.  

Comment 8

[Peter Trudelle]

nsbeta3+

Comment 9

[Peter Trudelle]

Has anyone seen this since 7/27?  I haven't been able to get cyclone queries to
show any, so I must be doing something wrong, and now it seems to be down.

Comment 10

[David Hyatt]

Mass-accepting.

Comment 11

[Peter Trudelle]

P1/Critical, but if nobody can reproduce it, or show evidence of it still
happening, and soon, then I'm going to resolve as WFM.

Comment 12

[John Morrison]

I did a cyclone query, and got a lot of matches for this, but none after 
08/15 (if I did the query right). Almost all of the ones I found had build ID 
080712, which I believe is the PR2 build ID. The comments mostly revolved 
around something to do with scrolling in trees (mail/ftp/bookmarks).

So:
1) This bug seems to be not occurring in recent builds
2) it wasn't fixed by bug 43374, as that fix went into the PR2 bits, yet 
   PR2 is hitting this crash a lot for people who downloaded it.

I also tried to reproduce this manually, but could not.

Comment 13

[David Hyatt]

Fixed.

Comment 14

[John Morrison]

Reopening. Something has changed to start triggering this again. I hit this
today in the tree in the prefs panel. I then did a talkback query and found
44 recent talkback incidents, all with build ID after 08/28, almost all of
which had the (abbreviated) stack trace of : 

nsXULTreeOuterGroupFrame::FindPreviousRowContent 
                                     [nsXULTreeOuterGroupFrame.cpp, line 813]
nsXULTreeOuterGroupFrame::InternalPositionChanged 
                                     [nsXULTreeOuterGroupFrame.cpp, line 494] 
nsXULTreeOuterGroupFrame::PositionChanged 
                                     [nsXULTreeOuterGroupFrame.cpp, line 453] 
nsSliderFrame::SetCurrentPosition               [nsSliderFrame.cpp, line 701] 
nsSliderFrame::HandleEvent                      [nsSliderFrame.cpp, line 480] 

Comment 15

[John Morrison]

Here is how to reproduce. With the default set of bookmarks for the commercial
build, open the bookmark manager. 

Expand most of the folders to get a scrollbar. Select one of the folder items
in the middle of the list (e.g. News and Sports). Make sure that the scrollbar 
thumb is neither at the top nor the bottom of the slider.

Now delete the selected folder (which also deletes the child bookmarks). You
should see the "white holes" have opened up in the tree rows. Now, grab the 
scrollbar thumb and yank it up and down. You should crash. 

(That seems contrived, but it is intended so hyatt can reproduce the crash 
easily. The other crashes occurred in various trees, and people were not always
clear on exactly how they had hit this state, but they were hitting it 
(including selmer, asa, phil in the email of the incidents)). 

Comment 16

[Phil Peterson]

PDT agrees P1

Comment 17

[David Hyatt]

I nailed it.  I found the core case that caused this again.

Comment 18

[scottputterman]

I just got this crash today in my debug build from this morning (9/21) with the 
exact same crash and with the exact same circumstances as bienvenu originally 
pointed out in the bug while scrolling my folder pane.

It seems like we could protect against the crash in a couple of ways:

  //Add a check for parent content some place in FindPreviousRowContent
  if(!parentContent)
    return 
  parentContent->GetTag(*getter_AddRefs(tag));
  if (tag && tag.get() == nsXULAtoms::tree) {
    // Hopeless. It ain't in there.
    return;
  }


Or in the calling function InternalPositionChanged, not call 
FindPreviousRowContent if rowContent is null. It may not solve the problem 
that's causing it, but at least it might prevent the crash.

Comment 19

[scottputterman]

adding myself to cc.

Comment 20

[scottputterman]

It just happened to me again the next time I started up, so something must have 
broken recently since I had never had this crash before.

Comment 21

[David Hyatt]

I'm guessing that nisheeth's async reflow landing has enabled the tree to get 
out of sync.  Yay. :)

Comment 22

[scottputterman]

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

Comment 23

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

This is showing up prominently in talkback data since 2000-09-20-06.

Comment 24

[Peter Trudelle]

mass-adding rtm keyword to all open nsbeta3+ xptoolkit bugs

Comment 25

[Peter Trudelle]

nsbeta3-, rtm+, possibly caused by asynch reflow

Comment 26

[David Hyatt]

Should also be fixed with eric's landing.

Comment 27

[Phil Peterson]

PDT marking [rtm need info] until patch and code reviews are available.
Definitely want a fix for this though.

Comment 28

[Eric Vaughan]

My current build fails when you try to delete bookmarks in this way it crashes 
in javascript somewhere. If I delete a header in the middle of mail it works 
with my new changes. Does this crash in the regular tree?

Comment 29

[Eric Vaughan]

You can also reproduce this as follows:

1) open mail
2) select a header in about the middle of the list
3) click on the sender header of mail to make it filter by sender.

Poof you crash. Same stack track.

Comment 30

[jefft]

I just got it crash exactly with the same stack while doing mail threading. 
Apparently we are dereferencing a null pointer - parentConten->GetTag(), line 
824. A defensive coding could prevent the hard crash. I'll be testing with the 
following patch.

Index: nsXULTreeOuterGroupFrame.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/xul/base/src/nsXULTreeOuterGroupFrame.cpp,v
retrieving revision 1.26
diff -c -r1.26 nsXULTreeOuterGroupFrame.cpp
*** nsXULTreeOuterGroupFrame.cpp        2000/09/20 23:10:48     1.26
--- nsXULTreeOuterGroupFrame.cpp        2000/10/03 21:43:49
***************
*** 765,770 ****
--- 765,771 ----
    }
    else if (aDownwardHint) {
      parentContent = dont_QueryInterface(aDownwardHint);
+     if (!parentContent) return;
      parentContent->ChildCount(index);
    }

***************
*** 778,783 ****
--- 779,785 ----
    for (PRInt32 i = index-1; i >= 0; i--) {
      nsCOMPtr<nsIContent> childContent;
      parentContent->ChildAt(i, *getter_AddRefs(childContent));
+     if (!childContent) return;
      nsCOMPtr<nsIAtom> tag;
      childContent->GetTag(*getter_AddRefs(tag));
      if (tag.get() == nsXULAtoms::treerow) {
***************
*** 803,808 ****
--- 805,811 ----
          for (j = childContentCount-1; j >= 0; j--) {

            childContent->ChildAt(j, *getter_AddRefs(grandChild));
+           if (!grandChild) return ;
            nsCOMPtr<nsIAtom> grandChildTag;
            grandChild->GetTag(*getter_AddRefs(grandChildTag));
            if (grandChildTag.get() == nsXULAtoms::treechildren)
***************
*** 822,827 ****
--- 825,831 ----
      }
    }

+   if (!parentContent) return;
    nsCOMPtr<nsIAtom> tag;
    parentContent->GetTag(*getter_AddRefs(tag));
    if (tag && tag.get() == nsXULAtoms::tree) {

-	parentContent	{...}
+	mRawPtr	0x00000000
+	tag	{...}
+	this	0x015226a4

nsXULTreeOuterGroupFrame::FindPreviousRowContent(int & 1, nsIContent * 
0x00000000, nsIContent * 0x00000000, nsIContent * * 0x0012f3c8) line 826 + 47 
bytes
nsXULTreeOuterGroupFrame::InternalPositionChanged(nsXULTreeOuterGroupFrame * 
const 0x015226a4, int 1, int 1) line 502 + 47 bytes
nsXULTreeOuterGroupFrame::PositionChanged(nsXULTreeOuterGroupFrame * const 
0x01522758, int 340, int 322) line 462
nsSliderFrame::SetCurrentPosition(nsIContent * 0x0792afa0, nsIFrame * 
0x01449ea0, int 322) line 701
nsSliderFrame::HandleEvent(nsSliderFrame * const 0x01522db4, nsIPresContext * 
0x05d8a110, nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8) line 463
PresShell::HandleEventInternal(nsEvent * 0x0012f8c8, nsIView * 0x079587d0, 
unsigned int 1, nsEventStatus * 0x0012f7b8) line 4270 + 38 bytes
PresShell::HandleEvent(PresShell * const 0x05d8e3f4, nsIView * 0x079587d0, 
nsGUIEvent * 0x0012f8c8, nsEventStatus * 0x0012f7b8, int 1, int & 1) line 4190 + 
25 bytes
nsView::HandleEvent(nsView * const 0x079587d0, nsGUIEvent * 0x0012f8c8, unsigned 
int 28, nsEventStatus * 0x0012f7b8, int 1, int & 1) line 379
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x05d8ecc0, nsGUIEvent * 
0x0012f8c8, nsEventStatus * 0x0012f7b8) line 1439
HandleEvent(nsGUIEvent * 0x0012f8c8) line 68
nsWindow::DispatchEvent(nsWindow * const 0x05d8e944, nsGUIEvent * 0x0012f8c8, 
nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8c8) line 702
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 3890 + 
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 
4100
nsWindow::ProcessMessage(unsigned int 512, unsigned int 1, long 14025589, long * 
0x0012fc44) line 2937 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x001905b8, unsigned int 512, unsigned int 1, long 
14025589) line 950 + 27 bytes
USER32! 77e7124c()

Comment 31

[jefft]

Attachment: a defensive fix

Comment 32

[Eric Vaughan]

Yes but by aborting are we leaving the tree in the right state? Reassigning to 
hyatt to take a look at the patch.

Comment 33

[David :Bienvenu]

I hit this crash yesterday, and continued past it with the debugger. In my case,
the tree was *not* in a good state, but it's probably better than crashing. I
think we should protect against the crash, since that's easy, and then try to
fix the underlying problem.

Comment 34

[Alec Flett]

throw an assertion in there before the bulletproofing, so at least we can catch
it when it happens

Comment 35

[scottputterman]

I agree that we should bulletproof this with the assertion.  If anyone can
reproduce this with the null check, can you close the mail window and then open
it up again and have the folder tree work?  If so, the fact that you can recover
added to the fact that you wouldn't crash is a big plus.

Comment 36

[David :Bienvenu]

yes, closing the mail window and re-opening it worked when I ran into this crash.

Comment 37

[David Hyatt]

Waiting on eric's tree landing before I muck further with trees.

Comment 38

[John Morrison]

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

Comment 39

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

According to today's list on n.p.m.crash-data, this is the #1 topcrash 
(excluding "MSVCRT.DLL", "msvcrt.dll", "libnecko.so", and "gkhtml.dll").

Comment 40

[lchiang]

hi hyatt - has eric's tree landing happened yet?  thanks.

Comment 41

[John Morrison]

Yes, Eric's changes to the tree have landed.

Comment 42

[(not reading, please use [e-mail] instead)]

I think this is still a topcrasher.

I think we should check in the defense patch,
but add some NS_ASSERTION(foo,"foo is null, see bug #44093");
everywhere we do the null checks.  that way it will still be a noticable bug in
debugs builds, not in release builds.

hyatt, if you are busy with other bugs and don't have the cycles to land this, I
can get a new patch (with the NS_ASSERTIONS()) and plead with the pdt to let me
check in.

Comment 43

[David Hyatt]

Here is a real patch for this.  You don't need to null-check quite so much,
since retrieved children can never be null.  Also added assertions.

Comment 44

[David Hyatt]

Attachment: Patch to stop crash.

Comment 45

[David Hyatt]

Looking for an r= and a= from the mailnews guys for my patch.  Then pdt will ++
it I hope.

Comment 46

[Jay Patel [:jay]]

This is indeed still a topcrasher (#2 on the list behind 
nsXULDocument::ResumeWalk, excluding MSVCRT.DLL and gkhtml.dll crashes). 

Comment 47

[(not reading, please use [e-mail] instead)]

r=sspitzer on the fix.

Comment 48

[David Hyatt]

Need an a=.  Alec?

Comment 49

[(not reading, please use [e-mail] instead)]

adding mscott for possible super review.

Comment 50

[Scott MacGregor]

sr=mscott. It'd be great to get this top crasher in rtm.

Comment 51

[David Hyatt]

Ok, PDT, this is ready for you.

Comment 52

[Alec Flett]

arg, would have sr'ed earlier if SERA wasn't so flakey!

Comment 53

[Peter Trudelle]

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

Comment 54

[Peter Trudelle]

PDT says rtm++, please land on branch ASAP, but please do not include cleanup of
the commented out code.

Comment 55

[David Hyatt]

Fixed.

Comment 56

[Peter "jag" Annema]

So, I'm seeing this assertion when I sort columns in the bookmarks manager.
Where should I start looking?

Comment 57

[John Morrison]

verified fixed -- talkback has no crashes for this stack since the patch 
went in, branch or trunk.