B
Bill Kelly
Hi,
I'm compiling a lot of ruby code via eval, and running parts of
it in $SAFE=4, and I'm noticing large gaps in the Exception
backtraces. (I've done experiments with Kernel#caller, and the
gaps are usually there, too.)
Here's an example backtrace I'm getting:
#<SecurityError: relative ../ not allowed in path>
(eval):185:in `get_fullpath'
(eval):451:in `value'
(eval):451:in `sandbox'
(eval):538:in `kickoff_background_export'
(eval):1253:in `kickoff_progress_task'
(eval):1250:in `kickoff_progress_task'
(eval):1235:in `handle_progress_timer'
(eval):1194:in `init_dialog'
(eval):418:in `dispatch_event'
(eval):540:in `dispatch_event'
(eval):129:in `create_sandbox_binding'
(eval):129:in `create_sandbox_binding'
(eval):93:in `run'
(eval):166:in `dispatch_new_contexts'
(eval):166:in `dispatch_new_contexts'
(eval):156:in `run'
(eval):24
This is a fairly typical example of what I'm seeing.
get_fullpath is indeed the method that raised the
exception. But there are several methods in the
call chain between "get_fullpath" and "value" that
are missing.
It should have looked like this:
(eval):185:in `get_fullpath'
! (eval):???:in `template_dest_mkdir'
! (eval):???:in `__do_proxy__'
~~~~~~~~~~~~~~~~~~~~~~~~~~ (note: thread boundary)
! (eval):???:in `method_missing'
! (eval):???:in `generate_css'
! (eval):???:in `generate_site'
~~~~~~~~~~~~~~~~~~~~~~~~~~ (note: thread boundary)
(eval):451:in `value'
(eval):451:in `sandbox'
etc. . .
Now I could understand possible difficulties with
picking up the call chain across thread boundaries
(meaning: cases like Thread.new{$SAFE=4; foo()}.value)
But, parts of the call chain are missing before we get
to a thread boundary. For ex., the "template_dest_mkdir"
and "__do_proxy__" callers are just completely normal,
with respect to being the immediate callers of
"get_fullpath", and yet they're missing from the
backtrace, too.
Anyway, I guess what I'm wondering is whether this
might be a known issue or have a reasonable explanation,
or whether it's unexpected behavior?
If it's unexpected behavior, then I'll be happy to try
to write a simpler test case that reproduces the
problem.
(Note: It's ruby 1.8.4 (2005-12-24) [i386-mswin32])
Thanks for your help,
Regards,
Bill
I'm compiling a lot of ruby code via eval, and running parts of
it in $SAFE=4, and I'm noticing large gaps in the Exception
backtraces. (I've done experiments with Kernel#caller, and the
gaps are usually there, too.)
Here's an example backtrace I'm getting:
#<SecurityError: relative ../ not allowed in path>
(eval):185:in `get_fullpath'
(eval):451:in `value'
(eval):451:in `sandbox'
(eval):538:in `kickoff_background_export'
(eval):1253:in `kickoff_progress_task'
(eval):1250:in `kickoff_progress_task'
(eval):1235:in `handle_progress_timer'
(eval):1194:in `init_dialog'
(eval):418:in `dispatch_event'
(eval):540:in `dispatch_event'
(eval):129:in `create_sandbox_binding'
(eval):129:in `create_sandbox_binding'
(eval):93:in `run'
(eval):166:in `dispatch_new_contexts'
(eval):166:in `dispatch_new_contexts'
(eval):156:in `run'
(eval):24
This is a fairly typical example of what I'm seeing.
get_fullpath is indeed the method that raised the
exception. But there are several methods in the
call chain between "get_fullpath" and "value" that
are missing.
It should have looked like this:
(eval):185:in `get_fullpath'
! (eval):???:in `template_dest_mkdir'
! (eval):???:in `__do_proxy__'
~~~~~~~~~~~~~~~~~~~~~~~~~~ (note: thread boundary)
! (eval):???:in `method_missing'
! (eval):???:in `generate_css'
! (eval):???:in `generate_site'
~~~~~~~~~~~~~~~~~~~~~~~~~~ (note: thread boundary)
(eval):451:in `value'
(eval):451:in `sandbox'
etc. . .
Now I could understand possible difficulties with
picking up the call chain across thread boundaries
(meaning: cases like Thread.new{$SAFE=4; foo()}.value)
But, parts of the call chain are missing before we get
to a thread boundary. For ex., the "template_dest_mkdir"
and "__do_proxy__" callers are just completely normal,
with respect to being the immediate callers of
"get_fullpath", and yet they're missing from the
backtrace, too.
Anyway, I guess what I'm wondering is whether this
might be a known issue or have a reasonable explanation,
or whether it's unexpected behavior?
If it's unexpected behavior, then I'll be happy to try
to write a simpler test case that reproduces the
problem.
(Note: It's ruby 1.8.4 (2005-12-24) [i386-mswin32])
Thanks for your help,
Regards,
Bill