Closed Bug 11832 Opened 25 years ago Closed 25 years ago

[PP]mac[CRASH][REGRESSION] Bookmarks|Manage Bookmarks sometimes crashes

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cmaximus, Assigned: nisheeth_mozilla)

References

Details

(Whiteboard: looking into this for M9 fix on Sat 08/21) 

*Summary
        Selecting Bookmarks|Manage Bookmarks caused a crash(crashed OS too) for
me 4X in a row, but now it won't. Instead now I get a small window with absolutely
nothing in it.

*To Repro
	0. Add some bookmarks, play around with 'em.
        1. Select Bookmarks|Manage Bookmarks.
        2. Wait a sec.
        3. BOOM!

*Build info
        This bug was tested with the 1999081208 builds on MacOS 8.5.1, WinNTsp4, and
RHLinux6.0. This bug is reproducible on MacOS only. MacOS 8.6 was not tested at this time.

*Expected Results
        After selecting Manage Bookmarks one should be presented with the Manage Bookmarks
window and be able to go about one's merry way.

*Actual Results
        After selecting the Manage Bookmarks menuitem, sometimes Seamonkey and the whole
OS crash. I reproduced this several times. Recently however, instead of crahing I'm presented
with a small window with absolutely_nothing_in_it. No column headers, no content, nothing.

*Additional Info
	Sorry about the gratuitous use of the []'s I just didn't want it to miss anyone's radar.
ccing chofmann in hopes this will make M9.
here's the stack trace from Talkback:(excuse the formatting)





   .__ptr_glue





   nsExpatTokenizer::OpenInputStream()

                                                      [nsExpatTokenizer.cpp, line

530]



   nsExpatTokenizer::HandleExternalEntityRef()

                                                      [nsExpatTokenizer.cpp, line

608]



   doProlog()

                                                      [xmlparse.c, line 2268]



   prologProcessor()

                                                      [xmlparse.c, line 2145]



   prologInitProcessor()

                                                      [xmlparse.c, line 2134]



   XML_Parse()

                                                      [xmlparse.c, line 867]



   nsExpatTokenizer::ParseXMLBuffer()

                                                      [nsExpatTokenizer.cpp, line

287]



   nsExpatTokenizer::ConsumeToken()

                                                      [nsExpatTokenizer.cpp, line

325]



   nsParser::Tokenize()

                                                      [nsParser.cpp, line 1263]



   nsParser::ResumeParse()

                                                      [nsParser.cpp, line 885]



   nsParser::OnDataAvailable()

                                                      [nsParser.cpp, line 1168]



   nsDocumentBindInfo::OnDataAvailable()

                                                      [nsDocLoader.cpp, line

2057]



   Network.shlb + 0xf30 (0x0da23f00)





   Network.shlb + 0x220 (0x0da231f0)





   PL_HandleEvent()





   PL_ProcessPendingEvents()





   nsEventQueueImpl::ProcessPendingEvents()

                                                      [nsEventQueue.cpp, line

117]



   EventDispatchingFunc()

                                                      [nsEventQueueService.cpp,

line 352]



   _hashEnumerate()

                                                      [nsHashtable.cpp, line 81]



   PL_HashTableEnumerateEntries()





   nsHashtable::Enumerate()            [nsHashtable.cpp, line 210]



   nsEventQueueServiceImpl::ProcessEvents()   [nsEventQueueService.cpp, line 363]
Status: NEW → ASSIGNED
Target Milestone: M9
Love to work on this, but my build from today crashes on startup
Priority: P3 → P1
Summary: [PP][CRASH][REGRESSION] Bookmarks|Manage Bookmarks sometimes crashes → [PP]mac[CRASH][REGRESSION] Bookmarks|Manage Bookmarks sometimes crashes
Assignee: slamm → waterson
Status: ASSIGNED → NEW
taking this bug for initial investigation
Status: NEW → ASSIGNED
Whiteboard: looking into this
This is mac-specific, right? I am not able to reproduce on win32...
I was playing around on windows and saw a crash when playing with
the bookmark manage dialog..
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=12390124

