Page 2 of 2

Re: Is it wrong to say that a debugger is a tool to HELP me

Posted: Wed Sep 02, 2020 5:51 am
by Denis
Saki wrote:A
In fact, a small workaround is required.
For me it was always strings in procedure parameters.
I was able to locate the error once because I noticed that a Val(string) call overwrote another variable.
Since this did not cause a crash, the cause of the overwriting was easy to identify.
A rectangle was drawn in the wrong size.
When you see this, at first you are completely flabbergasted.
Since both variables were in the procedure header, this was quite simple.
In other cases it was an almost endless search.
@Saki
In your opinion, should we only use our own pointers to pass strings as procedure parameters ?
Did you take a look to asm generated code ?

Bitblazer wrote: Indeed. It would make sense to simply adjust the compilation process so it keeps a copy of the last sources in a archive with the added timestamp. That way you could simply manually "rollback" to the last working version and at least track the compiler bug down. It is an easy to add feature for the IDE. Maybe an idea for 5.8? ;)
@Bitblazer
I agree, this is a really great idea!

@mk-soft
mk-soft wrote:I still don't know if the compiler crashes or only after creating the execute of the debugger.
Yes, this is the first thing to look at.

crash :
It would be interesting to have a special place in the forum, many coders have had crash problems and different approaches exist (locked post or something like that, to avoid having hundreds of posts, some ideas could be grouped together)
Locating crash causes is very time consuming and not easy to do...

Re: Is it wrong to say that a debugger is a tool to HELP me

Posted: Wed Sep 02, 2020 8:58 am
by Saki
Hi, Joris,
I have hardly dealt with the assembler yet,
I simply do not have the time.

It seems that this problem rarely occurs, but it is quite tangible and real.
If it occurs you will feel sick at first,
there may already be several hundred hours or more of work in it
and you know it can get really bad.
With stopping points I usually could not fix these things.
It is also often loops that are worked off hundreds or thousands of times.
If you do not find the error, the value of the program is zero.
Many codes are similar in structure and function.
I have made a habit of not using functions in procedure headers
like Val() or any string calculations.
Moving the strings within the parameter sequence did not help.
It has already occurred with codes with a few hundred lines, but more often with very large codes,
The attempt to reduce the code was not very helpful, because there are too many dependencies
and then the codes no longer did what they were supposed to do.
It's like when something rattles in your car, you take it apart into its component parts,
but then it just doesn't drive anymore.
With very complex codes this is extremely difficult and extremely annoying.
Once I had located these errors, I tried to extract them.
You can forget that, if the functions are extracted from the code they work without errors.
It was never possible to say that if you do this or that exactly like this you can trigger the bug.
Passing the strings as pointers solves the problem, but you can do that internally,
primarily rather unthinkable.

In the meantime I have my own approaches to this problem and have been spared for a long time,
but that does not primarily solve this problem.

Re: Is it wrong to say that a debugger is a tool to HELP me

Posted: Wed Sep 02, 2020 12:46 pm
by skywalk
Yes, a CRASH topic would be helpful.
My debugger assisted crashes are rare, and have been easily deterministic.
The few that are much harder are thread based or map() indices generated by a Macro.
As you know, Macro's are not "visible" when stepping through the debugger. This is a pain in the a$$.
For this reason, I never use WITH..ENDWITH.

My threading errors are deadlocks where the Main event loop misses or never receives a SignalSemaphore to the working thread.
This happens randomly when stepping through the worker thread and into the GUI main thread.

Re: Is it wrong to say that a debugger is a tool to HELP me

Posted: Wed Sep 02, 2020 12:56 pm
by Saki
Hi,
in all the codes I had the problem with were not threads.

Everything else is always as simple as possible, without any tricks.
Few macros, structures, maps or lists.
Because my codes usually do quite complicated things,
it is important to me to code as transparent as possible,
otherwise I can hardly debug or change them after a long time.

It's not so much about bugs on my part,
but more about PB bugs like Linux,
as sample the subsystem qt.

Re: Is it wrong to say that a debugger is a tool to HELP me

Posted: Wed Sep 02, 2020 1:44 pm
by skywalk
I don't understand avoiding threads?
They are mandatory if you have a GUI and any action that takes more than a few seconds to complete.

I agree the Linux IDE is limited.
I hoped PureBasic and SpiderBasic would adopt a few standard cross platform IDE's(lexers, plug-ins, etc.) and focus on core language development. Open sourcing the IDE has led to community improvements, but not on the cross platform scale everyone demands.