Closed
Bug 158592
Opened 23 years ago
Closed 22 years ago
Stack Trace code causes process thread to die.
Categories
(Core :: Security: CAPS, defect)
Core
Security: CAPS
Tracking
()
RESOLVED
FIXED
People
(Reporter: tim.c.quinn, Assigned: security-bugs)
References
Details
Attachments
(1 file)
|
406 bytes,
text/html
|
Details |
Try runngin the following code. If there is a better way to get a stack trace
please let me know.
<Html>
<head>
<title>Stack Trace Test</title>
</head>
<body>
<strong>
<u>MOZILLA CALLER BUG?</u><br>
ver: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0)
Gecko/20020530<br><br>
You should get a 'stack trace' alert then a 'process is not dead'
alert.<br><br>
If you do not get any messages, the process thread has died. <br><br>
In mozilla the thread always dies.
</strong>
</body>
<script>
function i() {return h()}
function h() {return g()}
function g() {return getStackTrace()}
function getStackTrace() {
var s = "Stack Trace:" + "\n"
try {
for(c = arguments.callee.caller; c; c = c.caller)
s += " " + c.toString().match(/function (\w*)/)[1] + "()" +
"\n"
} catch(e) {}
return s
}
alert(i())
alert("Process is not dead!")
</script>
</html>
|
||
Comment 1•23 years ago
|
||
Confirming bug with Mozilla trunk binary 20020715xx on WinNT.
Here is a reduced testcase, which I will attach below:
<SCRIPT>
alert(f());
alert(g());
function f()
{
return g();
}
function g()
{
return 'The current caller of g() is \n' + g.caller;
}
</SCRIPT>
There is also a version for the standalone JS shell (print() inst of alert()).
OUTPUT:
IE6, NN4.7, and JS shell: both alerts come up successfully.
The first one says
The current caller of g() is
function f() {
return g();
}
The second one says
The current caller of g() is
null
But in Mozilla, only the first alert comes up. The second one
fails SILENTLY: no error appears in the JS Console. No error
is being caught by try...catch blocks, either.
That's why the reporter's test brings up nothing. Eventually his loop
has to test when |c.caller| is null. He gets no error in the catch-block;
and no output as a result.
Since this is not failing in the standalone JS shell, reassigning
to DOM Level 0 component -
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM Level 0
Ever confirmed: true
QA Contact: pschwartau → desale
|
|
||
Comment 2•23 years ago
|
||
|
|
||
Comment 3•23 years ago
|
||
To clarify my remarks:
When a function g() is being called from top-level code, then |g.caller|
should simply be |null|, as it is in IE6, NN4.7, and our own JS shell.
This is failing silently in Mozilla. I don't want my remarks above
to suggest that we should be generating an error; we should not.
|
Reporter | |
Comment 4•22 years ago
|
||
Thanks for your attention Phil.
I agree, an error should not be thrown, however the JavaScript thread should not
die. Although I was able to build an Awesome Stack trace engine through parsing
the Error.stack property. I have come across a new need for this feature.
I have started porting about 2,000 lines of procedural Wizard/Web JavaScript
into Objects. I would like to encapsulate constructors and methods for my
Objects. JavaScript OO Encapsulation could be achieved by:
where aac=arguments.callee.caller
Only allow one method to create object(ie buildWidget(args) ):
if(aac!=window["<Function Name>"]){throw...}
Encapsulate Object methods:
if(!aac||aac.constructor!=window["<Object>"].constructor) {throw...}
Unfortunately if the caller was chrome the JS thread just dies. If it returned
null and did not kill the JS thread we can achieve JS OOE. Another benefit will
be had for Mozilla (future ex IE) newbies who play around with the caller
properties. Took me many hours to figure it out since it was my debugger that
was dying :[
Thanks for your time and regards,
Tim
|
||
Comment 5•22 years ago
|
||
nsScriptSecurityManager::CheckJSFunctionCallerAccess blocks access to .caller.
Rather odd since .caller is null in this case. I'm also seeing:
###!!! ASSERTION: CheckPropertyAccessImpl called without a target object or URL:
'Error', file nsScriptSecurityManager.cpp, line 723
Assignee: jst → mstoltz
Component: DOM Level 0 → Security: CAPS
QA Contact: desale → bsharma
|
|
||
Comment 6•22 years ago
|
||
Nominating for Mozilla 1.3 alpha. It is important that recursive
appeals to |f.caller| succeed all the way to top-level code.
This is one of the reasons the |caller| method is in JavaScript.
Furthermore, there is no problem in IE6, NN4.7, or the JS shell:
js> function g() { return 'The current caller of g() is \n' + g.caller; }
js> function f() { return g(); }
js> f();
The current caller of g() is
function f() { return g(); }
js> g();
The current caller of g() is
null
Keywords: mozilla1.3
|
|
||
Comment 7•22 years ago
|
||
*** Bug 179777 has been marked as a duplicate of this bug. ***
|
|
||
Comment 8•22 years ago
|
||
Note there is a nice testcase from the duplicate bug 179777:
------- Additional Comment_ #1 From Colin Surprenant 2002-11-12 11:39 -------
Created an attachment (id=106000)
arguments.callee.caller bug simple test case
This test case to show the bug in these 3 contexts:
1- Access to arguments.callee.caller from the body onload handler
2- Access to arguments.callee.caller in a try/catch from a top level function
3- Access to arguments.callee.caller from a onclick handler
Normally, the body onload handler should display an alert showing
arguments.callee.caller. The top level function invokes an alert in both the
try and catch, and after the try/catch. Finally, the onlick handler should
display an alert showing arguments.callee.caller.
|
|
||
Comment 9•22 years ago
|
||
Compare bug 119529,
"uncaught exception: Permission denied to get property Function.caller"
|
|
||
Comment 10•22 years ago
|
||
Brendan mentioned this in bug 119529:
> I just checked in the fix for bug 181934 -- anyone care to test
> whether it fixes this bug too?
It does seem to have fixed both bug 119529 and this bug, too.
Using Mozilla trunk binary 2002112711 on WinNT, when I try each
of the above testcases, they now work properly.
tim.quinn@honeywell.com, crsng1@netscript.com: do you find the same
to be true? Note: to verify this, you'll have to use a trunk build
from 2002-11-27 or after -
|
|
Reporter | |
Comment 11•22 years ago
|
||
Verified as fixed with Mozilla Trunk Binary 2002112908 on both NT5-sp3 and
OSX-1.22.
Great work!
:]
|
|
||
Comment 12•22 years ago
|
||
Tim: thanks!
Resolving this bug as FIXED due to the fix for bug 181934.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•