Forum > Debugger
Debugging run doesn't get to .PAS file ??
J-G:
I haven't needed assistance for quite some time - essentially because I haven't been writing any code!!
Having been annoyed at seeing one of the programs I use daily show that a 'Next date' should be '209th Dec' and wanting to sort out why, I did some small adjustments yesterday to display what dates were actually being calculated.
I'm well aware of how to set 'Debugging' and stepping through code with f7, f8 etc. and how to set breakpoints but - out of the blue - the form is partially created (and displayed) before breakpoints in the .pas file are activated.
I've set breaks in the .LPR file and they are obeyed but as soon as I expect to see a transfer to the .PAS file part of the form is created but the breakpoints in 'FormCreate' are ignored - and the form isn't correctly displayed.
Here is the 'FormCreate' code.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure TForm1.FormCreate(Sender: TObject);begin Top := 200; Height := 300; Width := 860; Left := (Screen.width - width) div 2; Left := Left + Screen.Width; // move to screen 2 ReadDate; ConfigDir := GetAppConfigDir(OK); Read_Path; CreateBlankRecords; CaptionLabels(DataYear); AssignFileNames; // Read_History; Calc_Meter_Read_Dates; // 585 (Breakpoint set here) CreateOrRead_Files; // 1943 // Correct_Errors; ShowGasFactors; Saved := FiT_Data[YearIndex,DayIndex].Value > 0; CheckIfReadingDue(DayIndex); // ReadCSVFile; ShowRecord(YearIndex,DayIndex); end;
I have checked that other programs do debug correctly using the same Laz installation which has served me very well for many years. (ver 1.6)
Martin_fr:
"Laz 1.6" => so presumingly we are talking about the "gdb based" debugger. (not FpDebug).
Not sure how long you've been on Fpc 3.0 ?
1)
There are known issues with line info generation (and they might be older, i.e. present in 3.0.0).
If you have "dead code" above the function...
If in front of "TForm1.FormCreate" is another function, and if that function is never called (and therefore not included in the exe / no blue dots at all).
Though the expected issues do not match exactly your problem, check if it is the case.
2)
Breakpoints (in gdb based debugging) are set, somewhere in the start up code of your app.
Unfortunately, after the unit "initializations" sections have run.
If you create your form, from within an "initializations" section, then the breakpoints are not yet set (that has always been like this).
Btw: appearing of the "blue dots", and setting of breakpoints, can be at different times.
I have no idea what features were avail in 1.6.
Check in Tools > Options > debugger options (the property grid) for
"InternalStartBreak" and try to change it. May have an effect....
3)
Could be changes to Windows....
You can try other versions of gdb (downloads on our Sourceforge page for 64 and 32 Win).
Not sure which one work, within an old 1.6.
I would expect up to, and including gdb 7.* / Maybe gdb 8.*
(gdb 9.* and up, will most likely need a newer Lazarus)
J-G:
Thanks for your input Martin - I'm not sure it will help :)
I've been using 1.6 since I first discovered FP & Lazarus - I think in August 2016 - but that’s only taken from my Laz folder date - it could have been prior, and of course it will be GDB based but I only know that by looking at the IDE options which I can’t recall ever doing previously. What I’m saying here is that Laz & FP ‘just works’ for me and I haven’t ever needed to do more that switch the debugger on or off as needed, all settings are ‘out of the box’ as it were.
As far as I am aware there is no “dead code” and I don’t have an issue with ‘Line Info generation’ - yesterday this code compiled and ran, just as the many other programs I’ve written - it simply records and displays meter-readings in graph-form and has done since 2014 (This may mean that I’ve been using FP & Laz prior to 2016 !!) I've just added a panel with some TLabels to display numbers indicating Day of Year.
Here is the code in the .LPR file - in fact the whole .LPR file :
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---program Energy; {$mode objfpc}{$H+} uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Interfaces, // this includes the LCL widgetset Forms, datetimectrls, tachartlazaruspkg, PowerUse { you can add units after this }; {$R *.res} begin RequireDerivedFormResource:=True; Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run;end.
I set breakpoints by ‘clicking’ within the margin of the IDE which sets that line to [ RED ].
In the Tools > Options > debugger section (I haven’t previously even looked at that section) there are 4 sub-categories : General; Event Log; Language Exceptions; OS Exceptions.
No settings within any section has been changed - as far as I know. Just in case I have done something silly by accident, This is the debugger path ‘$(LazarusDir)\mingw\$(TargetCPU)-$(TargetOS)\bin\gdb.exe’
My LazarusDir is T:\Lazarus wherein I have 3 ‘gdb.exe’ files : [mingw\i386-win32\bin (3/12/15)] - [mingw\x86_64-win64\bin (27/9/11)] & [fpc\3.0.0\bin\x86_64-win64 (14/2/16)]
There is no additional search path, ‘Show message on stop’ is ticked but ‘Reset Debugger after each run’ is not.
"InternalStartBreak" is set at [gdsbDefault] and has not been changed - there are 4 other options : gdsbAddZero - gdsbEntry - gdsbMain - gdsbMainAddr but since I have no idea what each option does would appreciate guidance.
I do not allow any changes to ‘Windows’ - I’m still using Win 7 Ultimate 64 (on this PC) and don’t allow updates of any kind.
The fact that other programs compile and run perfectly as they did previously and that just this one program exhibits the fault seems to indicate that I have inadvertently clicked on some setting or deleted some code - both sound implausible :(
Martin_fr:
Well yes, I have on issues with you using whichever version you want... But also, I am not going to go back and check what option 1.6 had, or what bugs....
You can try gdsbAddZero for InternalStartBreak. But I am not sure it will help. (especially, if you do stop in the LPR / and if you do not have code in "initialization" that triggers your form create)
I can't thing of any option that would match your description:
--- Quote ---I've set breaks in the .LPR file and they are obeyed but as soon as I expect to see a transfer to the .PAS file part of the form is created but the breakpoints in 'FormCreate' are ignored - and the form isn't correctly displayed.
--- End quote ---
".pas" being the unit with the form?
You could try switching between debug info => stabs or dwarf
You could try disabling "external debug info" (if you use it). It should not cause issues, but... well clutching at straws.
I assume the form is part of the project (not in some package?) => so it is compiled with debug info?
(if on Windows) You could try -Xe (external linker). Just in case, fpc gets upset by something.... again clutching at straws.
Then the question is => is the event OnFormCreate even called? Is it still set in the lfm? And is it correctly loaded by TReader from the lfm?
Is OnFormCreate stil published? (not public, but published)?
Is there an exception before it is entered?
Just throwing in anything I can thing of, however unlikely....
J-G:
Totally understand your position Martin and appreciate that you can only 'clutch at straws'.
FP 3.0 & Lazarus 1.6 have always simply worked for me and I'm not creating commercial applications - I don't really use OOP - I still prefer 'old style' at my age :)
There has been a further development inasmuch as when I press [f9] I no longer see 'messages' ?? The [Message] Window appears but there are none ??
I then noticed that the Object Inspector is blank !! and I can no longer see the form >:D
D'oh! - don't know how but the .LFM file had been deleted - thank the 'Lazarus Gods' that they create a backup!! Form and messages now returned.
I have tried changing the settings for 'InternalStartBreak' but without any effect.
As you'll see from the 'FormCreate' code, the first thing that I do there is to set the position, height and width. This is because I normally only want to show the top section. What happens now is that the outline of the whole form (887 wide x 785 high) is shown along with the three charts (empty), a few of the labels, edits and panels (not all).
This seems to me to show that for whatever reason the [form] is not being correctly included in the 'compile'.
I don't do anything extra-ordinary as far as using 'external' facilities, the .LPR file is 'Energy.LPR', the main unit is 'SolarPower.PAS' and the Form is SolarPower.LFM. I just use [f9] to compile the project. Is there some other means by which I can 'force' a complete [build] should there be some component that is being ignored?
All I've added to the program since it last 'worked', is a check that 'Today's' reading is greater than 'Yesterday's' reading (along with a warning flag) and a panel to show which day of the year readings are needed by the energy supplier.
What I have found is that I CAN get a breakpoint to trigger in another part of the program when I try to advance the period displayed. This shows that the debugger is operational - just not where the program starts - so it does seem that the FormCreate proc is not being included in the compile %)
How do I check if TReader is loading the Form? (do I even understand what that means?)
... or that OnFormCreate is 'published'?
There are no 'Exceptions' raised.
Navigation
[0] Message Index
[#] Next page