Re: Partial solution to debugging eval() code

Ok, what I said was fiction. I do have the source of eval-s,
from my scheme. What I need is to relate functions to their
correct source. I was using the frame.eval() to both jobs,
but I can just use it to get the source and different scheme
to relate the functions:

All jsd "scripts" are one of four types: (or so I think)
   top-level
   eval-level
   functions defined in top-level   << no problem
   functions defined in eval-level  << problem
All scripts come thru the onScriptCreated hook.  It looks like
the js engine emits all of the functions in each XX-level script
then emits the XX-level script. So if I stack up the scripts
until I see either top-level (discard stack) or eval-level
(mark all as fileName = data:url from eval). Then I can do your
line number subtraction to define baseLineNumber relative to
the eval source.

I'll try this one.
John.



John J. Barton wrote:
> James Ross wrote:
>> If you want to try being clever, would it not be possible to - from 
>> the stack frame - work out the eval line number by subtracting the 
>> offset of the call above it? I still think SpiderMonkey needs to fix 
>> this by numbering the eval lines from 1 and not line-of-call. :)
>>
> 
> The eval line number relative to the eval source isn't useful unless we
> have the eval source.  Numbering the eval lines from 1 would just shift
> the problem from one random-looking location to another ;-).
> 
> But the real problem with these solutions is that the stack containing
> the offsets is only available when eval() is called, while the code that
> one wants to debug is called at any time later.  So we have foo() from
> and eval that looks like it came from file bootstrap.js:240.   But we
> don't have the source containing foo() declaration and we don't know
> how many nested eval()s came between bootstrap.js:240 and the eval()
> that spawned foo().
> 
> Or so I think now.  Maybe I'll look to see if this fact or fiction.
> 
> I sure wish I could build the moz code so I could debug into jsd and
> see what really goes on.
> 
> John.