Closed Bug 109356 Opened 23 years ago Closed 23 years ago

Crash entering joins.com

Categories

(Core :: Layout, defect, P1)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME
mozilla0.9.7

People

(Reporter: tracy, Assigned: srgchrpv)

References

()

Details

(Keywords: crash, regression, smoketest)

seen on linux commercial build 2001-11-09-06-trunk

-goto www.joins.com

the page comes up momentarily, then...

Crash

talkback Incident:  
http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=37796560
this is one of the international browsers top page smoketests
Keywords: smoketest
I can't reproduce this bug with a debug or an optimized build on linux, with or
without flash installed ( there's a flash animation on the page. )
I cannot reproduce this with win2K or Mac X 110903 trunk builds. 
for those who can't see talkback data yet:
Stack Signature  nsLineLayout::CanPlaceFrame() 45ae3832
Bug ID
Trigger Time 2001-11-09 09:43:41
Email Address twalker@netscape.com
URL visited http://www.joins.com
User Comments crash entering joins.com
Build ID 2001110906
Product ID MozillaTrunk
Platform
Operating System LinuxIntel
Module
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
nsLineLayout::CanPlaceFrame()
nsLineLayout::ReflowFrame()
nsBlockFrame::ReflowInlineFrame()
nsBlockFrame::DoReflowInlineFrames()
nsBlockFrame::DoReflowInlineFramesAuto()
nsBlockFrame::ReflowInlineFrames()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableCellFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableRowFrame::IR_TargetIsChild()
nsTableRowFrame::IncrementalReflow()
nsTableRowFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableRowGroupFrame::IR_TargetIsChild()
nsTableRowGroupFrame::IncrementalReflow()
nsTableRowGroupFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableFrame::IR_TargetIsChild()
nsTableFrame::IncrementalReflow()
nsTableFrame::Reflow()
nsContainerFrame::ReflowChild()
nsTableOuterFrame::OuterReflowChild()
nsTableOuterFrame::IR_InnerTableReflow()
nsTableOuterFrame::IR_TargetIsInnerTableFrame()
nsTableOuterFrame::IR_TargetIsChild()
nsTableOuterFrame::IncrementalReflow()
nsTableOuterFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsContainerFrame::ReflowChild()
CanvasFrame::Reflow()
nsBoxToBlockAdaptor::Reflow()
nsBoxToBlockAdaptor::DoLayout()
nsBox::Layout()
nsScrollBoxFrame::DoLayout()
nsBox::Layout()
nsContainerBox::LayoutChildAt()
nsGfxScrollFrameInner::LayoutBox()
nsGfxScrollFrameInner::Layout()
nsGfxScrollFrame::DoLayout()
nsBox::Layout()
nsBoxFrame::Reflow()
nsGfxScrollFrame::Reflow()
nsContainerFrame::ReflowChild()
ViewportFrame::Reflow()
nsHTMLReflowCommand::Dispatch()
PresShell::ProcessReflowCommand()
PresShell::ProcessReflowCommands()
HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xe52a (0x4034d52a)
libglib-1.2.so.0 + 0xfbe6 (0x4034ebe6)
libglib-1.2.so.0 + 0x101a1 (0x4034f1a1)
libglib-1.2.so.0 + 0x10341 (0x4034f341)
libgtk-1.2.so.0 + 0x8c209 (0x40276209)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x181eb (0x4044e1eb) 
Adding some layout folks.
Component: Internationalization → Layout
People are reporting that this is reprocable on commercial builds.  I haven't
found anyone who sees it on moz builds yet.
WFM in a linux mozilla build pulled this morning. I'll try a commercial build, now.
Really strange. Here is what we saw in iQA's Linux machine- Launch NS ( displays
home.netscape.com )
- goto www.yahoo.com 
- goto www.joins.com   <- doesn't crash

- Launch NS 
- goto www.joins.com <- CRASH

Verified it crashs on yesterday's build as well.

Reducing the severity for now.  We'll want this for 0.9.6, though.
Blocks: 104864
Severity: blocker → critical
Keywords: crash
I checked this page on 11-08 trunk build, it crash also.

And I checked in on 10-31 trunk build, it doesn't crash there, however I noticed
there is a diference with this page display between 11-09 or 11-08 and 10-30 builds:
With this flash file(ad) which displaying on the top of this page, 10-31 and
11-09 is different.  Do we handle those kind of file differently now?
No longer blocks: 104864
Keywords: crash
Blocks: 104864
Keywords: crash
QA Contact: teruko → ylong
Hmm. I couldn't reproduce this in a commercial debug linux build. This _is_ a
linux-only problem, right?
Naoki, Roy and I did some more investigation:
It's happened between 11-06-12(no crash) and 11-07-08(crash).
Keywords: regression
we've discovered that going to yahoo.com first, then to joins.com will reproduce 
this crash...in commercial at least
  Checkins to directory mozilla/layout between 11/06/2001 11:59 and 11/07/2001 
