Closed Bug 130900 Opened 23 years ago Closed 16 years ago

Find crash in frames [@ nsContentIterator::NextNode]

Categories

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

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: yaneti, Unassigned)

References

()

Details

(Keywords: crash, helpwanted)

Crash Data

Attachments

(1 file)

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
related to bug 101710 ? Always add the build ID in a bug report...
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.
Over to another module.
Component: Embedding: GTK Widget → Embedding: Docshell
Over to akkana for triage.
Assignee: blizzard → akkana
Severity: normal → critical
Keywords: crash
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.
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.
Summary: Find crash in frames [@ nsContentIterator::NextNode] in galeon only → Find crash in frames [@ nsContentIterator::Next] in galeon only
oops, sorry, reverting the summary
Summary: Find crash in frames [@ nsContentIterator::Next] in galeon only → Find crash in frames [@ nsContentIterator::NextNode] in galeon only
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.
Oh well, I cant reproduce this any more with 1.0rc1. Will reopen when/if it happens again
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
*** Bug 244997 has been marked as a duplicate of this bug. ***
Status: RESOLVED → UNCONFIRMED
Component: Embedding: Docshell → DOM: Core
Resolution: WORKSFORME → ---
Blocks: 251088
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
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).
Assignee: akkzilla → general
QA Contact: pavlov → ian
Flags: blocking1.8a3?
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.
Summary: Find crash in frames [@ nsContentIterator::NextNode] in galeon only → Find crash in frames [@ nsContentIterator::NextNode]
i field bug 252970 for that talkback incident.
Flags: blocking1.8a3? → blocking1.8a3-
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
URL seems to have changed. Is this still an issue?
no new report and i can't see this stack in breakpad
Status: NEW → RESOLVED
Closed: 23 years ago16 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsContentIterator::NextNode]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: