9387 - Segmentation fault on mailto: link in mozilla/dist/bin/viewer and mozilla/webshell/embed/gtk/examples/simplebrowser/simplebrowser

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P3)

Description

[milindc]

Environment: Linux, Pentium
Mozilla code base: July 07, 1999 11:27AM EST (SeaMonkeyAll)
Configured as: ./configure --enable-toolkit=gtk --enable-gtk-mozilla

Bug reproduction using
mozilla/webshell/embed/gtk/examples/simplebrowser/simplebrowser

1. cd mozilla/webshell/embed/gtk/examples/simplebrowser
2. MOZILLA_FIVE_HOME=../../../../../dist/bin   ./simplebrowser
3. type http://www.mozilla.org/owners.html in the URL address bar
4. scroll to information on "Embeddable Mozilla"
5. click on the link "Nisheeth Ranjan" which is a mailto: link
6. Application crashes....Segmentation fault

I guess it will crash on any of the mailto: links.

Bug reproduction with mozilla/dist/bin/viewer
Kindly follow the above mentioned steps.
However, the application crashes on clicking the mailto: link
the SECOND time.


Stack trace while running 'viewer' from gdb is as follows:
-------------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x40029cb0 in EqualBaseURLs (url1=0x8181568, url2=0x0) at nsWebShell.cpp:1793
1793      url2->GetHost(getter_Shares(host2));
(gdb) where
#0  0x40029cb0 in EqualBaseURLs (url1=0x8181568, url2=0x0) at
nsWebShell.cpp:1793
#1  0x40029fb6 in nsWebShell::DoLoadURL (this=0x80e9758, aUrlSpec=@0xbffff970,
aCommand=0x40031f08 "view", aPostData=0x0, aType=nsURLReload,
    aLocalIP=0) at nsWebShell.cpp:1863
#2  0x4002ad4a in nsWebShell::LoadURL (this=0x80e9758, aURLSpec=0x814e378,
aCommand=0x40031f08 "view", aPostData=0x0, aModifyHistory=1,
    aType=nsURLReload, aLocalIP=0) at nsWebShell.cpp:2086
#3  0x40029c19 in nsWebShell::LoadURL (this=0x80e9758, aURLSpec=0x814e378,
aPostData=0x0, aModifyHistory=1, aType=nsURLReload, aLocalIP=0)
    at nsWebShell.cpp:1774
#4  0x4002c1b1 in nsWebShell::HandleLinkClickEvent (this=0x80e9758,
aContent=0x826a3bc, aVerb=eLinkVerb_Replace, aURLSpec=0x814e378,
    aTargetSpec=0x8070398, aPostData=0x0) at nsWebShell.cpp:2678
#5  0x4002f9d7 in OnLinkClickEvent::HandleEvent (this=0x8278970) at
nsWebShell.cpp:2506
#6  0x4002bac9 in HandlePLEvent (aEvent=0x8278970) at nsWebShell.cpp:2519
#7  0x404ac29b in PL_HandleEvent (self=0x8278970) at plevent.c:493
#8  0x404ac1ac in PL_ProcessPendingEvents (self=0x8088428) at plevent.c:454
#9  0x40473f0d in nsEventQueueImpl::ProcessPendingEvents (this=0x807c758) at
nsEventQueue.cpp:118
#10 0x40058e3a in event_processor_callback (data=0x807c758, source=8,
condition=GDK_INPUT_READ) at nsAppShell.cpp:78
#11 0x4063c5eb in gdk_get_show_events () from /usr/lib/libgdk-1.2.so.0
#12 0x4066c67a in g_io_add_watch () from /usr/lib/libglib-1.2.so.0
#13 0x4066dd36 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#14 0x4066e2e1 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#15 0x4066e481 in g_main_run () from /usr/lib/libglib-1.2.so.0
#16 0x40592349 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#17 0x40059379 in nsAppShell::Run (this=0x80897c0) at nsAppShell.cpp:241
#18 0x8052dc2 in nsNativeViewerApp::Run (this=0x8071690) at nsGTKMain.cpp:42
#19 0x8052fbf in main (argc=1, argv=0xbffffd14) at nsGTKMain.cpp:89
(gdb)
-------------------------------------------------------------------------

Comment 1

[Nisheeth Ranjan]

Accepting bug and setting milestone to M8...

Comment 2

[Nisheeth Ranjan]

This is happening on windows also.  Its an XP issue.  Marking as such.

Comment 3

[Nisheeth Ranjan]

I have a fix for this.  Awaiting code review from Vidur and checkin approval
from Chris.

Comment 4

[Nisheeth Ranjan]

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

Comment 5

[Nisheeth Ranjan]

I'm changing my patch a little based on Warren's comments in bug 9493.  We
should not only check for null nsIURIs but also look at the return value of
NS_NewURL.

Also, need to check with Radha whether DoLoadURL() should return immediately on
seeing a null nsIURI/bad return value or should it continue and pass the url
spec to the doc loader for loading?

I'm about to go see what the DoLoadURL() used to do prior to Necko changes.
Right now, we continue in the non-Necko-defined code path but return immediately
in the Necko-defined code path.

CCing waterson who reported bug 9493 and warren who was cc'd on it.

Comment 6

[Nisheeth Ranjan]

I spoke to Radha and we've decided that it makes the most sense to return
immediately once the creation of an nsIURI for the new url fails.  I'm in the
middle of a clobber build right now. Once that finishes, I'll test my patch in
viewer and apprunner and check it in.

Comment 7

[Nisheeth Ranjan]

Attachment: Patch for the bug fix

Comment 8

[Nisheeth Ranjan]

I just checked in a fix for this.  Marking bug resolved.

Comment 9

[Claudius Gayle]

after much pain on reproduction marking VERIFIED fixed as of 1999071208 on Linux with Viewer and Apprunner although it never
really crashed apprunner. Point is it works well now.