Closed Bug 38352 Opened 24 years ago Closed 24 years ago

crash if move browser window while multi-IFRAME doc opens

Categories

(Core :: XUL, defect, P3)

x86
All
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ekrock, Assigned: jud)

References

()

Details

(Keywords: crash)

Attachments

(1 file)

Using 2/27 Commercial 2000042709 on WinNT 4.0 SP4.

To repro:
1) enter URL in Location bar and hit return to start loading (it takes a while 
because there are lots of IFRAMEs & each one is a bugzilla query)
2) while the doc is loading, grab the title bar & drag the window around a lot; 
the browser will crash

Didn't have this problem in M15.

Assigning to XPApps on theory that the crash is being caused by the dragging 
rather than the document itself, because when I load the page without touching 
the window, at least one time it loaded fine. (A second time it seemed to crash 
on document load but I'm not sure whether I touched the window or not.)

Will attach the testcase.
QA Contact: sairuh → jrgm
Reassigning as per Don
Assignee: don → danm
Component: XPApps → XP Toolkit/Widgets
eric -- using 2000051108 on win2k, I cannot reproduce this crash. Can you?
Is this worksforme?
Whiteboard: worksforme?
Adding crash keyword
Keywords: crash
On PC/Linux, all tested build (4/28, 5/07, 5/11 and 5/21) seem to crash with 
the same stack trace:

#0  0x402af4a7 in memcpy (dstpp=0x8b51330, srcpp=0x0, len=44)
#1  0x400aa588 in nsByteArrayInputStream::Read ()
#2  0x40904f1c in InterceptStreamListener::Read ()
#3  0x408f80b4 in nsMultiMixedConv::OnDataAvailable ()
#4  0x409b81d8 in nsDocumentOpenInfo::OnDataAvailable ()
#5  0x40923e4e in nsHTTPFinalListener::OnDataAvailable ()
#6  0x40905005 in InterceptStreamListener::OnDataAvailable ()
#7  0x408ff5c0 in nsHTTPChunkConv::OnDataAvailable ()
#8  0x40922c86 in nsHTTPServerListener::OnDataAvailable ()
#9  0x408dfeb5 in nsOnDataAvailableEvent::HandleEvent ()
#10 0x408df6b5 in nsStreamListenerEvent::HandlePLEvent ()
#11 0x400bb35f in PL_HandleEvent ()
#12 0x400bb286 in PL_ProcessPendingEvents ()
#13 0x400bc139 in nsEventQueueImpl::ProcessPendingEvents ()
#14 0x4062a2bf in event_processor_callback ()
#15 0x4062a02f in our_gdk_io_invoke ()
 
With the 5/25 build (and sometimes with 5/21, too) I crash with a different
stack trace:

#0  0x408f8e46 in nsMultiMixedConv::SendStop ()
#1  0x408f82c0 in nsMultiMixedConv::OnDataAvailable ()
#2  0x409b81d8 in nsDocumentOpenInfo::OnDataAvailable ()
and so on (same as above).

Removing "worksforme?" from Status Whiteboard.
Whiteboard: worksforme?
Upping severity, OS=All, reassigning to valeski@netscape.com because he fixed
bug 39987 "Crash in nsMultiMixedConv::SendStopafter submitting form" which 
seems to have the same stack trace as the second one above. CC self.

Jud: the second stack trace was taken with my 5/21 build, so your fix can't be
in there. However, the 5/25 build (a nightly where the function symbols are 
not included in the libraries) shows a stack trace that would perfectly match
it:
#0  0x408954ac in NSGetModule ()   from components/libnecko.so
#1  0x40894af4 in NSGetModule ()   from components/libnecko.so
#2  0x409501b3 in NSGetModule ()   from components/liburiloader.so
#3  0x408bc7f9 in NSGetModule ()   from components/libnecko.so
#4  0x408a066a in NSGetModule ()   from components/libnecko.so
#5  0x4089b476 in NSGetModule ()   from components/libnecko.so
#6  0x408bb799 in NSGetModule ()   from components/libnecko.so
#7  0x4087e974 in NSGetModule ()   from components/libnecko.so
#8  0x4087e270 in NSGetModule ()   from components/libnecko.so
#9  0x400b212b in PL_HandleEvent ()   from libxpcom.so
#10 0x400b2066 in PL_ProcessPendingEvents ()   from libxpcom.so
#11 0x400b2d2d in nsEventQueueImpl::ProcessPendingEvents ()   from libxpcom.so
#12 0x405d120f in NSGetModule ()   from components/libwidget_gtk.so
#13 0x405d0fdd in NSGetModule ()   from components/libwidget_gtk.so
#14 0x4076dc9a in g_io_unix_dispatch (source_data=0x8239100, 
    current_time=0xbffff068, user_data=0x81ce5e8) at giounix.c:135
#15 0x4076f4d3 in g_main_dispatch (current_time=0xbffff068) at gmain.c:652
#16 0x4076fb0b in g_main_iterate (block=1, dispatch=1) at gmain.c:870
#17 0x4076fcc1 in g_main_run (loop=0x8239118) at gmain.c:928
#18 0x40691f0b in gtk_main () at gtkmain.c:475
Assignee: danm → valeski
Severity: normal → critical
OS: Windows NT → All
I can't repro this on NT. and I can't try from linux because my linux box isn't
inside the firewall.
I tested this with the attachment, not with the given URL. (Of course I'm
outside the firewall, too :)
By the way, maybe you have to "drag the window around a lot", literally.
Best thing seems to be keeping the window in motion all the time while loading.
The first time I tried with the 5/25 build, I did not crash, but the other
two times I could reproduce it. 
Don't know why, but currently I can't reproduce this with 5/25 and newer builds.
wfm
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: