I thought this was so obvious it *had* to be already logged, but have searched on "print twice", "again," "second," "printing twice," and so on, with no Bugzilla hits. Since at least 0.9.7, one can only print *once* from Mozilla safely. If one attempts to print a second time, Mozilla immediately crashes. The bug wherein Mozilla spawns dozens of windows when WordPerfect 10 tries to print may be related; in any event, it would appear something is seriously haywire in the printing process. I have labeled this "critical" because crashing upon second print is something which will affect everyone, and will seriously impact the credibility of Mozilla 1.0.

I cannot reproduce this. I'm using 3/20 trunk commercial build on win 98 and I can print fine several times in a row. Asa, can you try this out on a mozilla build. Also, reporter, can you download latest build and try again. thanks.

I believe that I have a related problem that is very repeatable. I use squirrelmail on my home machine to provide a web interface to my IMAP server. Squirrelmail has a feature that shows an email in its own window for clean printing. In addition to the email itself are two buttons, Print and CLose Window. Using the print button twice (same email or two separate emails) always results in a crash. I am using 0.9.9 (2002031104) on Windows NT.

I'll try it on the latest build, but I doubt that's the problem, since I've noticed this behavior for several milestones. I've got a computer upstairs running Windows 98; I'll see if it prints okay on that -- perhaps it has something to do with the Windows 2000 print subsystem.

I have this same problem. Also on a Win2K/SP2 machine. I've sent in two "talkback"-reports. I'm using Mozilla 0.9.9 Build ID:2002031104 Talkback Incident ID's: TB4305124H TB3987727Z Michael

To tell you the truth.. I dont understand the receipe for reproducing this. Are you just printing the same page more than once..any web page. Or are you on a specific web page and hitting a print button. Can you please clarify a receipe.

Recipe: 1) Print a web page. Any web page. Prints fine. 2) Do *not* close and re-start Mozilla. 3) Print a web page. Any web page, whether it's the same one or another one doesn't matter. 4) Crash. And the second web page doesn't print either.

On my NT 4.0 400 mhz machine.. I just printed 5 times.. same page. I will try my windows 2k machine tonight.

A perfect illustration of Larry Niven's Finagle Principle: "The Universe tends to be maximally perverse." I just tried printing a couple of times: whereas I've gotten consistent crashes for months doing this, no such luck today. I *did* get a crash after printing twice, then hitting the "back" button. I will fiddle with it further and come up with a more specific scenario.

confirming....others are seeing this too now....marking other bug a DUP of this one...

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

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=75456 Top three stacks for printing crashes Problems seem to be focused on Win2000 and XP platforms.

Adding JS_GetPrivate to summary since one of Michael's Talkback incidents in Comment #4 show that stack signature for this crash.

jay beat me to it. :) This one is a topcrasher on the Trunk and M099 with the JS_GetPrivate signature also. These are the top three stacks.

For what it's worth, here's how to duplicate on my system: Open Mozilla, go to Slashdot (http://www.slashdot.org). Print the page. Page prints fine. Click on a Slashdot link to go to a story. Print the page. Boom! Mozilla crashes.

TB 4528392W may be related.

I didn't have this problem in milestones 0.9.7 and 0.9.8, it occurred for the first time in 0.9.9 (as opposed to the original reporter). I could send in more TB-reports and publish the TB-numbers here if that would be helpful. I'm not sure since I'm not using nightly builds but using the 0.9.9 release build and it would only be more TB's from the same machine.

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

This affects all platform my mom ran into it last night.

Making this topcrash+, adding testcase keyword and nominating for nsbeta1. This is still happening when people try to print twice: (5052698) Comments: printing from browser (4795881) Comments: Tried to print to file. Worked before but this time I printed to the default mozilla directory mozilla.ps and it bombed. (4780548) URL: usfa.fema.gov (4780548) Comments: Trying to print a page from this site while an earlier print job was still finishing.

Here are a couple of recent incidents: Incident ID 5005196 Stack Signature js_Interpret() 2638d7ba Trigger Time 2002-04-09 10:50:13 Email Address URL visited printing to file Build ID 2002040908 Product ID MozillaTrunk Platform Operating System LinuxIntel Module Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) User Comments Selected file that might have been locked or in use by current print job, moz asked if I wanted to replace it, I said yes... crash. Stack Trace js_Interpret() js_Execute() JS_ExecuteScript() nsJSContext::ExecuteScript() nsXULDocument::ExecuteScript() nsXULDocument::LoadScript() nsXULDocument::ResumeWalk() nsXULDocument::EndLoad() XULContentSinkImpl::DidBuildModel() nsExpatDriver::DidBuildModel() nsParser::DidBuildModel() nsParser::ResumeParse() nsParser::OnStopRequest() nsDocumentOpenInfo::OnStopRequest() nsJARChannel::OnStopRequest() nsOnStopRequestEvent::HandleEvent() nsARequestObserverEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xee10 (0x40373e10) libglib-1.2.so.0 + 0x104d8 (0x403754d8) libglib-1.2.so.0 + 0x10ae3 (0x40375ae3) libglib-1.2.so.0 + 0x10c7c (0x40375c7c) libgtk-1.2.so.0 + 0x8d7e7 (0x402967e7) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x1917f (0x404b417f) Incident ID 5052698 Stack Signature JS_GetPrivate dd8f2264 Trigger Time 2002-04-10 13:06:34 Email Address URL visited printing from browser Build ID 2002040906 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation User Comments printing from browser Stack Trace JS_GetPrivate [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1913] nsJSContext::ExecuteScript [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 824] nsXULDocument::ExecuteScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 6196] nsXULDocument::LoadScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 5988] nsXULDocument::ResumeWalk [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 5767] nsXULDocument::EndLoad [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp, line 1672] XULContentSinkImpl::DidBuildModel [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULContentSink.cpp, line 537] nsExpatDriver::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsExpatDriver.cpp, line 881] nsParser::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1251] nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1790] nsParser::OnStopRequest [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2417] nsDocumentOpenInfo::OnStopRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 255] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp, line 609] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1078] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1431] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1766] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1784] WinMainCRTStartup() KERNEL32.DLL + 0xd326 (0x77e8d326)

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

I have never been able to reproduce this.... But I will try again.

Should this be marked as a windows bug? Printing works just dandy for me on Linux. I wasn't able to reproduce this and I do a lot of printing with moz uptimes of around a week.

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

Have we been able to repro this one, yet? What are the chances we could get a fix for this one before Friday, 04.26?

david, No my mom gets this on linux all the time.

I have the same problem on RedHat Linux 7.2 using the Ximian packages for 0.9.9. This is completely repeatable, I have yet to find a way to print twice in the same mozilla session without crashing mozilla.

Seems like some people have been able to reproduce this crash on linux, but I haven't seen any recent reports on Windows or Mac. Sujay - Can you try and reproduce this crash?

I am able to reproduce this on windows 2002-04-19-06-trunk. printing is crashing on subsequent attempts. added smoketest keyword. (printing once is all that is required in the smoketest, but this is really bad)

I cannot reproduce this on Windows using 4/19 commercial trunk and 4/17 branch build. WFM.

Per Sujay's and other comments, changing this to Linux only

doh! didn't see TWalkers comments ... changing back to ALL OS

my bad, I was testing print on home.netscape.com. (it fails there see bug 127891) I can't reproduce this bug on other pages. changed os back to linux and removed smoketest keyword. sorry 'bout that.

When mozilla crashes when trying to print, the page does not print successfully, instead a Post Script stack dump gets printed. I'm typing in the stack dump in case it is usefull for debugging. Its been the same for two differnt crashing pages. I'm running Rh7.2 with the ximian 0.99 mozilla packages, ghoscript-6.51-16 abd the printer is a HP LJ6L. I have been able to reproduce on yahoo, maps on us, cnn and bugzilla sites. It only started occuring for me in 0.99. Error: /syntaxerror in -file- Operand stack: unicodeshow Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1033/1476(ro) (G)-- --dict:0/20(G)-- --dict:111/200(L)-- Current allocation mode is local Last OS error: 2 %!PS-Adobe-3.0 [...]

topembed-. Doesn't meet the criteria for topembed. Linux only bug.

Changed OS back to "All" and restored "topembed," whatever that is. Please check the comments: this is *not* a Linux-only bug. I filed it, and I have been running Windows 2000 Pro all along. Others have duplicated it in Windows.

On Windows, it won't let two processes try to write to the same file, in fact, it won't let you get past where you enter the file name if the file name is in use.

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

Clearing + on topembed since it was not determined to be topembed+ before.

