Crash loading second ftp URL

VERIFIED FIXED

Status

SeaMonkey
General
P3
critical
VERIFIED FIXED
18 years ago
10 years ago

People

(Reporter: Jeffrey Baker, Assigned: Robert John Churchill)

Tracking

({crash, smoketest})

Trunk
x86
Linux
crash, smoketest

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dogfood+] FOR THE TRUNK/MOZ ONLY, URL)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
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
(Reporter)

Comment 1

18 years ago
This is effectively smoketest B.9
Keywords: smoketest

Comment 2

18 years ago
worksforme 2000080712, Mozilla build

Comment 3

18 years ago
Putting on [dogfood+] FOR THE TRUNK/MOZ ONLY - we cannot reproduce with 
2000-08-07-12 Linux commercial M17 build.
Whiteboard: [dogfood+] FOR THE TRUNK/MOZ ONLY
(Reporter)

Comment 4

18 years ago
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

18 years ago
there are mozilla builds and commercial (netscape) builds.  

Comment 6

18 years ago
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.



(Reporter)

Updated

18 years ago
Keywords: crash
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

18 years ago
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

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

Comment 10

18 years ago
I'm holding the tree for this.
Component: Browser-General → Bookmarks

Updated

18 years ago
Component: Bookmarks → Browser-General

Comment 11

18 years ago
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
Summary: Mozilla crashes loading ftp://ftp.netscape.com from alt-l → Crash loading second ftp URL

Comment 12

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

Comment 13

18 years ago
Created attachment 12614 [details] [diff] [review]
wallpaper fix

Comment 14

18 years ago
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.)
(Assignee)

Comment 15

18 years ago
"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

18 years ago
off blocker list
Severity: blocker → critical

Comment 17

18 years ago
Please add an ETA to the status whiteboard.  Thanks, PDT
(Assignee)

Comment 18

18 years ago
Created attachment 12866 [details] [diff] [review]
Diff: unregister if being created by content viewer case
(Assignee)

Comment 19

18 years ago
Chris, care to try this diff out for yucks?

Comment 20

18 years ago
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.
(Assignee)

Comment 21

18 years ago
Created attachment 12894 [details] [diff] [review]
Bigger, badder, bolder diff
(Assignee)

Comment 22

18 years ago
Created attachment 12895 [details]
Bigger, badder, bolder file (Unix line endings)
(Assignee)

Comment 23

18 years ago
Chris, something like this?

Comment 24

18 years ago
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

18 years ago
*** Bug 48236 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 26

18 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
adding verifyme keyword to bugs I can't verify
Keywords: verifyme

Comment 28

18 years ago
Verified Linux 093006.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

10 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.