47927 - Crash loading second ftp URL

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Jeffrey Baker]

Tested on Linux 2000080712 M17.  

1) Start Mozilla
2) Type ftp://ftp.netscape.com in the URL bar
3) Wait for it to load
4) Type Alt-L
5) Type ftp://ftp.netscape.com in the dialog box
6) Hit enter
7) Mozilla exits with a segfault

Comment 1

[Jeffrey Baker]

This is effectively smoketest B.9

Comment 2

[Jason Kersey]

worksforme 2000080712, Mozilla build

Comment 3

[leger]

Putting on [dogfood+] FOR THE TRUNK/MOZ ONLY - we cannot reproduce with 
2000-08-07-12 Linux commercial M17 build.

Comment 4

[Jeffrey Baker]

It's 100% reproduceable here with the 2000-08-07-12 M17 build from ftp.mozilla.org.  You can even vary the steps by e.g. leaving the scheme off of the URLs.



I dunno exactly what you mean by "Mozilla build".

Comment 5

[Asa Dotzler [:asa]]

there are mozilla builds and commercial (netscape) builds.  

Comment 6

[Steven Borrelli]

Able to reproduce the crash on 2000080712 Linux build (RedHat 6.2) and
ftp://ftp.mozilla.org 

Will crash when using the enter key, or when clicking on the "open" button from
the Open Web Location dialog. Will also crash when Open Web Location dialog is
selected from the File menu.

Additional comments:
Does not crash if you select "open in new navigator window" in the Open Web
Location diaglog and use either the enter key or the "open" button.

Comment 7

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

In my opt build I crash with a SIGILL (Illegal Instruction) at:

Program received signal SIGILL, Illegal instruction.
0x82fa995 in ?? ()
(gdb) bt
#0  0x82fa995 in ?? ()
#1  0x40547451 in nsXULDocument::CheckTemplateBuilder ()
   from /var/home2/david/build/obj/opt/dist/bin/components/librdf.so
#2  0x40545893 in nsXULDocument::ResumeWalk ()
   from /var/home2/david/build/obj/opt/dist/bin/components/librdf.so
#3  0x405491db in nsXULDocument::CachedChromeStreamListener::OnStopRequest ()
   from /var/home2/david/build/obj/opt/dist/bin/components/librdf.so
#4  0x404d6d37 in nsCachedChromeChannel::HandleStopLoadEvent ()
   from /var/home2/david/build/obj/opt/dist/bin/components/libchrome.so
#5  0x400b740b in PL_HandleEvent ()
   from /var/home2/david/build/obj/opt/dist/bin/./libxpcom.so
#6  0x400b7346 in PL_ProcessPendingEvents ()
   from /var/home2/david/build/obj/opt/dist/bin/./libxpcom.so
#7  0x400b805d in nsEventQueueImpl::ProcessPendingEvents ()
   from /var/home2/david/build/obj/opt/dist/bin/./libxpcom.so
#8  0x405db55f in event_processor_callback ()
   from /var/home2/david/build/obj/opt/dist/bin/components/libwidget_gtk.so
#9  0x405db31d in our_gdk_io_invoke ()
   from /var/home2/david/build/obj/opt/dist/bin/components/libwidget_gtk.so
#10 0x4077aaca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#11 0x4077c186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#12 0x4077c751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#13 0x4077c8f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#14 0x406a15b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#15 0x405dba30 in nsAppShell::Run ()
   from /var/home2/david/build/obj/opt/dist/bin/components/libwidget_gtk.so
#16 0x4039813a in nsAppShellService::Run ()
   from /var/home2/david/build/obj/opt/dist/bin/components/libnsappshell.so
#17 0x804d11e in main1 ()
#18 0x804d519 in main ()
#19 0x402529cb in __libc_start_main (main=0x804d40c <main>, argc=1, 
    argv=0xbffff724, init=0x804a65c <_init>, fini=0x8051cb0 <_fini>, 
    rtld_fini=0x4000ae60, stack_end=0xbffff71c)
    at ../sysdeps/generic/libc-start.c:92

In my debug build, I crash with SIGSEGV (segmentation fault) at roughly the same
place, except the top line is at libmozjs:

Program received signal SIGSEGV, Segmentation fault.
0x401fa4e5 in ?? () from /home/david/builds/obj/debug/dist/bin/./libmozjs.so
(gdb) bt
#0  0x401fa4e5 in ?? ()
   from /home/david/builds/obj/debug/dist/bin/./libmozjs.so
#1  0x40871b5e in ?? ()
   from /home/david/builds/obj/debug/dist/bin/components/librdf.so
#2  0x408badb8 in ?? ()
   from /home/david/builds/obj/debug/dist/bin/components/librdf.so
#3  0x408b6d64 in ?? ()
   from /home/david/builds/obj/debug/dist/bin/components/librdf.so
#4  0x408bed5c in ?? ()
   from /home/david/builds/obj/debug/dist/bin/components/librdf.so
#5  0x407be67a in ?? ()
   from /home/david/builds/obj/debug/dist/bin/components/libchrome.so
[ not enough memory to load these libraries in debug build ]

I can reproduce this crash only part of the time.

Comment 8

[Chris McAfee]

stack with symbols.

#0  0x401a693a in JS_GetClass (cx=0x852fff4, obj=0x40951e38) at jsapi.c:1356
#1  0x405dae95 in nsJSUtils::nsGetNativeThis (aContext=0x852fff4,
    aObj=0x40951e38) at nsJSUtils.cpp:616
#2  0x405b40d1 in SetWindowProperty (cx=0x852fff4, obj=0x40951e38,
    id=1082527360, vp=0x40860e80) at nsJSWindow.cpp:617
#3  0x40860f0e in RDFServiceImpl::GetDataSource (this=0x8129228,
    aURI=0xbfffe90c "rdf:httpindex", aDataSource=0xbfffe9f8)
    at nsRDFService.cpp:1065
#4  0x408a9548 in nsXULDocument::CheckTemplateBuilder (aElement=0x42616dc0)
    at nsXULDocument.cpp:5951
#5  0x408a54f4 in nsXULDocument::ResumeWalk (this=0x86c39c8)
    at nsXULDocument.cpp:5190
#6  0x408a6fe0 in nsXULDocument::OnStreamComplete (this=0x86c39c8,
    aLoader=0x0, context=0x0, aStatus=0, stringLen=8006,
    string=0x421cc4e0 "/* -*- Mode: Java; tab-width: 4; c-basic-offset: 4; -*-\n
* \n * The contents of this file are subject to the Netscape Public\n * License
Version 1.1 (the \"License\"); you may not use this file\n * except "...)
    at nsXULDocument.cpp:5584
#7  0x40d969a0 in nsStreamLoader::OnStopRequest (this=0x424c3da8,
    channel=0x4243eaf8, ctxt=0x0, aStatus=0, aStatusArg=0x4016c384)
    at nsStreamLoader.cpp:121
#8  0x40df91d6 in nsResChannel::EndRequest (this=0x4243eaf8, aStatus=0,
    aStatusArg=0x4016c384) at nsResChannel.cpp:706
#9  0x40df9164 in nsResChannel::OnStopRequest (this=0x4243eaf8,
    transportChannel=0x4243eb60, context=0x0, aStatus=0, aStatusArg=0x4016c384)
    at nsResChannel.cpp:699
#10 0x40dee41d in nsFileChannel::OnStopRequest (this=0x4243eb60,
    transportChannel=0x4243f0f0, context=0x0, aStatus=0, aStatusArg=0x4016c384)
    at nsFileChannel.cpp:632
#11 0x40d7ad79 in nsOnStopRequestEvent::HandleEvent (this=0x4245a150)
    at nsAsyncStreamListener.cpp:301
#12 0x40d7a327 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x4246ebb8)
    at nsAsyncStreamListener.cpp:97

Comment 9

[Chris Waterson]

This stack trace doesn't make sense. Specifically, I don't understand how frame
#3 gets to frame #2...

Comment 10

[Jon Granrose]

I'm holding the tree for this.

Comment 11

[Chris McAfee]

narrowing bug down, it looks like things crash on the
second ftp: URL typed into the URL bar, resummarizing.

#0  0x40860efe in RDFServiceImpl::GetDataSource (this=0x8129228, 
    aURI=0xbfffe90c "rdf:httpindex", aDataSource=0xbfffe9f8)
    at nsRDFService.cpp:1065
