Strange debugger behaviour

[cct]

I am revisiting some code I wrote in 2020 - just simple FreePascal, but I wrote it in lazarus.

I have been getting some strange runtime behaviour, so tried to run in the debugger, which I previously did fine. Initially I was just getting a cmd.exe window, just at a prompt, but retying, I either get into an assembler windows (which is of no use to me!) or sometimes I get the error:

Execution stopped with exit-code -1073741510 ($C000013A)

What am I doing wrong?

This is Lazarus 3.4, FPC 3.2.2 on Win 11

Chris

[Martin_fr]

Google says the app was interrupted with Ctrl-C or equivalent.

First of all you can try from the "run" menu: "Reset debugger". That makes sure you get a clean start, in case any stuff of the last debug session still had an impact (it never should, but ...)

Next, what debugger backend do you use? Menu: Tools > Options => then: Debugger > Backend => at the very top, in the toolbar: does it say ..."fpdebug" or ..."gdb" ?
If it isn't fpdebug, then you should be able to change it (the text at the very top is a drop down).
Though you can also try gdb, if the issue occurs with fpdebug.


Make sure Windows defender is not killing your project when it starts.

For all else, probably need more info.

[cct]

Thanks. I have reset debugger, and am set to use fpdebug - I did have a browse of the settings and help files.

I get the error above if I run - I get the cmd.exe window, and if I either type exit, or close the window.

If I set a breakpoint after the program start, I just go into the assembler window, and stepping  through I get the error show in the attachment.

If I run it from powershell, it seems to run, but sometimes doesn't perform. I have set the parameters up.

A bit lost now

Chris

[Martin_fr]

OK, so an Access violation. Usually that means some pointer (address of some data/object) was not initialized correctly.
It happens in the kernel, may mean that you called some Windows API with incorrect settings.

If it isn't initialized, then depending on many factors, it may sometimes "not cause a noticeable error". But that is just good luck.

Can you open menu: View > Debug Windows > Call Stack

There should be a list of "callers" => hopefully somewhere in that list is some of your code.
You can the double click to open that code in the editor.

Check, what it calls and what params it passes on.
- values can be seen in the stack window
- or in the stack window select the line with your code, and click the "green arrow" (which has a hint "current") // or from context menu select "current". => your code will then be marked by an arrow in the stack window => then you can hover over variables to see their content.


(Sorry if too verbose / don't know how much of the debugger you know)

[cct]

It just seems to be in bits of the RTL, when it fails it shows ntdll:RtlNtdllName+17200  against index 0 and just an address against index 2

Seems funny to throw an exception in debug, but not when running outside the debugger - whether compiled with debug, or without,

I am not doing anything odd - just using:

uses
    {$IFDEF UNIX}{$IFDEF UseCThreads}
        cthreads,
    {$ENDIF}    {$ENDIF}
    Classes,
    SysUtils,
    CustApp,
    paradoxds,                                  // Package lazparadoxpkg
    db,
    sqlite3conn,
    sqldb
    ;

[Martin_fr]

When running outside the debugger it is possible something catches the exception and ignores it. You said it sometimes was slow, well that could be slowing it down.
You can continue to run in the debugger, and see if it continues.

You can try setting the backend to gdb. Maybe it shows more of the stack. FpDebug sometimes stops the stack early. Though, if you get into the RTL then gdb probably wont get more.
Also, if there was any bug in FpDebug, and indeed that bug was causing your issues, then that bug should not happen under gdb.
If you use gdb, you may want to change "debug info type" to "Dwarf 2 with sets" in the "project options" (menu: project > project options)



Do you have any breakpoints set?
Menu: View > Debug Windows > Breakpoints.

It is possible to set breakpoints directly to an address (e.g. in the asm window). If they were set, and the the app changed (or Windows got updated, and the kernel changed), then those addresses become invalid, and can cause havoc.


Other than that, I really can't tell much from the info I have.

I am not aware of FpDebug causing crashes. But then, "I am not aware" doesn't mean it couldn't still be...
=> Other than above mentioned breakpoints.

There is an issue with some versions of fpc, when using GDB => then even some valid breakpoints can cause issues. But I have not seen that under FpDebug. And if you remove all breakpoints then you should be fine.

You could also try with 4.0RC1

Some generic tips:

For testing, compile with different optimization settings.
E.g. Does it happen with "Optimization off" / "Level 0"?

Have you compiled with range checks and all other such checks?

[cct]

I will have a play tomorrow, and report back.

I did set a single breakpoint in the FP source, but it never gets out of the ASM bits. I am unable to continue as I just get the access violation again. I have not experienced any slowdown, but sometimes is reports it is processing, but doesn't update.

The program is reading some Paradox DB files, and writing them into an SQLite3 database

[cct]

No luck using gdb, in fact it initially seemed worse - at one point it got completely stuck. I eventually got out by closing the project.

When I did get it going, it was exactly the same - if I chose run to cursor, I could step through until I got the access violation above.

If I choose run, then I get the empty cmd window, which does nothing. If I close it I get the first error, and all drops out.

Unless I am missing something basic, I am flummoxed!

[Martin_fr]

I don't really have any other ideas either...

Well the console window could be related to how TProcess is starting your project.

Mind, if you did build the IDE itself as console app (the IDE would then have a console window / rather unusual thing to do, but possible), then when running in the debugger the project may share the IDE's console win, rather than having its own.
But in a normal IDE, I am not aware....

If you test with Lazarus 4.0RC1 then you can setup stdout redirection => so you wouldn't need a console and can log at the output in a file.

You can also put a long "sleep" or even "readln"  at the start of your app. Run it from outside the IDE (and assuming it does not crash in startup, but reaches that wait-line), you can then attach the IDE to it (menu run > attach).

None of that explains any of the errors.


I know some proprietary code, and especially gaming related apps will detect if they are debugged, and will intentionally misbehave. But that shouldn't apply to some database drivers or whatever you may use.

As said before, make sure Windows defender isn't acting on your debug session.

I assume your app can run as normal user, no admin privileges needed?

All dll are in folders that are found? Including when run in the debugger (make sure current dir is set, if that is needed to differ from where the exe is).

I'd say check you have a compatible dll => but if not you would get error outside the debugger. Except if you have 2 versions and they get mixed up. or if the errors happen outside the debugger, and are just not noticeable.

[440bx]

One possibility is that there is a function in your code that, under some circumstances, fails to return a value.  That can cause all kinds of problems among them the one you're describing.

As an example see: https://stackoverflow.com/questions/63751668/process-terminated-with-status-1073741510-c-prime-factorization

Without having access to your code, it's not possible to tell if that's the reason but, at least it's a possibility you should probably investigate.

HTH.

[cct]

@Martin_fr the IDE is just the standard Windows installer build

I don't believe it is getting as far as the FP code.

I will try 4.0RC1, and rebuild the project from scratch.

I have checked Defender, and it hasn't done anything since 2023 - I do have a full fat security suite installed, and that hasn't logged anything

@440bx it is pretty simple code, with a single procedure built into a Lazarus console template, so I don't think that would be he case

[440bx]

@440bx it is pretty simple code, with a single procedure built into a Lazarus console template, so I don't think that would be he case

Would it be possible for you to post the code ?  it would be much easier to provide better suggestions if you posted it.

[cct]

Code attached

[cct]

Well I installed 4.0 RC1, rebuilt the project - eventually. and it runs fine - with or without debug. The debugger worked out of the box.

Heaven only knows what the problem was, but possibly something I had set in the project a while back.

Many thanks for your help