1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • A TclOO debug question

    From Helmut Giese@21:1/5 to All on Thu Jul 31 22:17:30 2025
    Hello out there,
    I have a problem following the 'next' chain of an object hierarchy.
    More precisely: When destroying an object I destroy each of its
    children as well as all the objects it has acquired. So far so good -
    I can even follow (via 'puts') all destructor calls.
    But then an already destroyed object wants to destroy itself again
    although I have seen already its destructor message.
    In the stack trace I only see a chain like
    <some command>
    .
    .
    .
    <some other command>
    The '.' being presumeably the 'next' calls.
    Question: Is there a way to find out whose 'next' call is hiding
    behind those '.' messages?
    Any help or idea will be greatly appreciated
    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From et99@21:1/5 to Helmut Giese on Thu Jul 31 14:38:15 2025
    On 7/31/2025 1:17 PM, Helmut Giese wrote:
    Hello out there,
    I have a problem following the 'next' chain of an object hierarchy.
    More precisely: When destroying an object I destroy each of its
    children as well as all the objects it has acquired. So far so good -
    I can even follow (via 'puts') all destructor calls.
    But then an already destroyed object wants to destroy itself again
    although I have seen already its destructor message.
    In the stack trace I only see a chain like
    <some command>
    .
    .
    .
    <some other command>
    The '.' being presumeably the 'next' calls.
    Question: Is there a way to find out whose 'next' call is hiding
    behind those '.' messages?
    Any help or idea will be greatly appreciated
    Helmut

    How are you getting the stack trace? Is this from an error message?

    I have used [info frame N] with N going say 1 to 20 (skipping and ignoring when it says invalid frame) and displaying all the info provided. Maybe that could be of some use, but you would need to do it while everything is still on the stack.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Giese@21:1/5 to All on Fri Aug 1 22:17:52 2025
    Hello et99,
    you saved my day: 'info frame' was the command to use. With it I found
    out rather easily what was hiding behind the 'next' calls and found -
    a mistake on my part (which was of course to be expected).

    Many, many thanks and have a nice weekend
    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)