Asm window pops up

[Martin_fr]

In reply to https://forum.lazarus.freepascal.org/index.php/topic,63867.msg484990.html#msg484990
from the 3.0RC announcment

Sorry Martin_fr,  i thought the information detailed by user alink (post) was enough.

With breakpoint? normal stepping? Caught Exceptions?

Details?
How to reproduce?

Ok, I thought it was an independent issue.

Can't reproduce. Tested Fedora 33.

press the button,

Sorry to be pedantic: The step over  button on the main ide bar?

So you expect to step to the next line of your code?

Does the debugger step to the next line of Pascal code? Or stop after one asm instruction?

Are you using FpDebug or GDB based debugger?

[TRon]

Can't reproduce. Tested Fedora 33.

Debian bookworm x86_64, gtk2.

Sorry to be pedantic: The step over  button on the main ide bar?

No problem, Martin. yes, but honestly pressing the corresponding function key (what is it, F8 ?)

So you expect to step to the next line of your code?

Affirmative and it actually does.

Does the debugger step to the next line of Pascal code? Or stop after one asm instruction?

The debugger steps to the next line but also the asm window gets a 'push' to be in front. I'm a bit busy atm, I'll try to post a screenshot later.

Are you using FpDebug or GDB based debugger?

fpDebug. When trying to run the program Lazarus asks me to set the debug type information (radio buttons, default to dwarf 3 as it detected I want to use fpdebug)

If there is any other information to be shared that can help then don't hesitate to ask/request.

fwiw it is a fresh installed RC1, build with (standalone) FPC 3.2.2 (units compiled without debug). Sources are detected by Lazarus. Lazarus is invoked from a terminal window using a custom directory for the configuration (--pcp).

[Martin_fr]

It's a bit of a guessing game at the moment...

If you close the asm window, will it pop up again?

Anchordocking, yes or no?

[Martin_fr]

Also could you start your ide with

Code: Text  [Select][+][-]

1. --debug-log=some_log_file --debug-enable=DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS,DBG_VERBOSE_BRKPOINT,DBG_STATE,DBG_EVENTS,DBG_DATA_MONITORS,DBG_LOCATION_INFO,DBG_FPDEBUG_VERBOSE,FPDBG_COMMANDS

And append the logfile.

Do you have any symbolic or fixed links to any of your files? Does any of your file exist in 2 folders, so FPC and the IDE could see a diff path?

[Martin_fr]

Btw, someone has the exact opposite issue https://forum.lazarus.freepascal.org/index.php/topic,63918.0.html
But that is indeed "expected", i.e. the current source has that issue.

[TRon]

Ok, I apologize because I seem unable to reproduce atm.    That is what you get for building everything on the fly for each session 

I was convinced yesterday that I was able to 100% reproduce (even created some other test projects with same results) so all I had to do was to repeat the steps I took yesterday. Apparently I forgot to do them all because as persistent as the asm window popped up yesterday, as persistent is it today for not popping up /et all/.

I'm very sorry for having wasted your time martin_fr 

Nonetheless, some answers on questions that you asked (might perhaps be helpful in case the issue creeps up again).

If you close the asm window, will it pop up again?

I did not close the window but pushed it to the background. Next 'step over' popped it up to front again.

Anchordocking, yes or no?

No, it was a pretty pristine lazarus install except for me having played a little with the layout of the IDE ((re)moving toolbars, changing colors etc -> experimenting with a minimal desktop) and having installed bgrabitmap package with OPM.

Also could you start your ide with

Oh, that is an interesting line with all those DBG_xxxx options. I have incorporated it into my build-script. Thank you for having mentioned that.

Do you have any symbolic or fixed links to any of your files?

One symbolic link named fpc, pointing directly (and only pointing) to fpc.sh.

fpc.sh script is custom, containing lots of bash but does not use hard-coded paths/files except for one environment variable pointing to the fpc root dir (home/apps/fpc) in which the different versions of fpc are located.

No symlinks or other dependencies unless the build process (fpc/laz) added them (automatically for me)).

Does any of your file exist in 2 folders, so FPC and the IDE could see a diff path?

Not that I am aware of and/or deliberately/willingly (e.g. if it is then it is without my knowledge -> log files does not seem to indicate that that situation is encountered).

Btw, someone has the exact opposite issue...

Yeah, I've read that (intriguing) post as well. Well for the part of having opposite experience.

[Martin_fr]

I was convinced yesterday that I was able to 100% reproduce (even created some other test projects with same results) so all I had to do was to repeat the steps I took yesterday. Apparently I forgot to do them all because as persistent as the asm window popped up yesterday, as persistent is it today for not popping up /et all/.

Yeah, the time when you want a bug to happen.... Been there.

Also could you start your ide with

Oh, that is an interesting line with all those DBG_xxxx options. I have incorporated it into my build-script. Thank you for having mentioned that.

Not sure what your build script has to do with that? Unless it runs the IDE?

Though you can specify them as defines with -d for each of the values.

Mind, you get a ton of output, and it has a small effect on the debugger speed.

Do you have any symbolic or fixed links to any of your files?

One symbolic link named fpc, pointing directly (and only pointing) to fpc.sh.

Only about source files. If Fpc sees them with a diff path, then Fpc may put that path in the debug info (relative to what Fpc thinks the project root is), causing the IDE to be unable to find the file. Or believe that there are 2 distinct files....


Btw, do you use "desktops" => that is a debug desktop that closes and opens some of the IDE windows when you start/stop debugging?

[TRon]

Not sure what your build script has to do with that? Unless it runs the IDE?

My build script creates a small startup script file that starts startlazarus with those options (when opted for when invoking my build script).

Only about source files. If Fpc sees them with a diff path, then Fpc may put that path in the debug info (relative to what Fpc thinks the project root is), causing the IDE to be unable to find the file. Or believe that there are 2 distinct files....

Ah , ic. Thank you for clarifying. In that case, there are no links whatsoever. All neatly tucked away in the fpc/fpc_version/source directory.

Btw, do you use "desktops" => that is a debug desktop that closes and opens some of the IDE windows when you start/stop debugging?

That was one of the things that I was experimenting with. Could that have had an influence on the asm window popping up ? I've tried to re-create what I did yesterday but seem to have done something in another order or missed a beat somewhere.

[Martin_fr]

Btw, do you use "desktops" => that is a debug desktop that closes and opens some of the IDE windows when you start/stop debugging?

That was one of the things that I was experimenting with. Could that have had an influence on the asm window popping up ? I've tried to re-create what I did yesterday but seem to have done something in another order or missed a beat somewhere.

I don't use desktops.

I don't know, if they are triggered after each step. If so, and if the asm window is in the list of windows that get changed...