User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.0.3) Gecko/20060508 Firefox/1.5.0.3 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.0.3) Gecko/20060508 Firefox/1.5.0.3 The earlier releases also haven't been very stable but 1.5.0.3 crashes even more frequently with the following messages: ~> ff X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 40 (X_TranslateCoords) Resource id in failed request: 0x933331 Serial number of failed request: 8568431 Current serial number in output stream: 8568431 ~> ff Bus Error - core dumped ~> ff Reproducible: Always Actual Results: Firefox is very unstable. Expected Results: It should be more robust.

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

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

Just a minute ago: ~> ff Segmentation Fault - core dumped ~>

Are you using an official mozilla.org build of Firefox (or do we not have official builds for Sun?)? Maybe the person who builds the Sun builds changed some option... Also, can you attach the core dump file?

Some more notes: - AFAIR the Firefox builds I'm usually using are from the contrib directory on mozilla.org - the frequent crashes on Solaris are a known problem from Mozilla times - Firefox on MacOS didn't crash a single time - I can attach a core file next time I get one but are you sure you want some 100 MB here (if this is even possible)?

The compressed core file is 32 MB, which can't be attached here. Do you have a ftp site where I can upload it?

BTW: this one was a ~> ff Gdk-WARNING **: GdkWindow 0x97bfba unexpectedly destroyed Gdk-ERROR **: called gdk_window_destroy on a pixmap (use gdk_pixmap_unref) aborting... Abort - core dumped ~> which is another very common crash message, mainly occuring when Firefox is unattended.

we can't use the solaris core dump. there's supposed to be a readme indicating who made the solaris build. contact them.

Frank, which Solaris are you using? Is it still crash for the latest Firefox 2.0.0.1 release? For the core file, you can run "pstack core" to generated the stack trace and post it here.

This applied to Solaris 9 and 10 and also to all the newer 1.5 releases. In the meantime, I changed my job and now I'm working on an ancient Solaris 8 (will soon be replaced by Solaris 10) where I installed 2.0. Believe it or not, it got even worse on this configuration. The thing sometimes crashes after just a coupe of minutes, with messages like bash-2.03$ ff X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 255 () Minor opcode of failed request: 0 Serial number of failed request: 294080 Current serial number in output stream: 294081 bash-2.03$ Those Solaris 8 crashes don't dump a core (why?), the program just exits. But if I ever get a dump again, I'll post the stack trace. On the other hand, the very cool "Restore session" feature takes up to a minute to get all the windows and tabs loaded and ready to work. I already got a 2.0.0.1 but it doesn't seem to like Solaris 8, it's compiled on Solaris 10.

How about the binary build for Solaris 8 here: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.1/contrib/?

it doesn't dump core because it didn't crash. instead it had a disagreement with the xserver, gdk's response to such disagreements is to quit. so it quit.

Ok, this Solaris 8 build wasn't available the last time I checked the site and I was too lazy to set up my own environment. At least, this one is coming up and now I'm playing around with it ... this message is being posted with 2.0.0.1 How do we find out what the root cause of this "disagreement" is? And why did Firefox really crash on Solaris 9 and 10 but doesn't on Solaris 8?

After Firefox had become ridiculously slow, we finally got a core dump: bash-2.03$ ff Segmentation Fault - core dumped (acroread:19092): Gdk-WARNING **: GdkWindow 0x6800145 unexpectedly destroyed bash-2.03$ pstack core core 'core' of 19091: /opt/firefox-2.0.0.1/firefox-bin ----------------- lwp# 4 / thread# 1 -------------------- ff3491f0 __sigprocmask (ff34b7f4, 0, 0, 16a9488, ff35c000, 0) + 8 ff33dd0c _sigon (16a9488, ff3638a8, b, ffbec38c, 16a9488, 5) + d0 ff340d4c _thrp_kill (0, 1, b, ff35c000, 1, ff36326c) + f8 ff24bce0 raise (b, ffbec450, 0, 0, b, 150a1b0) + 40 00419b28 __1cNnsProfileLockSFatalSignalHandler6Fi_v_ (b, 0, 419a04, 419800, a, b8) + e8 ff34b118 __sighndlr (b, ffbec8b0, ffbec5f8, 419a40, 16a9530, 16a9520) + c ff34811c sigacthandler (b, 16a9488, 0, 0, 0, ff35c000) + 708 --- called from signal handler with signal 11 (SIGSEGV) --- fc79cc04 _ZN16SCharacterParser10BuildEdgesEiP5SRECTi (ffbed790, ffbec990, 0, 0, 1000000, 1000000) + 180 fc79d840 _ZN7SObject10BuildEdgesEP10STransformi (5aed778, ffbee568, 0, 715bdbc, 5aed7c8, 1) + f0 fc7a0430 _ZN7SObject11DrawDevFontEP7CRaster10STransformPK19PlatformDisplayToolP6RColor (5aed778, 715bd98, ffbee568, ffbee6d8, 0, 1000000) + 8c fc7a055c _ZN7SObject11DrawDevFontEP7CRaster10STransformPK19PlatformDisplayToolP6RColor (5aed778, 715bd98, ffbee608, ffbee6d8, ffbee568, 1000000) + 1b8 fc7a055c _ZN7SObject11DrawDevFontEP7CRaster10STransformPK19PlatformDisplayToolP6RColor (4228918, 715bd98, ffbee6a8, ffbee6d8, ffbee608, 0) + 1b8 fc81d314 _ZN15PlatformDisplay11ClipAndDrawEP5SRECTP7SObjectP7CRaster10STransform (ffbee868, ffbeea00, 715bc38, 715bd98, ffbee838, ffbee868) + b8 fc78faa4 _ZN11DisplayList10UpdateRectEP5SRECTP7SObject (715bc08, ffbeea00, 715bc38, 10, 715bd24, ffbeea00) + f8 fc78ff18 _ZN11DisplayList6UpdateEP7SObject (715bc08, 0, fc7c7d4c, ff242b64, 715bc08, 0) + 7c fc7c7db4 _ZN10CorePlayer12UpdateBufferEi (0, 1, 0, 1, b375d, ffbeeb18) + 58 fc7c76e4 _ZN10CorePlayer10DrawScreenEPK5SRECT (715b648, ffbeeb88, 7ffffff, 10, 715bd24, ffbeeb88) + 8 fc7c7d30 _ZN10CorePlayer12UpdateScreenEv (715b648, fc8a16f0, fc7c7cdc, 0, fc8a1ac0, fc8a1ac0) + 54 fc7bfc3c _ZN10CorePlayer6DoPlayEi (715b648, 1, ffbeec18, fff4db4c, 10c4, 10d4) + 3f0 fc7eb890 _ZN16UnixCommonPlayer7OnTimerEv (715b648, 61a8, 23f47, 45c0b7f9, 4, 1) + e0 fc828c50 _Z16gtkTimerCallbackPv (715b648, fc828c20, 16e0a50, 16a7be4, 2ac4ba8, f) + 30 ff0c7414 g_timeout_dispatch (4b25ef0, ffbeee80, 715b648, ff34a7a8, 16ced2c, ffbeedd8) + 8 ff0c5ef8 g_main_dispatch (470, 470, 4d4, ab8, 4d4, ab8) + 128 ff0c6794 g_main_iterate (ff0ebf64, ff0ebed0, 4d4, ab8, 4d4, ab8) + 7bc ff0c69a8 g_main_run (1b20680, 16a9024, fef5e3d0, ff037a38, 15ff004, 13) + b8 fee1ffc8 gtk_main (0, 8, 1add278, 9, 0, ffbeef90) + 1a0 007095a0 __1cKnsAppShellDRun6M_I_ (1add270, 16aa3d0, 7093a4, 15ff050, c1f30000, 8) + 3c 00d8b42c __1cMnsAppStartupDRun6M_I_ (1ad96e8, 15ff050, 1, ffbef05c, 148fc00, 0) + 28 0040f134 XRE_main (ffbef0ec, ffbef130, ffbef1f4, ffbef214, ffbef22c, ffbef23c) + 1934 00408dd8 _start (0, 0, 0, 0, 0, 0) + 108 ----------------- lwp# 5 -------------------------------- ff349200 private___lwp_cond_wait (0, ff35cd6c, ff35c000, ff368d04, 0, fe401000) + 8 ff338c48 _qswtch (fd30dd98, fe675d38, 0, 5, 1, fe401000) + 118 ----------------- lwp# 6 / thread# 6 -------------------- ff349200 private___lwp_cond_wait (ff35cd28, ff35c000, ff35cd10, fe007d30, ff35c000, 0) + 8 ff34b01c _thread_start (0, 0, 0, 0, 0, 0) + 40 ----------------- lwp# 7 / thread# 181 -------------------- ff29f474 _lwp_sema_wait (fdf05e60, ff35c000, 0, fdf05d98, 2316c, fde03d98) + c ff3393a4 _swtch (fdf05d98, 0, ff35c000, 5, 1000, 0) + 424 ff337d88 cond_reltimedwait (0, fdf05d98, 0, ff35c000, 0, 0) + 1dc ff337b9c cond_timedwait (17d8578, 17cf268, fdf05ba0, 17d8578, 0, 0) + 2c ff337b04 pthread_cond_timedwait (17d8578, 17cf268, fdf05ba0, 0, 0, 0) + c fe8d3dc4 ???????? (17d8578, 17cf268, 6e, 3c, 45c0b836, 0) fe8d4000 PR_WaitCondVar (17d8570, 5b8d80, ffffe800, 5a0f350, 17cf23c, 0) + 7c 0053ee6c __1cOnsHostResolverPGetHostToLookup6MppnMnsHostRecord__i_ (17cf200, fdf05cd4, 0, 22cbbf8, 1, 5b8d80) + 70 0053f248 __1cOnsHostResolverKThreadFunc6Fpv_v_ (17cf200, 0, 13f07db, 8, 804b001e, 8020) + bc fe8d9d20 ???????? (5a0f350, 1, 1844c, 1, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (5a0f350, 0, 0, 0, 0, 0) + 40 ----------------- lwp# 12 / thread# 8 -------------------- ff29f474 _lwp_sema_wait (fde03e60, ff35c000, 0, fde03d98, 2316c, fe109d98) + c ff3393a4 _swtch (fde03d98, 0, ff35c000, 5, 1000, 0) + 424 ff337d88 cond_reltimedwait (0, fde03d98, 0, ff35c000, 0, 0) + 1dc ff337b9c cond_timedwait (1fe1468, 1fe4030, fde03bf0, 1fe1468, 58, 2) + 2c ff337b04 pthread_cond_timedwait (1fe1468, 1fe4030, fde03bf0, 0, 0, 0) + c fe8d3dc4 ???????? (1fe1468, 1fe4030, 2e, 0, 45c0b7fb, 0) fe8d4000 PR_WaitCondVar (1fe1460, 61a8, ffffe800, 1fe40c0, 26c44, 0) + 7c 00e1d66c __1cLnsSSLThreadDRun6M_v_ (1fe1438, 0, 1, 0, 16797ac, 3) + 278 fe8d9d20 ???????? (1fe40c0, 0, 1844c, 0, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (1fe40c0, 0, 0, 0, 0, 0) + 40 ----------------- lwp# 10 / thread# 4 -------------------- ff29d600 _poll (1589fef, 869e7960, 0, 17ce448, 5, ffffffff) + 8 00530c04 __1cYnsSocketTransportServiceEPoll6MpI_i_ (17cdf60, fe20bc74, 0, 2aab9a8, 869e7960, 5) + 8c 005314b0 __1cYnsSocketTransportServiceDRun6M_I_ (17cdf60, 17ce1e0, ffff, 0, 17d5f70, 13ef0a5) + 1f0 ff039824 __1cInsThreadEMain6Fpv_v_ (17c78a4, 0, 53192c, 8, 17ce728, 15c8b48) + 28 fe8d9d20 ???????? (17ce728, 0, 1844c, 0, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (17ce728, 0, 0, 0, 0, 0) + 40 ----------------- lwp# 1 / thread# 5 -------------------- ff29f474 _lwp_sema_wait (fe109e60, ff35c000, 0, fe109d98, 2316c, fdf05d98) + c ff3393a4 _swtch (fe109d98, 0, ff35c000, 5, 1000, 0) + 424 ff337d88 cond_reltimedwait (0, fe109d98, 0, ff35c000, 0, 0) + 1dc ff337b9c cond_timedwait (16aa2c0, 16f2c48, fe109ba8, 16aa2c0, 138, 4) + 2c ff337b04 pthread_cond_timedwait (16aa2c0, 16f2c48, fe109ba8, 1dcd64, 77359, 77358) + c fe8d3dc4 ???????? (16aa2c0, 16f2c48, e6, 0, 45c0b7fb, 1) fe8d4000 PR_WaitCondVar (16aa2b8, 153d4, ffffe800, 17ef730, 26c9c, 0) + 7c ff03cc98 __1cLTimerThreadDRun6M_I_ (16f2578, fffeac2c, ffffc5d6, a032dd0f, 3abf660, a0314f11) + 164 ff039824 __1cInsThreadEMain6Fpv_v_ (17e5f1c, 0, ff03cb34, 8, 17ef730, ff0a4358) + 28 fe8d9d20 ???????? (17ef730, 0, 1844c, 0, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (17ef730, 0, 0, 0, 0, 0) + 40 ----------------- lwp# 2 / thread# 2 -------------------- ff29edc4 _signotifywait (ff35c000, 0, 0, 0, 0, 0) + 8 ff341c2c thr_yield (0, 0, 0, 0, 0, 0) + 8c ----------------- lwp# 14 -------------------------------- ff29c968 _door_return (27, ff35d658, ff35d670, 3, ff35c000, 1) + 10 ff33a358 _lwp_start (fe6c5d98, 0, 6000, fd655b9c, 0, 0) + 18 ff341c2c thr_yield (0, 0, 0, 0, 0, 0) + 8c -------------------------- thread# 3 -------------------- ff33d9b8 _reap_wait (ff360980, ff35c000, 0, b3, 0, b3) + 38 ff33d710 _reaper (ff35ce00, ff362708, ff360980, ff35cdd8, 1, fe400000) + 38 ff34b01c _thread_start (0, 0, 0, 0, 0, 0) + 40 -------------------------- thread# 9 -------------------- ff337d88 cond_reltimedwait (0, fdd01d98, 0, ff35c000, 0, 0) + 1dc ff337b9c cond_timedwait (1fe1490, 1fe41b0, fdd01c00, 1fe1490, 58, 2) + 2c ff337b04 pthread_cond_timedwait (1fe1490, 1fe41b0, fdd01c00, 0, 0, 0) + c fe8d3dc4 ???????? (1fe1490, 1fe41b0, 2e, 0, 45c0b7fb, 0) fe8d4000 PR_WaitCondVar (1fe1488, 61a8, ffffe800, 1fe4210, 0, 0) + 7c 00e01688 __1cYnsCertVerificationThreadDRun6M_v_ (1fe4160, 1, ff35c000, 1fe4174, 16a7158, 1) + 54 fe8d9d20 ???????? (1fe4210, 0, 1844c, 0, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (1fe4210, 0, 0, 0, 0, 0) + 40 -------------------------- thread# 10 -------------------- ff3381ac cond_wait (fd40fd98, 0, 0, ff35c000, 0, 0) + 11c ff338070 pthread_cond_wait (1f7aad8, 1ebc518, ff33b798, fe8f3fc4, 17c1c, 400) + 8 fe8d3fe4 PR_WaitCondVar (1f7aad0, ffffffff, ffffe800, 1ebc5d8, 400, 0) + 60 004f12d4 ???????? (0, 0, 1, 0, 15c5800, ffffffff) 004f1e78 ???????? (1cf9908, be8, 5fa50, ff03a02c, c, 800) ff039824 __1cInsThreadEMain6Fpv_v_ (1f231e4, 0, 4f1e74, 8, 1ebc5d8, 15c5a74) + 28 fe8d9d20 ???????? (1ebc5d8, 0, 1844c, 0, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (1ebc5d8, 0, 0, 0, 0, 0) + 40 -------------------------- thread# 16 -------------------- ff3381ac cond_wait (fd30dd98, 0, 0, ff35c000, 0, 0) + 11c ff338070 pthread_cond_wait (23dc9b8, 2a67968, ff33b798, fe8f3fc4, 17c1c, 400) + 8 fe8d3fe4 PR_WaitCondVar (23dc9b0, ffffffff, ffffe800, 1c6eaf8, 579d168, 0) + 60 fe8d42d4 PR_Wait (2a67960, 10000, 1, fe8f3fc4, 210f460, 2a67960) + 20 ff035938 PL_WaitForEvent (ffffe897, 210f460, ffffe800, ff0379ec, 2e580, 0) + 44 ff037a1c __1cQnsEventQdDueueImplMWaitForEvent6MppnHPLEvent__I_ (23dca28, fd30dcbc, 1, ff0379fc, ff0a3ff0, 80004000) + 20 00dcbe24 ???????? (ff0a410c, fd30dcc8, 1676800, fd30dcbc, 80000000, 16c99f0) fe8d9d20 ???????? (1c6eaf8, 0, 1844c, 0, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (1c6eaf8, 0, 0, 0, 0, 0) + 40 -------------------------- thread# 180 -------------------- ff337d88 cond_reltimedwait (0, fd109d98, 0, ff35c000, 0, 0) + 1dc ff337b9c cond_timedwait (1b18240, 1b1e1e8, fd109c08, 1b18240, 0, 0) + 2c ff337b04 pthread_cond_timedwait (1b18240, 1b1e1e8, fd109c08, 0, 0, 0) + c fe8d3dc4 ???????? (1b18240, 1b1e1e8, 12, 3c, 45c0b835, 0) fe8d4000 PR_WaitCondVar (1b18238, 5b8d80, ffffe800, 30248b8, 26c9c, 0) + 7c 0050c8dc __1cOnsIOThreadPoolKThreadFunc6Fpv_v_ (1b1dd18, a02e9352, ff35c000, 1b1dd38, 0, 3c) + 70 fe8d9d20 ???????? (30248b8, 1, 1844c, 1, fe8f20d0, fe8f3fc4) ff34b01c _thread_start (30248b8, 0, 0, 0, 0, 0) + 40 bash-2.03$

Any plugins are you using? The result for about:plugins. Any specific website did you visit for the crash?

this is a plugin, /usr/local/lib/linux-flashplugin6/libflashplayer.so, see http://lists.freebsd.org/pipermail/freebsd-mozilla/2003-October/000062.html fc79cc04 SCharacterParser::BuildEdges(int, SRECT*, int) (ffbed790, ffbec990, 0, 0, 1000000, 1000000) + 180 fc79d840 SObject::BuildEdges(STransform*, int) (5aed778, ffbee568, 0, 715bdbc, 5aed7c8, 1) + f0 fc7a0430 SObject::DrawDevFont(CRaster*, STransform, const PlatformDisplayTool*, RColor*) (5aed778, 715bd98, ffbee568, ffbee6d8, 0, 1000000) + 8c fc7a055c SObject::DrawDevFont(CRaster*, STransform, const PlatformDisplayTool*, RColor*) (5aed778, 715bd98, ffbee608, ffbee6d8, ffbee568, 1000000) + 1b8 fc7a055c SObject::DrawDevFont(CRaster*, STransform, const PlatformDisplayTool*, RColor*) (4228918, 715bd98, ffbee6a8, ffbee6d8, ffbee608, 0) + 1b8 fc81d314 PlatformDisplay::ClipAndDraw(SRECT*, SObject*, CRaster*, STransform) (ffbee868, ffbeea00, 715bc38, 715bd98, ffbee838, ffbee868) + b8 fc78faa4 DisplayList::UpdateRect(SRECT*, SObject*) (715bc08, ffbeea00, 715bc38, 10, 715bd24, ffbeea00) + f8 fc78ff18 DisplayList::Update(SObject*) (715bc08, 0, fc7c7d4c, ff242b64, 715bc08, 0) + 7c fc7c7db4 CorePlayer::UpdateBuffer(int) (0, 1, 0, 1, b375d, ffbeeb18) + 58 fc7c76e4 CorePlayer::DrawScreen(const SRECT*) (715b648, ffbeeb88, 7ffffff, 10, 715bd24, ffbeeb88) + 8 Have you decided you're definitely interested in this crash and not another?

