130900 - Find crash in frames [@ nsContentIterator::NextNode]

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Yanko Kaneti]

I am not sure this is the right component but....

from galeon bug: http://bugzilla.gnome.org/show_bug.cgi?id=74547

go to   http://www.area450.com/hacks/regionhack.htm

search for "macrovision"
crash after three occurrences

the backtrace

.......
#5  <signal handler called>
#6  nsContentIterator::NextNode (this=0x8792158, ioNextNode=0x8792164, 
    aIndexes=0x8792174) at nsContentIterator.cpp:719
#7  0x41268651 in nsContentIterator::Next (this=0x8792158)
    at nsContentIterator.cpp:888
#8  0x40a16eab in nsFind::NextNode (this=0x85bf800, aSearchRange=0x8786ae8, 
    aStartPoint=0x8640370, aEndPoint=0x8703668, aContinueOk=0)
    at nsFind.cpp:362
#9  0x40a18637 in nsFind::Find (this=0x85bf800, aPatText=0x86e7020, 
    aSearchRange=0x8786ae8, aStartPoint=0x8640370, aEndPoint=0x8703668, 
    aRangeRet=0xbfffe064) at nsFind.cpp:629
#10 0x40a14462 in nsWebBrowserFind::SearchInFrame (this=0x86a9ca8, 
    aWindow=0x8597214, aDidFind=0xbfffe220) at nsWebBrowserFind.cpp:710
#11 0x40a0f7b0 in nsWebBrowserFind::FindNext (this=0x86a9ca8, 
    outDidFind=0xbfffe220) at nsWebBrowserFind.cpp:124
#12 0x080d2a8b in GaleonWrapper::Find (this=0x85d39f8, 
    search_string=0x8273948, matchcase=0, search_backwards=0, 
    search_wrap_around=1, search_for_entire_word=0, search_in_frames=0, 
    didFind=0xbfffe220) at GaleonWrapper.cpp:577
#13 0x080b86da in mozilla_find (embed=0x850a648, properties=0x8610620)
    at mozilla.cpp:330
#14 0x0808f537 in find_go (find_dialog=0x86e0ee8, backwards=0) at find.c:321
#15 0x0808f3b1 in find_entry_activate_cb (editable=0x862fed0, 
    find_dialog=0x86e0ee8) at find.c:252
#16 0x406d6e40 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#17 0x40704b75 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#18 0x40704000 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#19 0x407021c3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#20 0x40737248 in gtk_widget_activate () from /usr/lib/libgtk-1.2.so.0
#21 0x406aedc3 in gtk_entry_key_press () from /usr/lib/libgtk-1.2.so.0
#22 0x406d6a50 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#23 0x40704039 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#24 0x407021c3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#25 0x4073710c in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#26 0x4073e6ef in gtk_window_key_press_event () from /usr/lib/libgtk-1.2.so.0
#27 0x40427a10 in gnome_dialog_key_pressed () from /usr/lib/libgnomeui.so.32
#28 0x406d6a50 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#29 0x40704039 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#30 0x407021c3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#31 0x4073710c in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#32 0x406d6936 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#33 0x406d5b8a in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
#34 0x41592269 in handle_gdk_event (event=0x85d95c8, data=0x0)
    at nsGtkEventHandler.cpp:897
#35 0x40780472 in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#36 0x407aec99 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#37 0x407af261 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#38 0x407af3e9 in g_main_run () from /usr/lib/libglib-1.2.so.0
#39 0x406d54dc in gtk_main () from /usr/lib/libgtk-1.2.so.0
#40 0x08093ea1 in main (argc=2, argv=0xbfffeed4) at main.c:344
#41 0x4082e1eb in __libc_start_main (main=0x8093c80 <main>, argc=2, 
    argv=0xbfffeed4, init=0x8070fec <_init>, fini=0x80f4214 <_fini>, 
    rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbfffeecc)

#5  <signal handler called>
No locals.
#6  nsContentIterator::NextNode (this=0x8792158, ioNextNode=0x8792164, 
    aIndexes=0x8792174) at nsContentIterator.cpp:719
719
      (void) parent->ChildAt(indx, *getter_AddRefs(cSibling));