Adding M1RC1 to summary, this is also a topcrasher for Mozilla1.0 RC1: Count Offset Real Signature [ 4 js_Interpret cb6582b0 - js_Interpret ] [ 4 js_Interpret 5a50a4a8 - js_Interpret ] [ 3 js_Interpret f36ec2da - js_Interpret ] Crash date range: 2002-04-19 to 2002-04-20 Min/Max Seconds since last crash: 77 - 27311 Min/Max Runtime: 683 - 27311 Keyword List : print(5), Count Platform List 4 Windows NT 5.0 build 2195 4 Windows 98 4.10 build 67766446 3 Windows NT 5.1 build 2600 Count Build Id List 11 2002041717 No of Unique Users 8 Stack trace(Frame) js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 1269] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 970] JS_ExecuteScript [d:\builds\seamonkey\mozilla\js\src\jsapi.c line 3260] nsJSContext::ExecuteScript [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp line 824] nsXULDocument::ExecuteScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 6196] nsXULDocument::LoadScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 5988] nsXULDocument::ResumeWalk [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 5767] nsXULDocument::EndLoad [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 1672] XULContentSinkImpl::DidBuildModel [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULContentSink.cpp line 537] nsExpatDriver::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsExpatDriver.cpp line 882] nsParser::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 1253] nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 1790] nsParser::OnStopRequest [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 2419] nsDocumentOpenInfo::OnStopRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 255] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp line 609] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1078] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1431] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1766] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1784] WinMainCRTStartup() KERNEL32.DLL + 0x17d08 (0x77e97d08) (5425667) URL: http://www.spikything.com/games/kickups/ (5425667) Comments: Just installed Flash 6 plugin and visited the above site. Right clicked the flash object and was looking at the 'Macromedia Flash Player Settings' popup. (5395590) URL: http://slate.msn.com/?id=2064500 (5395590) Comments: Attempting to use slate's print page feature. (5394889) Comments: print twice (bug 132216) (5393895) URL: http://www.useit.com@a6r.ms/?4e57 (5393895) Comments: I think there is a fucking pattern here it is the second document that is printed that seem to crash the Liz. Just had the same thing happen a bit ago tried printing the URL above and whammo. The simularity is that both time it was the second document (5393895) Comments: that I printed. (5392993) URL: http://www.southwest.com/about_swa/airborne.html (5392993) Comments: Tried to pint the page at the URL above crash. I had just printed a page (that was still in the que). The Java Plug-in was also running as I had been to a page previously that used Java (5389740) Comments: Crashes whhen printing certain Web pages!!! Count Offset Real Signature [ 3 js_Interpret 4cdfad2c - js_Interpret ] Crash date range: 2002-04-18 to 2002-04-19 Min/Max Seconds since last crash: 215 - 14039 Min/Max Runtime: 215 - 14039 Keyword List : Count Platform List 3 Windows NT 5.0 build 2195 Count Build Id List 3 2002041717 No of Unique Users 3 Stack trace(Frame) js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 1226] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 970] JS_ExecuteScript [d:\builds\seamonkey\mozilla\js\src\jsapi.c line 3260] nsJSContext::ExecuteScript [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp line 824] nsXULDocument::ExecuteScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 6196] nsXULDocument::LoadScript [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 5988] nsXULDocument::ResumeWalk [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 5767] nsXULDocument::EndLoad [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp line 1672] XULContentSinkImpl::DidBuildModel [d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULContentSink.cpp line 537] nsExpatDriver::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsExpatDriver.cpp line 882] nsParser::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 1253] nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 1790] nsParser::OnStopRequest [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 2419] nsDocumentOpenInfo::OnStopRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 255] nsJARChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp line 609] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp line 213] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 597] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 530] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1078] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1431] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1766] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1784] WinMainCRTStartup() KERNEL32.DLL + 0xd326 (0x77e8d326) (5355996) Comments: printing. the second print job consistantly crashes the browser

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

i'm not crashing on subsequent attempts to print, but it still won't print a second document. The only way to print is to restart, reload the page and print (1st print only works)

this WFM on todays commercial trunk builds: windows 2002-04-24-06-trunk mac os9 2002-04-24-03-trunk

So if we're crashing in JS_Interp, then somebody has whack a JS object somehow. The stack trace looks like it has little to do with `printing', per se, but rather some evil interaction with the print dialog itself and the XUL cache. The `second time' makes me believe that we're crashing pulling the dialog out of the XUL cache -- people that can reproduce this consistently, try disabling the XUL cache (Edit > Preferences, then on the Debug > Networking panel, click `Disable XUL cache'. If that is the case, then this bug ought to go over to someone in XPToolkit to track down. (Sorry!)

I've tried the setting in comment #44 and I think Chris is right. With XUL-cache disabled I haven't had any print-crashes anymore.

OK so far with XUL cache disabled. In case it is useful: Very occasionally, instead of (or as well as) a Browser crash I would get a truncated/corrupted print progress bar on second print.

Waterson thinks this is a XUL cache issue, it seems like it is

Re comment #46 - Aagh it is now working with XUL cache on! Sorry! (I was going to try setting pref print.show_print_progress false - not a lot of point now)

This bug needs some attention.

RodS, don't you own the Print dialog, along with the printing backend?

->bryner/p1

As I am still not seeing a proper print progress window on these prints (I just see the window outline), my gut feeling is still that it it is a problem with PrintProgress. I am out of my depth, but this doesn't look right to me: nsDocumentViewer calls DoPrintProgress to open the Progress window. This presumably happens on a seperate thread. As part of its onLoad code it sets up a listener. Meanwhile nsDocumentViewer goes straight on to call onStartPrinting which relies on the listener being already loaded (DoOnProgressChange), which is surely questionable.

