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)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ekrock, Assigned: jud)
References
()
Details
(Keywords: crash)
Attachments
(1 file)
2.16 KB,
text/html
|
Details |
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.
Reporter | ||
Comment 1•24 years ago
|
||
Updated•24 years ago
|
QA Contact: sairuh → jrgm
Comment 2•24 years ago
|
||
Reassigning as per Don
Assignee: don → danm
Component: XPApps → XP Toolkit/Widgets
Comment 3•24 years ago
|
||
eric -- using 2000051108 on win2k, I cannot reproduce this crash. Can you? Is this worksforme?
Whiteboard: worksforme?
Comment 5•24 years ago
|
||
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?
Comment 6•24 years ago
|
||
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
Assignee | ||
Comment 7•24 years ago
|
||
I can't repro this on NT. and I can't try from linux because my linux box isn't inside the firewall.
Comment 8•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
Don't know why, but currently I can't reproduce this with 5/25 and newer builds.
Assignee | ||
Comment 10•24 years ago
|
||
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.
Description
•