Current language:  auto; currently c++
cSibling = {mRawPtr = 0x0}
parent = {mRawPtr = 0x0}
indx = 3
cN = {mRawPtr = 0x8696fe8}
#7  0x41268651 in nsContentIterator::Next (this=0x8792158)
    at nsContentIterator.cpp:888
888
  return NextNode(address_of(mCurNode), &mIndexes);
this = (nsContentIterator *) 0x0

this is the end of the bug-buddy trace, if you want i can try getting more data
running under gdb

Comment 1

[Matthias Versen [:Matti]]

related to bug 101710 ?

Always add the build ID in a bug report...

Comment 2

[Yanko Kaneti]

Dont know if its related to 101710 because I cant reproduce with the testcase
there. This one was test with both 0.9.9 (rh7 rpm) and a cvs HEAD build from few
hours back).  

To reiterate the crash is happening only from galeon. Mozilla itself works.

Comment 3

[Christopher Blizzard (:blizzard)]

Over to another module.

Comment 4

[Christopher Blizzard (:blizzard)]

Over to akkana for triage.

Comment 5

[Akkana Peck]

Can you find out any more information, like why it's crashing and what the
content iterator looks like then?  What node it's pointing to, etc.  I don't
think I'm likely to have time to get a working galeon build tree going in the
next few days, but I'd like to find out what's going on here and fix it before 1.0.

Comment 6

[Yanko Kaneti]

Did some more testing.

Unfortunately I cant reproduce with TestGtkEmbed patched to do the same search,
but I was really just copying what we do in galeon. Cant really figure what
might be different.

Its crashing because parent is NULL.

Will investigate further.

Comment 7

[Yanko Kaneti]

oops, sorry, reverting the summary

Comment 8

[Yanko Kaneti]

Ok with recent cvs this is now reproducable with TestGtkEmbed, I'll attach the
patch which puts a simple find button in testgtk embed that does a predefined find

In essence it only does
nsCOMPtr<nsIWebBrowser> mWebBrowser;
	
gtk_moz_embed_get_nsIWebBrowser (GTK_MOZ_EMBED(browser->mozEmbed),
					 getter_AddRefs(mWebBrowser));
nsCOMPtr<nsIWebBrowserFind> finder (do_GetInterface(mWebBrowser));

nsString search_string;
search_string.AssignWithConversion("macrovision");
finder->SetSearchString (search_string.get());


Which works smoothly for most of the pages, but produces the crash for some
framed pages.

Comment 9

[Yanko Kaneti]

Attachment: patch for TestGtkEmbed do a simple find

Comment 10

[Yanko Kaneti]

Oh well, I cant reproduce this any more with 1.0rc1.
Will reopen when/if it happens again

Comment 11

[timeless]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

Confirming based on dups.

See http://bugzilla.mozilla.org/show_bug.cgi?id=244997#c8 for some analysis

jst, do you know what this nsContentIterator code is trying to do?

Comment 13

[Akkana Peck]

I don't see the original problem reported here, at least not in mozilla (I don't
have galeon handy).  I wonder if keeping bug 244887 alive might have been
better?  (The URL mentioned there isn't answering for me, though, so I don't
know if I can reproduce that problem.)

Perhaps someone who can reproduce the crash can try adding the null check
Timeless suggests and see if it helps?

Joe, you've worked with the content iterator code here, right?  Is there any
reason not to add some null checks before the getChildAt() call?  How about
getParent() calls?  Or should this never happen, and is the problem someone
passing in a null to NextNode()?

A reproducible case would really help.

Over to DOM Core owner, not a find issue (but I'm willing to help test or fix if
someone comes up with a case I can reproduce).

Comment 14

[Andrew Hagen]

I don't think this bug is Galeon only.

Is this the same bug? TB404291X.  Crash on Win 98, Mozilla trunk build
2004071707. I generated the crash by selecting all the text in the middle column
and then doing a "View selection source" from the context menu.

Comment 15

[timeless]

i field bug 252970 for that talkback incident.

Comment 16

[José Jeria]

URL seems to have changed. Is this still an issue?

Comment 17

[Matthias Versen [:Matti]]

no new report and i can't see this stack in breakpad