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

Coruption after which BTMs won't run

Discussion in 'Support' started by vefatica, Aug 7, 2012.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,788
    Likes Received:
    29
    The first line of this BTMfile has an error; @LINE's parameters are reversed.
    Code:
    on error (echo Error %_? at line %_batchline: %@line[%@eval[%_batchline-1],v:\error.btm] & quit)
    delay 1
    dir *.yyy
    The first time I run it in an instance of TCC, I see this.
    Code:
    v:\> error.btm
     
    Volume in drive V is DATA          Serial number is c007:d3e4
    v:\>
    Further attempts to run it or any other BTM file in the same TCC unstance fail, resulting in nothing at all. My error has somehow got TCC into a corrupted state in which no BTMfiles run.

    If I try it with BDEBUGGER, IDE,EXE crashes thus:
    Code:
     Fault Module Name:    IDE.EXE
      Exception Code:    c0000005
      Exception Offset:    000127e6
    
     
  2. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    I can replicate this, also in older versions going back to about v6. Looks like the error handler is called recursively and getting wound around the axle...?
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,788
    Likes Received:
    29
    I figured that but TCC neither catches it nor crashes (and is somewhat crippled afterward).
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    The TCC behavior isn't surprising, since you forced it into an infinite loop. The question is what you expected it to do?

    TCC eventually aborts the loop when it runs out of stack, but you can't do much else at that point.
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,788
    Likes Received:
    29
    Not knowing if it's feasible, my only thought would be to test for an ON ERROR condition while processing an ON ERROR condition and if that test is positive, bail out with an "ON ERROR loop" message.
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    It's not feasible. (You want an "ON ERRORERROR"?!?) It's looping at a lower level in the exception handlers; it doesn't get back to the place where the batch parser handles ON xxx conditions. And if I changed that, you couldn't get any warning about your syntax error; your batch file would just exit without explanation. (Unless you want an additional nested exception handler for every existing exception handler? That'd be a good way to slow everything down for people who are complaining that TCC is too small and running too fast on their new system ...) The best I could do would be to disable all further "ON xxx" handling while in an "ON xxx" handler. (Which would probably introduce a host of new complaints from people who are using multiple ON conditions.)

    The help file does warn about the danger of your introducing errors into your error handler!
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,788
    Likes Received:
    29
    OK, but I didn't get any warning about my syntax error; the batch file just exited without explanation.
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    It's going to do that regardless. I can change the exception handling so it won't eat the stack when you tell it you want it to eat the stack; it should only involve a few thousand lines of code and a couple of weeks. Or you could fix your ON ERROR code, which might be somewhat faster ...
     

Share This Page