Aha got it:
For a frame object,
(##frame o) => #t
(##subprocedure-parent-name (##frame-ret o)) => the name of the procedure that the frame regards e.g. ##read-u8
(##frame-ref o N) where N = 0 .. (##frame-fs o) - 1 => the frame's bound objects, (##frame-slot-live? o N) checks the respective slot for aliveness.
2013/6/20 Mikael mikael.rcv@gmail.com
Dear Marc,
In memory leak hunting I've gotten to a place where there's two stack frame objects that keep the leaking pointer.
How can I introspect #<frame #[number]> objects to understand where in the sourcecode they come from in terms of location, code content and variable content?
Thanks, Mikael
Afficher les réponses par date
On 2013-06-20, at 7:13 AM, Mikael mikael.rcv@gmail.com wrote:
Aha got it:
For a frame object,
(##frame o) => #t
(##subprocedure-parent-name (##frame-ret o)) => the name of the procedure that the frame regards e.g. ##read-u8
(##frame-ref o N) where N = 0 .. (##frame-fs o) - 1 => the frame's bound objects, (##frame-slot-live? o N) checks the respective slot for aliveness.
Yes, and if you have compiled your program with "gsc -debug", you can get more information with (##subprocedure-info return-address) including the source code and location information. In other words, the debugging information is associated with return addresses.
Marc