Crash for scenario test case using execute (blk param not required) - trunk, N610, M095 [@ js_AllocRawStack][@ js_AllocStack]

VERIFIED FIXED in mozilla0.9.6


18 years ago
3 years ago


(Reporter: jimmykenlee, Assigned: dveditz)


({crash, regression, topcrash})

crash, regression, topcrash
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+]; [smartupdate] [Fix checked into 094 branch], crash signature)


(4 attachments)



18 years ago
Build: 2001-05-01-06-trunk(WIN), 2001-05-01-04-trunk(MAC), 

1. From http://jimbob/trigger3.html, enter u_new65.xpi in the Trigger URL field
2. Click Trigger button
3. Click OK from confirm dialog

Browser freezes during install.

No freeze/crash.  Install completes.

A similar test case, u_new65_noconfirm.xpi, is the same test except the call to 
execute and confirm are commented out.  I will attach the install scripts.

Comment 1

18 years ago
Created attachment 32825 [details]
Install script for u_new65.xpi

Comment 2

18 years ago
Created attachment 32826 [details]
Install script for u_new65_noconfirm.xpi

Comment 3

18 years ago
I forgot to mention that u_new65_noconfirm.xpi installs successfully on all 
platforms.  I cannot figure out why the the call to execute() appears to be the 
reason for the crash.  Just a reminder that the crash still occurs even if there 
is no use of the new blocking flag.

Nominating for Beta.  This test seems harmless enough, but it crashes.  I need 
an explanation because I cannot figure it out.  Maybe it's just a bug. ;-)
Keywords: crash, nsbeta1

Comment 4

18 years ago
please retest

Comment 5

18 years ago
Build: 2001-05-08-08-trunk(LINUX), 2001-05-09-08-trunk(MAC), 

This crash is still happening.  It's alive and well.


18 years ago
Keywords: nsbeta1 → nsbeta1+, regression
Target Milestone: --- → mozilla0.9.1


18 years ago
Whiteboard: [smartupdate]


18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 6

18 years ago
Build: 2001-06-05-03-0.9.1(MAC), 2001-06-05-04-0.9.1(LINUX), 

This is still reproducible.


18 years ago
Keywords: nsenterprise


18 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 7

18 years ago
Is this something our installer actually does?  How many users are likely to
experience this problem?

Comment 8

18 years ago
We call execute(), if that is the question. Bug implies some instability there.
Perhaps dveditz or ssu can comment more than I on the importance.

Comment 9

18 years ago
This is a big deal because it will mean that EA, Sun's Java plugin, and people 
going to our smartupdate site will not be able to install anything.  Even our 
native installers might be affected as well.  I'll have to do some testing with 

I've just tried a local copy of u_new65.xpi under NT40 and I see the hang/crash.  
I will investigate this more when I get into work tomorrow.  I have a really old 
build on my machine right now.

Comment 10

18 years ago
I should not have quickly jumped to the conclusion that this will affect those 
things.  I need to look at this closer to see exactly what's going on.  Since 
there's no log file created, it makes it more difficult.

Comment 11

18 years ago
Created attachment 41844 [details] [diff] [review]
Patch using JS_SuspendRequest/JS_ResumeRequest

Comment 12

18 years ago
r=ssu for Don's patch id=41844.  it fixes the problem!  reassigning to dbragg.

Syd, what was the other bug that this might fix?
Assignee: syd → dbragg

Comment 13

18 years ago
This bug might be the same underlying cause (js memory problems) as topcrash 
bug 58573

Comment 14

18 years ago
PDT+, we also expect 58573 to be fixed by this (please dup it.)
Whiteboard: [smartupdate] → PDT+; [smartupdate]


18 years ago
Keywords: nsBranch

Comment 15

18 years ago
*** Bug 58573 has been marked as a duplicate of this bug. ***

Comment 16

18 years ago

Comment 17

18 years ago
*** Bug 88455 has been marked as a duplicate of this bug. ***

Comment 18

18 years ago
patch checked in for Don in the trunk and branch.   marking this fixed.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 19

18 years ago
Build: 2001-07-17-05-0.9.2(WIN), 2001-07-17-03-0.9.2(MAC),

Verfied on all platforms on branch.  Adding "vtrunk" keyword.  Needs to be
verified on trunk.
Keywords: vtrunk

Comment 20

18 years ago
Build: 2001-08-01-06-trunk

Verified on trunk.  Removing "vtrunk" keyword.

Marking Verified!
Keywords: vtrunk

Comment 21

17 years ago
Bug 58573 was marked a dup of this one and the crash reported there seems to be
back with Mozilla 0.9.4, so reopening for now.  Here is the latest info:

Latest Mozilla 0.9.4 Talkback data shows this crash (or a very similar one)
occurring during java installation on both Windows and Linux.

js_AllocRawStack   46
			 58573 	 VERI 	 DUPL mozilla0.9 
