Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2024-08

Strange effect when debugging...

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael Van Canneyt

Hi,

Does lazarus (or gdb) start a binary twice sometimes when initializing debugging ?

I have a program that behaves strangely:

In the IDE without anchordockingdsgn I start a binary using F9. It starts debugging at once, no errors.

In the IDE with anchordockingdsgn, I start a binary using F9 (Run with debugging). I get almost immediatly 'socket binding failed' - the binding of a TCP socket fails.

Indeed, when I stop debugging and check the process list, a prior process is visible, running. It obviously occupies the port.

When I kill the prior process, the second F9 works at once, as do all other attempts to run it.

But if I stop the IDE and restart it, I have the same behaviour again: first attempt to run fails.

In the anchordockingdsgn IDE, when I switch project, run the new project and then return to the first project (which could not be debugged), all works again OK.

What is puzzling is that this only happens with the IDE that has anchordocking enabled. If I recompile the IDE after removing the anchordocking package, debugging works at once.

Most puzzling. I fail to see what anchordocking has to do with debugging, except that the list of opened debug windows is different. I can't for the life of me explain how this would result in starting a process twice.

Any hints ?

Michael.

Reply by email

Martin Frb
to Michael Van Canneyt
Michael Van Canneyt wrote 5 lines
Hi, Does lazarus (or gdb) start a binary twice sometimes when initializing debugging ?

...

Show quoted text 17 lines
When I kill the prior process, the second F9 works at once, as do all other attempts to run it. But if I stop the IDE and restart it, I have the same behaviour again: first attempt to run fails. In the anchordockingdsgn IDE, when I switch project, run the new project and then return to the first project (which could not be debugged), all works again OK. What is puzzling is that this only happens with the IDE that has anchordocking enabled. If I recompile the IDE after removing the anchordocking package, debugging works at once.

I don't think it is the debugger (neither of them). Except, if the IDE would internally start 2 instance of the debugger (then there would likely be mem leaks on exit).

I don't know if it is anything to do with ... but with anchordocking, I have seen some keystrokes been send to the wrong control. The questions then would be: Could a keystroke (F9) be duplicated? If the IDE received two times F9 in a short enough time, would there be a race condition were the first is in progress, but hasn't flagged the state internally, so the 2nd would also go ahead?
(If that happens, and if that happens with the gdb backend, then there would have to be 2 instances of gdb.exe running. Assuming that both runs were triggered as "with debugger" and not one "without debugger")

Otherwise maybe the output of the IDE to console does have hints.

----
Of course, I assume you ensured that before you tried to start, there wasn't any old instance already.

Reply by email

Michael Van Canneyt
to Martin Frb
Martin Frb wrote 34 lines
On 02/08/2024 17:53, Michael Van Canneyt via lazarus wrote: > > Hi, > > Does lazarus (or gdb) start a binary twice sometimes when initializing > debugging ? ... > When I kill the prior process, the second F9 works at once, as do all other > attempts to run it. > > But if I stop the IDE and restart it, I have the same behaviour again: > first > attempt to run fails. > > In the anchordockingdsgn IDE, when I switch project, run the new project > and then return to the first project (which could not be debugged), all > works again OK. > > What is puzzling is that this only happens with the IDE that has > anchordocking enabled. > If I recompile the IDE after removing the anchordocking package, debugging > works > at once. I don't think it is the debugger (neither of them). Except, if the IDE would internally start 2 instance of the debugger (then there would likely be mem leaks on exit). I don't know if it is anything to do with ... but with anchordocking, I have seen some keystrokes been send to the wrong control. The questions then would be: Could a keystroke (F9) be duplicated? If the IDE received two times F9 in a short enough time, would there be a race condition were the first is in progress, but hasn't flagged the state internally, so the 2nd would also go ahead?

Could very well be. I recently reported this:

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41041

The issue arises only when 2 IDE windows are open. The difference in behaviour between the mouse and keyboard point indeed to the events ending up in the wrong place.

Seems to me that anchordocking in the IDE is not yet where it is supposed to be... :-/

Show quoted text 5 lines
(If that happens, and if that happens with the gdb backend, then there would have to be 2 instances of gdb.exe running. Assuming that both runs were triggered as "with debugger" and not one "without debugger") Otherwise maybe the output of the IDE to console does have hints.

I will try that and report back.

---- Of course, I assume you ensured that before you tried to start, there wasn't any old instance already. --

Obviously :-)

Michael.

Reply by email