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

[marc_256]

Hi,

Is it wrong to say that a debugger is a tool to HELP the programmer find,
- syntax errors
- memory problems
- give warnings
- give error messages
- ...

And NOT to lose more than a week, hard work to find (myself) the problem with my source code ?
I restarted from scratch,
tested all the separated parts, they all work perfect.
No problems at all ...

Only when I assemble all the parts together nothing compiles ... ??

The compiler crashes without any massage at all ??
CRASH and quit the PB compiler ??

Marc

[Saki]

As said before, there is a suspicion that strings in the procedure parameters overwrite your memory.
The evil must be found at the root.
The moment the overwriting occurs, the debugger does not do anything about it.

[mk-soft]

I have to stop here ...

Crash of the compiler or the debugger. If the application is started, it is not the compiler. The debugger can crash if there are errors in memory management (pointers, etc) or if the API is not called correctly.
It can also be due to inline ASM code if wrong registers are used.

I searched for a long time in the PB-IDE under Linux for the crash, because the error was that the debugger did not output any more errors after an invalid call of an API

[Bitblazer]

Is this a rant or a request for help? I honestly can't say

In case of a request for help - have you used a tool like DTRACE on the IDE to find what exactly happens?

[marc_256]

Hello,
This is the reaction on 2 previous posts without any result ...
viewtopic.php?f=4&t=75865
and
viewtopic.php?f=13&t=75874

Hi mk-soft,

I'm using only 2D stuff, on screen mode and not one single PB gadged.
PC WIN10-Home / PB 5.72 LTS x64
after this message PB is closing without any message ...


Hi Bitblazer,

This is like a frustrating call for help,
I had a lot of reactions, but not one who is solving my problem.
see, posts above.

This is my work, a ARDUINO GUI debugger...




Thanks,
marc

[BarryG]

This is like a frustrating call for help,
I had a lot of reactions, but not one who is solving my problem.

I feel for you. I had a large app that would exit randomly and I had no way of knowing what it was. Eventually I found it by using OnError lines turned on in the Compiler, and the ErrorHandler() procedure from the manual:

https://www.purebasic.com/documentation ... or.pb.html

Give it a try. It helped me pinpoint that I was referencing an unused menu item in my app, leading to the app crashing silently (no error message).

[Marc56us]

Does the error also occur with other versions of PB ?
On 32 bits version of PB ?
With command-line compiler version ?
With external debbuger ?
On another PC ?
Also look at the Windows logs at the time the error occurred.
(Win + R : eventvwr)

[Bitblazer]

Hello Marc,
those Screenshots look very nice

I would make a copy of your complete sources and use the commandline compiler to compile it. Then reduce your source step by step till the commandline compiler does not crash anymore. That should point you closer to the compiler problem.

If you suspect a bug in the compiler, you could use a program like WinAPIOverride with the commandline compiler (${purebasic install path}/compilers/pbcompiler.exe).

It is not a quick method, but it will get you to a stripped source so you can make a bug report including a source example. Some kind of versioning editor would probably help.

As long as you don't give up from the overwhelming amount of information or work this produces, you WILL track the compiler bug down

[Denis]

Hi marc_256,

not easy to answer.

Hi,
The compiler crashes without any massage at all ??
CRASH and quit the PB compiler ??

Marc

After the crash, was the exe file still created (big file because of the code added for debugging)?
If so, did you run it ?
If not created, the problem is for Fred (send him all the code).

If the exe file is created, put at the beginning of all procedures this :

Code: Select all

"debug Procedure  " + #PB_Compiler_Procedure

to try to isolate the last procedure called and then investigate it or using Stopping point and try to compile (run it step by step)

I remember a crash I had with an MS structure badly declared by PB . In such crash, often the return procedure code is overwritten and the app crash.

For example, structure LVGROUP is badly declared by PB (most people here are using a MS version > VISTA

Code: Select all

PB: 64 bit
Structure LVGROUP
  cbSize.l
  mask.l
  *pszHeader
  cchHeader.l
  *pszFooter
  cchFooter.l
  iGroupId.l
  stateMask.l
  state.l
  uAlign.l
EndStructure

Code: Select all

MS:
typedef struct tagLVGROUP
{
    UINT    cbSize;
    UINT    mask;
    LPWSTR  pszHeader;
    int     cchHeader;

    LPWSTR  pszFooter;
    int     cchFooter;

    int     iGroupId;

    UINT    stateMask;
    UINT    state;
    UINT    uAlign;
#if (NTDDI_VERSION >= NTDDI_VISTA) 
    LPWSTR  pszSubtitle;
    UINT    cchSubtitle;
    LPWSTR  pszTask;
    UINT    cchTask;
    LPWSTR  pszDescriptionTop;
    UINT    cchDescriptionTop;
    LPWSTR  pszDescriptionBottom;
    UINT    cchDescriptionBottom;
    int     iTitleImage;
    int     iExtendedImage;
    int     iFirstItem;         // Read only
    UINT    cItems;             // Read only
    LPWSTR  pszSubsetTitle;     // NULL if group is not subset
    UINT    cchSubsetTitle;

If you use a lot of structures, it's better to use AllocateStructure instead of using global or local var.
May be, it could be a stack crash (overwriting ? --> compiler have to report it if purifier is activated), don't really know.

I always declare string with #Empty$

Code: Select all

MyString = #Empty$

[marc_256]

Hi everyone,

First at all, thanks for the info here.
This morning I started from scratch again,
not by removing part by part (what I did before, without result), but by restarting from nothing.

- EnableExplicit
- create a window,
- open screen
- and adding part by part of my old program
- ...

And till now, I'm about 95000 lines (+- half where I was before) and all works well, with the debugger on ...
I gone try to put some massages in the beginning of every structure / procedure / ...
So I can follow the debugger/compiler process.

Did not sleep this night, so ...
It becomes a little blurry on the screen (and in my head )

Thanks,
marc

[Josh]

I gone try to put some massages in the beginning of every structure / procedure / ...
So I can follow the debugger/compiler process.

How can I imagine that? Do you mean debugger messages? But that won't help you much to follow the compilation process.

[Saki]

If the error causing location in the code cannot be located,
the error will return exactly as it was.

[Bitblazer]

I gone try to put some massages in the beginning of every structure / procedure / ...
So I can follow the debugger/compiler process.

How can I imagine that? Do you mean debugger messages? But that won't help you much to follow the compilation process.

plenty of #compilerwarning commands could do that

If the problem is not found in the code, the crash will come back.
And it will be just as difficult to locate as before.

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?

[Saki]

As I already wrote, I had to deal with these problems more often.
You will only find it if you can locate the exact place based on the assumed cause and change the code there so that the overwriting does not happen anymore.
It only works if the suspected cause of the error is systematically eliminated.
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.
It gets really stupid if it crashes without debugger and runs perfectly with debugger.
You often only notice this when you are finished.
But it was always a string.

How does it look like now ?
Very different.
The immediate crash after starting the executable is the easiest to find.
Then you are very close to it, because you are compiling all the time.
It gets worse if it happens after the debugger is off.
It gets very worse if it happens only once every few hours or days.

[mk-soft]

I still don't know if the compiler crashes or only after creating the execute of the debugger.

Ever worked with Debugger Breakpoint.
Just set several breakpoints and see when it doesn't work anymore.