23493 - Switching from Internet to History/Bookmarks etc. in search causes crash

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Richard Zach]

If you switch from "Search the Internet" to search history/bookmarks, address
book, or mail news, Mozilla crashes.

To reproduce:
1. Search | Search the Internet
2. Click on one of the other search function tabs.

Actual result: Segfault
Expected result: Search window should change to selected search function

Switching among the other search functions or from one of them to Internet
works fine; crash only happens once Search Internet is selected.

Stack trace:

got a request
unloadPage(): 11 engines.
got a request

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1847]

Program received signal SIGSEGV, Segmentation fault.
0x40ad68a2 in NSGetModule ()
(gdb) where
#0  0x40ad68a2 in NSGetModule ()
#1  0x40ad61aa in NSGetModule ()
#2  0x400d6b9a in nsSupportsArray::Clear ()
#3  0x400d65b4 in nsSupportsArray::DeleteArray ()
#4  0x400d640e in nsSupportsArray::~nsSupportsArray ()
#5  0x400d64d8 in nsSupportsArray::Release ()
#6  0x400f904f in nsCOMPtr_base::~nsCOMPtr_base ()
#7  0x40d3b6cd in NSGetModule ()
#8  0x40d3ba18 in NSGetModule ()
#9  0x400f904f in nsCOMPtr_base::~nsCOMPtr_base ()
#10 0x40d52173 in NSGetModule ()
#11 0x40d527f9 in NSGetModule ()
#12 0x40355a88 in nsJSUtils::nsGenericFinalize ()
#13 0x40d3422b in NSGetModule ()
#14 0x4006d3ea in js_FinalizeObject ()
#15 0x4005e3e4 in js_GC ()
#16 0x4005dec5 in js_ForceGC ()
#17 0x40045d76 in JS_GC ()
#18 0x4033efa3 in nsJSContext::GC ()
#19 0x412fbe5d in nsWebShell::Embed ()
#20 0x412fe2a3 in nsWebShell::CreateViewer ()
#21 0x412fe067 in nsWebShell::DoContent ()
#22 0x411aa86f in NSGetModule ()
#23 0x411aa477 in NSGetModule ()
#24 0x4040622a in NSGetModule ()
#25 0x403f95a2 in NSGetModule ()
#26 0x403f9130 in NSGetModule ()
#27 0x4012bc17 in PL_HandleEvent ()
#28 0x4012bb86 in PL_ProcessPendingEvents ()
#29 0x400f388a in nsEventQueueImpl::ProcessPendingEvents ()
#30 0x412267bf in nsAppShell::SetDispatchListener ()
#31 0x4122658d in _init ()
#32 0x407e652a in g_io_unix_dispatch ()
#33 0x407e7be6 in g_main_dispatch ()
#34 0x407e81a1 in g_main_iterate ()
#35 0x407e8341 in g_main_run ()
#36 0x4070d859 in gtk_main ()
#37 0x41226c7a in nsAppShell::Run ()
#38 0x411e9692 in nsAppShellService::Run ()
#39 0x804a585 in JS_PushArguments ()
#40 0x804a8f4 in JS_PushArguments ()
#41 0x40210cb3 in __libc_start_main (main=0x804a718 <JS_PushArguments+5156>,
    argc=1, argv=0xbffff884, init=0x8049064 <_init>, fini=0x804bce0 <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff87c)
    at ../sysdeps/generic/libc-start.c:78

Linux build 2000.01.08.08

Comment 1

[Sean Richardson]

Based on the Additional Comments From [e-mail]  2000-01-12 13:24,
in bug 23262, this looks like another DUP of bug 23262:
  >To Repro:
  >1. Select Search| Search the Internet.
  >2. Select Search| Search Bookmarks/History.
  >3. Buh-bye.
  ...
  >Selecting Search the Internet again in step 2 yields strange results per
  >platform. on linux, I quit silently.

This looks like another way of triggering the same crash, and might give a
clue or two.

Comment 2

[Claudius Gayle]

strictly speaking this bug is not a dupe of bug 23262. The original problem in bug 23262 was
fixed and the bug was morphing into the problem addressed here, now it doesn't have to.
assigning to law since he is currently saddled with bug 23262.

Comment 3

[don]

Robert, is this yours?

Comment 4

[Robert John Churchill]

Nope.

Comment 5

[Claudius Gayle]

perform a search, click any other tab - still crashes with 2000011910 build (NT)

Comment 6

[Claudius Gayle]

submitting for PDT consideration. with this bug search works only very tenuously. Trying to do anytihng else but search the
internet, or sometimes trying to do that twice will cause you to crash quickly. If this is going to be the first release where search
gets a lot of eyeballs, that's not going to be good.