#1  0x408a9548 in nsXULDocument::CheckTemplateBuilder (aElement=0x88eda40)
    at nsXULDocument.cpp:5951
#2  0x408a54f4 in nsXULDocument::ResumeWalk (this=0x894ebb0)
    at nsXULDocument.cpp:5190
#3  0x408a6fe0 in nsXULDocument::OnStreamComplete (this=0x894ebb0, 
    aLoader=0x0, context=0x0, aStatus=0, stringLen=8006, 
    string=0x8788b40 "/* -*- Mode: Java; tab-width: 4; c-basic-offset: 4; -*-\n
* \n * The contents of this file are subject to the Netscape Public\n * License
Version 1.1 (the \"License\"); you may not use this file\n * except "...)
    at nsXULDocument.cpp:5584
#4  0x40d969a0 in nsStreamLoader::OnStopRequest (this=0x8903d48, 
    channel=0x88f1b00, ctxt=0x0, aStatus=0, aStatusArg=0x4016c384)
    at nsStreamLoader.cpp:121
#5  0x40df91d6 in nsResChannel::EndRequest (this=0x88f1b00, aStatus=0, 
    aStatusArg=0x4016c384) at nsResChannel.cpp:706
#6  0x40df9164 in nsResChannel::OnStopRequest (this=0x88f1b00, 
    transportChannel=0x88f1b68, context=0x0, aStatus=0, aStatusArg=0x4016c384)
    at nsResChannel.cpp:699
#7  0x40dee41d in nsFileChannel::OnStopRequest (this=0x88f1b68, 
    transportChannel=0x88f1a28, context=0x0, aStatus=0, aStatusArg=0x4016c384)
    at nsFileChannel.cpp:632

Comment 12

[Chris Waterson]

rjc: this is your fault. Although it was probably just recently exposed by leak
fixes. I'll attach a patch that shows you why.

Comment 13

[Chris Waterson]

Attachment: wallpaper fix

Comment 14

[Chris Waterson]

rjc: since nsHTTPIndex is not a singleton (you create one every single time you
open a new "ftp:" URL), it's wrong to put this into the RDF service as a "named
datasource". This fixes the crash, but will probably cause bizarre and evil
things to happen if >1 "ftp:" URL is open. (Like, all FTP browsers will get all
other browser's async notifies, making this slower than shit.)

Comment 15

[Robert John Churchill]

"rdf:httpindex" is used to get an aggregatable copy of nsHTTPIndex... bookmarks 
(window & sidebar panel) use this, for example.  We need a better solution than 
just never naming the datasource, I think... for example, perhaps not 
registering/unregistering it if its created by the content viewer.

This shouldn't be a smoketest blocker (IMO)... there isn't an easy fix that 
won't cause other problems.

Comment 16

[Chris McAfee]

off blocker list

Comment 17

[selmer (gone)]

Please add an ETA to the status whiteboard.  Thanks, PDT

Comment 18

[Robert John Churchill]

Attachment: Diff: unregister if being created by content viewer case

Comment 19

[Robert John Churchill]

Chris, care to try this diff out for yucks?

Comment 20

[Chris Waterson]

Seems like a better fix would be to have two methods for construction. The first
would only be used "internally": it would create a specific instance of the
nsHTTPIndex object for parsing FTP data that is intended for the directory
viewer. The other would be used "externally" by XPCOM when we do a
CreatenInstance() from RDF. Only the second constructor would actually register
the object it had created with the RDF service.

If you did this, the destructor should *always* try to unregister: since it
takes a pointer, the RDF service will just ignore you if you try to unregister
the wrong thing.

Comment 21

[Robert John Churchill]

Attachment: Bigger, badder, bolder diff

Comment 22

[Robert John Churchill]

Attachment: Bigger, badder, bolder file (Unix line endings)

Comment 23

[Robert John Churchill]

Chris, something like this?

Comment 24

[Chris Waterson]

Yeah, that looks good. My only other comment is that you should move all the

  if (gRefCnt++ == 0) { ... }

stuff into a separate routine. Do that, and r=waterson.

Comment 25

[Chris Waterson]

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

Comment 26

[Robert John Churchill]

Fixed.

Comment 27

[Doron Rosenberg (IBM)]

adding verifyme keyword to bugs I can't verify

Comment 28

[James Green]

Verified Linux 093006.