Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

BDEBUGGER observations

Jul
81
0
WinXP SP3, v12.0.23

- On both PCs where I installed v12.0.23, the debugger failed to display its window the first time I launched it. It has worked fine ever since.

- Breakpoints below a START command are lost after the START command is done. A "run to breakpoint" request will not respond to a breakpoint on the ECHO line below it
Code:
START /w /pgm "C:\foo\bar.exe" arguments
ECHO The debugger should stop here
--
Peter
 
> - On both PCs where I installed v12.0.23, the debugger failed to
> display its window the first time I launched it. It has worked fine
> ever since.

Not reproducible here. How are you starting the debugger? (There are
several possible ways.)


> - Breakpoints below a START command are lost after the START command is
> done. A "run to breakpoint" request will not respond to a breakpoint
> on the ECHO line below it
>
> Code:
> ---------
> START /w /pgm "C:\foo\bar.exe" arguments
> ECHO The debugger should stop here
> ---------

Fixed in build 25. (It didn't have anything to do with START; the "run to
breakpoint" was just stopping one line too soon.)

Rex Conn
JP Software
 
> Code:
> ---------
> START /w /pgm "C:\foo\bar.exe" arguments
> ECHO The debugger should stop here
> ---------
(It didn't have anything to do with START; the "run to
breakpoint" was just stopping one line too soon.)

I'm now on build 24. I changed the test batch to
-----
START /w /pgm "C:\foo\bar.exe" arguments
ECHO 1
ECHO 2
ECHO 3
ECHO 4
ECHO 5
QUIT
-----
With a single breakpoint on the "ECHO 1" line above, a "run to breakpoint" request will execute all 5 ECHO commands without stopping. The highlighted line will be over the QUIT command.

As for the window not appearing, It recurred just now. I started typing "tasklist /l" in a new TCC console window, the "t" stayed on the command line, but the "a" disappeared, and the "s" indented the first line of the batch file in the now-opened debugger window. Could the "a" have been an admissible response to a hidden query window? "a" for "all" or "a" for "abort"? I invoked the debugger again, voilà the window appeared immediately.

Something is fishy here, I think I should reinstall.
--
Peter
 
> ---End Quote---
> I'm now on build 24. I changed the test batch to
> -----
> START /w /pgm "C:\foo\bar.exe" arguments
> ECHO 1
> ECHO 2
> ECHO 3
> ECHO 4
> ECHO 5
> QUIT
> -----
> With a single breakpoint on the "ECHO 1" line above, a "run to
> breakpoint" request will execute all 5 ECHO commands without stopping.
> The highlighted line will be over the QUIT command.

Same issue as before; the breakpoint is being reported on the wrong line
(the "start" line, which is also the current line), so it will not stop.

As I said, it's fixed in build 25. (Which should be uploaded in another day
or two.)


> As for the window not appearing, It recurred just now. I started
> typing "tasklist /l" in a new TCC console window, the "t" stayed on the
> command line, but the "a" disappeared, and the "s" indented the first
> line of the batch file in the now-opened debugger window. Could the
> "a" have been an admissible response to a hidden query window? "a" for
> "all" or "a" for "abort"? I invoked the debugger again, voilà the
> window appeared immediately.

You didn't respond to my previous query -- *how* are you invoking the
debugger?

Rex Conn
JP Software
 
Same issue as before; the breakpoint is being reported on the wrong line
(the "start" line, which is also the current line), so it will not stop.

As I said, it's fixed in build 25. (Which should be uploaded in another day
or two.)
You didn't respond to my previous query -- *how* are you invoking the
debugger?

Apologies, I got sidetracked replying and didn't finish what I started. I always call it from a TCC command line, like BDEBUGGER {file name}. Usually the target btm file is in the current directory, now and again the argument has to be a compete path. I don't use TCMD very much.

I installed v12.0.24 for the first time on 2 other PCs. With TCC being the only running application, I typed "BDEBUGGER test" and waited. It took almost exactly 30 seconds after hitting OK on the registration window for the IDE window to display. In 3 or 4 subsequent invocations the window popped up immediately. It behaved the same way on both PCs. This should help, I found a GPF file in the TCC directory on both PCs.
PC # 1:
TCC 12,00,24
Module=C:\4nt\IDE.EXE
Address=00409656
Exception=C0000005
EAX=0112E83C EBX=00409630 ECX=00000001 EDX=00734AF8
ESI=03DF0878 EDI=03DF0878 EBP=0112E794 ESP=0112E780
CS=0000001B DS=00000023 ES=00000023 SS=00000023
Flags=00010202

Stack:
1 : IDE.EXE 0001:00008656
2 : IDE.EXE 0001:001324db
3 : IDE.EXE 0001:0012da0c
4 : IDE.EXE 0001:00130952
5 : IDE.EXE 0001:001309e1
6 : USER32.dll 0001:00007734
7 : USER32.dll 0001:00007816
8 : USER32.dll 0001:00017ea0

The GPF file from PC # 2 differs only on these 2 lines:
EAX=0112ECEC EBX=00409630 ECX=00000001 EDX=00734AF8
ESI=03DC6BF0 EDI=03DC6BF0 EBP=0112EC44 ESP=0112EC30
--
Peter
 

Similar threads

Back
Top