No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Bug in filter processing?
From: Kristoffer Lawson <setok_at_scred.com>
Date: Sun, 29 Aug 2010 04:02:04 +0300
Take a look at this code:
package require XOTcl 1.6
namespace import xotcl::*
Class Foo
Foo instproc hello {} {
puts hello
}
Foo instproc myfilter {args} {
puts "\nme: [self]"
::set targetclass [my info class]
puts "targetclass: $targetclass"
puts "calledproc: [self calledproc]"
::set r [next]
puts "back from next"
puts "paramcmds: [$targetclass info instparametercmd]"
}
Foo instfilter myfilter
Foo ob
ob hello
ob foo
So first I have a filter installed which does nothing but print some information, and checks something using the [info] method afterwards. I call an instantiated object with [hello] (an existing method) and again with [foo] (a non-existing method). The latter is when things get interesting. Check the output:
me: ::ob
targetclass: ::Foo
calledproc: configure
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: init
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: hello
hello
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: foo
back from next
me: ::alloc
::alloc: unable to dispatch method 'info'
while executing
"my info class"
(procedure "cleanup" line 4)
::alloc ::Foo->myfilter
::Foo ::xotcl::Class->recreate
::Foo ::xotcl::Class->create
::Foo ::xotcl::Class->unknown
::Foo ::xotcl::Class->create
::Foo ::xotcl::Class->unknown
::Foo ::xotcl::Class->create
::Foo ::xotcl::Class->unknown
invoked from within
"$targetclass info instparametercmd"
(procedure "foo" line 9)
::ob ::Foo->myfilter
invoked from within
"ob foo"
(file "filtertest.tcl" line 24)
me: ::alloc
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:
me: ::info
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:
...
So while the [hello] method works as expected, things get totally weird for [foo]. The first thing we notice is that it doesn't jump out at [next] (which should give an error as it does not exist). It continue execution of the filter after [next]. This may or may not be intended, I don't know. The documentation is not clear on this.
More interesting still, we end up with a totally unexpected error. The thing I believe is happening is that, for some reason or other [$targetclass info instparametercmd] is not ending up calling [info] for $targetClass, but creating an object called ::info (and thus overriding the original Tcl command). How [alloc] gets involved in the filter chain too, I am not sure. My guess is that the "unknown method" that resulted from [foo] is being interpreted by the XOTcl $targetclass C implementation as an error that occurred there, and that a new instance called "info" or possibly "alloc" should be created.
This causes major havoc as soon as an unknown method is called. Does the filter code look correct?
This happens with 1.6.2. I had a quick look at CHANGES for later versions and while there was some mention of memory leaks in [info] I wasn't sure if there was anything that would have fixed this.
Any ideas?
Date: Sun, 29 Aug 2010 04:02:04 +0300
Take a look at this code:
package require XOTcl 1.6
namespace import xotcl::*
Class Foo
Foo instproc hello {} {
puts hello
}
Foo instproc myfilter {args} {
puts "\nme: [self]"
::set targetclass [my info class]
puts "targetclass: $targetclass"
puts "calledproc: [self calledproc]"
::set r [next]
puts "back from next"
puts "paramcmds: [$targetclass info instparametercmd]"
}
Foo instfilter myfilter
Foo ob
ob hello
ob foo
So first I have a filter installed which does nothing but print some information, and checks something using the [info] method afterwards. I call an instantiated object with [hello] (an existing method) and again with [foo] (a non-existing method). The latter is when things get interesting. Check the output:
me: ::ob
targetclass: ::Foo
calledproc: configure
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: init
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: hello
hello
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: foo
back from next
me: ::alloc
::alloc: unable to dispatch method 'info'
while executing
"my info class"
(procedure "cleanup" line 4)
::alloc ::Foo->myfilter
::Foo ::xotcl::Class->recreate
::Foo ::xotcl::Class->create
::Foo ::xotcl::Class->unknown
::Foo ::xotcl::Class->create
::Foo ::xotcl::Class->unknown
::Foo ::xotcl::Class->create
::Foo ::xotcl::Class->unknown
invoked from within
"$targetclass info instparametercmd"
(procedure "foo" line 9)
::ob ::Foo->myfilter
invoked from within
"ob foo"
(file "filtertest.tcl" line 24)
me: ::alloc
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:
me: ::info
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:
me: ::ob
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:
...
So while the [hello] method works as expected, things get totally weird for [foo]. The first thing we notice is that it doesn't jump out at [next] (which should give an error as it does not exist). It continue execution of the filter after [next]. This may or may not be intended, I don't know. The documentation is not clear on this.
More interesting still, we end up with a totally unexpected error. The thing I believe is happening is that, for some reason or other [$targetclass info instparametercmd] is not ending up calling [info] for $targetClass, but creating an object called ::info (and thus overriding the original Tcl command). How [alloc] gets involved in the filter chain too, I am not sure. My guess is that the "unknown method" that resulted from [foo] is being interpreted by the XOTcl $targetclass C implementation as an error that occurred there, and that a new instance called "info" or possibly "alloc" should be created.
This causes major havoc as soon as an unknown method is called. Does the filter code look correct?
This happens with 1.6.2. I had a quick look at CHANGES for later versions and while there was some mention of memory leaks in [info] I wasn't sure if there was anything that would have fixed this.
Any ideas?
-- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/