Installed plug-ins Find more information about browser plug-ins at mozilla.org. Help for installing plug-ins is available from plugindoc.mozdev.org. Adobe Reader 7.0 File name: nppdf.so The Adobe Reader plugin is used to enable viewing of PDF and FDF files from within the browser. MIME Type Description Suffixes Enabled application/pdf Portable Document Format pdf Yes application/vnd.fdf Acrobat Forms Data Format fdf Yes application/vnd.adobe.xfdf XML Version of Acrobat Forms Data Format xfdf Yes application/vnd.adobe.xdp+xml Acrobat XML Data Package xdp Yes application/vnd.adobe.xfd+xml Adobe FormFlow99 Data File xfd Yes Default Plugin File name: libnullplugin.so The default plugin handles plugin data for mimetypes and extensions that are not specified and facilitates downloading of new plugins. MIME Type Description Suffixes Enabled * All types .* No Demo Print Plugin for unix/linux File name: libunixprintplugin.so The demo print plugin for unix. MIME Type Description Suffixes Enabled application/x-print-unix-nsplugin Demo Print Plugin for Unix/Linux .pnt Yes RealPlayer(tm) 7.0 Plug-In File name: rpnp.so RealPlayer(tm) 7.0 LiveConnect-Enabled Plug-In MIME Type Description Suffixes Enabled audio/x-pn-realaudio-plugin RealPlayer Plugin Metafile rpm Yes vCal plugin File name: npvcal.so This plugins displays vCal MIME Type Description Suffixes Enabled text/x-vCalendar VCal Viewer vcs Yes Shockwave Flash File name: libflashplayer.so Shockwave Flash 6.0 r80 MIME Type Description Suffixes Enabled application/x-shockwave-flash Shockwave Flash swf Yes application/futuresplash

From the latest core stack, this bug is related to the flash plugins, and not a Firefox bug. FYI, Flash 7.0 is available at http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash and flash 9.0 for Solaris is still under development.

Sometimes, Firefox doesn't crash or terminate but completely hangs. SOme minutes ago with the following message: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 72 (X_PutImage) Resource id in failed request: 0x3c14efc Serial number of failed request: 1364968 Current serial number in output stream: 1365159

This really sucks ... X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 53 (X_CreatePixmap) Resource id in failed request: 0x3c09777 Serial number of failed request: 395961 Current serial number in output stream: 395968 ... and during the last weeks, I had fewer crashes but but quite frequent freezes. Firefox hangs, the window is no longer updated and the only cure is stopping it.

I can't give you any help based on the previous two comments. How if you try the latest FF 2.0.0.2 with flash plugin disable? Does that still crash or hang when you go to some websites?

WFM on Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9a5pre) Gecko/20070515 Minefield/3.0a5pre

hi report, please help us try the latest Firefox 2.0.x and Trunk build to reproduce this bug and provide more informations. Thanks

As announced, I have now switched to a new SunRay server running Solaris 10. But despite earlier plans, it's not a SPARC machine but an Opteron box. After some weeks of testing, I can confirm other statements that 2.0.0.4 on Solaris 10/x86 mit the latetst Flash plugin is by far more stable. I neither had a crash nor a memory leak on this box up to now. So the problem seems to be very SPARC related.

(In reply to comment #24) > As announced, I have now switched to a new SunRay server running Solaris 10. > But despite earlier plans, it's not a SPARC machine but an Opteron box. > > After some weeks of testing, I can confirm other statements that 2.0.0.4 on > Solaris 10/x86 mit the latetst Flash plugin is by far more stable. I neither > had a crash nor a memory leak on this box up to now. So the problem seems to be > very SPARC related. is your platform the only change? (i.e. you were running the same version FF and plugin on your sparc as you are now running on your opteron?) did flash 9 for solaris get tested? (comment 18)