Closed Bug 158592 Opened 22 years ago Closed 22 years ago

Stack Trace code causes process thread to die.

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: tim.c.quinn, Assigned: security-bugs)

References

Details

Attachments

(1 file)

Reduced HTML testcase
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>
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
Attached file Reduced HTML testcase — 

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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

    
    

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

    
    

    
  
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.

    
    

    
  
Compare bug 119529,
"uncaught exception: Permission denied to get property Function.caller"

    
    

    
  
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 -

    
    

    
  
Verified as fixed with Mozilla Trunk Binary 2002112908 on both NT5-sp3 and
OSX-1.22. 

Great work! 

:]

    
    

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: