when thinBasic crashes...

[ReneMiner]

sometimes- especially in larger project- it's very hard to find out what made thinBasic crash.

It's nice to have a debugger - but to use is cumbersome in larger scripts since all goes very slow and the crashes sometimes do not happen in debug-mode.

The current #Profile-directive gave me the idea to have another "switch" like that, so thinBasic will document all performed steps during script-execution.

It could be as simple like:

thinBasic enters a script-function and writes the function-name at the end of a txt-file.
Always if a function gets encountered.

The myscript.tBasic.FunctionLog.txt could look as this:


tUI._Create
tColor._Create
tMouse._Create
tKeyboard._Create
tDesktop._Create
tDesktop.NewInfo
TBMain
tWindow.Open
tWindow.NewInfo
tKeyboard.Init
tFont.Install
tFont.Init
tFont.Install
tFont.Init
...


the log can be overwritten the next time the script runs and it can be saved next to the script.
If thinBasic crashes then we would have some more clue where to check for the reason...

[ReneMiner]

I have another idea i can do myself to debug.
Maybe someone has a use for it.




Uses "Console"
Alias PrintL As Debug


now can use "Debug" in each and every function instead of PrintL.
Later just have to change that 2 lines:



' Uses "Console"
Alias Rem As Debug

and now don't have to go through all functions and comment all PrintL-statements...

[ErosOlmi]

Well,

dealing with GPF (General Protection Failure) is quite complex.
Most of the time it is just a pointer to a memory area not allocated or previously allocated and later de-allocated but still referenced by the code.

If problem is inside the interpreter, it can be complex but sooner or later I'm able to get it if people using thinBasic report here the problem.
If problem is inside a script, it is hard to me to help.

What I can do is:

improve thinDebug speed in order it could be more easy to debug.
improve thinDebug breakpoints
improve thinDebug debug stepping in order not just to have Step-In but also Step-Out (just execute next line without entering sub-functions)
improve thinDebug to have a more usable live debugging
improve thinDebug in order to have GPF intercept instead of leaving it to the operating system


I will see what I can do.

Ciao
Eros

[ErosOlmi]

Hi René,

I had some spare time to have a look at thinBasic Debugger and found that I left some "Sleep 1" inside the code instead of a more correct DoEvents plus some other conceptual errors.

Attached to this post please find new thinBasic_Trace.dll you can put into \thinbasic\Lib\ directory replacing your current one
You need thinBasic 1.9.16.9 installed!!!!

Using F6 for live debugging will be MUCH MUCH more quick. And you will be able to press F8 while live debugging is taking place to stop debugger at current line.
Also thinDebugg window response will be much better.

I will work on debugger more during holidays.

Let me know if this version is better also for you.

Ciao
Eros

[ReneMiner]

F6- live debug is lot's faster then the old way where i had to press a key after each step. Much better for a lot of situations.

But in case thinICE, it still needs 15 minutes to go through startup, and then there's no input that gets received in TBGL-window.

( If i stop the debugger using the red x-symbol thinBasic crashes )

I saw it would be a huge amount of data if thinBasic would create a list of all functions, also saving the functions name after each step would slow script-execution very much down.
I have another idea.

Turn


#Profile On

in your mind...

If a function gets encountered store the current stack-list (as shown in right area of debugger)

for example



[1] Global
[2] TBMain
[3] AllControlsCreate
[4] tUi.AddControl
...

to some seperate process that gets started from thinAir. (Is that doable at all?)

Currently if thinBasic crashes then profiler does not show up.

If thinBasic returns to thinAir after script-execution and profiler starts up then profiler could return some exit-code or stop the function-log-storing-process.

If thinAir does not receive an exit-code from profiler or log-process still runs if #Profile On then thinAir would "know" that thinBasic crashed...
In that case it would be simple to get the function-stack from the stack-log-process, stop it and present its result to the user or save an error-report...

[ErosOlmi]

Regarding debug big sources you need to set some break points before starting debug.
right click on the line you want debug to stop then insert a break
make break point in some strategical places and then start debug and press F5
debugger will stop at your break points