1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Chaining crashes the debugger

Discussion in 'Support' started by djspits, Sep 17, 2016.

  1. djspits

    Joined:
    Apr 13, 2010
    Messages:
    189
    Likes Received:
    2
    Using latest version, calling one batch from another without the use of the "call" command while debugging causes the debugger to crash.

    Actually does that for many versions of TCC.

    Regards,

    DJ
     
  2. MaartenG

    Joined:
    Aug 3, 2016
    Messages:
    355
    Likes Received:
    8
    That seems somehow "logical": you are debugging a batchfile that is no longer running /active.
    I created a batchfile to reproduce this behaviour:

    Code:
    echo Goedenmiddag!
    EXIT
    
    Same behaviour ...

    But I might miss out on something (or two), because this is literally the first time I started IDE.exe
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,032
    Likes Received:
    84
    Not reproducible here -- what's the exact syntax you're using?
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,032
    Likes Received:
    84
    WAD, and not a crash -- EXIT tells TCC you want to shut down the session. And it does.
     
  5. MaartenG

    Joined:
    Aug 3, 2016
    Messages:
    355
    Likes Received:
    8
    IDE did hang after the exit ("waiting-cursor" forever).
    Can't reproduce it anymore. Now it just exits, like you said. Strange ....

    Minor "issue": if you start IDE.exe from a CMD prompt, afterwards the window title is set to "ide" and the prompt is not shown. [Enter] fixes that last one.
     
  6. djspits

    Joined:
    Apr 13, 2010
    Messages:
    189
    Likes Received:
    2
    Source is linked to this message.

    Regards, DJ.
     

    Attached Files:

  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,032
    Likes Received:
    84
    What is "TCApp.BTM"? And hwhat arguments are you passing to AppDispatch.BTM?
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,032
    Likes Received:
    84
    Assuming you're in a console session (not a TCMD tab window), the title change is being done by CMD, not IDE.

    The prompt issue is unreproducible here (and cannot possibly be related to IDE, which is a GUI app running in a separate session). When you start IDE.EXE from a CMD prompt, CMD displays a new prompt immediately, because it's not waiting on the GUI app for anything.
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,032
    Likes Received:
    84
    I created a "TCApp.BTM" that just echos something and waits for a key before quitting. I tried starting AppDispatch.BTM with an "auto" argument and ran the batch debugger both from a TCC console window and a TCMD tab window. It worked perfectly chaining directly in both cases (and also when using CALL).

    You say that chaining is "crashing the debugger" - are you actually getting a crash dialog from Windows? If so, please send the contents of that dialog. (And if you are, it's almost certainly coming either from Windows or from third-party injected code, as IDE does its own exception handling.)

    If IDE is crashing in its internal code, it will create a log file named "IDE.exception.log". If you have that file, please post it here. (If you don't have it, the crash isn't in IDE.EXE.)

    IDE will load yout TCMD.INI and your plugins and run TCSTART before launching the batch file, so try starting IDE with the /I option to disable TCMD.INI, plugins, and TCSTART.
     
  10. MaartenG

    Joined:
    Aug 3, 2016
    Messages:
    355
    Likes Received:
    8
    You are right, the title change *is* done by CMD. When you strart "ise.exe", everything OK; starting "ise" (without the .exe) gives the new ise title right away. To make sure I copied ide.exe to abc.exe and started "abc" : title = abc.

    Regarding the prompt: 100% reproducable here :-) . But I don't concider this as something worth looking further into. It might even be some quirk in my system.
     
  11. djspits

    Joined:
    Apr 13, 2010
    Messages:
    189
    Likes Received:
    2
    Sorry. It took a while to get back at you.

    Enclosed two screenshots. "Crash" should be understood as an unhandled exception in IDE.exe, followed by an Access violation, followed by a restart of the IDE/debugger.

    If you want I could install a screen recorder and mail you the video. However, sending more source files would probably add to the confusion.

    Please let me know if you plan to look into this any further and what info would be helpful. Note that I have a workaround for my problem.

    I do think there is a vulnerability here, somewhere. If I may suggest something - what might be a rare condition and perhaps therefor untested - is:

    process A (deferring something) - chaining to B - chaining to C

    When is the deferred action executed? Before B or after C? Just a thought.

    Regards,
    DJ.
     

    Attached Files:

  12. djspits

    Joined:
    Apr 13, 2010
    Messages:
    189
    Likes Received:
    2
    I can reproduce the error with these simplified source files

    Regards, DJ
     

    Attached Files:

  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,032
    Likes Received:
    84
    The deferred action is executed when the current batch file exits. That means if you chain to another batch file without a CALL, the DEFER will be done before executing the second batch file.
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,032
    Likes Received:
    84
    The crash is actually in Microsoft code (as was shown by the exception address). I was able to reproduce it and track it that far.

    I can't fix their crash, but I added a workaround in build 21 to prevent it from calling the bad code.
     

Share This Page