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

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Jimmy Lee]

Build: 2001-05-01-06-trunk(WIN), 2001-05-01-04-trunk(MAC), 
2001-05-01-08-trunk(LINUX)

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

RESULT:
Browser freezes during install.

EXPECTED RESULT:
No freeze/crash.  Install completes.

NOTE:
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

[Jimmy Lee]

Attachment: Install script for u_new65.xpi

Comment 2

[Jimmy Lee]

Attachment: Install script for u_new65_noconfirm.xpi

Comment 3

[Jimmy Lee]

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

Comment 4

[Syd Logan]

please retest

Comment 5

[Jimmy Lee]

Build: 2001-05-08-08-trunk(LINUX), 2001-05-09-08-trunk(MAC), 
2001-05-09-06-trunk(WIN)

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

Comment 6

[Jimmy Lee]

Build: 2001-06-05-03-0.9.1(MAC), 2001-06-05-04-0.9.1(LINUX), 
2001-06-05-11-0.9.1(WIN)

This is still reproducible.

Comment 7

[selmer (gone)]

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

Comment 8

[Syd Logan]

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

[Sean Su]

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

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

[Sean Su]

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

[dbragg]

Attachment: Patch using JS_SuspendRequest/JS_ResumeRequest

Comment 12

[Sean Su]

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?

Comment 13

[Daniel Veditz [:dveditz]]

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

Comment 14

[rubydoo123]

PDT+, we also expect 58573 to be fixed by this (please dup it.)

Comment 15

[dbragg]

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

Comment 16

[Scott MacGregor]

sr=mscott

Comment 17

[Daniel Veditz [:dveditz]]

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

Comment 18

[Sean Su]

patch checked in for Don in the trunk and branch.   marking this fixed.

Comment 19

[Jimmy Lee]

Build: 2001-07-17-05-0.9.2(WIN), 2001-07-17-03-0.9.2(MAC),
2001-07-17-03-0.9.2(LINUX)

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

Comment 20

[Jimmy Lee]

Build: 2001-08-01-06-trunk

Verified on trunk.  Removing "vtrunk" keyword.

Marking Verified!

Comment 21

[Jay Patel [:jay]]

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

	 js_AllocRawStack()
	 js_AllocStack()
	 JS_PushArgumentsVA()
	 JS_PushArguments()
	 handleTriggerEvent()
	 PL_HandleEvent()
	 PL_ProcessPendingEvents()
	 nsEventQueueImpl::ProcessPendingEvents()
	 event_processor_callback()
	 our_gdk_io_invoke()
	 libglib-1.2.so.0 + 0xec40 (0x4034ac40)
	 libglib-1.2.so.0 + 0x10308 (0x4034c308)
	 libglib-1.2.so.0 + 0x10913 (0x4034c913)
	 libglib-1.2.so.0 + 0x10aac (0x4034caac)
	 libgtk-1.2.so.0 + 0x8d7e7 (0x4026f7e7)
	 nsAppShell::Run()
	 nsAppShellService::Run()
	 main1()
	 main()
	 libc.so.6 + 0x1d2eb (0x404862eb)     (35483928)	Comments: Java Software Installation
     (35482537)	URL: www.tuhh.de
(35481909)
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: http://toc.oscar.aol.com
(35437554)
URL: java.sun.com
     (35437554)	Comments: installing java pluging
     (35430410)	URL: http://www.netwielder.f2s.com
(35430410)
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: https://www.1822direkt.com
(35425339)
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.

Comment 22

[Jerome Lacoste]

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
Mozilla.
The 'click here once the plugin is installed' window, once clicked, say 'click
here to install plugin'.

Comment 23

[Cindy Roberts]

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

[lchiang]

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.

Comment 25

[Daniel Veditz [:dveditz]]

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

[Syd Logan]

We need top people looking at this who can settle it once and for all.
Assigning to jband for his suggestions.

Comment 27

[John Bandhauer]

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

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 
fix?

Comment 28

[John Bandhauer]

Attachment: quick and dirty fix

Comment 29

[Syd Logan]

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.

Thanks!

Comment 30

[Syd Logan]

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

[Jimmy Lee]

Build:  2001-09-26-05-0.9.4(WIN),  2001-09-26-04-0.9.4(LINUX),
2001-09-26-03-0.9.4(MAC)

This problem is not reproducible.

Comment 32

[Daniel Veditz [:dveditz]]

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

[Jimmy Lee]

I just installed it.  No problems.  

Comment 34

[John Bandhauer]

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.

Comment 35

[Daniel Veditz [:dveditz]]

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

sr=dveditz, that should help a lot.

Comment 36

[Daniel Veditz [:dveditz]]

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

Comment 37

[Daniel Veditz [:dveditz]]

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

Comment 38

[Syd Logan]

I'll check this into the branch tonight.

Comment 39

[Syd Logan]

Fix checked into branch.

Comment 40

[John Bandhauer]

Reopening. This is still busted on the trunk.

Comment 41

[John Bandhauer]

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

Comment 42

[Hong Kwon]

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

Comment 43

[Asa Dotzler [:asa]]

0.9.5 is out the door. bumping TM up by one.

Comment 44

[lchiang]

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

Comment 45

[Jimmy Lee]

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.

Comment 46

[Jay Patel [:jay]]

Added [@ js_AllocStack] to summary, since that stack signature has also been a
topcrasher for Mozilla 0.9.4.

Comment 47

[Jan Carpenter]

js_AllocRawStack & js_AllocStack are both topcrashers on M095.  Updated summary.

Comment 48

[Christopher Blizzard (:blizzard)]

Checked into the 0.9.6 branch.

Comment 49

[Daniel Veditz [:dveditz]]

Checked into trunk.

Comment 50

[Jimmy Lee]

Build: 2001-11-19-15-trunk

Finally catching up.  This looks good on the trunk as well.  Marking Verified!