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

VERIFIED FIXED in M14

Status

P3
critical
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: rzach, Assigned: danm.moz)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

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

Updated

19 years ago
Component: Browser-General → XPApps
QA Contact: nobody → claudius

Comment 1

19 years ago
Based on the Additional Comments From claudius@netscape.com  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.

Updated

19 years ago
Assignee: nobody → law

Comment 2

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

Updated

19 years ago
Assignee: law → rjc

Comment 3

19 years ago
Robert, is this yours?

Comment 4

19 years ago
Nope.

Updated

19 years ago
OS: Linux → All

Comment 5

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

Updated

19 years ago
Summary: [CRASH] Switching from Internet to History/Bookmarks etc. in search causes crash → [CRASH][dogfood] Switching from Internet to History/Bookmarks etc. in search causes crash

Comment 6

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

Updated

19 years ago
Assignee: rjc → don

Comment 7

19 years ago
Back to Don...

Comment 8

19 years ago
Putting on PDT- radar.  But added beta1 keyword.  And putting on M14....don, 
please change if you disagree.
Keywords: beta1
Whiteboard: [PDT-]
Target Milestone: M14

Comment 9

19 years ago
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.
Just opening the "Search the Internet" dialog and then closing it causes this 
same crash also.

(Perhaps a webshell issue?)

Comment 11

19 years ago
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
Hardware: PC → All
Whiteboard: [PDT-]

Comment 12

19 years ago
Getting fixed for next milestone.  Still putting on PDT-.
Whiteboard: [PDT-]
(Assignee)

Comment 13

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

Comment 14

19 years ago
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.
Assignee: don → danm
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Whiteboard: [PDT-] → [PDT-] bah-. systemic crash. fix in hand, awaiting review.

Comment 15

19 years ago
Clearing PDT- since this is nominated for beta1 and needs PDT re-review.
Whiteboard: [PDT-] bah-. systemic crash. fix in hand, awaiting review. → bah-. systemic crash. fix in hand, awaiting review.
*** Bug 22187 has been marked as a duplicate of this bug. ***

Comment 17

19 years ago
removing dogfood tag, since PDT rejected that status and it is now nominated for 
beta1
Summary: [CRASH][dogfood] Switching from Internet to History/Bookmarks etc. in search causes crash → Switching from Internet to History/Bookmarks etc. in search causes crash
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

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: bah-. systemic crash. fix in hand, awaiting review. → [PDT+]bah-. systemic crash. fix in hand, awaiting review.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]bah-. systemic crash. fix in hand, awaiting review. → [PDT+]
(Assignee)

Comment 20

19 years ago
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.
Great work on this, Dan!

Comment 22

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

19 years ago
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.
Status: RESOLVED → REOPENED
That's weird;  I pulled Dan's changes and they *did* work on my Linux build.

Comment 25

19 years ago
Clearing FIXED resolution due to reopen.
Resolution: FIXED → ---
(Assignee)

Comment 26

19 years ago
The crash you're seeing today is a new one. It's the subject of bug 25155.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 27

19 years ago
marking verified since there is another bug for the linux specific case
Status: RESOLVED → VERIFIED

Comment 28

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

Comment 29

19 years ago
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 30

19 years ago
  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.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 31

19 years ago
VERIFIED with 2000020108 WinNT build
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.