Access violation during debug

[dennis_uniwin]

Hello,

I have the following version installed:
Lazarus 4.2 (rev lazarus_4_2) FPC 3.2.2 i386-win32-win32/win64 on a laptop running the following OS Windows 11 Pro, 24H2 64 bits.
I am trying to debug a dll. So i have set a host application. This dll connects to sql using ODBC. I receive the av as shown by av.png when during debug the dll hits the following line:

Code: Pascal  [Select][+][-]

1. DatabaseError(lasterror);

this code is part of the following code:

Code: Pascal  [Select][+][-]

1.     if FRet = SQL_ERROR then begin
2.       lasterror := GetOdbcError(fret, SQL_HANDLE_STMT, STMTHnd);
3.       DumpStringInfoToFile('c:\temp\db_error_log.txt', lasterror);
4.       if (rpt and (doLogging and 8 = 8)) or (doLogging and 16 = 16) then
5.         DatabaseError(lasterror);
6.     end  

I have attached the db_error_log.txt file. from this file i can't see something strange contained in the lasterror string.

Also I have also a Windows 10 pro, 64 bits laptop with Lazarus installed only this version is: Lazarus 3.6 (rev lazarus_3_6) FPC 3.2.2 i386-win32-win32/win64
On this laptop if I do the same so start debugging with a host program and i make sure the same line is touched no AV is shown, but the expected error message.

What I am wondering is why am I getting this particular AV? Do I have wrong settings?
if you need more information please ask. 

[andersonscinfo]

The access violation (AV) you're encountering during debugging in Lazarus 4.2 is likely caused by a mismatch or instability in the debug environment when handling ODBC errors, particularly with the `DatabaseError(lasterror)` call. The fact that it works fine on Lazarus 3.6 suggests a regression or configuration issue specific to Lazarus 4.2.

Here’s what you should check and try:

### 1. **Verify Debugging Settings**
In Lazarus 4.2, go to:
- **Project → Project Options → Debugger**
- Ensure “Use GDB” is selected (not “Internal”).
- Check “Enable debug info” and “Strip symbols” settings — they should be consistent with your build mode.

### 2. **Avoid Calling `DatabaseError` During Debugging**
The AV occurs at `DatabaseError(lasterror)`, which may internally trigger UI elements or string operations that are unsafe under the debugger. Try replacing it temporarily with a simple `WriteLn` for testing:

```pascal
if (rpt and (doLogging and 8 = 8)) or (doLogging and 16 = 16) then
begin
  WriteLn('ODBC Error: ', lasterror);
  // DatabaseError(lasterror);  // Commented out for safety during debug
end;
```

If this prevents the AV, the issue is likely in how `DatabaseError` interacts with the debugger or GUI thread context.

### 3. **Check ODBC Driver Compatibility**
The error message indicates a network-level ODBC failure (`ConnectionWrite`). Ensure:
- You’re using the same ODBC driver version on both machines.
- The driver is 32-bit if your app is compiled as 32-bit (which it is, based on your FPC target).

### 4. **Update Lazarus/FPC**
Lazarus 4.2 is still relatively new. Consider switching to the latest stable release (e.g., 3.2.x) or test with Lazarus 3.6 on Windows 11 to confirm if the issue is version-specific.

### 5. **Run Without Debugger First**
Try running the host application *without* debugging. If no AV occurs, the problem is almost certainly debugger-related.

---

**Summary**: The AV is likely triggered by `DatabaseError` under the debugger in Lazarus 4.2. Temporarily replace it with `WriteLn`, verify debugger settings, and consider downgrading to Lazarus 3.6 until the issue is resolved upstream.

Espero que ajude.

[dennis_uniwin]

Hello,

Point 1: Under **Project → Project Options → Debugger** do I need to change the Debugger Backend to GDb? This is now set to -- use project Debugger -- which is FpDebug I believe. I have added my Compiler Options - Debugging perhaps this will help.

Point 2:
This calls the procedure DataBaseError from db.pas. Which does the following:

Code: Pascal  [Select][+][-]

1. Raise EDatabaseError.Create(Msg)

And msg is Const Msg : string in the procedure call
But I am not a fan of disabling the line because their are multiple DataBaseError calls.

Point 3:
The debug was actually trying to check the dll behavior when the SQl server drops for any reason.
So the error message were expected.

Point 4:
I will install 3.6 and see what happens.

Point 5:
I started the dll with run without debugging and no av was shown, but just expected behavior of the dll when the sql server is dropped.

I will let you know if version 3.6 works on my windows 11 pro laptop.

[andersonscinfo]

Hello,

Based on your setup and the attached screenshot, here’s what you should adjust:

### 1. Debugger Backend
Yes, change **Debugger Backend** from “Use Project Debugger” (FpDebug) to **GDB**. FpDebug can be unstable with complex scenarios like ODBC in DLLs, especially in Lazarus 4.2. GDB is more reliable for debugging DLLs with external dependencies.

Go to:
- **Project → Project Options → Debugger**
- Set **Debugger Backend** to `GDB`.

### 2. Compiler Debugging Options
Your current settings look mostly correct, but ensure:
- `Generate info for the debugger` is checked.
- Avoid `Strip symbols from executable` unless necessary.
- If you’re using `Use Heaptrc unit`, make sure it’s not conflicting with ODBC memory handling.

### 3. Why AV Happens Only in Debug Mode
The AV occurs because FpDebug may not handle exceptions or memory access correctly when calling `DatabaseError(lasterror)` inside a DLL during debug. This is a known instability in Lazarus 4.2 with FpDebug + ODBC. Running without debug (`Run → Run`) works because no debugger is intercepting the exception.

### 4. Quick Fix Without Disabling Code
Instead of commenting out `DatabaseError(lasterror)`, wrap it in a try-except block to catch the AV gracefully:

```pascal
if FRet = SQL_ERROR then begin
  lasterror := GetOdbcError(fret, SQL_HANDLE_STMT, STMTHnd);
  DumpStringInfoToFile('c:\temp\db_error_log.txt', lasterror);
  if (rpt and (doLogging and 8 = 8)) or (doLogging and 16 = 16) then
    try
      DatabaseError(lasterror);
    except
      on E: Exception do
        ShowMessage('Database error caught: ' + E.Message);
    end;
end;
```

This prevents the AV from crashing the debugger while still logging the error.

### 5. Test Lazarus 3.6 on Windows 11
If Lazarus 3.6 works on Windows 10, it should work on Windows 11 too. Install it and test — this will confirm if it’s a Lazarus 4.2 regression.

Let me know if you need help adjusting the debugger settings or testing further.

Att.

[Khrys]

What does the call stack look like when the segfault happens? Could you post a screenshot of the relevant window (can be opened with  Ctrl+Alt+S)?
And in case you're trying to connect to an Access database, be aware that the 32-bit and 64-bit variants don't mix well when installed in parallel (and that Access is a mess in general).


@andersonscinfo you could've at least fixed the formatting of the answers you copy/pasted from <INSERT AI CHATBOT> 

[dennis_uniwin]

Using point 1 and point 4 it appears to work a bit better, but even then when trying to inspect a value I get an error about the debugger.
i have attached the error.
additional information:

The GDB command:
"-data-evaluate-expression TDBConn(DBCONN[D]).lasterror"
did not return any result.

The GDB process is no longer running.

But good news. Using lazarus version 3.6 the debugger works as expected. No av received just the expected error message. I have attached this as well as Debugger Exception Notification.png

The connection is to a SQl server and about the call stack at the moment the av comes lazarus does not respond to the ctrl+alt+s key combination. Also having the call stack open and then a break point on the
DatabaseError(lasterror); line shows I believe the expected call stack, but as soon as I press f8 the call stack becomes completely empty. 

[andersonscinfo]

The GDB error you're seeing — `"-data-evaluate-expression TDBConn(DBCONN[D]).lasterror" did not return any result. The GDB process is no longer running.` — indicates that GDB is crashing or losing context when trying to evaluate expressions during debugging, especially inside a DLL with ODBC calls.

This is a known instability in Lazarus 4.2’s GDB integration when debugging DLLs that interact with external libraries (like ODBC). The fact that Lazarus 3.6 works fine confirms this is a regression in 4.2.

### Immediate Workaround

Since you’re debugging a DLL and need to inspect values, avoid evaluating complex expressions like `TDBConn(DBCONN[D]).lasterror` directly in the debugger watch window. Instead, log the value before the crash:

```pascal
if FRet = SQL_ERROR then begin
  lasterror := GetOdbcError(fret, SQL_HANDLE_STMT, STMTHnd);
  DumpStringInfoToFile('c:\temp\db_error_log.txt', lasterror);
  // Log to console for immediate inspection
  WriteLn('DEBUG: lasterror = ', lasterror); // <-- Add this line
  if (rpt and (doLogging and 8 = 8)) or (doLogging and 16 = 16) then
    try
      DatabaseError(lasterror);
    except
      on E: Exception do
        ShowMessage('Database error caught: ' + E.Message);
    end;
end;
```

Run the program in debug mode, and check the console output (or log file) for `lasterror`. This avoids triggering GDB’s expression evaluator.

### Why This Happens

- GDB in Lazarus 4.2 has trouble resolving object fields (`TDBConn(DBCONN[D]).lasterror`) inside DLLs.
- The call stack becoming empty after `F8` suggests GDB loses thread context — common when debugging DLLs with external dependencies.
- Lazarus 3.6 uses an older, more stable GDB backend that handles this better.

### Recommendation

Stick with Lazarus 3.6 for debugging this DLL until Lazarus 4.2 stabilizes its GDB integration. If you must use 4.2, disable expression evaluation in the debugger (remove watches/expressions) and rely on logging.

Att.

[dennis_uniwin]

I'll stick with 3.6 then. Thanks for the help!

[Martin_fr]

You can use any gdb backend with any Lazarus version.  At least the ones that at some time where used/shipped.

They are available for download on our sourceforge page under "alternative gdb" (in the Window 32/64 folders).

The really important bit, when using gdb is, to switch debug info to "Dwarf 2" (with or without sets, depending on your needs). Using Dwarf 3 will have gdb crash more easily (its not Dwarf 3, but Dwarf 3 as produced by FPC).

That change must be done for each package involved. (as well as project and dll, if produced by FPC)


Please report issues with FpDebug, if there is a way to reproduce them.


As for the access violation => the original image shows an access violation in the application. So the debugger itself did not crash, the app did.
- Does it also crash when running outside the debugger? (It may catch such an error, so it may not be noticeable).
- If not, then we need to seek how the debugger affects that.
  -- Are there breakpoints?

About "app crashes, but only when debugged".

There are 2 issues that I can think of.

1) breakpoints. If the debug info is faulty (fpc sometimes does that) the a breakpoint might be incorrectly placed such as that instead of breaking it will crash the app.

2) Timing issues. An app running under a debugger can get different timing (the OS reports stuff to the debugger, that takes time). In that case the error exists always (as a race condition), but may only show symptoms in the debugger.

3) Well there are probably more, but I can't think of any.

[PascalDragon]

@andersonscinfo you could've at least fixed the formatting of the answers you copy/pasted from <INSERT AI CHATBOT> 

Definitely. And if they don't learn that by us reminding them about that I'm going to report their posts in the (near) future.