Closed Bug 22294 Opened 25 years ago Closed 25 years ago

Reproducable crash when sorting by Title in History window

Categories

(Core :: DOM: Navigation, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: MatsPalmgren_bugz, Assigned: waterson)

References

Details

Attachments

(5 files)

DESCRIPTION:
Reproducable crash when sorting by Title in History window

STEPS TO REPRODUCE:
1. start Mozilla
2. load http://www.mozilla.org/
3. invoke menu item Tasks->Tools->History
4. in History window, click on the heading of the Title column

ACTUAL RESULTS:
Crash

EXPECTED RESULTS:
No crash, history entries sorted by title

DOES NOT WORK CORRECTLY ON:
Mozilla nightly build 1999121915 on Windows NT 4.0 sp6.

ADDITIONAL INFO:
Stack dump follows...

FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
0012edc0 6063058c 0a5266a0 0012ee8c 0a4c6650 60b75933
rdf!nsQueryReferent::nsQueryReferent [omap]
0012eee4 606302c8 0a517b60 0012f030 0012f048 0a4c6610
rdf!nsQueryReferent::nsQueryReferent [omap]
0012f060 60b92fb9 0a079450 0a517b60 0a50ae60 0a50a2e0
rdf!nsQueryReferent::nsQueryReferent [omap]
0012f078 6089c433 0a079450 00000003 00000003 0012f09c xpcom!XPTC_InvokeByIndex
0012f198 6089cc0a 0a4c6650 0a50af20 0a50af74 03000000 xpc3250!NSGetModule
0012f1d8 609d4640 0a50abf0 09737c10 00000003 09747d0c xpc3250!NSGetModule
0012f27c 609d81dc 0a4c6650 00000003 00000000 09747cf0 js3250!js_Invoke
0012f3dc 609d4680 0a4c6650 0012f460 0012f5f0 09747cd4 js3250!js_Invoke
0012f474 609d81dc 0a4c6650 00000001 00000000 00000000 js3250!js_Invoke
0012f5d4 609d4680 0a4c6650 0012f658 00000001 0012f68c js3250!js_Invoke
0012f66c 609d47b1 0a4c6650 00000001 00000002 80000000 js3250!js_Invoke
0012f6e4 609c3b27 00000000 09737b48 09737b68 00000001 js3250!js_Invoke
0012f704 60a1ae08 0a4c6650 09737b48 09737b68 00000001
js3250!JS_CallFunctionValue
0012f758 60a2da51 0a4c5450 09737b48 09737b68 00000001
jsdom!NS_NewScriptGlobalObject
0012f834 6022a242 0a53afc4 0012fab4 0a5177b0 0012fae4
jsdom!NS_NewScriptCharacterData
0012f9b0 6022a9a2 010375a0 0a53afc4 0a4c5450 0012fab4 gkhtml!NS_NewXMLDocument
0012f9e8 6064772b 00000000 0012fae4 0012fab4 00000007 gkhtml!NS_NewXMLDocument
0012fabc 6022c7a5 0a517860 0a4da960 0012fae4 0012fab4
rdf!NS_NewScriptXULDocument
0012fb28 6022bc59 0a524b30 0a4da960 0012fd0c 0012fccc
gkhtml!NS_NewEventListenerManager
0012fb90 601a9536 0a524b30 0a4da960 0012fd0c 0973d48c
gkhtml!NS_NewEventListenerManager
0012fbcc 602f1df9 00000000 0a528100 0012fd0c 0012fccc gkhtml!NS_NewPresShell
0012fc10 602f1dbe 00000000 0012fd0c 00000008 0012fccc
gkview!nsCreateInstanceByProgID::operator=
0012fc58 602f70bd 00000000 0a528100 0000001c 0012fccc
gkview!nsCreateInstanceByProgID::operator=
0012fcb4 602f2537 00000159 0000001a 0012fccc 0012fcfc
gkview!nsCreateInstanceByProgID::operator=
0012fcd0 6097528b 0a4da750 0000012d 00000000 609752d1
gkview!nsCreateInstanceByProgID::operator=
0012fce0 609752d1 0a4da524 0012fd0c 0012fcfc 0012fd84 gkwidget!NSGetFactory
(FPO: [3,0,2])
0012fcf4 60977c51 00000000 00000000 0a4da520 00000000 gkwidget!NSGetFactory
0012fd84 60977f90 0000012d 00000000 0a4da520 60977657 gkwidget!NSGetFactory
0012fd94 60977657 0000012d 00000000 006ed118 0a4da520 gkwidget!NSGetFactory
(FPO: [2,0,1])
0012fe34 6097558b 00000202 00000000 001a0017 0012fe78 gkwidget!NSGetFactory
0012fe64 77e7124c 022f0b44 00000202 00000000 00000000 gkwidget!NSGetFactory
0012feb4 001a0017 156c0e65 00000024 0000003a 0012ff14 user32!TranslateMessageEx
Assignee: radha → slamm
Slamm does History window...
Priority: P3 → P1
Target Milestone: M13
Steve, is this for you or alecf?
*** Bug 22674 has been marked as a duplicate of this bug. ***
*** Bug 22674 has been marked as a duplicate of this bug. ***
*** Bug 22674 has been marked as a duplicate of this bug. ***
(Sorry for the multiple duplicate-markings; fumble-finger handling of
mid-air collision by yrs. truly to blame)

