[SOLVED] Unable to debug certain files?

[Aistis]

This is probably a rookie question, but I can't seem to debug certain files. I can debug my own created units fine (breakpoints and step-in work without problems).

This time I'm trying to step through code to check why I can't successfully unzip files into memory by calling TUnZipper.UnZipAllFiles in my code and setting breakpoints in unit Zipper for the procedure UnZipAllFiles. But the breakpoints are ignored.

I also tried to step-in from the breakpoint set in my code which calls UnZipAllFiles, but step-in then acts like-step over, stepping over the function call.

Happened both on Lazarus 4.0 and (after updating today) on 4.2 too.

Project's "Show options" output:

Code: [Select]

C:\lazarus\fpc\3.2.2\bin\x86_64-win64\fpc.exe
-MObjFPC
-Scaghi
-CirotR
-gw3
-gl
-gh
-Xg
-WG
-l
-vewnhibq
-Filib\x86_64-win64
-FuD:\projects\programs\REDACTED\
-FuC:\lazarus\components\opengl\lib\x86_64-win64\win32
-FuC:\lazarus\lcl\units\x86_64-win64\win32
-FuC:\lazarus\lcl\units\x86_64-win64
-FuC:\lazarus\components\freetype\lib\x86_64-win64
-FuC:\lazarus\components\lazutils\lib\x86_64-win64
-FuC:\lazarus\packager\units\x86_64-win64
-FUlib\x86_64-win64
-FE.
-oREDACTED.exe
-dLCL
-dLCLwin32
REDACTED.lpr



[Martin_fr]

TUnzipper is part of FPC (fpc-packages / paszlib).

So in order to debug this, you need to recompile FPC with debug info. This can't be done by the IDE, fpc comes pre-installed (but without debug info).

An easy way to do this is fpcupdeluxe.


Sometime you can just make a copy of the fpc package. However, that depends what other code uses that package. As you then need to redirect all such other code... (if you use other fpc packages that depend on it, then that is not going to be easy).

[Zvoni]

Errr??!??!??!?

*snip*
This time I'm trying to step through code to check why I can't successfully unzip files into memory by calling TUnZipper.UnZipAllFiles in my code and setting breakpoints in unit Zipper for the procedure UnZipAllFiles. But the breakpoints are ignored.
*snip*

I just looked through the source-code of the package Martin mentioned, and it definitely uses an OutPutFilename

[Aistis]

TUnzipper is part of FPC (fpc-packages / paszlib).

So in order to debug this, you need to recompile FPC with debug info. This can't be done by the IDE, fpc comes pre-installed (but without debug info).

I thought that this might be the case as I've read around some more after posting this. Thank you for the reaffirmation.

I just looked through the source-code of the package Martin mentioned, and it definitely uses an OutPutFilename

I managed to get it to read files into TMemoryStream by using TUnZipper.OnCreateStream and TUnZipper.OnDoneStream as shown in this thread.

[wp]

Usually rebuilding FPC with debug information takes some time, and I try to avoid this. In fact, I have a special installation of FPC with debugging enabled, as well as a special Lazarus installation which is permanently linked to this "debug-FPC". In this case, debugging of an FPC unit is just a matter of opening the project in that "Debug-IDE".

An annoying feature of the debug-FPC is that during debugging always system routines are entered which makes it very easy to lose track of where the debugger actually is.

Sometimes using the debug-FPC can be avoided: When the unit to be debugged is at the "end of the food chain", i.e. no other FPC unit used by your project depends on it, then you could try to copy the unit into your project directory. Then your project will use this copy rather than its original in the FPC directory. And when you are lucky compilation will still be successful in spite of this change. In this case, you'll be able to debug that unit like any other project unit. Later, after you have fixed the issue, simply delete the copied source unit and delete also the compiled unit output directory - now the compiler will use the original unit again.

[Thaddy]

Building the compiler+rtl with debug code is certainly not meant for beginners.
If they get an error it is likely in their code, not the compiler or the rtl.
They should simply ask on the forum and IF it is related to compiler or rtl, let one of us with debug builds figure it out.
That does not mean it is bad, but certainly for beginners confusing. They tend to blame the compiler....

[Martin_fr]

An annoying feature of the debug-FPC is that during debugging always system routines are entered which makes it very easy to lose track of where the debugger actually is.

Yes, an ignore list is needed (someday). Till then: "Step out" Shift-F8
This goes back into the calling line, so you can then "Step in" again to go where you wanted.

[wp]

Yes, an ignore list is needed (someday). Till then: "Step out" Shift-F8
This goes back into the calling line, so you can then "Step in" again to go where you wanted.

Ah, didn't know that...

[CM630]

Should not that work for cases like this? In think @WP told me that in another thread, it sound to me like the same issue, but he is not mentining it now:

[wp]

Similar. But this opens only LCL and 3rd party package units for debugging.