105275 - crash after loads rtl.de - M099 N622 Trunk[@ nsBlockFrame::ComputeFinalSize][@ nsTableRowFrame::IR_TargetIsChild]

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Yuying Long]

Build: 10-17 0.9.4 linux branch build on RH7.1-Ja

Crashes after finished loading rtl.de, not sure it's cause by JavaScript problem.

I also see the crash on Mac OS X-Ja / 10-16 0.9.4 non-smi branch build, but no
stack track for that though.

Please change component if not an i18n problem.

Talkback ID 36827137, 36827044 for linux.
-----------------------------------
Incident ID 36827137
Stack Signature nsTableRowFrame::IR_TargetIsChild() 0d75721e
Bug ID
Trigger Time 2001-10-17 12:40:48
Email Address [e-mail]
URL Visited www.rtl.de
User Comments crash when launch rtl.de
Build ID 2001101705
Product ID Netscape6.20
Platform ID LinuxIntel
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
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()
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 + 0x1001e (0x4036701e)
libglib-1.2.so.0 + 0x117f3 (0x403687f3)
libglib-1.2.so.0 + 0x11dd9 (0x40368dd9)
libglib-1.2.so.0 + 0x11f8c (0x40368f8c)
libgtk-1.2.so.0 + 0x94803 (0x4027d803)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1c177 (0x404ab177)

Comment 1

[Teruko Kobayashi]

Roy, please look at this.

Comment 2

[Roy Yokoyama]

teruko: I love to; but it's Linux bug.
ylong: is this regression?
-> bstell

Comment 3

[Yuying Long]

I think it's a regression - I didn't see the crash on 10-02 branch build but
crashed on 10-15 branch build though.

Comment 4

[Frank Tang]

crash inside table. give to table team 
is this the top 100 site?

Comment 5

[Jaime Rodriguez, Jr.]

Nominating because I think this is top 20 german sites. argh! This may be a stopper.

Comment 6

[Jaime Rodriguez, Jr.]

Ylong/Ftang - Can you pls attach a test case for karnaze to look at, ASAP?

Comment 7

[Jaime Rodriguez, Jr.]

This #17 site in the Germany. :-(

Comment 8

[Jaime Rodriguez, Jr.]

from Lisa ...

"Jay - can you look at the talkback reports to see if these are top crashes?

Ylong - ... "has the site changed betweeen 10-2 (when the reporter says the bug
was working last) and now?   It'd be interesting to go back to the 10-2 build to
try."

Comment 9

[lchiang]

Could the page have changed between when you tested on the 10-2 build vs.
today's build?   What happens if you go back to the 10-2 build now?   (I
couldn't tell from the comments if this was done or if you were recalling your
10-2 results from the past.)  Thanks.

Comment 10

[lchiang]

Is this only on Linux and Mac?

I tried this on the following Win32 builds and all were ok (Page and plugin
window opened and loaded fine):

1.  Netscape 6.1
2.  2001-10-17-05-094 branch build (installed using Custom install with all
components checked).

Comment 11

[kill this account]

