Had a quick look and did not see a folder for mac osx x86_64 to test? Just OSXi386
Am I missing something?
Sorry, but I can't find the package, see screenshot in the attachment. Did I overlook anything?
but on the Mac you do not get the line numbers seen when run on Linux or Windows:If that is the case, and if the settings are correct (e.g the debugger gets line info, but the heaptrc does not), then this is an issue in fpc (and may need reporting there)
About HeapTrc
Quote from: ChrisR on October 23, 2018, 04:23:50 am
but on the Mac you do not get the line numbers seen when run on Linux or Windows:
If that is the case, and if the settings are correct (e.g the debugger gets line info, but the heaptrc does not), then this is an issue in fpc (and may need reporting there)
On Windows you should get a much better experience with the gdb based debugger. Or if you want: fpdebug (which is used if the FpLldb debugger). If you want fpdebug (on win/linux) you can choose between pure fpdebug, or gdb+fpdebug.
I'm aware the GDB debugger is currently more feature-complete in Lazarus. I just meant that LLDB is not in any way only a "Mac" thing, and that generally speaking it's a better debugger than GDB (as all LLVM/Clang tools are compared to their GNU equivalents.)That comparison is currently hard to make...
I only noticed that starting of an app with LLDB debugger takes more time (4-6 seconds longer).Sorry about the slow down There is probably not much that can be done right now.
Also lldb can't show values for WideString variables.For LazDebuggerFpLLdb, (the "with fpdebug") version, I added a workaround for widestring. They *should* work in the next version.
One problem. I can't install lazdebuggerfplldb on macOS Mojave 10.14. Please include pre-built lldb debuger for Lazarus 2.0 RC2.
Because I can't compile any carbon or 32-bit app on macOS Mojave 10.14 in Lazarus, I get linking error. Only 64-bit / cocoa apps can be compiled and works fine.
Also lldb can't show values for WideString variables.Just for info/background: That is actually fpdebug. (Not tested if lldb itself can). The IDE bypasses lldb for all work on pascal related data. lldb just provides the memory dump (raw bytes)
always stopping on every raised exception -- even when the exceptions were set to be ignored.
I also had regular crashes when viewing objects/variables during debug breakpoints.Crashes in the IDE, or crashes of lldb itself (is lldb still in the task list?)
Do know that really I greatly appreciate the effort being made to move away from gdb on the mac since it is so messy to fool with codesigning, crsutil non-standard settings, etc.Thanks.
"/users/example/lazarus64bit/config_lazarus/onlinepackagemanager/packages/Indy10/lib/x86-64-darwin/idServerIOHandlerStack.o"
max files 256 unlimited
Could not set resource limits: 1: Operation not permitted
For app I'm currently developing, using lldb(alpha) it worked, kind of (buggy but at least runs). With lldb(with fpdebug), it crashes immediately:See above
Unable to open file "/Developer/lazarus/components/tachart/lib/x86_64-darwin/qt5/tadatapointseditor.o".
Laz 2.0RCL2/64bit/Cocoa. Compling to 64bit/Qt5.
Looks like step-over still does a step-into, though.32 and 64 bit?
I managed to get lldb working on macOS cocoa lazarus 2.0 revision 59715, the latest fixes, after a great deal of fiddling. lldb seems to be working on very simple projects, but I tried to run one of my large projects with it, and get an access violation. The project runs fine without lldb.
I have attached the log in case it may be helpful.
lldb is working in another large project. One thing I notice is that "Step Over" does not seem to be working, it seems to "Step Into". I have to use "Step Out" to get back.The step problem appears to be related to some debug info that fpc writes for the exe. Since both gdb and lldb react the same way to it, I think it is a problem in fpc.
to override TApplication.OnException:Tracking the exception from inside the running IDE may not work anyway. DumpStack and similar commands will produce the same address-only trace on Mac. Fpc does not have the line info reader for dwarf on Mac https://bugs.freepascal.org/view.php?id=32775
Instructions are at the top of the form unit. It fails consistently on DARWIN. I don't have 2RCL2 installed on anything else to try at the moment.It all comes down to if it will also fail for someone in the fpc team. See the bug report.
It seems that unchecking "Use Application Bundle" in Project Options breaks debugger. Is this a known bug? Or should I check it deeper?No, not known. Please provide a log.
It seems that unchecking "Use Application Bundle" in Project Options breaks debugger. Is this a known bug? Or should I check it deeper?No, not known. Please provide a log.
Try to get a log file (see 1st message of this thread)Removed bundle, cleanup&build, run -> laz1.log
FUNC: GETINFOPLISTSTRINYou are right! It was error in sample from wiki (http://wiki.lazarus.freepascal.org/Mac_Show_Application_Title,_Version,_and_Company). CFBundleGetMainBundle is not good for checking bundle existance. I've described it in wiki.
That would be a good starting point, to see if you can find if any address/object is nil (and should not be).
Shortly before the crash, the LCL (I assume) logged the following: "(V)TCarbonWSCustomForm.ShowHide Error: GetWindowClass failed with result -5600"I suppose it is not related. The same lines are in log with bundle option turned on.
I do not know if that is related (I don't know the cocoa, nor carbon workings; just the debugger)
The debugger should of course show the stop-reason. That needs to be fixedThat would be great!
Just committed. Should even make it into RC3The debugger should of course show the stop-reason. That needs to be fixedThat would be great!
What is the status for LLDB on Windowze?Same as on Mac.
I would test LLDB on Linux if you tell me how-to.
Which command will build an IDE from zero with this lldb installed? Because I was using "make bigide" and it wasn't available, but maybe my revision was too old?
always stopping on every raised exception -- even when the exceptions were set to be ignored.Thanks for pointing out. That was a simple oversight when putting the new debugger together. The code for this is identical with what all other debuggers do.
I fixed this, and it will be in RC3.
Also fixed incorrect classnames for exceptions (the 2 digits at the start).
I'm doing more testing today...I am having instances of debug runs (without any breakpoints set) where things just hung and I had to actually kill and restart Lazarus.
I put the "exit" at the top of the LazLogger.CreateIndent function and the backtest is chugging away...without any issues so far (this will be a several hour test).I still need to get an official fix in. But the trace you delivered was gold. And errors like this are most often hell to find.
I did notice that setting a breakpoint "on the fly" while program was running in the lldb debugger caused an unknown class error -- but this is something I never "need" to do.More details, please?
Also, KUDOS to those involved in making Cocoa work so well under Lazarus.You can find them here. If you go further back there are others.
With the the your lldb debugger setup work and Cocoa (vs Carbon) allowing for easy 64-bit OSX applications, Lazarus will be well set to remain a great environment for all platforms :-)
I'll try my same tests after shifting all my stuff & IDE back to 32 bit (Carbon) to see what stepping does there.
1) You want to continue stepping, in the thread that was interrupted by the breakpoint?Yes
But (unless you do changes in the thread window), stepping happens in a different thread? (main thread? or thread in which previous breakpoint occured?)Yes, using the capablilty you showed me of being able to send a command directly to lldb, after the breakpoint successfully works, I can select/set the source code thread. Only then can I use F7 and/or F8 (from the IDE) successfully. Not sure what you mean by the "main thread" (IDE or my source) but stepping does not occur in my source code thread -- shown by the assembler window not longer showing my source code as it did when the breakpoint occurred. Without lldb intervention to select my thread, after doing an "IDE" step (F7 or F8), the assembler window shows some other section of code. (I'll give you attachments to show this.)
2) You stop at a breakpoint, change the thread to a different thread, that the one that hit the breakpoint, and then want to continue stepping in the thread that you switched too? But it steps in the thread of the breakpoint?If I don't force lldb to use the thread for my source code, then and F7 and F8 IDE commands cause stepping in what appears to be some other thread.
Also, when you reach the breakpoint, in the thread window, is the correct thread selected?Haven't looked at the "thread window" -- but the assembler window at the breakpoint stop is correct (showing my source code lines). However, unless I then reset the thread to the source code thread directly sending the "select thread" command to lldb, any stepping (F7 or F8) does NOT step through the source code -- and appears to step through some other thread (though if I F9) things proceed again to the next breakpoint.
I don't understand the internals of the Lazarus IDE or debugger code, but am trying to rebuild the Lazarus IDE in debug mode -- with the hope of doing some debugging through lazdebuggerlldb.pas -- though at the moment packages don't seem to be generating the debug output needed to stop at breakpoint source code lines.In many cases it is enough, to open menu: Tools > Configure build Lazarus => There you can add options for compiling the IDE. You can use -gw3 (dwarf3). (Should that give unexpected trouble (errors produced by lldb), then use only -gw (dwarf2)).
-gw3 -O- -gh -gt -Criot
(With your knowledge and experience, of course, your efficiency is superior but I thought I'd give this a shot since the OSX environment seems likely to be the issue for the laz lldb code?)The LLDB debugger was written only for the OSX environment. All other OS are better of with GDB.
I will try to provide information re: the stack though I'm not sure how exactly to do that.If you run a logfile --debug-log as specified in the very first post of this thread, then the data will be included in the logfile. All you need to do, is to keep the IDE's stack window open, so the IDE will need the data, and get it from lldb.
My last assembly language programming (mostly 8080 and 8086) was back in the 1980's and then moved onto "C/C++" and since I've mainly worked in applications-level programming since then, I rarely even think about stacks :-(Well all I mean is the high level representation of the Stack. Just look at the Stack window.
I will do what I can to put together a relevant logfile.So you send for exampleQuote1) You want to continue stepping, in the thread that was interrupted by the breakpoint?
YesQuoteBut (unless you do changes in the thread window), stepping happens in a different thread? (main thread? or thread in which previous breakpoint occured?)
Yes, using the capablilty you showed me of being able to send a command directly to lldb, after the breakpoint successfully works, I can select/set the source code thread. Only then can I use F7 and/or F8 (from the IDE) successfully. Not sure what you mean by the "main thread" (IDE or my source) but stepping does not occur in my source code thread -- shown by the assembler window not longer showing my source code as it did when the breakpoint occurred. Without lldb intervention to select my thread, after doing an "IDE" step (F7 or F8), the assembler window shows some other section of code. (I'll give you attachments to show this.)
thread select 5
to the debugger.Ok that answers the question I did ask 2 lines above....QuoteAlso, when you reach the breakpoint, in the thread window, is the correct thread selected?
Haven't looked at the "thread window" -- but the assembler window at the breakpoint stop is correct (showing my source code lines). However, unless I then reset the thread to the source code thread directly sending the "select thread" command to lldb, any stepping (F7 or F8) does NOT step through the source code -- and appears to step through some other thread (though if I F9) things proceed again to the next breakpoint.
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk.
--debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,FPDBG_DWARF_ERRORS,FPDBG_DWARF_WARNINGS,FPDBG_DWARF_VERBOSE_LOAD,FPDBG_DWARF_DATA_WARNINGS,DBG_VERBOSE,DBG_WARNINGS,DBG_STATE,DBG_EVENTS,DBG_THREAD_AND_FRAME
MojaveDefinetely need to see a log. Check the DBG_CMD_ECHO as it is important in this case.
The "step crash" issue: Please test with rev 60338.Replaced the file as suggested, and have no problems with stepping f7 & f8 -- but as noted earlier, even before your 60338 change, I actually couldn't reproduce the "step crash" unless running under the laz IDE under lldb.
Can you compile your IDE with range checking please? (Tools > Configure build Lazarus : add to options: -CrI know you didn't need me to do this in the end but...Interesting that in my setup, Lazarus IDE won't start up successfully with the range check option "Cr" set in the IDE build configuration options. See the first attachment laz.log generated from this terminal command:
This probably occured while stepping into, and therefore pausing on a "begin" line of a procedure/function.QuoteThe "step crash" issue: Please test with rev 60338.but as noted earlier, even before your 60338 change, I actually couldn't reproduce the "step crash" unless running under the laz IDE under lldb.
So the cocoa code as a range check issue....QuoteCan you compile your IDE with range checking please? (Tools > Configure build Lazarus : add to options: -CrI know you didn't need me to do this in the end but...Interesting that in my setup, Lazarus IDE won't start up successfully with the range check option "Cr" set in the IDE build configuration options.
This probably occured while stepping into, and therefore pausing on a "begin" line of a procedure/function.In my main form, just as a test I created a new procedure TestMe which I then called at the start of FormCreate:
The function needs at least 2 params/locals. One of them a local string var. And then some bad luck. And it is 64bit only
Code: Pascal [Select]
var a: integer; b: ansistring;
a:= 1;
pointer(b):= pointer(high(qword));
a:=a;// break on this line
watch a and b (a as first entry in watches). That should likely cause the crash.
procedure TfrmSystemRulesMain.TestMe;
var
a: integer; b: ansistring;
begin
a:= 1;
pointer(b):= pointer(high(qword));
a:=a;// break on this line
end;
procedure TfrmSystemRulesMain.FormCreate(Sender: TObject);
var
i: integer;
o: TOrderType;
e: TEvaluator;
Userdir: string;
TechRules: TTechRules;
begin
TestMe;
...
I successfully stepped (F7) into and within the TestMe procedure, but on f7 stepping out of the TestMe procedure an exception is raised:Commenting out the line "pointer(b):= pointer(high(qword));" eliminates the exception.Yes this line of code intentionally and seriously screws up the string. And it is expected that the test app, does no longer work thereafter.
constructor TLldbInstructionWatchSet.Create(AWatch: String;
AKind: TDBGWatchPointKind
; {kca} AThread: Integer = -1; AFrame: Integer = -1);
begin
case AKind of
wpkWrite: inherited Create(Format('watchpoint set variable -w write %s', [AWatch]), {kca}AThread, AFrame);
wpkRead: inherited Create(Format('watchpoint set variable -w read %s', [AWatch]),{kca}AThread, AFrame);
wpkReadWrite: inherited Create(Format('watchpoint set variable -w read_write %s', [AWatch]),{kca}AThread, AFrame);
end;
end;
And in LldbDebugger.pas, I modified TLLdbBreakpoint.SetBreakPoint adding this under bpkData: bpkData: begin
if not Enabled then // do not set, if not enabled
exit;
// TODO: scope
// TODO: apply , Expression, not Enabled
Instr := TLldbInstructionWatchSet.Create(WatchData, WatchKind,
{kca} TLldbDebugger(Debugger).FCurrentThreadId, TLldbDebugger(Debugger).FCurrentStackFrame);
if Expression <> '' then
FNeededChanges := FNeededChanges + [ciCondition];
end;
procedure TBacktest.DoTest(SentIndex: integer; SentSingleRun: Boolean);
var
i, CompleteCount: integer;
valuelo, valuehi: double;
str: string;
begin
str := 'frogman';
try // try finally
try // try except
with TradeSession
do begin
...
Personally I wish it didn't show "ANSISTRING" since that uses a lot of screen real estate when I really just want to see the string, but that's personal.Dry dwarf3 (at least for strings)
FInstr := TLldbInstructionExpression.Create(FWatchValue.Expression, FWatchValue.ThreadId, FWatchValue.StackFrame)
and rebuilt the IDE.I confirmed that selecting/pressing current made the "watch" work! I agree totally that the watch isn't working correctly because the thread isn't set correctly at watch evaluation time.Ok, technically that means the watch works. But the thread does not. (and in more ways, than just being the wrong one selected)
I would be interested to know if the "watch" issue arises in this example (multi-threaded) for your normal working non/Mac environment or if it is specific to OSX, or maybe 64 bit environments?I have not checked 32 bit Mac, but it does not arise on windows.
Can you confirm a couple of things please, relating to Lazarus 2.0.0 -It should be in the left side list, as it should already be installed.
1. Right at the start, you mentioned that LazDebuggerFpLLdb "should be in the list of available packages" but on my system, Packages->Install/UninstallPackages does not list it. It is, as you also mention, in Components->....
Should I assume thats as expected ?
2. When setting the IDE to use LLdb, we should choose "LLDB debugger (with fpdebug) (Beta)" ?Yes.
3. The IDE then requires us to choose one of several exe formats. Is there any particular preference ?Not sure what you refer to? I assume "debug info"?
Known Issues in the 2.0 release that are fixed for 2.0.2:
Single stepping, may sometimes step the wrong thread (if paused in a multithreading app)
To apply the fix in Lazarus 2.0.0 go to https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60339 and download the 2 files. You can replace the entire files in your 2.0.0 install. Rebuild the IDE and restart.
Fix a crash for local/watches on begin/end of procedure.
To apply the fix in Lazarus 2.0.0 go to https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60353 and download the file. You can replace the entire files in your 2.0.0 install. Rebuild the IDE and restart.
Fix several issues when debugging multi-threaded apps:
- Eval watches,hints,locals according to selected thread (and stackframe)
- Select correct thread at breakpoint
- Select correct Stackframe for thread, when switching threads
To apply the fix in Lazarus 2.0.0 go to https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60436 and download the file. You can replace the entire files in your 2.0.0 install.
In order for this to work you must also install the file lldbinstructions.pas from for revision=60339 / 1st in this list. (the file lldbdebugger.pas must be taken from this changeset (revision=60436).
Rebuild the IDE and restart.
OK, clarified. Its there on the left side (Installed) only in the bigide model. On the Mac at least it probably needs to be in either build.Can you confirm a couple of things please, relating to Lazarus 2.0.0 -It should be in the left side list, as it should already be installed.
.... LazDebuggerFpLLdb "should be in the list of available packages" but ......
......