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

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[Michael A. Koenecke]

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.

Comment 1

[sujay]

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.

Comment 2

[jimshep]

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.

Comment 3

[Michael A. Koenecke]

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.

Comment 4

[Michael Jonker]

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

Comment 5

[dcone (gone)]

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.

Comment 6

[Michael A. Koenecke]

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.

Comment 7

[dcone (gone)]

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

Comment 8

[Michael A. Koenecke]

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.

Comment 9

[sujay]

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

Comment 10

[sujay]

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

Comment 11

[sujay]

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.  

Comment 12

[Jay Patel [:jay]]

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

Comment 13

[greer]

Attachment: Stacks for the JS_GetPrivate siganture

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.

Comment 14

[Michael A. Koenecke]

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.

Comment 15

[Carl-Daniel Hailfinger]

TB 4528392W may be related.

Comment 16

[Michael Jonker]

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.

Comment 17

[Keyser Sose]

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

Comment 18

[Keyser Sose]

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

Comment 19

[Jay Patel [:jay]]

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.

Comment 20

[Jay Patel [:jay]]

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) 

Comment 21

[sujay]

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

Comment 22

[rods (gone)]

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

Comment 23

[Blu3]

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.

Comment 24

[sujay]

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

Comment 25

[Jaime Rodriguez, Jr.]

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?

Comment 26

[Keyser Sose]

david,

No my mom gets this on linux all the time.

Comment 27

[jimshep]

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.

Comment 28

[Jaime Rodriguez, Jr.]

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?

Comment 29

[Tracy Walker [:tracy]]

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)

Comment 30

[sujay]

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

WFM.

Comment 31

[Jaime Rodriguez, Jr.]

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

Comment 32

[Jaime Rodriguez, Jr.]

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

Comment 33

[Tracy Walker [:tracy]]

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.

Comment 34

[Travis Caldwell]

 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

  [...]



 

Comment 35

[Kevin McCluskey (gone)]

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

Comment 36

[Michael A. Koenecke]

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.

Comment 37

[rods (gone)]

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.

Comment 38

[Boris 'pi' Piwinger]

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

Comment 39

[Kevin McCluskey (gone)]

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

Comment 40

[Jay Patel [:jay]]

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://[e-mail]/?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

Comment 41

[sujay]

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

Comment 42

[Tracy Walker [:tracy]]

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)

Comment 43

[Tracy Walker [:tracy]]

this WFM on todays commercial trunk builds:

windows 2002-04-24-06-trunk
mac os9 2002-04-24-03-trunk

Comment 44

[Chris Waterson]

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

Comment 45

[Michael Jonker]

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.

Comment 46

[John P Baker]

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.

Comment 47

[rods (gone)]

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

Comment 48

[John P Baker]

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) 

Comment 49

[Chris Waterson]

This bug needs some attention.

Comment 50

[Peter Trudelle]

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

Comment 51

[Peter Trudelle]

->bryner/p1

Comment 52

[John P Baker]

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.

Comment 53

[Brian Ryner (not reading)]

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.

Comment 54

[John P Baker]

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.

Comment 55

[timeless]

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

Comment 56

[Peter Trudelle]

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

Comment 57

[Jay Patel [:jay]]

Attachment: Recent crashes for Mozilla1.0 RC1 (Windows and Linux)

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.

Comment 58

[Brian Ryner (not reading)]

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

Comment 59

[Brendan Eich [:brendan]]

shaver said he was giving bryner new JS API love.

/be

Comment 60

[Brian Ryner (not reading)]

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.

Comment 61

[Jan Carpenter]

Attachment: Attaching current talkback information. (Stack trace is the same, so not including.)

Comment 62

[Brian Ryner (not reading)]

Attachment: patch

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.

Comment 63

[jorge o. castro]

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.

Comment 64

[Jaime Rodriguez, Jr.]

whi can review this for bryner?

Comment 65

[Brendan Eich [:brendan]]

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

Comment 66

[Brian Ryner (not reading)]

Attachment: patch #2

good catch.

Comment 67

[Brendan Eich [:brendan]]

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

sr=[e-mail] contingent on waterson r='ing, looks good to me.

/be

Comment 68

[Chris Waterson]

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

r=waterson

Comment 69

[Asa Dotzler [:asa]]

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

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 70

[Jaime Rodriguez, Jr.]

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.

Comment 71

[Jaime Rodriguez, Jr.]

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

Comment 72

[Brian Ryner (not reading)]

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

Comment 73

[Frederic Bezies]

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

Comment 74

[Brian Ryner (not reading)]

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

Comment 75

[sujay]

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

Comment 76

[jorge o. castro]

build 2002050506 - 

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

Comment 77

[Brian Ryner (not reading)]

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.

Comment 78

[sujay]

anyone else besides Jorge see this fixed now? thanks.

Comment 79

[Michael Jonker]

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

Comment 80

[John P Baker]

OK so far

Comment 81

[sujay]

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.

Comment 82

[jorge o. castro]

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.

Comment 83

[Ron Fabre]

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

Comment 84

[Boris 'pi' Piwinger]

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

Comment 85

[Boris 'pi' Piwinger]

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

Comment 86

[Boris 'pi' Piwinger]

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

Comment 87

[Jay Patel [:jay]]

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