http://rtl.de/rtlworld.html
I ran this on my 0.9.4 branch build (declined plugins) and it did not crash.
(boy, it it !@#$ agressive about wanting to install the plugins).

Comment 12

[Yuying Long]

It not reproducible case on windows.

I need make clear one more thing - in my previous comments said not reproducible
on 10-02, I realized I installed 10-02 build as a recommand install but 10-17 is
a full installation.

Comment 13

[Yuying Long]

Attachment: Saved today's rtl.de page in case it contains some data

Comment 14

[kill this account]

downloaded shockwave plugin, page loads for me without crashing.

Comment 15

[Jay Patel [:jay]]

This looks like a dup of bug 101855...which is a topcrasher with Mozilla 0.9.4.
 That bug hasn't gone anywhere since we don't have a reproducible test case and
also don't have line numbers in the Linux stacktrace.

Since this is a topcrasher with M094 and has been seen with recent branch
builds, it might be worth looking into some more.  I haven't seen this crash on
any other topcrash lists though (MozillaTrunk, M095, etc)

Comment 16

[karnaze (gone)]

Attinasi was able to reproduce the bug with an older linux build with the plugin 
installed but not with it uninstalled. He was not able to reproduce on Mac OS 9 
with (or without) the plugin installed. We are not able to reproduce it on Win2K 
with (or without) the plugin installed.

Comment 17

[karnaze (gone)]

*** Bug 101855 has been marked as a duplicate of this bug. ***

Comment 18

[Marc Attinasi]

Peter L. tried to repro on a branch OS X build and was not able to. His build
date was 10-12.

Comment 19

[Jay Patel [:jay]]

I found A LOT of these crashes in the M094 Talkback reports.  Here are some user
comments and urls from the Mozilla 0.9.4 Talkback data for this crash:

(36759154)
URL: http://www.ntl.co.uk
(36515688)
URL: www.rtl.de
(36515688)
Comments: i did connect the page from www.rtl.de
(36509010)
URL: www.rtl.de
(36509010)
Comments: open
     (36496593)	Comments: Sending an email with Yahoo! Mail.
     (36496560)	Comments: Sending a message using yahoo mail.
     (36435092)	URL: http://mail.yahoo.com/
(36435092)
Comments: Logging into mail account (I was in standard/insecure mode).
     (36407876)	URL: www.washingtonpost.com
(36407825)
URL: www.acm.org
(36371593)
Comments: Playing with JavaScript to automate URL navigation (like: "loation.href=")
     (36337788)	URL: http://www2.sonyericssonmobile.com/T39/presentation/03_pim.shtml
(36337788)
Comments: when i klicked on the link(linked to the above adres) my mozilla just
shut off

Comment 20

[kill this account]

both a full and a recommended install of 
ftp://sweetlou/products/client/seamonkey/unix/linux/2.2/x86/2001-10-17-04-0.9.4/netscape-i686-pc-linux-gnu-sea.tar.gz  
crashes on my Redhat 7.1 US system

Comment 21

[Marc Attinasi]

Attachment: copy of the main frame, with the script that redirects us to the real site commented out.

Comment 22

[Marc Attinasi]

Attachment: testcase: copy of page with some script hacked so we can play the movies (but not get sent to the real site)

Comment 23

[Marc Attinasi]

Attachment: testcase - bottom frame

Comment 24

[Marc Attinasi]

Attachment: frameset - uses teh two frames attached to the bug

Comment 25

[kill this account]

once I have a working profile it does not crash on the installed builds

Comment 26

[Amarendra Hanumanula]

 Crashes for me on Linux 7.1 but dint crash on WIN2K and Mac osx.. 
Tested it on Build ID: 2001-10-17-07-0.9.4

Comment 27

[Amarendra Hanumanula]

 My above comments are based on installing the plugins

Comment 28

[Marc Attinasi]

bstell - what do you mean by this:

'once I have a working profile it does not crash on the installed builds'

I was able to crash using the testcases I attached, but now I cannot. Ugh, we
really need a reduced testcase, or somebody with a clue. Peter L. thinks that
this might be a LiveConnect issue, and I'm CC'ing Patrick Beard since he might
have a clue...

Comment 29

[Peter Lubczynski]

More URL from dup bug:

http://www.serveisweb.com/castella/index.htm
http://www.fitforfun.de/food/specials/100fetttipps/
http://www.gmate.co.kr
http://relaunch.bad-zwischenahn.de/index1.html

Marc, do any of those crash for you?

Comment 30

[karnaze (gone)]

Reassigning to beard.

Comment 31

[Amarendra Hanumanula]

 I have installed 2001-10-17-04-0.9.4 build with out java pluigns on Linux 7.1..
the given URI and the testcase does not crash
It might be problem with the plugins
 

Comment 32

[kill this account]

I cannot get a reproducible crash case so have to retract the "once I have a
working profile it does not crash" comment.  For the executables downloaded 
from sweetlou: sometimes it crashes and sometimes it does not.

Sadly, my debug build never seems to crash.

This feels to me like a memory corruption problem. If it were my bug I would
move quickly to using purify.

Comment 33

[Patrick C. Beard]

--> peterl for investigation

Comment 34

[Marc Attinasi]

One thing to think about: I am generally crashing after _leaving_ the rtl page,
so maybe some of the reported URLs are not the actual culprits, but instead it
was the page they were on before. Just a thought... some of the URLs look pretty
harmless (acm.org, washingtonpost for example) while others do have Flash or
Java (sonyerricson, ntl)

Comment 35

[danielmc]

I have had great difficulty reproducing this with any consistancy. I have 
been testing on Mandrake Linux 8.0. At first I could not reproduce the crash 
with a complete or recommended build.

I tried a custom install not installing flash. I then D/L the flash plugin and 
installed it. When I relaunched N6 and went to rtl.de the browser crashed after 
loading the plugin (submitted the talkback report). However when I relaunched 
after the crash I was not able to get to to crash again. I tried with a number 
of different profiles/installations and was unable to reproduce this. 

I was also unable to reproduce on OS X

Build ID: 2001-10-17-16-0.9.4

Comment 36

[Jaime Rodriguez, Jr.]

Adding more German QA folks ... 

Comment 37

[Jaime Rodriguez, Jr.]

Ylong - Pls check this in both Netscape 6.1, and with the 1.3.0 JRE? We would be
interested to know, if this problem occurs there as well.

Comment 38

[Peter Lubczynski]

I need some QA help to track this down. 

Can someone help me fine a RELIABLE way to reproduce this crash.
http://www.rtl.de only crashes for me about 15% of the time and it looks
completely random. Does anyone crash at another site with the same stack?

Comment 39

[lchiang]

I will email Asa and QA.

Comment 40

[Yuying Long]

I checked it on N6.1 (both my machine and Xianglan's machine), it hangs. 

Comment 41

[Yuying Long]

> re you testing NS 6.1 on RH 7.1? If so, the hang may be due to a known old  
> problem with the JRE. Set enviornment variable LD_ASSUME_KERNEL=2.2.5 and does
it > still hang? NS 6.2 will have JRE 1.3.1 which should not show this problem.

> -peterl

-- after I did the change, then loads OK.

Comment 42

[ji]

With environment variable LD_ASSUME_KERNEL set to 2.2.5, 6.1 works on
http://news.chinatimes.com
http://www.rtl.de
Sun's Java i18n demo pages.

But the latest linux 0.9.4 build crashes in the same environment.

Comment 43

[Yuying Long]

Seems when I set LD_ASSUME_KERNEL=2.2.5 then the 10-17-16 0.9.4 build loads ok
on rtl.de on my linux 7.1-Ja. (but crash on news.chinatimes.com though)

Comment 44

[Peter Lubczynski]

ylong:
http://news.chinatimes.com does not crash for me at all but I'm using a US
build. Does the stack from Talkback on that crash look the same as the one in
this bug? 

ji: Are you able to RELIABLEY crash every time on those links with your build?
If so, could you try to narrow down the HTML causing the crash? Thanks.

Also, be sure you do a FULL install to test because of bug 100880 of problems
with JRE 1.3.1 and fonts in i18n applets.

Comment 45

[Yuying Long]

> ylong:
> http://news.chinatimes.com does not crash for me at all but I'm using a US
> build. Does the stack from Talkback on that crash look the same as the one in
> this bug? 

-- No, I can not get the talkback window after the crash on news.chinatimes.com,
the error message only in terminal window which is same as before.

Comment 46

[Yuying Long]

Actually, I tried rtl.de page on 10-17-16 0.9.4 branch build, sometimes crash
sometimes not.  But yesterday it crashed everytime, also I don't know why the
attachment of yesterday's rtl.de page was failed, so I can not checked that.

Comment 47

[ji]

With a full install of 10-17-16-0.9.4 build on my RH7.1-J
http://www.chinatimes.com   crashes everytime
Sun's Java i18n pages       crashes everytime
http://www.rtl.de           crashes one out of 7 times, but the loading of the
page is quite slow, it takes about 30 seconds to finish the whole page loading.
No talkback report for the crash.

Comment 48

[Peter Lubczynski]

ji: Do you get the same results for those sites on a US English build and on an
English system? 

Maybe the JRE 1.3.1 is at fault. Can someone try these crashes on with JRE 1.3.0
but on a 0.9.4 build? Please try on Linux that is NOT RH 7.1 (suse is okay).

I don't know if http://news.chinatimes.com is the same as this bug. That is a
problem with Java and this but is about a problem with Flash. I think the Java
problem is bug 105287 and this is a Flash issue. Marc said he was able to
reproduce the crash on http://www.rtl.de WITHOUT Java. Can anyone else?

Comment 49

[Olga]

I've just gotten crash on Linux when using branch build: 2001-10-17-04-0.9.4
It happened when I tried to retrieve:
http://www.serveisweb.com/castella/index.htm

My Linux terminal states: "shell-init: could not get current directory: getcwd:
cannot access parent directories: No such file or directory"

No crash with these ones:
http://news.chinatimes.com
http://www.fitforfun.de/food/specials/100fetttipps/
http://www.gmate.co.kr
These sites were loaded without need to download Plugin. 
When I got Default Plugin message: ?this page contains information of a type
(application/-java-vm) that can only be viewed with the appropriate plugin. 
Click OK to download Plugin.? -  clicked Cancel.
Then I continied working with Browser till I got above crash.

After crash I restarted browser, launched the same 'castella' site - now without
crash.
No problem with loading: http://www.rtl.de

Comment 50

[ji]

Peter, all my test results are based on English build.
My RH7.1 is a Japanese system, but I can switch to English or German environment
by locale setting. The result for http://www.rtl.de is about the same in
Japanese, German or English environment. It doesn't seem to be locale related. 

Comment 51

[Peter Lubczynski]

I'm starting to think this has something to do with the cache. Somehow, I was
able to crash http://www.serveisweb.com/castella/index.htm until I cleard my
cache. Now I can not crash anymore. Can those seeing this crash try to clear
your cache and see if that helps?

This error message is also interesting:
"shell-init: could not get current directory: getcwd:
cannot access parent directories: No such file or directory"

I don't think this bug has anything to do with Java. I was able to reproduce
this crash with just Flash. 

Comment 52

[Yuying Long]

Clear cache seems doesn't help me here - I still see the crashes randomly even I
clear cache everytime.

Comment 53

[Patty Mac]

I tried on Linux redhat 6.2 branch build (2001-10-17-16-0.9.4) using Custom
install with all component checked, it loaded fine.

Comment 54

[ji]

Clearing cache doesn't help me either. And I'm more frequently crash at
http://www.serveisweb.com/castella/index.htm than at http://www.rtl.de.
And now I can get talkback reports for the crashes. They are all same as the
callstack posted on the report.

Comment 55

[Peter Lubczynski]

http://www.serveisweb.com/castella/index.htm is also crashing more frequently
for me but never in a debug build. :( This page is much simpler, Ji (or anyone
else), can you try to narrow down the HTML on this page untill it's down to bare
minimum to crash?

Comment 56

[ji]

For the URLs and attached testcases on this report (not including
http://news.chinatimes.com and Sun Java i18n demo pages, which should be used
for Java testing), I only crash at http://www.serveisweb.com/castella/index.htm
and http://www.rtl.com

Comment 57

[ji]

I meant "http://www.rtl.de" in above comments.

Comment 58

[Peter Lubczynski]

Attachment: frame3.html

Comment 59

[Peter Lubczynski]

Attachment: frame2.html

Comment 60

[Peter Lubczynski]

Attachment: frame1.html MAIN FRAMESET TESTCASE (framesets already setup for viewing in bugzilla)

Comment 61

[Peter Lubczynski]

ahhh...finally, I think I found the problem. My initial hunch was right, it's
the swliveconnect=yes attribute on the embed tag for Flash that is causing the
memory curruption.

Take a look at the last three attachments.
frame3.html - contains simple flash src with swliveconnect=yes
frame2.html - contains a flash plugin, no source
frame1.html - tester

If the type of plugin is changed in either frame3 or frame2, we do not crash.
If frame3 or frame2 are not in a frameset, we do not crash
If swliveconnect=yes is removed from frame3, we do not crash

I'm reassinging this bug to Arun for evangelism. It's very similar to another
bug. At this point, there isn't much we can do on our side if the Flash plugin
is trashing memory. We can work with Macormedia to resolve this issue and other
Liveconnect problems but they have not been responsive in the past. I think the
best solution at this time may be to get plugin authors not use
swliveconnect=yes until the Flash plugin can be updated.

Comment 62

[kill this account]

Attachment: purify startup FRM

Comment 63

[kill this account]

Attachment: purify ABR when going to www.chinatimes.com

Comment 64

[kill this account]

Attachment: purify crash report (I do not know if this is real)

Comment 65

[kill this account]

When it crashed it left this on the xterm console:

For * found plugin
/builds/bstell/mozilla/modules/plugin/samples/default/unix/libnullplugin.so
About to create new ws_info...
About to create new xtbin of 130 X 90 from 1ee4958...
Segmentation Fault - core dumped

Comment 66

[kill this account]

the crash was when I when to rtl.de
(www.chinatimes.com was reporting a timeout problem)

Comment 67

[kill this account]

Attachment: rtl.de - FMW: Free memory write

Comment 68

[kill this account]

Attachment: purify from another crash when going to rtl.de

Comment 69

[kill this account]

looks the same as before (sadly it takes about 60 minutes to launch a solaris
purified build on the machine sheep)

 Unexpected call to undefined function XtMalloc!
 ZPW: Zero page write
 This is occurring while in:
   XtCreateApplicationContext [Display.c]
   gtk_xtbin_new  [gtkxtbin.c:350]
   unsigned ns4xPluginInstance::SetWindow(nsPluginWindow*)
        [ns4xPluginInstance.cpp:884]

Comment 70

[kill this account]

again on the console:

 For * found plugin  
 /builds/bstell/mozilla/modules/plugin/samples/default/unix/libnullplugin.so
 About to create new ws_info...
 About to create new xtbin of 130 X 90 from 1bd0ab8...
 Segmentation Fault - core dumped

Comment 71

[Arun Ranganathan]

peterl, this one shouldn't be assigned to me, since it isn't one of my favorite
usual suspects.  it's yours till further notice.

Comment 72

[Arun Ranganathan]

peterl, sorry, i was hasty re-assigning that back to you.  assign it back to me
-- let's talk about it in the meeting tomorrow.
More info: swliveconnect=yes doesn't necessarily mean the plugin is scripted via
JRI/JNI bridge.  I'll definitely look thru' the code to find a definite method
invocation to the DLL, but can't conclude one yet.

Comment 73

[Peter Lubczynski]

Oh WOW! Brian, your Purify logs point to maybe some curruption in
ns4xPluginInstance::SetWindow() [ns4xPluginInstance.cpp:884]. There is some
UNIX-only code there, so that may be it.

cc:ing Pavlov who worked at on that code at one time

Comment 74

[Arno Winter]

Just for your information:
http://www.serveisweb.com/castella/index.htm 
also crashes on Mandrake 8.1 with Mozilla 0.9.5
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

Comment 75

[Frank Tang]

the purify stack track look like the area serge touch to fix bug 85701 . serge,
can you take a look at this one ?

Comment 76

[Frank Tang]

from bug 85701
>------- Additional Comments From [e-mail] 2001-09-27 10:21 -------
>I wasn't be able to reproduce this ever, but here is my wild guess:

Comment 77

[serge (gone)]

>Unexpected call to undefined function XtMalloc!
>ZPW: Zero page write
>This is occurring while in:
> XtCreateApplicationContext [Display.c]
>gtk_xtbin_new  [gtkxtbin.c:350]
looks very suspicion, according to the code of gtkxtbin.c [r1.8.22.1]
...
     54 static int              xt_is_initialized = 0;
...
    322 GtkWidget*
    323 gtk_xtbin_new (GdkWindow *parent_window, String * f)
    324 {
...
    336   if (xt_is_initialized == 0) {
...
    350     app_context = XtCreateApplicationContext();
...
    387     xt_is_initialized++; /* bump up our count here */
    388   }
...
we call XtCreateApplicationContext() only ones  
when line 336   if (xt_is_initialized == 0)  is true
and in debugger I never reentry gtk_xtbin_new() before finish that if () block
even I have more than 5 plugins on the same page.
What I'm trying to say is we can call XtCreateApplicationContext() twice and
more only if xt_is_initialized == 0,
or crash on first access to the test page, but I did crash only after several
reload or resizes, so somehow memorey is getting corrupted:(

Comment 78

[Peter Lubczynski]

-->serge

Comment 79

[Yuying Long]

I checked rtl.de on 09-17 branch build - it hanged.

Comment 80

[serge (gone)]

Attachment: top of stack trace from crahs on www.rtl.de

Comment 81

[serge (gone)]

above stack trace points to
#16 0x42bce1d7 in _XtGlobalTM () from /u/serge/plugins/linux/libflashplayer5.so
after that frame there is no mozilla code.

Comment 82

[ji]

Checked 09/21 build which doesn't have the fix for bug 85701, browser hangs at
http://www.rtl.de and http://www.serveisweb.com/castella/index.htm

Comment 83

[serge (gone)]

Attachment: one more stack trace from crash on www.rtl.de

Comment 84

[serge (gone)]

I've got above stack trace twice only with Shockwave Flash 5.0 r47
but not with Shockwave Flash 4.0 r12

Comment 85

[serge (gone)]

I was able to reproduce crash on www.rtl.de with win32 release builds.
trunk TB ID: 37023747, branch TB ID: 37024176
   0x0c09b9c9
   0x0012fdcc
   0x0c09ae46
   USER32.DLL + 0x4aa7    (0x77e14aa7)
   USER32.DLL + 0x166fd   (0x77e266fd)
unfortunately it's difficult to say what hides behind 0x0c09ae46 address,
there is no such address in TB module list at all, and there is no npsw32.dll in 
that list either, but I suspect that call is belong to npsw32.dll, at least my 
branch debug build does crash with stack trace looks very close to release one
  NPSWF32! 07d2b9d2()
  NPSWF32! 07d2ae46()
  USER32! 77e14aa7()
  USER32! 77e266fd()
  nsAppShellService::Run(nsAppShellService * const 0x0116e408) line 468
  main1(int 0x00000001, char * * 0x00358160, nsISupports * 0x00000000) line 1304 
  main(int 0x00000001, char * * 0x00358160) line 1632 + 37 bytes
  mainCRTStartup() line 338 + 17 bytes
I think we'll not be able to figure out what's going on in flash dll  without  
help from macromedia.
All I can say the stack trases from my unix and windows debug builds point to 
their plugin library.

Comment 86

[Jan Carpenter]

*** Bug 109355 has been marked as a duplicate of this bug. ***

Comment 87

[Jan Carpenter]

COMMENTS/URLs from todays topcrash list.

     (37779342)	URL: http://www.komputer.onet.pl
(37761452)
URL: www.msnbc.com/news/636781.asp
     (37683478)	URL: http://www.uol.com.br/ultnot
(37683478)
Comments: Navigating into www.vitria.com
     (37626013)	URL: www.autsch.de
     (37626013)	Comments: error occures with other banners on that page too.
     (37625843)	URL: www.autsch.de
     (37625843)	Comments: reproduced my last error. (don't know url of the banner)
     (37581724)	URL: www.subaru.com
     (37581724)	Comments: CLicked on the Outback
     (37530239)	Comments: serching the web
     (37514928)	Comments: crash on sony music japan
     (37504407)	URL: http://www.uol.com.br/ultnot
(37504407)
Comments: I was accessing a link in another windows  using the middle button.
     (37502256)	URL: http://www.whitehattech.com
(37502256)
Comments: I was viewing the URL above through www.safeweb.com.
     (37416693)	URL: www.macromedia.com
     (37416693)	Comments: While the macromedia home page was loading

Comment 88

[kill this account]

> I was able to reproduce crash on www.rtl.de with win32 release builds.

This bug is currently marked Linux. 

Should it be marked all or a new bug opened?

Comment 89

[serge (gone)]

well, I did not find any  TB reports for windows build with Signature = 
nsTableRowFrame::IR_TargetIsChild, so let's do not change the OS for now, beside 
the stack traces from mine crashes on www.rtl.de have different signatures:(

Comment 90

[Marc Attinasi]

*** Bug 106322 has been marked as a duplicate of this bug. ***

Comment 91

[Jay Patel [:jay]]

Adding  [@ nsBlockFrame::ComputeFinalSize] to summary for tracking, since bug
106322 was marked a dup.

Comment 92

[Jaime Rodriguez, Jr.]

No patchey. No plussey. PDT-

Comment 93

[av (gone)]

Attachment: reduced test case to illustrate the similar (no usable stack) crash

Not sure if this is related, but serge and I just found a reproducable way to
crash Flash on Windows. Run the test case, see movie playing, hit Reload
button, right mouse click on the movie to invoke the context menu. The trick is
-- you should do it fast enough to catch the moment when the plugin is already
loaded but the movie itself is still not. The context menu in such a case
consists of only one line (no play controls). If this is condition is met we
crash 100% of time. Stack trace is absolutely unusable, addresses shown don't
exist in any loaded modules.

Comment 94

[Peter Lubczynski]

That's a general bug in plugins. You can crash 4.x that way too. I crash 100% of
the time in 4.x if I quickly right click after pressing CTRL+R on disney.com. Is
there a bug already open on this?

I think this bug may be different because it DOES send something back to
talkback. I have not tried recently, but last time I tried to reproduce this bug
on Linux, I could only do it in a release commercial build from sweetlou on a
clean profile. I think that's why I tried to make all those testcases. In
comment #55 I finally got it to crash in a debug build.

Comment 95

[Jan Carpenter]

changing topcrash bugs to critical

Comment 96

[serge (gone)]

-> mozilla 1.0.1
I'm not sure if this is a mozilla problem.
I 'm always getting some sort of memory corruption on www.rtl.de in 
libflashplayer.so:(
PRLog & stack trace from latest debug session are following

Comment 97

[serge (gone)]

Attachment: Plugins PRLog & stack trace from crash on www.rtl.de

Comment 98

[shrirang khanzode]

*** Bug 117389 has been marked as a duplicate of this bug. ***

Comment 99

[Matthias Versen [:Matti]]

*** Bug 119050 has been marked as a duplicate of this bug. ***

Comment 100

[Olav Vitters]

*** Bug 119354 has been marked as a duplicate of this bug. ***

Comment 101

[Jaime Rodriguez, Jr.]

nsbranch is going away. changing nsbeta1 nomiantions.

Comment 102

[Jaime Rodriguez, Jr.]

removing PDT grafitti.

Comment 103

[Jay Patel [:jay]]

Updating summary with just N621, since there are quite a few crashes with
Netscape 6.21.  Other than those crashes, there is only one crash reported for
M097 and one reported with a recent MozillaTrunk build.  

Here is the only incident reported in the last 30 days on a MozillaTrunk build:
 Incident ID 2019868   
Stack Signature  nsBlockFrame::ComputeFinalSize() e889de82
Trigger Time 2002-01-23 10:19:25
Email Address
URL visited www.wetter.de
User Comments
Build ID 2002011821
Product ID MozillaTrunk
Platform
Operating System LinuxIntel
Module
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
nsBlockFrame::ComputeFinalSize()
nsBlockFrame::Reflow()
nsBlockReflowContext::DoReflowBlock()
nsBlockReflowContext::ReflowBlock()
nsBlockFrame::ReflowBlockFrame()
nsBlockFrame::ReflowLine()
nsBlockFrame::ReflowDirtyLines()
nsBlockFrame::Reflow()
nsAbsoluteContainingBlock::ReflowAbsoluteFrame()
nsAbsoluteContainingBlock::IncrementalReflow()
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()
PresShell::FlushPendingNotifications()
PresShell::EndReflowBatching()
nsEditor::EndUpdateViewBatch()
nsEditor::EndPlaceHolderTransaction()
nsPlaintextEditor::InsertText()
nsGfxTextControlFrame2::SetTextControlFrameState()
nsGfxTextControlFrame2::SetProperty()
nsHTMLInputElement::SetValueSecure()
nsHTMLInputElement::SetValue()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_GetterSetter()
js_Invoke()
js_InternalInvoke()
js_SetProperty()
js_Interpret()
js_Execute()
JS_EvaluateUCScriptForPrincipals()
nsJSContext::EvaluateString()
GlobalWindowImpl::RunTimeout()
GlobalWindowImpl::TimerCallback()
nsTimerImpl::Process()
handleMyEvent()
PL_HandleEvent()
PL_ProcessEventsBeforeID()
processQueue()
nsVoidArray::EnumerateForwards()
nsAppShell::ProcessBeforeID()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17dd4 (0x40355dd4)
libglib-1.2.so.0 + 0x10c46 (0x40387c46)
libglib-1.2.so.0 + 0x11273 (0x40388273)
libglib-1.2.so.0 + 0x1143c (0x4038843c)
libgtk-1.2.so.0 + 0x9276c (0x402a076c)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main() 

Considering the fact that we haven't seen any crashes other then the 2 I
mentioned since N621, this might be worth a worksforme resolution.

Comment 104

[Jay Patel [:jay]]

Comment #103 was regarding the "nsBlockFrame::ComputeFinalSize" crash signature.
 I also looked up  the "nsBlockFrame::ComputeFinalSize" and Talkback reported
similar results.  There are a lot of crashes with N621, but only a couple
reported for M097, and none for recent MozillaTrunk builds.

Comment 105

[serge (gone)]

Lets see what we'll get from 0.9.8,
some crashes in linux flash plugin could be eliminated by fix for bug 108347

Comment 106

[greer]

Of the two signatures listed in the summary:
nsBlockFrame::ComputeFinalSize shows no incidents in Trunk or M098 data in the 
past 12 days.
nsTableRowFrame::IR_TargetIsChild shows one incident in M098, none in Trunk (in 
the past 12 days of builds).

The one crash represents a negligible statistical sampling. I think this one 
should be WFM.

Comment 107

[serge (gone)]

finally resoled as WFM

Comment 108

[greer]

Reopening this one for another look. (My appologies I recommended it be WFM in 
comment #106 after M098 data was so thin). Talkback shows a lot of incidents 
under these two signatures (again) on N622, M099 and the Trunk.

Originally, this was marked as an i18n issue. Looking at the int'l flavor of the 
comments I'm wondering if there is something to that.

I'll attach the comments below.

Comment 109

[greer]

Attachment: Recent crasher comments associated with the signatures in this bug's summary

maybe we can find a testcase in here somewhere.

Comment 110

[lchiang]

Is this stack trace showing up for Windows and/or Mac or this is only for Linux?  

ylong, you had originally reported this bug.  Does it reproduce for you?  If so,
we should remove qawanted keyword.

Comment 111

[Yuying Long]

I don't see the crash on original page rtl.de with latast trunk build, the web
site may has been changed a lot since the bug filed.  If I find some other pages
has same crash, I'll add comments here.

And this crash only happens on linux with me.

Comment 112

[serge (gone)]

We need a reproducible test case here,
I've tried almost all urls from attachment 77770 [details], all FWM, rh 7.2, mozilla build
20020402.

Comment 113

[rubydoo123]

marking as WFM, please do not reopen unless you can provide a reproducible test 
case that you attach to this bug