302555 - Selecting any article link crashes the program

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Jim Moe]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/20050726
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/20050726

The Arizona Daily Star website recently changed, um, something. The articles
take longer to download and now, with v1.7.10, it partially renders an article
then crashes.

In v1.7.8 this was a rarity. And after restarting the v1.7.8, the link would
actually load as desired.


Reproducible: Always

Steps to Reproduce:
1. go to http://www.azstarnet.com/
2. click on an article link


Actual Results:  
It crashses after partially displaying an article.

Expected Results:  
Display the page so it can be read.


Here is summary crash data:
07-28-2005  14:21:48  SYS3175  PID 045c  TID 0001  Slot 00c5
D:\MOZILLA\MOZILLA\MOZILLA.EXE
c0000005
1d31b3b8
P1=00000001  P2=00000018  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=00000000  EBX=012d41c8  ECX=17e39304  EDX=00000000
ESI=013c49cc  EDI=012c2c80  
DS=0053  DSACC=f0f3  DSLIM=ffffffff  
ES=0053  ESACC=f0f3  ESLIM=ffffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1d31b3b8  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0012e3f4  SSACC=f0f3  SSLIM=ffffffff
EBP=0012e43c  FLG=00012202

GKLAYOUT.DLL 0001:0005b3b8

I have a crash dump if that would help. It's about 2 MB in size.

Comment 1

[Jim Moe]

Damn! I just tried it again and it worked correctly. 
And now it refuses to misbehave. Apparently there is another step to reproduce
that I have not recognized. Although to get the procdump I went to the site,
clicked on an article; no intervening actions.

Comment 2

[Peter Weilbacher]

I can take a look in my .map files what that crash address corresponds to, but
if you cannot reproduce any more than this is usually a waste of time. Crashes
in GKLAYOUT are normally not caused by plugins but you could try to download the
webpage source with wget or 1.7.8 and have a look if they now use Flash or the like.

Comment 3

[Peter Weilbacher]

Jim, has that ever occured again?

[I looked up the crash address and in my 1.7.10 tree it corresponds to 

nsCSSFrameConstructor::WipeContainingBlock(nsIPresContext*,
nsFrameConstructorState&, nsIContent*, nsIFrame*, nsIFrame*)

which has something to do with how to handle special constructs with frames. Not
sure this is really where it is crashing, I don't see a pointer that could
wrongly point to address 18.]

Comment 4

[Jim Moe]

I have since updated to v1.7.11. I believe the crash happened once since then
and that was right after the update, and has not occurred again.

I suspect something about the site itself. It had changed in some way about how
it delivers content. And it is smoothing the difficulties it has been having.

I suggest changing the status to INVALID since I can no longer even occasionally
reporduce the error.

Comment 5

[Peter Weilbacher]

OK, for that WORKSFORME is usually taken. :-) Please reopen, if you see this
problem again.