Reproduced on 1999-12-28-08-M13 nightly binary on Windows NT 4.0sp3 ...

A note from bug 22674 -- trying to sort by "URL" also causes an immediate
crash (also reproduced with 1999-12-28-08-M13)
Assignee: slamm → rjc
Target Milestone: M13
Robert, this is dying in nsXULSortService.cpp:1405. Am I calling things
incorrectly, or is this a true backend bug?
Assignee: rjc → waterson
Chris, can you take a deeper look at this?

It appears to be happening because nsGlobalHistory::GetTargets() is returning
bogus rows from Mork. For example, in nsMdbTableEnumerator::GetNext() after the
line:
    nsCAutoString uri((const char*) yarn.mYarn_Buf, yarn.mYarn_Fill);
add the following:
    #ifdef    DEBUG
    printf("    ****  History URL: '%s'\n", uri.ToNewCString());
    #endif
and then run Mozilla and open up the History window. You'll see that the first
history item returned has a URI which is an empty string... which ends up
confusing a lot of code later on.
Status: NEW → ASSIGNED
Target Milestone: M13
rjc: you were right. I added some code that just ignores empty URIs, and
everything works ok. Had to delete my "history.dat" file first, of course. So
I'll add that, and then will try to figure out who's trying to add the empty
string to the global history.

As a side note, sorting uses ArcLabelsIn(), which is "difficult to implement" on
some platforms. In fact, for history, it's going to require me to do a full
table scan to correctly answer the query. Any way we can remove that?
ArcLabelsIn() is used by the sorting code to try and determine natural order
positioning.  I think we should always enforce a sort on some column (whether its
date visited, site name, ...) for history;  natural order won't be an issue and
we shouldn't have to worry about fully implementing ArcLabelsIn(), I suspect.
Tail wagging the dog? It seems wrong to say "you don't need to implement
ArcLabelsIn() correctly because sorting doesn't need it".

But hmm...

I guess I was confusing ArcLabelsIn() and GetSources(). Do you need
GetSources() to be implemented? (It looks like you do, at line 1194 of
nsXULSortService.cpp.) I can implement ArcLabelsIn() fairly cheaply, but
GetSources() will require a full table scan.
What, you don't like dogs?  :^)

Anyway, for sorting in particular, both ArcLabelsIn() as well as GetSources() are
used for determining natural order positioning.

I thought that Mork kept everything in memory (which in my opinion is bad, we're
going to need how many megs to run, with all of history in memory), so
implementing GetSources() shouldn't be "that bad" in terms of performance, should
it?

The way to get rid of the calls to ArcLabelsIn() and GetSources()  is to pass the
"property arc" in when XULSortServiceImpl::InsertContainerNode() is called from
the generic builder.  That's basically what the sorting code is looking for.  (I
seem to remember that there was some issue with getting the generic builder to do
that, but its been a while since I've looked at it.)
By the way, another thing to watch for is that the Find datasource (which you
were thinking about using for various History containments like "History by
Site", etc) works its magic by calling GetAllResources()... which I'd expect to
also require a full table scan.
I guess my beef with nsXULSortService::GetNodeValue() doing a ArcLabelsIn() and
GetSources() is mostly just that it is called from the "compare" function,
which means these (potentially very slow methods) will be called a ghastly
number of times.

Like you say, it seems like this information should be pushed down from the
container. If the container that you're sorting is an RDF:Seq, then by virtue
of enumerating the element, you know it's natural order. We'll figure something
out. I'll file a separate bug.
mscott: could you review the patch I just attached ("first patch"). As we'd
discussed on IRC, I've changed the code that pokes global history to use the
spec from aURI rather than the mURL string.
rjc: could you review the second patch for me? I added some sanity checking to
nsGlobalHistory.cpp's AddPage() method to disallow null URLs. Furthermore, I
implemented GetSource[s](). Oops, still gotta do ArcLabelsIn(). Anyway, this'll
give you something to look at to start...
rjc: ok, this time i mean it. take a look at the second patch (or the entire
nsGlobalHistory.cpp file). I've implemented ArcLabelsIn() and GetSource[s]().
Gimme your lovin' review, baby.
Chris, looks good to me.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fix checked in.

claudius: note that, to verify, you will need to remove "history.dat" from your
profile directory -before- starting the browser (current versions of
history.dat are corrupted).

thanks,
chris
Status: RESOLVED → VERIFIED
thanks for the tip. VERIFIED with the 2000011108 build
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: