FB debugger : 3.02 32/64 BIT WDS/LNX..... (2023/07/05)

User projects written in or related to FreeBASIC.
Post Reply
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by VANYA »

SARG wrote: About gdb, it doesn't update a tree with all the variables at each step. It displays values only when you send a request.
It would be nice if such an option was in fbdebugger. When large and demanding programs, then disable all updates of values ​​in the GUI.
SARG wrote:There are two ways :
- Drag and drop a bas file directly on the source code window or start fbdebugger with a bas file name in command line. The compilation starts automatically.
- In tools menu 'Quick edit' / F9 option allows a light editing of the current source code (readonly property is removed temporary) then you can also start a compilation directly 'Compil (-g)...' / F11.
Path for fbc needs to be defined in settings.
SARG wrote:There is already a backtrace feature in contextual menu of thread tab. You can use RUN until the debuggee crashes and after use backtrace option.
Thank you, I did not know. I have not updated the debugger for a long time, I used the old version.
SARG
Posts: 1755
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by SARG »

VANYA wrote:It would be nice if such an option was in fbdebugger. When large and demanding programs, then disable all updates of values ​​in the GUI.
????? This option has been just added so I don't understand :-) Reread my post.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by VANYA »

SARG wrote:
VANYA wrote:It would be nice if such an option was in fbdebugger. When large and demanding programs, then disable all updates of values ​​in the GUI.
????? This option has been just added so I don't understand :-) Reread my post.
SARG! We are probably talking about different things and cannot understand each other. I will try again to explain:

1) I am uploading EXE to FbDebugger, click the button Update On and click button Run Stopped by Halt
2) Load file in the EXE (editor) 500-1000 rows.

Further, in the Proc/Var tab, there is a long update of information:

Image

The editor is "hanging" at this time. When the update in this tab ends and I start doing something in the editor, the update starts again in this tab. I think that displaying information in Proc/Var (TreeView) slows down the whole debugger when debugging big programs.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by VANYA »

I apologize to the members of the forum, but I will ask in my own language, especially since Xusinboy understands it. There are no private messages on the forum unfortunately ...

@Xusinboy!
Может ты сможешь мне сможешь объяснить? Ты же вроде говоришь, что все работает. У меня что с включенной кнопкой , что с выключенной кнопкой - результат один и тот же: обновление во вкладке Proc/Var происходит. В итоге , отлаживать свой редактор (с загруженным туда исходником) не получается , все жутко тормозит. Меня SARG уверяет , что все сделано , но как я могу не верить своим глазам? Языковый барьер не дает нам друг друга понять. Я верю , что он что-то сделал , но я не понимаю что , и я вижу , что в моем случае это не помогает. Используя GDB , тормозов нет , по крайней мере я нормально могу работать в редакторе. Но GDB часто при вылете программы показывает одни адреса памяти, и зачастую сложно понять где произошел вылет. Вот например вывод GDB после ошибки:
Program received signal SIGSEGV, Segmentation fault.
0x767643f9 in strlen () from C:\Windows\system32\msvcrt.dll

#0 0x768143f9 in strlen () from C:\Windows\system32\msvcrt.dll
#1 0x00476374 in fb_StrAllocTempDescZ@4 ()
#2 0x00000001 in ?? ()
#3 0x00487400 in Lt_4193 ()
#4 0x0012ef2c in ?? ()
#5 0x6abbe522 in iup_scintilla!Scintilla_DirectFunction ()
from D:\Freebasic\iup_fb_editor32\iup_scintilla.dll
Как видишь , информативности мало, но при удаче и некоторой практике , все таки это может помочь. По крайней мере адрес 0x00487400 дал зацепку и я смог найти место ошибки.
Xusinboy Bekchanov
Posts: 782
Joined: Jul 26, 2018 18:28

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by Xusinboy Bekchanov »

VANYA wrote:I apologize to the members of the forum, but I will ask in my own language, especially since Xusinboy understands it. There are no private messages on the forum unfortunately ...

@Xusinboy!
Может ты сможешь мне сможешь объяснить? Ты же вроде говоришь, что все работает. У меня что с включенной кнопкой , что с выключенной кнопкой - результат один и тот же: обновление во вкладке Proc/Var происходит. В итоге , отлаживать свой редактор (с загруженным туда исходником) не получается , все жутко тормозит. Меня SARG уверяет , что все сделано , но как я могу не верить своим глазам? Языковый барьер не дает нам друг друга понять. Я верю , что он что-то сделал , но я не понимаю что , и я вижу , что в моем случае это не помогает.
Russian:
Моя проблема и ваша, это две разные вещи. В моем случае переход на следующую строку (Step by step) очень долго было. В вашей программе нету много переменных, поэтому переход по строке с обновлением/без обновления переменных не имеет значения. Вы можете поставить курсор на IupClose() и использовать кнопку CAUTION FAST Run to cursor. В этом режиме программа останавливается только на точках остановки. В моем программе Run (только без указания курсора) и Run to Cursor работает в режиме Fast Run.

English:
My problem and yours are two different things. In my case, moving to the next line (Step by step) took a very long time. Your program doesn't have a lot of variables, so it doesn't matter whether or not you move across the line with or without updating the variables. You can put the cursor on IupClose() and use the CAUTION FAST Run to cursor button. In this mode, the program only stops at breakpoints. In my program Run (only without specifying the cursor) and Run to Cursor work in Fast Run mode.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by VANYA »

Xusinboy, thanks for the answer! I hope SARG understands what I am talking about and does not think that I am crazy :)
SARG
Posts: 1755
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by SARG »

VANYA wrote: I hope SARG understands what I am talking about and does not think that I am crazy :)
Nobody is crazy. Sometimes things are hard to explain and therefore hard to understand. I have just to reproduce the case for better understanding.

My first thought : RUN doesn't update the values in proc/var until the debugger stops the debuggee (HALT). However new procs are handled (created/deleted) and every line has a breakpoint instruction so running should be/is slow. When using FAST RUN (as suggested by Xusinboy , thank you) there is only a breakpoint on the selected line and ALL is only updated when the line is reached.

For now I have donwloaded the source of the editor and compiled with -g. I'll debug and try to reproduce what you described.
Vanya wrote:There are no private messages on the forum unfortunately ...
You can use discord : https://freebasic.net/forum/viewtopic.php?f=17&t=26784
Xusinboy, Jeff and I are exchanging there, it's easier and faster than through the forum. My alias : SARG.
SARG
Posts: 1755
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by SARG »

IMPORTANT: I'll upload a new version for all the exes : there is a missing comment statement in fbdebugger source so loading of big debuggees is very long and any execution too.

Edit : not very long but a bit longer... Anyway I have to push new exes.
Xusinboy Bekchanov
Posts: 782
Joined: Jul 26, 2018 18:28

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by Xusinboy Bekchanov »

SARG wrote:IMPORTANT: I'll upload a new version for all the exes : there is a missing comment statement in fbdebugger source so loading of big debuggees is very long and any execution too.

Edit : not very long but a bit longer... Anyway I have to push new exes.
Suggestion: in Run mode, stopped by Halt you can not update new procs are handled (created/deleted) in TreeView. When the program is stopped then it is possible to update in TreeView from variables (the variables already have all this data).
Xusinboy Bekchanov
Posts: 782
Joined: Jul 26, 2018 18:28

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by Xusinboy Bekchanov »

VANYA wrote:Используя GDB , тормозов нет , по крайней мере я нормально могу работать в редакторе. Но GDB часто при вылете программы показывает одни адреса памяти, и зачастую сложно понять где произошел вылет. Вот например вывод GDB после ошибки:
Program received signal SIGSEGV, Segmentation fault.
0x767643f9 in strlen () from C:\Windows\system32\msvcrt.dll

#0 0x768143f9 in strlen () from C:\Windows\system32\msvcrt.dll
#1 0x00476374 in fb_StrAllocTempDescZ@4 ()
#2 0x00000001 in ?? ()
#3 0x00487400 in Lt_4193 ()
#4 0x0012ef2c in ?? ()
#5 0x6abbe522 in iup_scintilla!Scintilla_DirectFunction ()
from D:\Freebasic\iup_fb_editor32\iup_scintilla.dll
Как видишь , информативности мало, но при удаче и некоторой практике , все таки это может помочь. По крайней мере адрес 0x00487400 дал зацепку и я смог найти место ошибки.
Russian:
Если использовать Fast Run в FBDebugger, показывает место ошибки? Я сделал свой пример, он показал:
English:
If you use Fast Run in FBDebugger, does it show the error location? I made my example, it showed:

