Closed Bug 58238 Opened 24 years ago Closed 24 years ago

Crash in subscribe dialog trying to open "alt." subtree

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.6

People

(Reporter: waterson, Assigned: sspitzer)

References

Details

(Keywords: crash, Whiteboard: [rtm-])

Attachments

(3 files)

patch that makes us crash on startup, making the problem very easy to reproduce
939 bytes, patch
Details | Diff | Splinter Review
some of the changes required to fix this
2.09 KB, patch
Details | Diff | Splinter Review
a fix based on bienvenu's fix.
3.25 KB, patch
Details | Diff | Splinter Review 
I'm crashing trying to open the "alt." subtree in the news subscribe dialog on
news.mcom.com; have submitted a couple talkback reports. Here are repro
instructions.

1. Add account for news server "news.mcom.com"
2. Click "Subscribe"
3. Wait for all newsgroups to load (may take 2-3 minutes)
4. Either a) type "alt." or b) scroll to "alt" subtree and click twisty

Expected: "alt" subtree opens
Actual: crash

This happened with Nscp RTM branch build ID 2000-10-27-04.
Nominating for RTM: the "alt" subtree is pretty "high profile" if you, ah, know
what I mean.
Keywords: crash, rtm
yeah, alt is a popular thing.

does your crash look like the one in bug #51571

this bug will probably be a dup of that one.

I don't have a stack trace, but it does look similar. I've had similar reports
(crashing in the atom table) from people on n.p.m.rdf who were trying to read in
large RDF files. I'd bet we've got an atom refcounting bug somewhere.
In your install directory, in the components subdirectory, run talkback.exe and
you'll see the talkback IDs you submitted.  If you add those to the bug report
they'll be easier to find.
Whiteboard: [rtm need info]
My Incident IDs are:

  TB19898167H
  TB19897764X
  TB19897194X

after looking at the talkback incidents, this is a duplicate.

marking it so.  the fix will come when the subscribe architecture changes in 6.5

chris, is there a bug on this:

"I don't have a stack trace, but it does look similar. I've had similar reports
(crashing in the atom table) from people on n.p.m.rdf who were trying to read in
large RDF files. I'd bet we've got an atom refcounting bug somewhere."

I'll go start one, and cc the people who commented in n.p.m.rdf




*** This bug has been marked as a duplicate of 51571 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
marking rtm- to get it off the pdt radar.

fyi, the new bug is #58922
Whiteboard: [rtm need info] → [rtm-]
re-opening.

I'm about to land a fix of the subscribe architecture, but I still see this.

marking p1, mail1, crash, etc.

I'll start working on this soon.
Status: RESOLVED → REOPENED
Keywords: mail1
OS: Windows NT → All
Priority: P3 → P1
Resolution: DUPLICATE → ---
Summary: crash in subscribe dialog → crash in subscribe dialog trying to open "alt." subtree
Target Milestone: --- → mozilla0.6
stack trace and comments from #51571

Compare(const basic_nsAReadableString<unsigned short> & {...}, const
basic_nsAReadableString<unsigned short> & {...}) line 1285 + 11 bytes
Compare(const basic_nsAReadableString<unsigned short> & {...}, const unsigned
short * 0x08214f9c) line 1326 + 22 bytes
CompareKeys(const basic_nsAReadableString<unsigned short> * 0x0821ab9c, const
unsigned short * 0x08214f9c) line 181 + 13 bytes
PL_HashTableRawLookup(PLHashTable * 0x00f141d0, unsigned int 2228717036, const
void * 0x0821ab9c) line 181 + 28 bytes
PL_HashTableRawAdd(PLHashTable * 0x00f141d0, PLHashEntry * * 0x05e9e9e8,
unsigned int 1855767017, const void * 0x082c0d0c, void * 0x082c0d00) line 258 +
23 bytes
NS_NewAtom(const basic_nsAReadableString<unsigned short> & {...}) line 215 + 31
bytes
nsXULAttribute::SetValueInternal(const basic_nsAReadableString<unsigned short> &
{...}) line 560 + 10 bytes
nsXULAttribute::nsXULAttribute(nsIContent * 0x071c8ee0, nsINodeInfo *
0x03ac9930, const basic_nsAReadableString<unsigned short> & {...}) line 223
nsXULAttribute::Create(nsIContent * 0x071c8ee0, nsINodeInfo * 0x03ac9930, const
basic_nsAReadableString<unsigned short> & {...}, nsXULAttribute * * 0x00129b5c)
line 246 + 39 bytes
nsXULElement::SetAttribute(nsXULElement * const 0x071c8ee0, nsINodeInfo *
0x03ac9930, const basic_nsAReadableString<unsigned short> & {...}, int 0) line
2710 + 21 bytes
nsXULElement::SetAttribute(nsXULElement * const 0x071c8ee0, int 0, nsIAtom *
0x01d375e0, const basic_nsAReadableString<unsigned short> & {...}, int 0) line
2789 + 29 bytes
nsXULTemplateBuilder::BuildContentFromTemplate(nsIContent * 0x03b9a430,
nsIContent * 0x081ede90, nsIContent * 0x082880e0, int 1, nsIRDFResource *
0x07148520, int 0, Match * 0x05e8ee50, nsIContent * * 0x0012b2e4, int *
0x0012b2e8) line 5378 + 52 bytes
nsXULTemplateBuilder::BuildContentFromTemplate(nsIContent * 0x03b9a580,
nsIContent * 0x081ede90, nsIContent * 0x081ede90, int 1, nsIRDFResource *
0x07148520, int 0, Match * 0x05e8ee50, nsIContent * * 0x0012b2e4, int *
0x0012b2e8) line 5356 + 61 bytes
nsXULTemplateBuilder::CreateContainerContents(nsIContent * 0x081ede90,
nsIRDFResource * 0x06dbb9d0, int 0, nsIContent * * 0x0012b2e4, int * 0x0012b2e8)
line 6127
nsXULTemplateBuilder::OpenContainer(nsXULTemplateBuilder * const 0x03b99da4,
nsIContent * 0x081ede90) line 4312 + 54 bytes
nsXULDocument::OpenWidgetItem(nsIContent * 0x081ede90) line 4488 + 22 bytes
nsXULDocument::AttributeChanged(nsXULDocument * const 0x03a4fd40, nsIContent *
0x081ede90, int 0, nsIAtom * 0x01d42d40, int -1) line 1645
nsXULElement::SetAttribute(nsXULElement * const 0x081ede90, nsINodeInfo *
0x08281200, const basic_nsAReadableString<unsigned short> & {...}, int 1) line 2769
nsXULElement::SetAttribute(nsXULElement * const 0x081ede98, const
basic_nsAReadableString<unsigned short> & {...}, const
basic_nsAReadableString<unsigned short> & {...}) line 1229 + 31 bytes
ElementSetAttribute(JSContext * 0x03a19290, JSObject * 0x05dc9b58, unsigned int
2, long * 0x05e72564, long * 0x0012b9b8) line 239 + 26 bytes
js_Invoke(JSContext * 0x03a19290, unsigned int 2, unsigned int 0) line 731 + 23
bytes
js_Interpret(JSContext * 0x03a19290, long * 0x0012c340) line 2538 + 15 bytes
js_Invoke(JSContext * 0x03a19290, unsigned int 1, unsigned int 2) line 748 + 13
bytes
js_InternalInvoke(JSContext * 0x03a19290, JSObject * 0x05dc9930, long 98343952,
unsigned int 0, unsigned int 1, long * 0x0012c4d4, long * 0x0012c464) line 821 +
19 bytes
JS_CallFunctionValue(JSContext * 0x03a19290, JSObject * 0x05dc9930, long
98343952, unsigned int 1, long * 0x0012c4d4, long * 0x0012c464) line 3175 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x03a196d0, void * 0x05dc9930,
void * 0x05dc9c10, unsigned int 1, void * 0x0012c4d4, int * 0x0012c4d0, int 0)
line 902 + 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x08280a24) line 154 + 64 bytes
nsXBLEventHandler::ExecuteHandler(nsXBLEventHandler * const 0x0822ab50, const
basic_nsAReadableString<unsigned short> & {...}, nsIDOMEvent * 0x08280a24) line 555
nsXBLEventHandler::MouseClick(nsIDOMEvent * 0x08280a24) line 260 + 36 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x03a4caa0, nsEvent *
0x0012d39c, nsIDOMEvent * * 0x0012d2c8, nsIDOMEventTarget * 0x081aa13c, unsigned
int 2, nsEventStatus * 0x0012d694) line 861 + 23 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x081aa130, nsIPresContext *
0x03a4caa0, nsEvent * 0x0012d39c, nsIDOMEvent * * 0x0012d2c8, unsigned int 2,
nsEventStatus * 0x0012d694) line 3257
nsXULElement::HandleDOMEvent(nsXULElement * const 0x081ede90, nsIPresContext *
0x03a4caa0, nsEvent * 0x0012d39c, nsIDOMEvent * * 0x0012d2c8, unsigned int 2,
nsEventStatus * 0x0012d694) line 3265 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x04c069c0, nsIPresContext *
0x03a4caa0, nsEvent * 0x0012d39c, nsIDOMEvent * * 0x0012d2c8, unsigned int 2,
nsEventStatus * 0x0012d694) line 3265 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x067b0ef0, nsIPresContext *
0x03a4caa0, nsEvent * 0x0012d39c, nsIDOMEvent * * 0x0012d2c8, unsigned int 2,
nsEventStatus * 0x0012d694) line 3265 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0686ba60, nsIPresContext *
0x03a4caa0, nsEvent * 0x0012d39c, nsIDOMEvent * * 0x0012d2c8, unsigned int 1,
nsEventStatus * 0x0012d694) line 3265 + 39 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012d39c, nsIView * 0x00000000,
nsEventStatus * 0x0012d694) line 4040 + 45 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x03a4b9e0, nsEvent *
0x0012d39c, nsIFrame * 0x05e558d4, nsIContent * 0x0686ba60, nsEventStatus *
0x0012d694) line 4021 + 18 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x03969ef0, nsIPresContext * 0x03a4caa0, nsMouseEvent * 0x0012d7a4,
nsEventStatus * 0x0012d694) line 1811 + 59 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03969ef8,
nsIPresContext * 0x03a4caa0, nsEvent * 0x0012d7a4, nsIFrame * 0x05e558d4,
nsEventStatus * 0x0012d694, nsIView * 0x081a0e10) line 892 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012d7a4, nsIView * 0x081a0e10,
nsEventStatus * 0x0012d694) line 4060 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x03a4b9e4, nsIView * 0x081a0e10,
nsGUIEvent * 0x0012d7a4, nsEventStatus * 0x0012d694, int 1, int & 1) line 3975 +
23 bytes
nsView::HandleEvent(nsView * const 0x081a0e10, nsGUIEvent * 0x0012d7a4, unsigned
int 28, nsEventStatus * 0x0012d694, int 1, int & 1) line 379
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x03a4c790, nsGUIEvent *
0x0012d7a4, nsEventStatus * 0x0012d694) line 1429
HandleEvent(nsGUIEvent * 0x0012d7a4) line 68
nsWindow::DispatchEvent(nsWindow * const 0x081a1624, nsGUIEvent * 0x0012d7a4,
nsEventStatus & nsEventStatus_eIgnore) line 614 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012d7a4) line 635
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3811 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4021
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 3211271, long *
0x0012db20) line 2889 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x0d310bb0, unsigned int 514, unsigned int 0, long
3211271) line 883 + 27 bytes
USER32! 77e71820()
JS3250! js_WithClass + 3863 bytes



