Closed Bug 5106 Opened 26 years ago Closed 25 years ago

viewer core dumps when resizing during a URL load

Categories

(Core Graveyard :: Viewer App, defect, P3)

Sun
Solaris

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 5661

People

(Reporter: dejong, Assigned: harishd)

Details

Resized while loading slashdot.org #0 0xef29e46c in SinkContext::~SinkContext (this=0x261a28, __in_chrg=3) at ../../../../../layout/html/document/src/nsHTMLContentSink.cpp:895 #1 0xef2a0848 in HTMLContentSink::~HTMLContentSink (this=0x246c00, __in_chrg=3) at ../../../../../layout/html/document/src/nsHTMLContentSink.cpp:1429 #2 0xef2a0b14 in HTMLContentSink::Release (this=0x246c00) at ../../../../../layout/html/document/src/nsHTMLContentSink.cpp:1442 #3 0xef558f90 in nsParser::~nsParser (this=0x246ba8, __in_chrg=3) at ../../../htmlparser/src/nsParser.cpp:166 #4 0xef559164 in nsParser::Release (this=0x246ba8) at ../../../htmlparser/src/nsParser.cpp:175 #5 0xef778920 in nsDocumentBindInfo::OnStopBinding (this=0x2215e0, aURL=0x1f85d0, aStatus=0, aMsg=0xefffe2b8) at ../../../webshell/src/nsDocLoader.cpp:2007 #6 0xeec8ccd4 in stub_complete (stream=0x2069d0) at ../../../network/module/nsStubContext.cpp:765 #7 0xeed0546c in net_MemCacheComplete (stream=0x261aa0) at ../../../network/cache/mkmemcac.c:720 #8 0xeecc72dc in net_ChunkedComplete (stream=0x206598) at ../../../network/cnvts/cvchunk.c:258 #9 0xeed9e8ec in net_ProcessHTTP (ce=0x1f8628) at ../../../../network/protocol/http/mkhttp.c:3604 #10 0xeebfbcd0 in NET_ProcessNet (ready_fd=0x283948, fd_type=2) at ../../../network/main/mkgeturl.c:3355 #11 0xeec08070 in NET_PollSockets () at ../../../network/main/mkselect.c:320 #12 0xeec82d3c in nsNetlibService::NetPollSocketsCallback (aTimer=0x1e0980, aClosure=0x1e03b8) at ../../../network/module/nsNetService.cpp:1279 #13 0xef5a41cc in TimerImpl::FireTimeout (this=0x1e0980) at ../../../../base/src/gtk/nsTimer.cpp:73 #14 0xef5a4984 in nsTimerExpired (aCallData=0x1e0980) at ../../../../base/src/gtk/nsTimer.cpp:189 #15 0xee5067c4 in g_timeout_dispatch (source_data=0x27b970, current_time=0xefffef70, user_data=0x1e0980) at gmain.c:1147 #16 0xee5054a4 in g_main_dispatch (current_time=0xefffef70) at gmain.c:647 #17 0xee505cdc in g_main_iterate (block=1116, dispatch=1) at gmain.c:854 #18 0xee505eec in g_main_run (loop=0x1ee950) at gmain.c:912 #19 0xee646164 in gtk_main () at gtkmain.c:475 #20 0xef711b98 in nsAppShell::Run (this=0xaed10) at ../../../../widget/src/gtk/nsAppShell.cpp:208 #21 0x21d48 in nsNativeViewerApp::Run (this=0xaa648) at ../../../../webshell/tests/viewer/nsGTKMain.cpp:42 #22 0x22080 in main (argc=1, argv=0xeffff234) at ../../../../webshell/tests/viewer/nsGTKMain.cpp:97 SinkContext::~SinkContext() { if (nsnull != mStack) { for (PRInt32 i = 0; i < mStackPos; i++) { NS_RELEASE(mStack[i].mContent); (THIS IS LINE 895 !!) } delete [] mStack; } if (nsnull != mText) { delete [] mText; } } So it seems like the problem is with the mStack pointer not pointing to a valid chunck of memory. Perhaps the real issue is that the mStackPos variable should be zero in this case? (gdb) print mStack $1 = (Node *) 0x6c617368 (gdb) print i $2 = 0 (gdb) print mStackPos $3 = 1869768495 (gdb) print mStack[i] Cannot access memory at address 0x6c617368. (gdb) print mStack[i].mContent Cannot access memory at address 0x6c61736c.
Assignee: rickg → kipp
This may be something you already know about.
Assignee: kipp → harishd
QA Contact: 3853 → 4079
sujay, chofmann and I would like to know if this happens with Linux too on Apprunner. If so with the latest build, we may have an M5 blocker here. Thanks!
I don't see the crash in Apr20th build!! Sujay, do you see the crash??
I"m working on this one...will have status shortly...installing Linux builds right now!
Okay, I just installed the 4/21 build on Linux and gave it a whirl for both apprunner AND viewer. I can resize both inward and outward for the URL mentioned(slashdot.org) w/o any crash/coredump. I also tried other random URLs.
Target Milestone: M5
Setting M5 Milestone
Target Milestone: M5 → M6
Moving to M6
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Seems to work Ok on Linux. I think this is a dup of 5661, Solaris simply dies in timer code on startup. *** This bug has been marked as a duplicate of 5661 ***
Status: RESOLVED → VERIFIED
verified in 4/29 build.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.