Code: Select all

Type d
	c As String
	
End Type

Type a
	c As String
	g As d Ptr
End Type

Dim b As a Ptr = 0

b->g->c = "fdfdf"

?b->g->c

Sleep
SARG
Posts: 1755
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by SARG »

SARG wrote:IMPORTANT: I'll upload a new version for all the exes : there is a missing comment statement in fbdebugger source so loading of big debuggees is very long and any execution too.
Edit : not very long but a bit longer... Anyway I have to push new exes.
Done : https://users.freebasic-portal.de/sarg/ ... r298_1.zip

@VANYA
I started the editor under fbdebugger. It's working fine (except one thing,see below).
Using RUN every proc call is handled so there is a lot of creation/delete in proc/var tab and procrs tab. In case of loading a big file in the editor obviously the time can be huge. But after it seems acceptable.

What can be done to spare a little of time :
- set update OFF and only ON when you need to see the values
- disable some procs, an option in procrs tab. In this case no breakpoint is used on every line of the proc.
- use fast run

one remark:
You are using timers for updating information, not a good way in my opinion. For example timer_update_statusbar proc is always blinking (create/deleted). I guess another way could be used.

The issue (I 'm not passed through all the features) :
- fdlg_dlg_open_proc freezes the editor, the dialog box is not displayed and fbdebugger can't exit properly, I had to kill the process. For now I don't know what happens.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by VANYA »

Xusinboy wrote:Если использовать Fast Run в FBDebugger, показывает место ошибки?
да конечно.
yes
SARG wrote:Done : https://users.freebasic-portal.de/sarg/ ... r298_1.zip

@VANYA
I started the editor under fbdebugger. It's working fine (except one thing,see below).
Using RUN every proc call is handled so there is a lot of creation/delete in proc/var tab and procrs tab. In case of loading a big file in the editor obviously the time can be huge. But after it seems acceptable.

What can be done to spare a little of time :
- set update OFF and only ON when you need to see the values
- disable some procs, an option in procrs tab. In this case no breakpoint is used on every line of the proc.
- use fast run
Thanks SARG, helped a lot. Now I can debug large programs in FBDEBUGGER.

SARG! I always used Run Stopped by Halt , And rarely used fast run. The only difference between them is that one works up to the exception, and the other up to the required line? Do I understand correctly?

I also want to ask: when I move the mouse (not click) on any record in the treeview, the SHOW \ Expand window pops up. Is that how it should be?
SARG wrote:The issue (I 'm not passed through all the features) :
- fdlg_dlg_open_proc freezes the editor, the dialog box is not displayed and fbdebugger can't exit properly, I had to kill the process. For now I don't know what happens.
By the way, if you load any application with winapi GetOpenFileName, GetSaveFileName into the OLLYDBG debugger, then several exceptions occur when called, and if they are not passed with SHIFT + F9, then any program will crash. Perhaps these functions need to be processed somehow in debuggers.


------------------

And I also forgot to write: If you download the source code to the debugger in UTF-16LE, then it is not displayed.

-----------------

And one more thing :) If you don't give up the idea of writing a debugger for Linux, I advise you to use a pure GTK. Under no circumstances use IUP, I assure you you will learn all the bad words, not only French, but also other languages :) I have already regretted 100 times , that I used this library for my editor. For example IupList+IupSplit (placed one inside the other) - hemorrhoids are provided. In the debugger, speed is critical, and the IUP is entirely built on lines, which is bound to be bad news. However, I must admit that the author of the IUP has made many things very convenient. If there will be problems with GTK, I can tell you what I know.
Last edited by VANYA on Feb 02, 2021 17:33, edited 1 time in total.
SARG
Posts: 1755
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by SARG »

VANYA wrote:Thanks SARG, helped a lot. Now I can debug large programs in FBDEBUGGER.
Nice to read.
VANYA wrote:SARG! I always used Run Stopped by Halt , And rarely used fast run. The only difference between them is that one works up to the exception, and the other up to the required line? Do I understand correctly?
With Run every line has a breakpoint (an asm instruction that triggers a special exception) then it's possible to check things like breakpoints on var, breakpoints with counter, etc. While you don't stop it the debuggee runs and all the trees are updated (except values of variables but their places are reserved).
On the other hand with Fast run there is only one breakpoint for the selected line so all the updates (creation of all the elements) are made when the debuggee reachs the line, so runs really fast. But no check can be done for the breakpoints as with simple Run). And to stop (HALT) the debuggee it's necessary to reinsert one breakpoint for each line.
Hope it's clear :-)
VANYA wrote:I also want to ask: when I move the mouse (not click) on any record in the treeview, the SHOW \ Expand window pops up. Is that how it should be?
You can disable this feature in settings uncheck 'shw/exp when hovering'.
VANYA wrote:By the way, if you load any application with winapi GetOpenFileName, GetSaveFileName into the OLLYDBG debugger, then several exceptions occur when called, and if they are not passed with SHIFT + F9, then any program will crash. Perhaps these functions need to be processed somehow in debuggers.
I'll have a look. I'm using x64dbg / x32dbg. They are the up to date versions of Ollydbg.
VANYA wrote:And I also forgot to write: If you download the source code to the debugger in UTF-16LE, then it is not displayed.
Ok. To be studied.
VANYA wrote:And one more thing :) If you don't give up the idea of writing a debugger for Linux, I advise you to use a pure GTK. Under no circumstances use IUP, I assure you you will learn all the bad words, not only French, but also other languages :) I have already regretted 100 times , that I used this library for my editor. For example IupList+IupSplit - hemorrhoids are provided. If there will be problems with GTK, I can tell you what I know.
Thank you for the advice. It made me laugh a lot :-) 4 years ago I began to use IUP for Fbdebugger on linux but I tested only on Windows......
I just start to test the GUI with Window9. I guess if needed I'll 'hack' easily the Windows part but for Linux/GTK any help will be welcome. Also I think use Scintilla (tested on Windows) but I don't know if it will be easy on linux.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by VANYA »

You can disable this feature in settings uncheck 'shw/exp when hovering'.
Ooh, I'll turn it off of course.
GUI with Window9
I don't think this is a good idea. I already wrote in the last post (edited after your post, but too late). Speed ​​is very important to the debugger, and my library will still eat up time on built-in event mechanisms. Window9 is suitable for programs that are not so speed critical. In the case of IUP, almost any command there is sending a string to a function (which means the time spent on parsing strings). But if you still choose window9, then for my part I will try to help everyone I can.
And thanks for the help with fbDebugger

-------------------
Also I think use Scintilla
Not a problem, Scintilla is easy to connect to both GTK and window9.

By the way, if you don't know where to start at all, here are a couple of parts on PTRACE (I did the translation into Russian, but using freebasic):

1 part , Part 2

Original, but for C language and for 32-bit here
SARG
Posts: 1755
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.98.1 32/64 BIT ..... (2021/01/30)

Post by SARG »

VANYA wrote:GUI with Window9
I don't think this is a good idea. I already wrote in the last post (edited after your post, but too late). Speed ​​is very important to the debugger, and my library will still eat up time on built-in event mechanisms. Window9 is suitable for programs that are not so speed critical. In the case of IUP, almost any command there is sending a string to a function (which means the time spent on parsing strings). But if you still choose window9, then for my part I will try to help everyone I can.
About speed of the GUI this is not very important : modern CPUs are so fast. The trick is to avoid useless update like it's now done with update on/off. Other updates could be also avoid until the user wants them.
VANYA wrote:By the way, if you don't know where to start at all, here are a couple of parts on PTRACE (I did the translation into Russian, but using freebasic):

1 part , Part 2
Original, but for C language and for 32-bit here
I have already a lot of documentation for debugging on linux, even some stuff coded by myself. Anyway thanks, more information doesn't hurt.
Feel free to come on Discord. We'll exchange in an efficient way.
Post Reply