I'm unable to reproduce this on Linux or Windows XP, with either skin. If we think it's the XUL cache, Brendan has given me an idea how to fix some _potential_ problems, but it would really be a stab in the dark if we can't reproduce this.

What I think (see comment #52) is that with the XUL cache off - the print progress window is open before the initialisation code, on the listener, is called. with the XUL cache on - the print progress window is still being created, the initialisation doesn't get called properly, and, sometime later, something that should have been initialised is causing a crash.

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

Could those that can reproduce this please supply more info about how they they do it (machine, OS details, etc.)?

I have attached recent crashes for Windows and Linux grouped by unique stack traces. All but one of the incidents are under the js_Interpret stack signature, there is one crash under the nsScriptSecurityManager::GetScriptPrincipal stack signature on Linux.

Implementing the fix to use JS_LockGCThing() as Brendan has suggested will require a new API, JS_LockGCThingRT().

shaver said he was giving bryner new JS API love. /be

Just a note, the function names and line numbers in the stack trace (matched up against rev 1.494 of nsXULDocument.cpp) do support the theory that the problematic JSObject is coming from the XUL cache.

This patch adds a GC lock on all JSObjects while they are in the XUL cache. In the future, we'll want to change nsXULPrototypeScript and nsXULPrototypeAttribte to use locking instead of rooting for the script object pointer, to save on memory. shaver's patch from bug 141356 is required for this.

On 2002042806: I see this bug on two Windows XP machines and a Windows 2000 box, but not Linux. No idea about Win9x. All XP/2000 boxen are patched to the latest from MS. Modern skin, no plugins, and tabbed browsing enabled for all of them. I can reproduce about 1/3 of the time. Using www.section508.gov, File->Print, works great. Hit print again, crash. Don't remember my talkbalk IDs but I did send them in. I can't reproduce it on a regular basis, sometimes it goes, sometimes it works. Once it gets past the second print, it keeps working after that.

whi can review this for bryner?

Comment on attachment 82148 [details] [diff] [review] patch >+/* static */ >+void PR_CALLBACK >+nsXULPrototypeCache::UnlockJSObjectCallback(nsHashKey *aKey, void *aData, void* aClosure) >+{ >+ JS_UnlockGCThingRT((JSRuntime*) aClosure, aData); >+} > > NS_IMETHODIMP > nsXULPrototypeCache::FlushScripts() > { >- mScriptTable.Reset(); >+ // This callback will unlock each object so it can once again be gc'd. >+ mScriptTable.Reset((nsHashtableEnumFunc) UnlockJSObjectCallback, (void*) GetJSRuntime()); You shouldn't have to cast the enum-funarg like that -- do you have the right return type? I see PRBool, not void. /be

good catch.

Comment on attachment 82304 [details] [diff] [review] patch #2 sr=brendan@mozilla.org contingent on waterson r='ing, looks good to me. /be

Comment on attachment 82304 [details] [diff] [review] patch #2 r=waterson

Comment on attachment 82304 [details] [diff] [review] patch #2 a=asa (on behalf of drivers) for checkin to the 1.0 branch

Thanks for the patch Brian. Much Appreciated. adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 brnach. Pls check this in after you receive a= from Drivers, then add the fixed1.0.0 keyword.

If this was fixed on the branch, pls add the keyword fixed1.0.0.

Checked in on the trunk and MOZILLA_1_0_0_BRANCH. We should watch the talkback reports to verify that this is no longer happening (trunk builds starting with the 5/4 morning builds, and branch builds starting with tonight or tomorrow morning's builds).

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

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

Can we get some feedback from the people who saw this problem before? Please download the latest branch builds after 5/4 and test it out, then report back here in this bug report... thanks...

build 2002050506 - WFM in WindowsXP and 2000! Tested different combinations for about an hour. (Luckily I had lots to print).

Talkback shows one crash with the js_Interpret stack, on the trunk, after this patch was checked in (5960559), with build 2002050507. No comments were given for how to reproduce it. No trunk crashes are showing up since my checkin with the JS_GetPrivate stack. No crashes have shown up on the branch with either stack since this was checked in.

anyone else besides Jorge see this fixed now? thanks.

I tried this with build 2002050508 and it works fine for me on WinXP. I'll do some more testing tomorrow on Win2000.

OK so far

marking verified based on 3 people confirming that this problem is gone for them. If anyone else is still having a problem, let us know.

Probably a moot point by now, but I don't see this bug on three more Win2k boxes. I never tested the original bug on these, but it's not there now.

Tested ok on my system (Redhat 7.2) with latest nightly. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020507

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

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

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

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