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.

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.

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 ***

marking rtm- to get it off the pdt radar. fyi, the new bug is #58922

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.

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.

*** 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. ***

*** 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.

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.

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]

Adding mostfreq keyword.

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

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

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.

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

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.

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...

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