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

Repeated crashing!

Discussion in 'Support' started by vefatica, Oct 3, 2011.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    Right now I've got TCC v13 stuck in a crashing loop. 10 seconds after I say "Don't send" It crashes again, at the same place, namely at 0x004067C4 (code 0x00000005).

    It must be here:

    Code:
    do while "%string" EQ ""
        iff %reg eq 3 then
            set string=%@execstr[d:\uty\whois.exe -h %[reg%reg] "n + %ip" | d:\ttk\grep ountry.* 2> NUL]
        else
            set string=%@execstr[d:\uty\whois.exe -h %[reg%reg] %ip | d:\ttk\grep ountry.* 2> NUL]
        if "%string" eq "" delay 30
    enddo
    because that's the only place in the script that would start a secondary instance (and TaskMgr shows two instances running). Neither WHOIS nor GREP is running. Snooping on the two TCCs I see the envvars are correctly set:

    Code:
    v:\> echo %@pset[2544,reg]
    2
    
    v:\> echo %@pset[2544,ip]
    118.97.208.194
    
    v:\> echo %@pset[3264,ip]
    118.97.208.194
    
    v:\> echo %@pset[3264,reg]
    2
    If I kill it, open a new TCC v13, and run the script again, it happens all over again. TCC v12 will run the script completely and without error. All this is on my XP machine at work.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    I can't do anything without the tcc.gpf file.
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    On Tue, 04 Oct 2011 12:30:52 -0400, rconn <> wrote:

    |---Quote---
    |> Right now I've got TCC v13 stuck in a crashing loop.
    |---End Quote---
    |I can't do anything without the tcc.gpf file.

    A TCC.GPF was not produced. I'll keep my eyes open. This script isn't run
    often and I have seen it run to completion under TCC v13. After running to
    completion, it would have nothing to do for a while. It analyses the sources of
    the unwanted (refused) connections to the mail server on my work machine.

    For the curious, here are the summary stats after 16 months.

    Code:
    Intruders
    ---------------------------
    apnic	  2460	 44.9%
    ripencc	  1786	 32.6%
    arin	   571	 10.4%
    lacnic	   483	  8.8%
    afrinic	   178	  3.2%
    
    total	  5478
    
    57.0% of 9612 connections since 2010-06-01
    ---------------------------
    OK
    And here's the leader board. This is a bit misleading because the numbers for
    GB, US, and MM are greatly inflated by a few instances of badly behaved servers
    (in the GB case, a Microsoft server tried each hour for 12 days to deliver a
    legitimate email, notifying the sender of delivery failure 4 or 5 times over
    those 12 days).

    Code:
    GB=536
    US=455
    IN=327
    RU=317
    MM=285
    ID=240
    BR=214
    TW=207
    PH=195
    CN=195
    VN=186
    BD=169
    HK=155
    UA=153
    CA=147
    DE=141
    KR=114
    CL=110
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    On Tue, 04 Oct 2011 13:15:46 -0400, vefatica <> wrote:

    ||---Quote---
    ||> Right now I've got TCC v13 stuck in a crashing loop.
    ||---End Quote---
    ||I can't do anything without the tcc.gpf file.
    |
    |A TCC.GPF was not produced. I'll keep my eyes open. This script isn't run
    |often and I have seen it run to completion under TCC v13.

    I looked on the wrong computer. There is a GPF file (last night, 23:50), but it
    may not correspond to the original incident. I'll be more diligent the next
    time.

    Code:
    TCC  13.00.24
    Module=d:\tc13\TakeCmd.dll
    Address=100C4037
    Exception=C00000FD
    EAX=00452000  EBX=00000000  ECX=00416FFC  EDX=00000000
    ESI=004B7154  EDI=00000000  EBP=004770C0  ESP=00477128
    CS=0000001B  DS=00000023  ES=00000023  SS=00000023
    Flags=00010206
    
    Stack:
    1 : TakeCmd.dll 00000001:000c3037
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Can you at least say in what module the crash occurred? A bare address
    doesn't do much good if I have to look at several hundred dll's.
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    That's in the Microsoft RTL. Specifically, it's in the _fgets (or _fgetws)
    routine, which is only called in five places in the TCC code:

    * When reading descriptions
    * When reading a file for @SELECT
    * When reading a temp file for the command dialogs "Show" button
    * Reading a history list
    * Parsing TCMD.INI

    Since I doubt you're doing the first three in the snippet you posted, if
    it's being called from the TCC code(and not from a plugin or somebody's
    injected code), it would probably be while loading a history list or parsing
    TCMD.INI. Most likely the history list -- try turning that off and see if
    you can still reproduce it.
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    On Tue, 04 Oct 2011 17:16:25 -0400, rconn <> wrote:

    |---Quote---
    |> I looked on the wrong computer. There is a GPF file (last night, 23:50),
    |> but it may not correspond to the original incident.
    |---End Quote---
    |That's in the Microsoft RTL. Specifically, it's in the _fgets (or _fgetws)
    |routine, which is only called in five places in the TCC code:
    |
    | * When reading descriptions
    | * When reading a file for @SELECT
    | * When reading a temp file for the command dialogs "Show" button
    | * Reading a history list
    | * Parsing TCMD.INI
    |
    |Since I doubt you're doing the first three in the snippet you posted, if
    |it's being called from the TCC code(and not from a plugin or somebody's
    |injected code), it would probably be while loading a history list or parsing
    |TCMD.INI. Most likely the history list -- try turning that off and see if
    |you can still reproduce it.

    OK, but as I said, that BTM file often has nothing to do. I'll have to wait
    until the next time. I don't use a history file. And I use a global history
    list. What do you mean by "turn it off".

    As I said, I got those crash messages avary time through a loop; TCC didn't
    actually stop running. At some point it was quite screwed up, maybe having
    overwritten some of its own memory. Other simple things didn't work, like my
    "e=d:\textpad5\textpad.exe" alias. And (also as I said before) I'm not sure
    exactly what caused the GPF file I posted.

    I'll keep you informed but I'll have to wait for some more email intruders (and
    hope it fails again).
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    It happened again and with a little effort I can repro it. It definitely happens here:

    Code:
        do while "%string" EQ ""
            iff %reg eq 3 then
                set string=%@execstr[d:\uty\whois.exe -h %[reg%reg] "n + %ip" | d:\ttk\grep ountry.* 2> NUL]
            else
                set string=%@execstr[d:\uty\whois.exe -h %[reg%reg] %ip | d:\ttk\grep ountry.* 2> NUL]
            if "%string" eq "" delay 30
        enddo
    With ECHO ON the last thing I see is "iff %reg eq 3 then". I crashed it twice. The first time there was an extra TCC and WHOIS (no GREP); the second time only the extra TCC. Snooping on the crashed app's environment showed ip, reg, and reg3 all set correctly; "string" was not set.

    There is no GPF file. Windows gives the location 0x004067C4.

    It won't crash if I run it in the debugger (IDE).

    After the crash the BTM runs to conclusion but it's screwed up. I see no further output (and I should).
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    Code:
        do while "%string" EQ ""
            iff %reg eq 3 then
                set string=%@execstr[d:\uty\whois.exe -h %[reg%reg] "n + %ip" | d:\ttk\grep ountry.* 2> NUL]
            else
                set string=%@execstr[.\whois.exe -h %[reg%reg] %ip | .\grep ountry.* 2> NUL]
            if "%string" eq "" delay 30
        enddo
    I thought I'd make a little "kit" for reproducing this with the data files and two externals all in one place. But when I change the paths to WHOIS and GREP (above) to ".\", it won't crash. Also, if I remove "2> NUL", it won't crash. I said before, when it crashes, it has already been through a bigger loop a few times; typically, I'll see:

    Code:
    5491    112.65.165.132  CN
    5492    23.19.63.87     US
    5493 crash
    Just now I crashed it and dismissed the message. It crashed a few more times (dismissed) and eventually disappeared, leaving this GPF file. I'm still not sure the GPF file describes the original crash because, as I said, after the first crash (at 0x004067C4 in TCC) TCC is somehow handicapped. No messages (nor the GPF file) give the PID so I don't even know which TCC (BTM interpreter or secondary) is crashing.

    Code:
    TCC  13.00.26
    Module=d:\tc13\TakeCmd.dll
    Address=100C3F57
    Exception=C00000FD
    EAX=00452000  EBX=00000000  ECX=0044F18C  EDX=004EF1E8
    ESI=0048F1A4  EDI=00000000  EBP=004EF1D8  ESP=0048F188
    CS=0000001B  DS=00000023  ES=00000023  SS=00000023
    Flags=00010206
    
    Stack:
    1 : TakeCmd.dll 00000001:000c2f57
    2 : TakeCmd.dll 00000001:000c0b47
    3 : TakeCmd.dll 00000001:000c2195
    4 : TakeCmd.dll 00000001:0008ec4c
    5 : TakeCmd.dll 00000001:0008e88d
    6 : TakeCmd.dll 00000001:0008e63a
     
  10. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,190
    Likes Received:
    11
    Have you considered changing to in-process
    pipes? I.e. use the |! syntax. That may "fix" your
    issue. Or possibly using command grouping to insure your redirection
    is being applied to the right process.

    -Scott




    Code:
    do while "%string"
    EQ ""
    iff %reg eq 3 then
    set string=%@execstr[d:\uty\whois.exe
    -h %[reg%reg] "n + %ip" | d:\ttk\grep ountry.* 2> NUL]
    else
    set string=%@execstr[.\whois.exe
    -h %[reg%reg] %ip | .\grep ountry.* 2> NUL]
    if "%string" eq "" delay
    30
    enddo
    I thought I'd make a little "kit"
    for reproducing this with the data files and two externals all in one place.
    But when I change the paths to WHOIS and GREP (above) to ".\",
    it won't crash. Also, if I remove "2> NUL", it won't crash.
    I said before, when it crashes, it has already been through a bigger loop
    a few times; typically, I'll see:

    Code:
    5491 112.65.165.132 CN
    5492 23.19.63.87 US
    5493 crash
    Just now I crashed it and dismissed the
    message. It crashed a few more times (dismissed) and eventually disappeared,
    leaving this GPF file. I'm still not sure the GPF file describes the original
    crash because, as I said, after the first crash (at 0x004067C4 in TCC)
    TCC is somehow handicapped. No messages (nor the GPF file) give the PID
    so I don't even know which TCC (BTM interpreter or secondary) is crashing.

    Code:
    TCC 13.00.26
    Module=d:\tc13\TakeCmd.dll
    Address=100C3F57
    Exception=C00000FD
    EAX=00452000 EBX=00000000 ECX=0044F18C EDX=004EF1E8
    ESI=0048F1A4 EDI=00000000 EBP=004EF1D8 ESP=0048F188
    CS=0000001B DS=00000023 ES=00000023 SS=00000023
    Flags=00010206

    Stack:
    1 : TakeCmd.dll 00000001:000c2f57
    2 : TakeCmd.dll 00000001:000c0b47
    3 : TakeCmd.dll 00000001:000c2195
    4 : TakeCmd.dll 00000001:0008ec4c
    5 : TakeCmd.dll 00000001:0008e88d
    6 : TakeCmd.dll 00000001:0008e63a
     
  11. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    I want to figure out what's going wrong.

    On Wed, 12 Oct 2011 11:25:22 -0400, samintz <> wrote:

    |Have you considered changing to in-process
    |pipes? I.e. use the |! syntax. That may "fix" your
    |issue. Or possibly using command grouping to insure your redirection
    |is being applied to the right process.
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    Getting closer ...

    I have this line in TCSTART:

    Code:
    SET _TCSTART=%_batchname
    When I comment it I can no longer reproduce the crash.

    Why would that line cause a crash (sometimes)? The crash usually happens the second or third time through a bigger loop containing this loop, where the crash occurs:

    Code:
        unset /q string
        do while "%string" EQ ""
            iff %reg eq 3 then
                set string=%@execstr[d:\uty\whois.exe -h %[reg%reg] "n + %ip" | d:\ttk\grep ountry.* 2> NUL]
            else
                set string=%@execstr[d:\uty\whois.exe -h %[reg%reg] %ip | d:\ttk\grep ountry.* 2> NUL]
            if "%string" eq "" delay 30
        enddo
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    I can't imagine *why* you'd be doing that, but I doubt that it's directly involved. (Unless you're doing something subsequently with %_tcstart?) This sounds more like a timing issue.
     
  14. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    On Wed, 12 Oct 2011 18:27:10 -0400, rconn <> wrote:

    |---Quote (Originally by vefatica)---
    |Getting closer ...
    |
    |I have this line in TCSTART:
    |
    |
    |Code:
    |---------
    |SET _TCSTART=%_batchname
    |---------
    |
    |When I comment it I can no longer reproduce the crash.
    |---End Quote---
    |
    |I can't imagine *why* you'd be doing that, but I doubt that it's directly involved. (Unless you're doing something subsequently with %_tcstart?) This sounds more like a timing issue.

    That's leftover from when there was no _TCSTART variable.

    I get a crash with that as the only line in TCSTART. Normally there's also

    Code:
    IF %_PIPE == 1 ( CURSOR OFF & QUIT )
    IF %_TRANSIENT == 1 QUIT
    And if **INSTEAD** (of the SET line) I use the line

    Code:
    ECHOS %_BATCHNAME
    then there's no crash, but the batch file doesn't run correctly; it terminates
    right after the routine which would have caused the crash. Here's it's correct
    output followed by the output when "ECHO %_BATCHNAME" is in TCSTART. TCC12 does
    the same thing. Apparently, the outer DO loop (on lines from a file) is screwed
    up because before exiting prematurely, it re-processes the same line from the
    file.

    Code:
    e:\users\vefatica\desktop\iptest> whois.btm
    5491    112.65.165.132  CN
    5492    23.19.63.87     US
    5493    50.57.132.242   US
    5494    83.102.154.134  RU
    5495    219.146.225.147 CN
    5496    219.146.225.147 CN
    5497    219.146.225.147 CN
    5498    219.146.225.147 CN
    5499    211.147.211.16  CN
    5500    62.149.227.67   IT
    5501    219.146.225.147 CN
    5502    62.149.227.67   IT
    
    e:\users\vefatica\desktop\iptest> whois.btm
    5491    112.65.165.132  D:\TC13\TCSTART.BTMCN
    5492    23.19.63.87     D:\TC13\TCSTART.BTMUS
    5493    50.57.132.242   D:\TC13\TCSTART.BTMUS
    5494    50.57.132.242   D:\TC13\TCSTART.BTMUS
    e:\users\vefatica\desktop\iptest>
    It also misbehaves similarly if instead I "ECHO %_ININAME" or "ECHO %_ROWS"
    (perhaps any internal var) but not if I "ECHO %USERNAME" (an envvar).

    And after all that messing around, if I go back to "SET _TCSTART=%_BATCHNAME" in
    TCSTART, it goes back to crashing.
     
  15. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    And it has something to do with the length of the command/variable used in TCSTART ... repeatably, but without apparent rhyme or reason.

    I put "SET var=%_BATCHNAME" in TCSTART. In place of "var" I used names of different lengths, each length 5 times. For each length the crash happened (repeatedly) on the same iteration through the main loop; but which iteration that was varied with the length. Here are some variable name length / crash iteration pairs (the test only goes for 12 iterations).

    variable name length / crash iteration
    8 / 3
    6 / 11
    4 / 5
    2 / 4
    1 / no crash

    As goofy as it seems, I repeated each of those 5 (or more) times with the same result.
     

Share This Page