Closed
Bug 130900
Opened 23 years ago
Closed 16 years ago
Find crash in frames [@ nsContentIterator::NextNode]
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: yaneti, Unassigned)
References
()
Details
(Keywords: crash, helpwanted)
Crash Data
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
related to bug 101710 ?
Always add the build ID in a bug report...
Reporter | ||
Comment 2•23 years ago
|
||
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•23 years ago
|
||
Over to another module.
Component: Embedding: GTK Widget → Embedding: Docshell
Comment 5•23 years ago
|
||
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.
Reporter | ||
Comment 6•23 years ago
|
||
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
Reporter | ||
Comment 7•23 years ago
|
||
oops, sorry, reverting the summary
Summary: Find crash in frames [@ nsContentIterator::Next] in galeon only → Find crash in frames [@ nsContentIterator::NextNode] in galeon only
Reporter | ||
Comment 8•23 years ago
|
||
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.
Reporter | ||
Comment 9•23 years ago
|
||
Reporter | ||
Comment 10•23 years ago
|
||
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
Comment 11•20 years ago
|
||
*** Bug 244997 has been marked as a duplicate of this bug. ***
Status: RESOLVED → UNCONFIRMED
Component: Embedding: Docshell → DOM: Core
Resolution: WORKSFORME → ---
Comment 12•20 years ago
|
||
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•20 years ago
|
||
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
Updated•20 years ago
|
Flags: blocking1.8a3?
Comment 14•20 years ago
|
||
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]
Comment 15•20 years ago
|
||
i field bug 252970 for that talkback incident.
Updated•20 years ago
|
Flags: blocking1.8a3? → blocking1.8a3-
Comment 16•16 years ago
|
||
URL seems to have changed. Is this still an issue?
Comment 17•16 years ago
|
||
no new report and i can't see this stack in breakpad
Status: NEW → RESOLVED
Closed: 23 years ago → 16 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ nsContentIterator::NextNode]
You need to log in
before you can comment on or make changes to this bug.
Description
•