301265 - [@ js_SetClassPrototype]

Status: RESOLVED INCOMPLETE

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

Description

[timeless]

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=js_SetClassPrototype&vendor=All&product=MozillaTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

28 crashes found where the Stack Signature contains 'js_setclassprototype' and
the Deployment ID looks like '%MozillaTrunk%%' and the sort is by ID. 

Incident ID: 7456087
Stack Signature	js_SetClassPrototype ed7ed7ca
Product ID	MozillaTrunk
Build ID	2005070105
Trigger Time	2005-07-13 13:46:47.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0002e745)
URL visited	
User Comments	
Since Last Crash	408904 sec
Total Uptime	408904 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line 3754
Stack Trace 	
js_SetClassPrototype 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
3754]
js_InitAnyNameClass 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsxml.c, line
7367]
RunInstallOnThread 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpinstall/src/nsSoftwareUpdateRun.cpp,
line 545]
_PR_NativeRunThread 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/nsprpub/pr/src/threads/combined/pruthr.c,
line 458]
kernel32.dll + 0xb50b (0x7c80b50b)

Comment 1

[timeless]

and for those of you who don't like optimizers there's one proper crash from
macosx curteosy of the clever gcc compiler:

Incident ID: 7166963
Stack Signature	js_SetClassPrototype() 8b493bd1
Product ID	MozillaTrunk
Build ID	2005070113
Trigger Time	2005-07-02 10:29:07.0
Platform	MacOSX
Operating System	Darwin 7.8.0
Module	libmozjs.dylib.1.0.0 + (000437b0)
URL visited	http://mozmonkey.com/packages/extuninstaller/extuninstaller.xpi
User Comments	
Since Last Crash	89 sec
Total Uptime	920 sec
Trigger Reason	SIGSEGV: Segmentation Violation: (signal 11)
Source File, Line No.
/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/js/src/jsobj.c, line 3749
Stack Trace 	
js_SetClassPrototype() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/js/src/jsobj.c, line
3749]
js_SetClassPrototype() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/js/src/jsobj.c, line
3736]
js_InitAnyNameClass() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/js/src/jsxml.c, line
7366]
js_InitXMLClasses() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/js/src/jsxml.c, line
7459]
JS_InitStandardClasses() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/js/src/jsapi.c, line
1182]
SetupInstallContext() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/xpinstall/src/nsSoftwareUpdateRun.cpp,
line 398]
RunInstallOnThread() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/xpinstall/src/nsSoftwareUpdateRun.cpp,
line 547]
_pt_root() 
[/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla/nsprpub/pr/src/pthreads/ptthread.c,
line 223]
libSystem.B.dylib.71.1.1 + 0x246e8 (0x900246e8)

Comment 2

[Brendan Eich [:brendan]]

This is because xpinstall runs JS on other threads than the main one, but does
not use requests, I bet.

Anyone know the history here?  Cc'ing dougt.  It may be easy to fix this, but
I'd like to know why a new thread is being used.

/be

Comment 3

[Doug Turner (:dougt)]

xpinstall uses a new thread since the install execution is blocking.  For example:

initInstall("", "", "");
setPackageFolder(getFolder("Program"));
addFile(a);
addFile(b);
performInstall();

The above script will copy two files out of the xpi and install them into the
programs directory above.  This process might take a long time -- consider a
script with dozens of large files.

During the development of xpinstall, a requirement was to display a progress
dialog during installation.  This dialog was to be written in xul and js.  We
found that our blocking design of the xpinstall and these dialogs couldn't
co-exist.  A decision was made to keep the design (which stems from the design
of SmartUpdate from Netscape 4), and move the javascript execution to a new
thread and post messages from that new thread back to the ui thread.  Born here
was xpcom/proxy to aide in this message passing.

Maybe there is a better approach then the one we took some years ago?

Comment 4

[timeless]

brendan, that's an interesting guess, but afaik xpinstall *does* use requests:
this url is based on comment 1

http://bonsai.mozilla.org/cvsblame.cgi?
file=/mozilla/xpinstall/src/nsSoftwareUpdateRun.cpp&mark=540-
545,389,395&rev=1.98#362

note that rev 1.98 <[e-mail]> 2005-06-29 06:58
predates Build ID	2005070113 by a few days.

unfortunately there aren't many trunk crashes atm to look at.

Comment 5

[Brendan Eich [:brendan]]

Does not use requests correctly, then.  There's an early return in a request,
although that's not the bug that is biting.  There could be other probs -- I'll
look later today.

/be

Comment 6

[Doug Turner (:dougt)]

brendan, if you are going to be poking in xpinstall land looking at js usage,
you might want to team up with shaver for a quick second.  it sounds like there
are js string fu that isn't GC safe either.  See bug 302284.

Comment 7

[Brendan Eich [:brendan]]

I'm actually not going to get to this any time soon.  Reassigning to default.

/be