On Tue, 3 Jun 2003, Fredrik (Naranek) Hubinette (Real Build Master) @ Pike (-) developers forum wrote:
You probably want to call _locate_references(this_object()[var]), otherwise you'll find all references to the string which contains the variable name...
Oh, yes thanks :)
I get lot more output this way :)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-06-03 19:43: Subject: Re: Debugging memory problems
On Tue, 3 Jun 2003, David Gourdelier wrote:
Are all these really variables in your object? If so, do they point to functions in some global module or something like that?
Yes there are variables inside my object. There are not referenced by other global modules.
. Is it possible to know which things reference which variables ?
There's one tool: If you compile with rtl-debug, there's a function _locate_references that walks through all things and prints the ones that reference the argument (in debug style). It's really useful, especially in 7.4 and later where it has been improved to report on the more odd sorts of references.
Ok I will try that.
Ok I've got some news. I've install Camas on a Caudium 1.3/Pike 7.4 and added this code:
foreach(indices(this_object()), string var) { if(this_object()[var] && !intp(this_object()[var])) { int refs = _refs(this_object()[var]); if(refs > 2) { write("\n------------------------------------\n" "variable %s is referenced %d times\n", var, refs); #if constant(_locate_references) write("by %O\n", _locate_references(var)); #endif } } }
And the output is ... well... strange :)
variable destroy is referenced 8 times **Looking for references to 0x8377314: ***One ref found on current interpreter stack. -> at location 0x28337460 ----------end------------ **Done looking for references to 0x8377314. by "destroy"
variable files is referenced 701 times **Looking for references to 0x83c4d24: ***One ref found on current interpreter stack. -> at location 0x28337460 ----------end------------ **Done looking for references to 0x83c4d24. by "files"
variable name is referenced 87 times **Looking for references to 0x844085c: ***One ref found on current interpreter stack. -> at location 0x28337460 ----------end------------ **Done looking for references to 0x844085c. by "name"
And so on, every variables are referenced by themselves and the location address is the same. The location address is the same if the user login and logout, maybe it points to a module ? So is it possible to know what is at this address ?
Thanks,
-- David Gourdelier
/ Brevbäraren