Comment 7

[Robert John Churchill]

Back to Don...

Comment 8

[leger]

Putting on PDT- radar.  But added beta1 keyword.  And putting on M14....don, 
please change if you disagree.

Comment 9

[Robert John Churchill]

Ah... what?  This is a recent crash... it was working fine just a few days ago. 
It locks up the user's machine (on Mac) and is most likely not just a search 
dialog problem, but could be affecting other windows in the product as well.

I think that this should be fixed for M13.

Comment 10

[Robert John Churchill]

Just opening the "Search the Internet" dialog and then closing it causes this 
same crash also.

(Perhaps a webshell issue?)

Comment 11

[Claudius Gayle]

that's great that this is on beta radar but in light of rjc's last comments that means that I'm going to have to write a release note 
for M13 that says "Don't use Search" and tag this as a Most Frequent Bug right out the door. I don't think anyody wants that. 
Resubmitting this bug for one last shot at PDT love.

Things to consider:
Highly reproducible crash on all platforms with current M13 builds.
Sometimes locks up users' machine.
Only takes two clicks to crash--> Select Search|Search the Internet. Click close box. crash

Comment 12

[leger]

Getting fixed for next milestone.  Still putting on PDT-.

Comment 13

[Dan M]

NB: this is crashing because circumstances have apparently recently
crept in to the code triggering the premature deletion of nsHTMLFormElements.
I don't know who caused the circumstances, but the deletion decision looks
to me like something that will be a perpetual time bomb if we don't find
some other way to make that decision. It was very tricky to find the problem,
and I don't relish doing that again. It's code owned by Karnaze. He and I
should probably collaborate to fix this.

Comment 14

[Dan M]

Actually I'm not completely sure that the deletion decision is so dangerous.
Wants more investigation. I'm taking this bug for now, but I reserve
the right to give it away once I figure out who really wants it.

Comment 15

[leger]

Clearing PDT- since this is nominated for beta1 and needs PDT re-review.

Comment 16

[Robert John Churchill]

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

Comment 17

[Peter Trudelle]

removing dogfood tag, since PDT rejected that status and it is now nominated for 
beta1

Comment 18

[Robert John Churchill]

Note: it looks like this bug also crops up if a text input field is put into a 
sidebar panel, which happens to be the plan for the "Search" sidebar panel for 
beta 1.

So, if this bug isn't fixed for beta 1, the Search sidebar panel plans will 
either need to be changed, or it will lock up (or crash, depending on the 
platform) the browser.

Comment 19

[leger]

Putting on PDT+ radar for beta1.

Comment 20

[Dan M]

The containing form wasn't being notified when a form element was removed from 
it. This resulted in the early deletion of the form object through a strange 
carnival of errors, which means virtual methods were being called from dangling 
pointers. This was probably a widespread bug, since all XUL windows are forms. 
All better now.

Comment 21

[Robert John Churchill]

Great work on this, Dan!

Comment 22

[Claudius Gayle]

I don't suppose there's any chance of getting this in m13? like, if we have to respin to pick up something else. I hate to whine 
but it's only cuz there's going to be so many bugs/dupes and noise.

Comment 23

[Claudius Gayle]

so this works with the 2000012609 WinNT comm opt build, but NOT with the same build on Linux. I've REOPENED this bug and I'll 
post Mac results as soon as I ge an opt build that has the fix.

Comment 24

[Robert John Churchill]

That's weird;  I pulled Dan's changes and they *did* work on my Linux build.

Comment 25

[leger]

Clearing FIXED resolution due to reopen.

Comment 26

[Dan M]

The crash you're seeing today is a new one. It's the subject of bug 25155.

Comment 27

[Paul MacQuiddy]

marking verified since there is another bug for the linux specific case

Comment 28

[Claudius Gayle]

for historical accuracy and completeness i will note that this bug has actually now been verified fixed on Mac builds as well.

Comment 29

[Claudius Gayle]

reopening bugs the same symptoms have reoccured. to reiterate (copied from this bug):

To reproduce:
1. Search | Search the Internet
2. Click on ANY one of the other search function tabs.

Comment 30

[Dan M]

  Damn I hate this bug.
  We're running into a question of whether a bug report describes a symptom or an 
underlying problem. I tend to look at it as the latter, if for no other reason 
than a new underlying problem probably wants a new owner. Personally, I'd prefer 
a new bug be opened, like last time: the symptoms are similar, but not identical, 
and the stack trace is completely different.
  I'd go open a new bug, if it weren't a waste of time because sfraser's fix for 
bug 25952 also caught this one, about four hours ago. Closing yet again.

Comment 31

[Claudius Gayle]

VERIFIED with 2000020108 WinNT build