Closed Bug 132216 Opened 21 years ago Closed 21 years ago

Print twice, second, again crashes M1RC1 Trunk [@ js_Interpret | JS_GetPrivate]

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: mike, Assigned: bryner)

References

Details

(4 keywords, Whiteboard: [adt1] [ETA 05/03] [m5+])

Crash Data

Attachments

(4 files, 1 obsolete file)

Stacks for the JS_GetPrivate siganture
8.99 KB, text/plain
Details
Recent crashes for Mozilla1.0 RC1 (Windows and Linux)
13.91 KB, text/plain
Details
Attaching current talkback information. (Stack trace is the same, so not including.)
4.13 KB, text/plain
Details
patch #2
2.69 KB, patch
waterson
: review+
brendan
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
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.
Keywords: crash
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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.
Keywords: topcrash
Summary: Print twice, second, again crashes Mozilla → Print twice, second, again crashes Mozilla M099, Trunk [@ js_Interpret]
Adding JS_GetPrivate to summary since one of Michael's Talkback incidents in
Comment #4 show that stack signature for this crash.
Summary: Print twice, second, again crashes Mozilla M099, Trunk [@ js_Interpret] → Print twice, second, again crashes Mozilla M099, Trunk [@ js_Interpret | JS_GetPrivate]
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.
OS: Windows 2000 → All
Hardware: PC → All
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.
Keywords: topcrash → nsbeta1, testcase, topcrash+
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
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?
Whiteboard: [adt1] [ETA Needed]
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?
Keywords: topembed
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)
Keywords: smoketest
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
Keywords: nsbeta1 → nsbeta1+
OS: All → Linux
doh! didn't see TWalkers comments ... changing back to ALL OS
OS: Linux → All
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.
Keywords: smoketest
OS: All → Linux
Hardware: All → PC
 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.
Keywords: topembed → topembed-
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.
Keywords: topembed- → topembed+
OS: Linux → All
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.
Keywords: topembed+ → topembed
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
Summary: Print twice, second, again crashes Mozilla M099, Trunk [@ js_Interpret | JS_GetPrivate] → Print twice, second, again crashes M1RC1 Trunk [@ js_Interpret | JS_GetPrivate]
*** 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
Assignee: rods → hyatt
Status: ASSIGNED → NEW
Component: Printing → XP Toolkit/Widgets: XUL
QA Contact: sujay → shrir
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.
Assignee: hyatt → trudelle
QA Contact: shrir → sujay
Blocks: 138000
Keywords: mozilla1.0+
RodS, don't you own the Print dialog, along with the printing backend?
->bryner/p1
Assignee: trudelle → bryner
Priority: -- → 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().
Depends on: 141356
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.
Status: NEW → ASSIGNED
Attached patch patch (obsolete) — — Splinter Review 
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?
Whiteboard: [adt1] [ETA Needed] → [adt1] [ETA 05/03] [m5+] [Needs r/sr/a=]
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
Attached patch patch #2 — — Splinter Review 
good catch.
Attachment #82148 - Attachment is obsolete: true
Comment on attachment 82304 [details] [diff] [review]
patch #2

sr=brendan@mozilla.org contingent on waterson r='ing, looks good to me.

/be
Attachment #82304 - Flags: superreview+
Comment on attachment 82304 [details] [diff] [review]
patch #2

r=waterson
Attachment #82304 - Flags: review+
Comment on attachment 82304 [details] [diff] [review]
patch #2

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82304 - Flags: approval+
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.
Keywords: adt1.0.0+
Whiteboard: [adt1] [ETA 05/03] [m5+] [Needs r/sr/a=] → [adt1] [ETA 05/03] [m5+]
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).
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
*** 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.
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
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. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: sujay → xptoolkit.widgets
Crash Signature: [@ js_Interpret | JS_GetPrivate]
You need to log in before you can comment on or make changes to this bug.