the windows stack looks much different
ncident ID 12390124
0x01d4d93c
nsWebShell::CreateScriptEnvironment
[d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 3163]
nsWebShell::GetScriptGlobalObject
[d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 3194]
DocumentViewerImpl::Init
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 375]
nsWebShell::Embed [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line
943]
nsDocumentBindInfo::OnStartRequest
[d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 1954]
nsHTTPResponseListener::FinishedResponseHeaders
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 629]
nsHTTPResponseListener::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 154]
nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
350]
nsStreamListenerEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
150]
PL_HandleEvent [plevent.c, line 510]
PL_ProcessPendingEvents [plevent.c, line 471]
_md_EventReceiverProc [plevent.c, line 936]
KERNEL32.DLL + 0x35d9 (0xbff735d9)
KERNEL32.DLL + 0x2222f (0xbff9222f)
0x00638c00
should also note that this crash was not reproducable when I play some more.
I also see some funny behavior in that if I click on one of the bookmarks
in the the manage bookmark dialogs I launch the url that I've bookmarked
in a new window, but when the page has fininshed loading it reloads
the home page (http://www.mozillazine.org)
sideba shows this funky reloading behavia too.  is thata 'notha bug?
more interesting stuff on the bookmark load, then reloading the home page thang.
look like it only happens when clicking on the last bookmark added to bookmark
list.
Somehow it gets its knickers in a knot if you try to open the same bookmark
several times from the "manage bookmarks" window. I'm seeing it call
nsXULDocument::RemoveChild(), which is bizarre. I'll start to prowl through the
JS.
if any one can get the knots out of knickers, its waterson.
Assignee: waterson → rjc
Status: ASSIGNED → NEW
Robert, could you take a look at this bug? It seems to have to do with inline
editing. To reproduce:

1. Open the Manage Bookmarks window.
2. Find a bookmark, preferably one near the top of the hierarchy (e.g.,
choosing a newly added bookmark would be good).
3. Single-click on the bookmark. Wait 10 sec.
4. Single-click again on the bookmark. This may open a new browser window; if
it does, dismiss the window.
5. Single-click again. This will assert, because its trying to remove a node
from the document object.

I took a brief spin through the code in "bookmarks.js" and am not sure what's
going on. It looks like you're adding and removing nodes to the DOM and
something is getting screwed up.
Status: NEW → ASSIGNED
Chris (Waterson), try this:

cd \mozilla\xpfe\components\bookmarks\resources
edit bookmarks.xul
remove the onclick() handler from the bookmarks tree (around line #74).... make
sure NOT to remove the ondblclick() handler.
(On Windows) in the resources dir, "nmake /f makefile.win" to export the change
into $DIST

Now try it. Does that fix the problem?
Chris (Waterson) says it fixes it.

Chris (Hoffman), may I have your permission to check in this simple fix to a
JavaScript file?
ok on the fix.  checkin.

how about the wierd last bookmark page reload thing.
can rjc and waterson show this to danm to see if its
related to some wierd page loading behavior that we was looking
at with joki today?
QA Contact: beppe → claudius
What's the deal here?  Are onclick and ondblclick fighting for adjacent clicks,
and both firing where only one should?  Or is the JS in question misbehaving
when given unexpected mixtures of single and double clicks?

/be
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed.

Brendan, the issue was with making changes to XUL via the DOM which hits some
snags in RDF-land that need fixing at some point.
Status: RESOLVED → REOPENED
Reopening bug because it still crashes(on MAC) with the 1999081609 builds. The

stack trace is different, it is no longer failing where it used to but it still

crashes nonetheless.

Here is a MacsBug stack trace:



 Calling chain using A6/R1 links

  Back chain  ISA  Caller

  00000000    PPC  0D8CF3D0

  05652C80    PPC  0D8CE8F8  main+0002C

  05652C30    PPC  0D8CE6B0  main1(int, char**)+00DA0

  05652A50    PPC  0D603470  nsAppShellService::Run()+00018

  05652A10    PPC  0D5C96E8  nsAppShell::Run()+00038

  05652990    PPC  0D5CA1DC  nsMacMessagePump::DoMessagePump()+0003C

  05652940    PPC  0D5CA494  nsMacMessagePump::DispatchEvent(int, EventRecord*)+

00158

  056528F0    PPC  0D850564  Repeater::DoRepeaters(const EventRecord&)+00030

  056528B0    PPC  0D5AE1A0  nsToolkit::RepeatAction(const EventRecord&)+00048

  05652860    PPC  0D7E2AD4  nsEventQueueServiceImpl::ProcessEvents()+00020

  05652820    PPC  0D7DE5F8  nsHashtable::Enumerate(int (*)(nsHashKey*, void*,

void*), void*)

+00024

  056527E0    PPC  0D8577C4  PL_HashTableEnumerateEntries+00060

  05652770    PPC  0D7DDF1C  _hashEnumerate(PLHashEntry*, int, void*)+00024

  05652730    PPC  0D7E2A44  EventDispatchingFunc(nsHashKey*, void*, void*)+0002C

  056526F0    PPC  0D7F5B34  nsEventQueueImpl::ProcessPendingEvents()+00010

  056526B0    PPC  0D856BB8  PL_ProcessPendingEvents+00078

  05652660    PPC  0D856C58  PL_HandleEvent+00028

  05652620    PPC  0CF4A1E0  nsStreamListenerEvent::HandlePLEvent(PLEvent*)+0001C

  056525D0    PPC  0CF4AEF0  nsOnDataAvailableEvent::HandleEvent()+00034

  05652580    PPC  0D50115C  nsDocumentBindInfo::OnDataAvailable(nsIChannel*,

nsISupports*, n

sIInputStream*, unsigned int, unsigned int)+000DC

  05652510    PPC  0D1B8720  nsParser::OnDataAvailable(nsIChannel*, nsISupports*,

nsIInputStr

eam*, unsigned int, unsigned int)+001D0

  056524B0    PPC  0D1B80F0  nsParser::ResumeParse(nsIDTD*, int)+00090

  05652460    PPC  0D1B89D4  nsParser::Tokenize(int)+0008C

  05652410    PPC  0D1D7580  nsExpatTokenizer::ConsumeToken(nsScanner&)+00068

  056523C0    PPC  0D1D7454  nsExpatTokenizer::ParseXMLBuffer(const char*,

unsigned int, int)

+0003C

  05652370    PPC  0D1DAA6C  XML_Parse+0011C

  05652310    PPC  0D1DD934  prologInitProcessor+00058

  056522D0    PPC  0D1DD9E4  prologProcessor+0006C

  05652280    PPC  0D1DDD84  doProlog+00358

  056521E0    PPC  0D1D81B8  nsExpatTokenizer::HandleExternalEntityRef(void*,

const char*, co

nst char*, const char*, const char*)+000BC

  056520F0    PPC  0D1D7E20  nsExpatTokenizer::OpenInputStream(const nsString&,

const nsStrin

g&, nsIInputStream**, nsString*)+00060

 Return addresses on the stack

  Stack Addr  Frame Addr   ISA   Caller

   05652418                PPC   0D1B89D4 nsParser::Tokenize(int)+0008C

   056523F4                68K   04C91F66

   056523D8    056523D0    PPC   0D1B88DC nsParser::WillTokenize(int)+00028

   056523C8    056523C0    PPC   0D1D7580

nsExpatTokenizer::ConsumeToken(nsScanner&)+00068

   0565239C                68K   04C91F66

   05652378    05652370    PPC   0D1D7454 nsExpatTokenizer::ParseXMLBuffer(const

char*, unsig

ned int, int)+0003C

   05652338                PPC   0D8BA52C operator new(unsigned long, const

std::nothrow_t&)+

00014

   05652318    05652310    PPC   0D1DAA6C XML_Parse+0011C

   056522D8    056522D0    PPC   0D1DD934 prologInitProcessor+00058

   056522A8                PPC   0D80AE0C nsString::Append(const char*, int)+

000AC

   05652298                68K   049DFC1A

   05652288    05652280    PPC   0D1DD9E4 prologProcessor+0006C

   0565224C                68K   04C96826

   05652208                PPC   0D1DD4CC initializeEncoding+000C4

   056521E8    056521E0    PPC   0D1DDD84 doProlog+00358

   05652180                68K   04C91F66

   05652164                68K   04C91F66

   05652148                68K   04C91F66

   05652108    05652100    PPC   0D8BB5C8 calloc+00030

   056520F8    056520F0    PPC   0D1D81B8

nsExpatTokenizer::HandleExternalEntityRef(void*, co

nst char*, const char*, const char*, const char*)+000BC

   056520BC                68K   04C96826

   056520B8    056520B0    PPC   0D808D7C nsString::nsString(eCharSize,

nsIMemoryAgent*)+0002

0

   05652098    05652090    PPC   0D1D7E20 nsExpatTokenizer::OpenInputStream(const

nsString&,

const nsString&, nsIInputStream**, nsString*)+00060

   05652078    05652070    PPC   0D802CA8 nsStr::Initialize(nsStr&, eCharSize)+

00018

   05652068    05652060    PPC   0D80AA84 nsString::Assign(const unsigned short*,

int)+00040

   05652048    05652040    PPC   0D84ED84 NS_OpenURI(nsIInputStream**, nsIURI*)+

00018
Resolution: FIXED → ---
clearing fixed resolution, cc'ing leger
I should state that I was unable to reproduce the assert on windows following
waterson's previous directions.
Assignee: rjc → nisheeth
Status: REOPENED → NEW
This crash is different, and far away from RDF.  Looks like the XML parser
maybe...  Re-assigning to Nisheeth.  (Sorry, Nisheeth!)
Also cc'ing Gagan, as its getting to NS_OpenURI (so, maybe Necko).
Claudius, does this happen with the original set of repro instructions? Any
chance I could get you to narrow stuff down a bit?
I can reproduce this crash merely by running apprunner and selecting "Bookmarks
| Manage Bookmarks".
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 10703 ***
To answer waterson's question. Like I said, following your repro directions on windows
works w/o problem on WinNT.  I originally wrote this as a Mac bug however. Following
my initial repro directions still crashes - just differently, on Mac.

Niseeth, this is really a dupe of bug 10703, that's not a typo? I see the XML parser calls but
wouldn't other stuff be crashing too, not just Manage Bookmarks?
Necko currently does not support blocking reads on HTTP urls.  It seems like the
bookmarks XML file is trying to load up an external DTD or external entity with
an http URL leading to the crash in Necko.  Robert, if that is the case, then
this bug is a duplicate of 10703.  Otherwise, I goofed and we should re-open
this bug.
I'm not sure what its trying to load. Its probably worthwhile for something to
check.  Note that this crasher is relatively new in appearing.
*** Bug 11993 has been marked as a duplicate of this bug. ***
*** Bug 11993 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I am reopening this bug because its not a duplicate of 10703.  I can't take a
look at this till Friday night, though, because I am away for an XML demo.  If
somebody in Necko land can take over this bug for the next two days, that would
be great.  Otherwise, I'll work on this on Saturday.
Whiteboard: looking into this → looking into this for M9 fix on Sat 08/21
So, it sounds like Win as well as Mac has a problem here, yes?  claudius, can we
consider a release note for M9?
This is currently only a MAC issue as labeled. The Win32 issues mentioned earlier appear fixed.

I will check weekend builds for a fix, absent that I will write a release note for Monday.
It's all my fault. sdagley and nisheeth told me that the 'dtd' file is never
exported on the Mac. While the MANIFEST file is listed in NGLayoutBuildList.pl,
I forgot to check it in.

We need to add xpfe/components/bookmarks/resources/locale/MANIFEST with the
following lines:

en-US:bm-props.dtd
en-US:bookmarks.dtd
Thanks for fixing that, slamm.  I think that this bug should be left open and
the summary renamed to indicate that we should NOT crash if a DTD file isn't
available.  :^)
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
We no longer crash when a DTD is not present.
nsChromeProtocolHandler::NewChannel was returning NS_OK even when Necko returned
an error code.  On fixing that, we no longer crash.  This fix was checked in by
Steve Dagley on the tip.  We are not planning to check it into the branch.
Status: RESOLVED → VERIFIED
listen closely. This bug is now fixed and VERIFIED for 1999082412-M9 builds
AND for 1999082513-M10.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.