Repeated crashing!

vefatica · 2011-10-03

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.

rconn · 2011-10-04

> Right now I've got TCC v13 stuck in a crashing loop.

I can't do anything without the tcc.gpf file.

vefatica · 2011-10-04

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

vefatica · 2011-10-04

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

rconn · 2011-10-04

> A TCC.GPF was not produced. I'll keep my eyes open.

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.

rconn · 2011-10-04

> I looked on the wrong computer. There is a GPF file (last night, 23:50),
> but it may not correspond to the original incident.

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.

vefatica · 2011-10-04

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).

vefatica · 2011-10-12

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).

vefatica · 2011-10-12

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

samintz · 2011-10-12

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

vefatica · 2011-10-12

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.

vefatica · 2011-10-12

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

rconn · 2011-10-12

vefatica said:
Getting closer ...

I have this line in TCSTART:

Code:

SET _TCSTART=%_batchname

When I comment it I can no longer reproduce the crash.

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.

vefatica · 2011-10-12

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.

vefatica · 2011-10-12

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.

Search

Welcome!

Repeated crashing!

vefatica

rconn

Administrator

vefatica

vefatica

rconn

Administrator

rconn

Administrator

vefatica

vefatica

vefatica

samintz

Scott Mintz

vefatica

vefatica

rconn

Administrator

vefatica

vefatica