it looks like we are crashing as a result of trying to grow the hash table in
PL_HashTableRawAdd().

the call to PL_HashTableRawLookup() that causes the crash comes from this for
loop at line 255 in plhash.c

        for (i = 0; i < n; i++) {
            for (he = oldbuckets[i]; he; he = next) {
                next = he->next;
                hep = PL_HashTableRawLookup(ht, he->keyHash, he->key);
                PR_ASSERT(*hep == 0);
                he->next = 0;
                *hep = he;
            }
        }


accepting.
Status: REOPENED → ASSIGNED
*** Bug 51571 has been marked as a duplicate of this bug. ***
*** Bug 51571 has been marked as a duplicate of this bug. ***
*** Bug 60453 has been marked as a duplicate of this bug. ***
QA Contact: esther → stephend
*** Bug 60798 has been marked as a duplicate of this bug. ***
nominating for fix in 6.5
We get a log of bug reports on this crash.
Keywords: mail2
adding self to cc list because interested in keeping track of this bug
I have been experiencing this bug too, both at home: PC, WinMe,
news.freeserve.co.uk, and at work: PC, Win98. It applies to all of the handful
of builds I have tried, for example this one is 2000112204. The bug happens
exactly as others have described it, so I won't say more. What I wanted to say was:

Work-around:

How to subscribe to a particular alt.* newsgroup on WinMe.

(You can probably work this out for yourself, but this may save you some time).
In a directory called something like

C:\WINDOWS\Application Data\Mozilla\Users50\default\News

there will be a file called something like

news.freeserve.co.uk.rc

open this file in any text editor, it consists of lines like:

rec.games.abstract:1-5563
comp.lang.c.moderated:1-16870

There may be more random numbers after the colon, but that doesn't matter. All
you need to do is to add a line like

alt.games.tiddlywinks:

restart mozilla, and you will find that you have successfully subscribed to that
group.

I should point out that I don't really know what I am talking about, but this
works for me on WinME. I expect that there is a simmilar solution on other
platforms.

I'm not seeing this on Windows NT, Build ID 2000112908, Commercial bits.  Unable
to test on other platforms at the moment.  Chris, are you still seeing this?
(The subscribe dialog has been tweaked greatly since you've reported this).
It still happens.  I can reproduce fairly easily and also see that there's been
a few recent reports marked duplicates.
On my machine opening the alt subtree is dog slow, but that is to be expected.
Laurel, how many times do you have to click the twisty before seeing the crash?
 I've clicked it ~20 times consecutively and haven't seen a crash.
Brad, do you see this on Mac?
stephend, i can get this to happen on winNT, using 2000.11.29.09 comm verif bits
[and using news.netscape.com as the server]. i was able to expand alt.*, but
once i tried to expand alt.binaries.*, it crashed --or rather, it crashed right
after i single-clicked alt.binaries.* [to select/highlight it]. talkback report
is at
http://cyclone.mcom.com/reports/SingleIncidentInfo.cfm?dynamicBBID=22020587

also occurred on linux [same build id], but it took the third double-click for a
crash to occur:
http://cyclone.mcom.com/reports/SingleIncidentInfo.cfm?dynamicBBID=22020376

Platforms: ALL.
Hardware: PC → All
using 2000.11.29.09 bits on Mac OS 9.0, i don't get as far as a list of group
--i crash in the middle of the initial refresh
http://cyclone.mcom.com/reports/SingleIncidentInfo.cfm?dynamicBBID=22021653:

0x0045837c 
0x0044d3b4 
InterfaceLib + 0x16a60 (0xffd0e1e0) 
nsMemoryImpl::IsLowMemory() [nsMemoryImpl.cpp, line 338] 
MemoryFlusher::Run() [nsMemoryImpl.cpp, line 167] 
nsThread::Main() [nsThread.cpp, line 84] 
_PR_UserRunThread() [pruthr.c, line 489] 
_PR_UserDestroyThread() [pruthr.c, line 360]

however, bug 61374 already seems to cover this...
Not that I need to say it, but I see this also on Mac OS 8.6
crashes for me at just a single click. alt. can't be expanded _at all_ :(
Win98.
adding david to the cc list.

while purifying, I've see a IPR.

the invalid pointer read was in in nsCStringArray::EnumerateBackwards()

I'll give a stack trace.  I'm still working on this elusive beast.
from purify:

[E] IPR: Invalid pointer read in
nsCStringArray::EnumerateBackwards((*)(nsCString&,void *),void *) {1 occurrence}
        Reading 4 bytes from 0x0065007a (4 bytes at 0x0065007a illegal)
        Address 0x0065007a points into private memory
        Thread ID: 0xce
        Error location
            nsCStringArray::EnumerateBackwards((*)(nsCString&,void *),void *)
[xpcom.dll]
            nsCStringArray::EnumerateBackwards((*)(nsCString&,void *),void *)
[xpcom.dll]
            NS_NewAtom(basic_nsAReadableString<WORD> const&) [xpcom.dll]
            PL_HashTableRawLookup [plds4.dll]
            NS_NewScriptXULDocument [rdf.dll]
            NS_NewScriptXULDocument [rdf.dll]
            NS_NewScriptXULDocument [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            nsGetInterface::=(nsGetInterface const&) [rdf.dll]
            NS_NewScriptXULDocument [rdf.dll]
            NS_NewScriptXULDocument [rdf.dll]
            NS_NewScriptXULCommandDispatcher [rdf.dll]
            js_Invoke      [js3250.dll]
            js_Invoke      [js3250.dll]
*** Bug 62319 has been marked as a duplicate of this bug. ***
Summary: crash in subscribe dialog trying to open "alt." subtree → {crash} in subscribe dialog trying to open "alt." subtree
Severity: normal → critical
Keywords: nsbeta1
Summary: {crash} in subscribe dialog trying to open "alt." subtree → Crash in subscribe dialog trying to open "alt." subtree
attached is a patch that makes us crash on startup.  I've changed
PL_HashTableRawLookup() so that we always compare the keys, instead of first
comparing the keyHash.  by removing that performance optimization, I force the
crash to happen more frequently.  it happens while calling
PL_HashTableRawLookup() during the "grow hash table" process.

I'm still stumped, seeking help from others.  (purify was of no help on this bug.)
note, if I hack plhash.c to not grow, I don't crash.  it smells like memory
stompage top me, but purify and purify 2000 aren't showing anything.

still working on it (with help from brendan and bienvenu)
OK, I *think* I understand this (but I've thought that before :-( )

It looks like the atom code is just broken in the way it handles the keys it
passes to plhash. When it's doing a raw lookup, it passes in a pointer to an
nsAReadableString and this is what the Compare hash function it provides expects.

  PLHashEntry** hep = PL_HashTableRawLookup(gAtomHashTable, hashCode,
                                            &aString);

but when it adds an entry to the hash table, it passes in a PRUnichar *:

      PL_HashTableRawAdd(gAtomHashTable, hep, hashCode, id->mString, id);

so, if Compare gets called on this, it doesn't work, because id->mString is not
a pointer to an nsAReadableString.

static PRIntn CompareKeys( const nsAReadableString* k1, const PRUnichar* k2 )

Am I missing something?
Adding jst and scc to cc list.
Oh, that's just broken.  The types of key1 and key2 (the formal params to a
keyCompare function) must be identical.  It's true that PL_HashTableRawLoookup
*happens* to pass its key argument as the first param, and he->key as the second
-- but PL_HashTableRawAdd, when growing the table, *must* pass he->key to
PL_HashTableRawLookup, which means *both* args to keyCompare come from stored
keys (PRUnichar*), not from an actual parameter passed by the nsAtomTable code
(nsAReadableString*).

/be
Assignee: sspitzer → scc
Status: ASSIGNED → NEW
the attached patch fixes the crash, but I'm not proposing to check it in, since
the code should be refactored so that NS_NewAtom( const PRUnichar* us ) does the
work currently done by NS_NewAtom( const nsAReadableString& aString ), the
latter should call the former, and CalculateHash should go away. I'll leave that
to scc or jst.
I just talked to scc.  we've got an idea for the right way to fix this.  I'm
going to implement it and test it.

taking bug back from scc.

thanks to bienvenu for the excellent detective work.
Assignee: scc → sspitzer
accepting.

I'm starting with bienvenu's patch and making some changes (based on suggestions
from bienvenu and scc).

eta on checking the fix: monday, 12-18
Status: NEW → ASSIGNED
looks good to me, sr/r=bienvenu. However, the variable name "us" could be just
"s" :-)
I changed "us" to "str", I'll land this when the tree opens.

thanks again, david.


finally fixed!

way back in october, waterson wrote:

"I've had similar reports (crashing in the atom table) from people on n.p.m.rdf
who were trying to read in large RDF files."

that would be fixed now, too.  when loading up those large RDF files, we'd be
stuffing atoms into the atom table and growing it.  at some point, we'd hit this
crash.

the same crash is possible on hash table shrinkage, but less likely.

thanks again to bienvenu, scc, brendan, and hyatt for the help on this beast.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
I can verify this as fixed. However it took me _ages_ to get past typing in 
what I wanted.
Typing: alt   was fast enough
But as soon as it got to: .    it slowed down, almost like it was crashing.. 
but I stuck with it.. and eventually the next letters appears slowly.. and then 
YAY it worked. I was screaming and whooping and got sedated and dragged off by 
the men in white coats. But I did escape them to come back and tell you.
Would be nice though if this could be speeded up? Is that possible? A new bug?
Does anyone else see it this slow? Is it just my machine?
Win98 2000121904 P200 64MB RAM
I logged #62985 to cover the performance problem you mentioned.
I want you all to know I used and abused the alt tree with both the twisty and 
by typing into the newsgroup text field in the Subscribe window.  Didn't crash 
on Mac 2000122010, Linux 122008, and Windows 2000 2000122004.  I am seeing bug 
62985 like everyone else though but at least the crasher is fixed (for now ;-).
VERIFIED...
Status: RESOLVED → VERIFIED
*** Bug 58922 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Component: MailNews: Subscribe → MailNews: Message Display
QA Contact: stephend → search
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: