View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0035414||Lazarus||IDE||public||2019-04-18 14:00||2020-06-06 03:43|
|Reporter||chronos||Assigned To||Martin Friebe|
|Status||resolved||Resolution||unable to reproduce|
|Summary||0035414: Error dialog always shown on exit of debugged application|
|Description||If any project is run from Lazarus IDE then an exception is raised after executed application is exited/closed. It started to happen suddenly and it is probably related to some OS updates, MacAfee or Crowdstrike Falcon protection. It happens only if an application is executed from IDE. Not if it is executed directly as compiled executable. So it is somewhat related to debugger.|
Tested also with IDE 1.8.4 with same behavior.
Tested on 3 company computers with all running Windows 7 64-bit with the same result.
As workaround I found out that in Compatibility tab of Lazarus shortcut I can select "Compatibility Mode" with any version of Windows and then the problem with exception disappears.
|Steps To Reproduce||Start Lazarus IDE.|
Create new project.
Error dialog with exception will appear.
After closing error message Assembler window would appear with location inside RPCRT4!Ndr64AsyncClientCall function.
|Tags||No tags attached.|
|Fixed in Revision|
I can not reproduce this. (Though I have win 10)
I tested the 32 and 64bit 2.0.2 install (2.0.0 should be the same). Though my test app consists only of a simple form, with an open dialog on it (and executed, on button).
This issue may only arise with specific components.
If your app uses file dialogs (open/save/select dir/ maybe printer) then it may also depend on 3rd party software installed. Those dialogs load libraries from 3rd party software into your app (shell handler for file context menu, etc).
Please see if it happens with a simple form (no file dialog) for you?
Also in case you are cross compiling (between 32 ad 64 bit) make sure that your debugger config has the path like this
This ensures that the gdb according to the bitness of your target app is chosen. Using a gdb with a bitness different than the debugged app will definitely cause trouble.
You may also wish to try the following:
2) Use an alternate version of GDB
For 64 bit
For 32 bit
Thanks for the tips.
The exception is always thrown even with default blank one form project. Without any OpenDialog or SaveDialog components. Also with "Simple program" console application.
I use 64-bit Lazarus with 32-bit cross-compilation. Gdb path is set correctly and binaries look ok.
Tried alternative GDB 8.2 with same results.
Tried to delete(rename) Lazarus configuration directory but I have same problem also with default settings.
Tried Lazarus 2.0.2 64-bit without 32-bit package installed with default settings and same error always appears. So the problem should not be Lazarus configuration or installed packaged dependent.
Unfortunatelly I can't uninstall/disable/change system applications like antivirus and other protection tools as it is company laptop. I don't even know how to get some log from Mcafee.
I don't have any windows 10 remote machine available to test if Lazarus/GDB is working under Win10. But if it would, then it would still doesn't solve the problem with Windows 7.
So it is probably similar problem like with other antiviruses http://wiki.freepascal.org/GDB_Debugger_Tips#SigSegV_-_even_with_new.2C_empty_application
Ok, I can get a similar issue (not yet sure if anything can be done about it)....
If I press "stop" in a 64bit IDE, with a running/debugged 32bit app, then I get such an error.
It even happens when changing breakpoints while this app runs.
If however, I close the same app, using the normal windows red cross close button, then the app exits with no issue at all.
Can you please test with svn trunk revision 61090 or up?
You need to install LazGDeBugControl.exe.
This can be found in https://svn.freepascal.org/svn/lazarus/binaries
Or build from sources under components\lazdebuggergdbmi\apps\lazgdebugcontrol
To cross-debug a 32 bit app, you need a 32bit build of LazGDeBugControl.exe.
LazGDeBugControl.exe must be in the same folder as your 32bit gdb exe.
You can use the task monitor to verify the setup. Once your app is running in the debugger, there should be a LazGDeBugControl.exe shown as running in the task monitor. (And it should keep running, at least until you stop debugging)
Does the issue still exist, once you have the above setup?
To cross-debug a 64bit app (from a 32bit IDE, you need a 64bit build of LazGDeBugControl.exe.And must have it together with the 64bit gdb.
Thanks for another reply. Mantis was not sending me notification emails. I activated those options in my profile so I will see if it works.
From your description I don't understand how I am supposed to use that LazGDeBugControl.exe? Just to put in to the same directory as gdb.exe? Something like "C:\lazarus\mingw\x86_64-win64\bin\ ? How lazarus will see that it should use that file? Is it usable only for cross-debug or also for normal non-cross-debug?
And you write about "cross-debug" but I just use 64-bit lazarus with 64-bit gdb. So where is that "cross-debug" thing used? Usually I do only cross-compilation from 64-bit to 32-bit to have both 64 and 32-bit executables in one innosetup installer. But debugger should run simply in the same bit width as the application.
Maybe there is a missunderstanding. In 0035414:0115747 you wrote:
>> I use 64-bit Lazarus with 32-bit cross-compilation. Gdb path is set correctly and binaries look ok.
So I assumed you debug 32bit apps from within 64bit apps.
In that case, you need LazGDeBugControl.exe
The IDE looks for a file of that name in the GDB folder, and uses it if present (but only for cross debugging).
As for debugging 64bit apps from 64bit IDE.
I can not reproduce this on my PC.
The installed cross compiler should not matter. But please verify that the correct 64bit GDB is actually used (rename the 32bit gdb / or check with the task manager, if win7 task mgr shows the bitness)
Please test the following:
Tools > Options > Debugger: In the property grid set "DisableLoadSymbolsForLibraries" to true.
If that helps, then you the problem will be down to some library that conflicts with gdb. If you go through the GDB output, you will see that some libraries are always loaded when you run your app.
(If that helps, and if possible for you, then test this with GDB 8.2 too, thanks)
If it does not help, then please generate a logfile: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session
and reproduce the problem (ideally with a minimum empty form app)
no further feedback received / unable to reproduce
If the issue still occurs, even when using LazGDeBugControl then please re-open.
IF LazGDeBugControl fixes the issue, this should be part of 2.2 and the issue would be resolved.
Otherwise please add feedback (and reopen) if available.
|2019-04-18 14:00||chronos||New Issue|
|2019-04-18 14:00||chronos||File Added: Error.png|
|2019-04-18 14:00||chronos||File Added: Assembler.png|
|2019-04-18 15:10||Martin Friebe||Assigned To||=> Martin Friebe|
|2019-04-18 15:10||Martin Friebe||Status||new => assigned|
|2019-04-18 17:08||Martin Friebe||LazTarget||=> -|
|2019-04-18 17:08||Martin Friebe||Note Added: 0115654|
|2019-04-18 17:08||Martin Friebe||Status||assigned => feedback|
|2019-04-23 11:26||chronos||Note Added: 0115747|
|2019-04-23 11:26||chronos||Status||feedback => assigned|
|2019-04-23 13:21||Martin Friebe||Note Added: 0115749|
|2019-04-30 19:48||Martin Friebe||Status||assigned => feedback|
|2019-04-30 19:48||Martin Friebe||Note Added: 0115931|
|2019-05-06 14:27||chronos||Note Added: 0116043|
|2019-05-06 14:27||chronos||Status||feedback => assigned|
|2019-05-06 15:56||Martin Friebe||Status||assigned => feedback|
|2019-05-06 15:56||Martin Friebe||Note Added: 0116046|
|2019-05-06 15:56||Martin Friebe||Note Edited: 0116046||View Revisions|
|2020-06-06 03:43||Martin Friebe||Status||feedback => resolved|
|2020-06-06 03:43||Martin Friebe||Resolution||open => unable to reproduce|
|2020-06-06 03:43||Martin Friebe||Note Added: 0123248|