1. Forum
  2. USENET
  3. comp.lang.tcl

  • A TclOO debug question

    From Helmut Giese@hgiese@ratiosoft.com to comp.lang.tcl on Thu Jul 31 22:17:30 2025
    From Newsgroup: comp.lang.tcl

    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
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From et99@et99@rocketship1.me to comp.lang.tcl on Thu Jul 31 14:38:15 2025
    From Newsgroup: comp.lang.tcl

    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.


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Helmut Giese@hgiese@ratiosoft.com to comp.lang.tcl on Fri Aug 1 22:17:52 2025
    From Newsgroup: comp.lang.tcl

    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

    --- Synchronet 3.21a-Linux NewsLink 1.2