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 ylong@netscape.com 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)

Roy, please look at this.

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

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.

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

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

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

This #17 site in the Germany. :-(

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."

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.

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).

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).

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.

downloaded shockwave plugin, page loads for me without crashing.

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)

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.

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

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

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

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

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

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

My above comments are based on installing the plugins

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...

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?

Reassigning to beard.

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

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.

--> peterl for investigation

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)

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

Adding more German QA folks ...

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.

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?

I will email Asa and QA.

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

> 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.

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.

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)

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.

> 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.

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.

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.

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?

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

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.

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.

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

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.

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.

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?

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

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

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.

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

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

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]

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

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.

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.

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

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

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

from bug 85701 >------- Additional Comments From serge@netscape.com 2001-09-27 10:21 ------- >I wasn't be able to reproduce this ever, but here is my wild guess:

>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:(

-->serge

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

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

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

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

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.

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

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

> 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?

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:(

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

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

No patchey. No plussey. PDT-

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.

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.

changing topcrash bugs to critical

-> 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

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

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

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

nsbranch is going away. changing nsbeta1 nomiantions.

removing PDT grafitti.

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 #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.

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

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.

finally resoled as WFM

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.

maybe we can find a testcase in here somewhere.

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.

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.

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.

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