08:00:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&bra
nchtype=match&dir=mozilla%2Flayout&file=&filetype=match&who=&whotype=match&sortb
y=Date&hours=2&date=explicit&mindate=11%2F06%2F2001+11%3A59%3A00&maxdate=11%2F07
%2F2001+08%3A00%3A00&cvsroot=%2Fcvsroot

cc to people who checked in, please take a look at the stack trace.

Need help, all linux machines in i18n group been dead since this Monday and we 
cannot identify what cause the problem.


hyatt@netscape.com,peterlubczynski@netscape.com,karnaze@netscape.com,loadrunner@
betak.net,alecf@netscape.com
Reassign to attinasi, it is crashing in layout.
Assignee: yokoyama → attinasi
I did not crash for me (Redhat 6.2 on accipiter) until I install the flash 
plugin.
crash in ns4xPluginInstance.cpp at line 811

 	802	  NS_TRY_SAFE_CALL_RETURN(error, CallNPP_NewProc(fCallbacks->newp,
 	803	                                          (char *)mimetype,
 	804	                                          &fNPP,
 	805	                                          (PRUint16)mode,
 	806	                                          count,
 	807	                                          (char**)names,
 	808	                                          (char**)values,
-	809	                                          NULL), fLibrary);
 	810	
-	811	  NPP_PLUGIN_LOG(PLUGIN_LOG_NORMAL,
 	812	  ("NPP New called: this=%p, npp=%p, mime=%s, mode=%d, argc=%d,
return=%d\n",
-	813	  this, fNPP, mimetype, mode, count, error));
 	814	
-	815	  if(error != NPERR_NO_ERROR)
-	816	    rv = NS_ERROR_FAILURE;

stack trace:

#0  ns4xPluginInstance::InitializePlugin (this=0x86ed828, peer=0x8681740) at
ns4xPluginInstance.cpp:811
#1  0x418e2676 in ns4xPluginInstance::Initialize (this=0x86ed828,
peer=0x8681740) at ns4xPluginInstance.cpp:697
#2  0x418eef43 in nsPluginHostImpl::SetUpPluginInstance (this=0x8189d40,
aMimeType=0x8685660 "application/x-shockwave-flash", aURL=0x85e81b0,
aOwner=0x86e1ad8) at nsPluginHostImpl.cpp:3684
#3  0x418edbac in nsPluginHostImpl::InstantiateEmbededPlugin (this=0x8189d40,
aMimeType=0x8685660 "application/x-shockwave-flash", aURL=0x85e81b0,
aOwner=0x86e1ad8) at nsPluginHostImpl.cpp:3239
#4  0x41c98bc8 in nsObjectFrame::InstantiatePlugin (this=0x86ec6e8,
aPresContext=0x85ac0d0, aMetrics=@0xbfffab30, aReflowState=@0xbfffab70,
aPluginHost=0x8189d44, aMimetype=0x8685660 "application/x-shockwave-flash",
aURI=0x85e81b0) at nsObjectFrame.cpp:1300
#5  0x41c980f7 in nsObjectFrame::Reflow (this=0x86ec6e8, aPresContext=0x85ac0d0,
aMetrics=@0xbfffab30, aReflowState=@0xbfffab70, aStatus=@0xbfffb0e0) at
nsObjectFrame.cpp:1120
#6  0x41c8f750 in nsLineLayout::ReflowFrame (this=0xbfffb1b8, aFrame=0x86ec6e8,
aNextRCFrame=0xbfffadb4, aReflowStatus=@0xbfffb0e0, aMetrics=0x0,
aPushedFrame=@0xbfffacac) at nsLineLayout.cpp:1037
#7  0x41c893be in nsInlineFrame::ReflowInlineFrame (this=0x8718728,
aPresContext=0x85ac0d0, aReflowState=@0xbfffaf80, irs=@0xbfffadb4,
aFrame=0x86ec6e8, aStatus=@0xbfffb0e0) at nsInlineFrame.cpp:706
#8  0x41c88d60 in nsInlineFrame::ReflowFrames (this=0x8718728,
aPresContext=0x85ac0d0, aReflowState=@0xbfffaf80, irs=@0xbfffadb4,
aMetrics=@0xbfffaf40, aStatus=@0xbfffb0e0) at nsInlineFrame.cpp:521
#9  0x41c88ab6 in nsInlineFrame::Reflow (this=0x8718728, aPresContext=0x85ac0d0,
aMetrics=@0xbfffaf40, aReflowState=@0xbfffaf80, aStatus=@0xbfffb0e0) at
nsInlineFrame.cpp:432
#10 0x41c8f750 in nsLineLayout::ReflowFrame (this=0xbfffb1b8, aFrame=0x8718728,
aNextRCFrame=0xbfffbb20, aReflowStatus=@0xbfffb0e0, aMetrics=0x0,
aPushedFrame=@0xbfffb0dc) at nsLineLayout.cpp:1037
#11 0x41c43383 in nsBlockFrame::ReflowInlineFrame (this=0x86fd148,
aState=@0xbfffbaa4, aLineLayout=@0xbfffb1b8, aLine={mCurrent = 0x86fd3a8,
mListLink = 0x86fd184}, aFrame=0x8718728, aLineReflowStatus=0xbfffb14f "") at
nsBlockFrame.cpp:3673
#12 0x41c42f32 in nsBlockFrame::DoReflowInlineFrames (this=0x86fd148,
aState=@0xbfffbaa4, aLineLayout=@0xbfffb1b8, aLine={mCurrent = 0x86fd3a8,
mListLink = 0x86fd184}, aKeepReflowGoing=0xbfffb840,
aLineReflowStatus=0xbfffb66f "\002", aUpdateMaximumWidth=1, aDamageDirtyArea=1)
at nsBlockFrame.cpp:3555
#13 0x41c42c82 in nsBlockFrame::DoReflowInlineFramesAuto (this=0x86fd148,
aState=@0xbfffbaa4, aLine={mCurrent = 0x86fd3a8, mListLink = 0x86fd184},
aKeepReflowGoing=0xbfffb840, aLineReflowStatus=0xbfffb66f "\002",
aUpdateMaximumWidth=1, aDamageDirtyArea=1) at nsBlockFrame.cpp:3478
#14 0x41c42a42 in nsBlockFrame::ReflowInlineFrames (this=0x86fd148,
aState=@0xbfffbaa4, aLine={mCurrent = 0x86fd3a8, mListLink = 0x86fd184},
aKeepReflowGoing=0xbfffb840, aDamageDirtyArea=1, aUpdateMaximumWidth=1) at
nsBlockFrame.cpp:3424
#15 0x41c402f3 in nsBlockFrame::ReflowLine (this=0x86fd148, aState=@0xbfffbaa4,
aLine={mCurrent = 0x86fd3a8, mListLink = 0x86fd184},
aKeepReflowGoing=0xbfffb840, aDamageDirtyArea=1) at nsBlockFrame.cpp:2460
#16 0x41c3f455 in nsBlockFrame::ReflowDirtyLines (this=0x86fd148,
aState=@0xbfffbaa4) at nsBlockFrame.cpp:2149
#17 0x41c3c2f8 in nsBlockFrame::Reflow (this=0x86fd148, aPresContext=0x85ac0d0,
aMetrics=@0xbfffbf0c, aReflowState=@0xbfffbe54, aStatus=@0xbfffd018) at
nsBlockFrame.cpp:824
#18 0x41c536a7 in nsContainerFrame::ReflowChild (this=0x86fd0ec,
aKidFrame=0x86fd148, aPresContext=0x85ac0d0, aDesiredSize=@0xbfffbf0c,
aReflowState=@0xbfffbe54, aX=0, aY=0, aFlags=0, aStatus=@0xbfffd018) at
nsContainerFrame.cpp:714
#19 0x41d5eb54 in nsTableCellFrame::Reflow (this=0x86fd0ec,
aPresContext=0x85ac0d0, aDesiredSize=@0xbfffc174, aReflowState=@0xbfffc0bc,
aStatus=@0xbfffd018) at nsTableCellFrame.cpp:839
The problem on line 811 is only when logging is active. It should be printing
out the address of fNPP:

("NPP New called: this=%p, npp=%p, mime=%s, mode=%d, argc=%d, return=%d\n",
this, &fNPP, mimetype, mode, count, error));

This shouldn't be compiled in release builds. I'll try backing out my changes.
I commented out that code and it still crashes.
This sounds similar to the memory curruption in bug 105275 and the HTML markup
shows SWLiveConnect=TRUE on the EMBED tag. This works fine in Windows and I
don't have a Linux build. :(

There is a lot of UNIX-only plugin code in NPP_SetWindow() but I don't know gtk:
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/ns4xPluginInstance.cpp#835
Target Milestone: --- → mozilla0.9.6
Over to peterl - this is plugin stuff.
Assignee: attinasi → peterl
Priority: -- → P1
Target Milestone: mozilla0.9.6 → mozilla0.9.7
I think this is similar to another one Serge has....
Assignee: peterl → serge
Hmm, I cannot reproduce the crash in mozilla debug build from 2001-11-14,
commercial optimized build 2001-11-19-21-trunk also WFM.
ylong, could you try the latest build, if it still crashes talkback would be 
useful. Thanks.
Yes, I haven't seen this crash on 11-19 trunk build - I tried it by Tracy's
steps too.
I cannot reproduce this with 2001-12-13 trunk build,
I'm resolving this as WFM.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Not reproduce it on 12-13 trunk build too.  
Mark verified as works for me.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.