BBID range: 35401410 - 35495217
Min/Max Seconds since last crash: 79 - 77935
Min/Max Runtime: 79 - 100835
Crash data range: 2001-09-14 to 2001-09-17
Build ID range: 2001091311 to 2001091311

Stack Trace: 

	 our_gdk_io_invoke() + 0xec40 (0x4034ac40) + 0x10308 (0x4034c308) + 0x10913 (0x4034c913) + 0x10aac (0x4034caac) + 0x8d7e7 (0x4026f7e7)
	 main() + 0x1d2eb (0x404862eb)     (35483928)	Comments: Java Software Installation
     (35482537)	URL:
Comments: installing java plugin
     (35478506)	Comments: I just updated Mozilla 0.9.4 for Java support when the crash
happened.  The install for Java continued but the crash still happened.  The
install of the JRE was from the Netscape web site suggested by the release notes.
     (35477590)	Comments: Installing Java
     (35464103)	Comments: trying to autoupdate for the java2 plugin
     (35463259)	Comments: I was downloading JRE via the mozilla downloader  and it crashed.
     (35456413)	Comments: writing a mail
     (35455791)	Comments: when it finished downloading java2 from netscape mozilla crashed
but the java 2 installer still starts
     (35455160)	Comments: after downloaded Java 1.3
     (35442416)	Comments: it was installing java 2 RE
     (35442387)	URL:
     (35437554)	Comments: installing java pluging
     (35430410)	URL:
Comments: On my home page there is a clock in Java. Mozilla noticed it was an
applet and proceeded to download and subsequently install the Java 1.3 Plug-in
at Netscape. I closed down the window to the URL leaving just the download
dialog running and continued to
     (35430410)	Comments:  surf in other Mozilla windows. During the installation Windows 95
said Mozilla caused an invalid page fault. Only applications running were AOL 
Mozilla and ICQ. Hope this helps! : )
     (35429344)	Comments: Downloading Java plugin (this crash happens in Linux as well
     (35425605)	Comments: Automatic Installation of Java
     (35425339)	URL:
Comments: load the url  then a windows pops up where a java applett is loaded.
as i have no java installed I clicked on the plugin so I got the possibility to
install java. confirmed software installation (java for windows). As the
download process takes a bit too
     (35425339)	Comments:  long I clicked on cancel. then mozilla crashed.
     (35424684)	Comments: Donwloading java plug-in
     (35416376)	Comments: Java 2 auto-installer (as prompted by the browser) had just
launched the installation portion when the browser crashed.
     (35414758)	Comments: Was installing the Java plug in via the automated system when it
crashed just as the Java setup program started.
     (35414078)	Comments: I went to javasoft.comMozilla asked me to download java pluginI
click yesThe download started asking me additionnal privilegesAt the end of the
downloadThe installer start creating folders in /op/mozilla/plugins/javaAfter
maybe 5 second of intensive
     (35414078)	Comments:  file creationAn crash occurendI was running moz as colMoz was
installed as root
     (35413894)	Comments: installing the Java plugin

This is one of the topcrashers for M094 thus far.
Keywords: topcrash
Resolution: FIXED → ---
Summary: Crash for scenario test case using execute (blk param not required) → Crash for scenario test case using execute (blk param not required) - M094 [@ js_AllocRawStack]

Comment 22

17 years ago
I've tried to get a quick look at the code, but except from a NULL Context, I
didn't see anything shocking.
Anyway I tried to reproduce the bug on my w2k machine with 0.9.4 2001091303.
Mozilla doesn't crash, the plugin says it installs correctly (and the pluggin is
indeed installed on my machine) but in fact it doesn't start using the plugin in
The 'click here once the plugin is installed' window, once clicked, say 'click
here to install plugin'.

Comment 23

17 years ago
There aren't any comments on this bug since the 19th of
Sept.  Can get fixes/reviews in the next day or two?  If so, please mark as
nsbranch+ which will get this on the PDT radar. Else, mark is as nsbranch-.
Also, can someone comment in the bug how serious you think this is?  PDT is only
accepting "stop ship" bugs such as data loss and loss of major functionality.

Comment 24

17 years ago
This is a bug which has been reopened.  Is dbragg still the right owner for this? 

Jimmy - is your original test case/scenario fixed?

I'm wondering if we should file a new bug for this topcrash.


17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.5


17 years ago
Keywords: nsbranch → nsbranch+

Comment 25

17 years ago
**Please** don't confuse us between a crash on Linux and a failure to copy the
plugins correctly on Windows. The java installer is completely different for the
two platforms, and the symptoms are completely different.

There's another bug for the windows thing. Dunno if this one should be the crash

Comment 26

17 years ago
We need top people looking at this who can settle it once and for all.
Assigning to jband for his suggestions.
Assignee: dbragg → jband

Comment 27

17 years ago
I couldn't manage to reproduce this crash. But here's what I think is happening 
and what needs to be done... 

I think we are crashing because the JSContext that handleTriggerEvent tries to 
use has already been deleted. Since nsXPITriggerInfo::mGlobalWrapper should keep 
that from occuring, it seem that handleTriggerEvent is getting called after the 
nsXPITriggerInfo has been destroyed. It does not look like the this was planned 
for - even though with a posted event you'd want to expect that this might 

The *right* way to fix this is to convert nsXPITriggerInfo into a refcounted 
xpcom object and have the XPITriggerEvent object hold a reference. This requires 
fixing all the users of nsXPITriggerInfo also.

The quick and dirty fix is to have nsXPITriggerInfo hold a reference to the 
object reference by nsXPITriggerInfo::mGlobalWrapper and to *also* hold a JS 
root on XPITriggerEvent::cbval (XPITriggerEvent::global is presumably rooted by 
the reference we hold on that global wrapper).

I'll attach a patch. 

Can anyone reproduce the bug? Or should we accept this based on analysis only?

Do we want to do a better fix at this point or just take a quick and smaller 

Comment 28

17 years ago
Created attachment 50857 [details] [diff] [review]
quick and dirty fix

Comment 29

17 years ago
Damn I knew if I gave this to jband he'd get on top of it!

quick fix is good for nsbranch, longer term 9the trunk) we should do the right
thing, and we can wait for that to happen (within reason).

Tomorrow I will apply this patch and fish around for a person who can take the
build and verify it works.


Comment 30

17 years ago
Jimmy, can you dupe, and if so, what platform? I'll get you a branch build as
soon as you tell me (and I wake up).

Comment 31

17 years ago
Build:  2001-09-26-05-0.9.4(WIN),  2001-09-26-04-0.9.4(LINUX),

This problem is not reproducible.

Comment 32

17 years ago
Did you try installing JRE on Linux? I wonder if there's some common
configuration we could find by looking at the crash data?

Comment 33

17 years ago
I just installed it.  No problems.  

Comment 34

17 years ago
So, where do we stand? 

There is a hacky (but safe) patch for a bug we can't reproduce. I believe that
it is very likely to fix the problem.

Does anyone want to offer a r= or sr=?

Am I gonna be stuck owning this bug?

Should we push for PDT+ or does syd's nsbranch+ annotation count as approval for
the 0.9.4 branch under the current rules?

reassiging to syd to prod him to push process.
Assignee: jband → syd

Comment 35

17 years ago
Comment on attachment 50857 [details] [diff] [review]
quick and dirty fix

sr=dveditz, that should help a lot.
Attachment #50857 - Flags: superreview+

Comment 36

17 years ago
*** Bug 100010 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago
*** Bug 101986 has been marked as a duplicate of this bug. ***

Comment 38

17 years ago
I'll check this into the branch tonight.

Comment 39

17 years ago
Fix checked into branch.
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 40

17 years ago
Reopening. This is still busted on the trunk.
Resolution: FIXED → ---

Comment 41

17 years ago
Reassigning. dveditz told me he would be willing to help this one along. Maybe 
just get the current patch into the trunk or do a better fix (or find someone 
else who would).
Assignee: syd → dveditz


17 years ago
Keywords: nsenterprise → nsenterprise-

Comment 42

17 years ago
marking nsenterprise-; will be reevaluated for nsenterprise in future release.


17 years ago
Keywords: nsbeta1+

Comment 43

17 years ago
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6


17 years ago
Whiteboard: PDT+; [smartupdate] → [PDT+]; [smartupdate] [Fix checked into 094 branch]

Comment 44

17 years ago
Jimmy - the fix is on the branch. Pls verify your original scenario.  Thanks.

Comment 45

17 years ago
Build: 2001-10-15-05-0.9.4(WIN), 2001-10-15-05-0.9.4(LINUX)

This still works fine on the branch.  Adding vtrunk keyword.
Keywords: vtrunk

Comment 46

17 years ago
Added [@ js_AllocStack] to summary, since that stack signature has also been a
topcrasher for Mozilla 0.9.4.
Summary: Crash for scenario test case using execute (blk param not required) - M094 [@ js_AllocRawStack] → Crash for scenario test case using execute (blk param not required) - M094 [@ js_AllocRawStack][@ js_AllocStack]

Comment 47

17 years ago
js_AllocRawStack & js_AllocStack are both topcrashers on M095.  Updated summary.
Summary: Crash for scenario test case using execute (blk param not required) - M094 [@ js_AllocRawStack][@ js_AllocStack] → Crash for scenario test case using execute (blk param not required) - trunk, N610, M095 [@ js_AllocRawStack][@ js_AllocStack]


17 years ago
Blocks: 107066


17 years ago
Keywords: nsbranch+
Checked into the 0.9.6 branch.
Blocks: 104864
Keywords: mozilla0.9.6+

Comment 49

17 years ago
Checked into trunk.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 50

17 years ago
Build: 2001-11-19-15-trunk

Finally catching up.  This looks good on the trunk as well.  Marking Verified!
Keywords: vtrunk
Crash Signature: [@ js_AllocRawStack] [@ js_AllocStack]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.