Print Page - Problems with Debugger on OSX

Using the Lazarus IDE => Debugger => Topic started by: ahnz on April 06, 2019, 09:51:56 pm

Title: Problems with Debugger on OSX
Post by: ahnz on April 06, 2019, 09:51:56 pm

Hi All.

When running application with Debug, it compiles ok with just one warning "Compile Project, Mode: Debug, CPU: x86_64, Target: MyStamps: Success, Hints: 1" and then after a wee delay fails with the attached “Access Violation” error.

I believe this occurs on all application I try and create, 32 or 64bit, Carbon or Cocoa.

Heres what I have ...

OS: OSX High Sierra 10.13.6
Lazarus: 2.0.0 (2019-03-07) - as reported by Help|About

Widgetset: Cocoa
Target: 64bit OSX

Compiler:
FPC 3.0.4 [2017/11/26] for x86_64

Debug:
LLDB (with fpdebug)(Beta)
Path: /usr/bin/lldb
Version: lldb-1000.11.38.2

LLDB appears to be code signed ok ...

$ codesign -dv --verbose=4 /usr/bin/lldb

Executable=/usr/bin/lldb
Identifier=com.apple.lldb
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=223 flags=0x0(none) hashes=3+2 location=embedded
Platform identifier=4
VersionPlatform=1
VersionMin=658688
VersionSDK=658688
Hash type=sha256 size=32
CandidateCDHash sha256=8784dbb260e938bbc83d3ab1adfdaa415900485e
Hash choices=sha256
Page size=4096
CDHash=8784dbb260e938bbc83d3ab1adfdaa415900485e
Signature size=4485
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=64

Anyone have any ideas what I might (probably) be missing or where to look

Cheers guys

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 07, 2019, 01:36:01 am

lldb is supplied by apple, when you install their developer tools, so yes it should be codesigned.

Unless you are logged in as root, it should ask you once for the password. A dialog should pop up (at least it does for me).

Unfortunately the screen shot does not help much. Can you generate, and attach a logfile?
Step for doing so: https://forum.lazarus.freepascal.org/index.php/topic,42869.0.html

It may be necessary that you have to recompile your IDE with debug settings
Menu: Tools > configure build lazarus
In the Options field add, if your IDE itself is 64 bit: -gw
if your IDE is 32bit: -gs

It may also be that you may have to run the IDE under lldb. I will know after looking at the log. If so I will provide detailed steps.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 07, 2019, 06:58:46 am

Thanks martin_fr

I don't recall ever being prompted for the password - of course thats not to say it didn't a happen

Attached is the log you asked for

I tried the lazarus rebuild with -gs and all I got was a bunch of

Compile package FCL 1.0.1: Exit code 1, Errors: 11
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.
Error: assembler: error: unsupported directive '.stabs'. Hint: Use another type of debug info.

Thanks again

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 07, 2019, 02:29:11 pm

Ok.
Unfortunately fpc misses a feature on Mac, that would allow to collect further info in the log file. (Not the reason of the crash, just making it a few extra steps to find out why it happens)

So you will need a few extra steps.

1) rebuild the IDE, this time with -gw (even for 32bits)

2) start the IDE in lldb
Open a terminal, and run

Code: [Select]

lldb /path/to/lazarus/lazarus.app/Contents/MacOS/lazarusIn lldb enter: r
and return

3) Use the IDE, when the crash happens the lldb in the terminal should print something like:

Code: [Select]

Process 39997 stopped
* thread #14, stop reason = EXC_BAD_ACCESS (code=1, address=0x11d0c1000)
    frame #0: 0x000000010000cc44 Lazarus`SYSTEM_$$_DEFAULTANSI2UNICODEMOVE$PCHAR$WORD$UNICODESTRING$INT64 + 52
Lazarus`SYSTEM_$$_DEFAULTANSI2UNICODEMOVE$PCHAR$WORD$UNICODESTRING$INT64:

in lldb enter (followed by return): bt

Copy the output and post it here (or copy to a file and attach)

Note that lldb may give data for the wrong thread, so you need to repeat the "bt" and add more data.
In lldb enter: thread list

This will list a number of threads (starting at 0 or 1), for each of them do (replacing 1 by the thread number
thread select 1
bt

At least one, probably two of the results should contain some of the units names, of units used in the IDE.

I understand your IDE is 32 bit, and you compile your app for 64 bit?
While this should work, it is possible that the crash is related to this cross debug situation.

It would be good to have the data to fix this. But you might want to try and build your IDE for 64 bits (so that may give you other limitations, outside the debugger). It may then be able to debug your app.
Or you can debug your app compiled for 32 bit, and then later build for 64 bit.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 07, 2019, 09:58:26 pm

Hi,

Ok, attached is the lldb output. I've include the output for all 5 threads that were listed, but only 1 looks relevant I'm guessing

I tried compiling for 32bit and the debug failed in the same way... "Access Violation". I haven't tried any of the steps you previously suggested, with this 32bit compile. Happy to do so if you think it worthwhile

I'm not sure I'm ready to attempt to build a 64bit IDE and deal with any loss of functionality, least not yet - this is my first gui app in over 20yrs and the learning curve is pretty steep as it is

Thanks for all the help

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 08, 2019, 12:53:11 am

I had a first look at it.

The crash is probably a side effect. It seems that the debugger has problem reading the debug info from the app.

So in all likelihood, if it did not crash, it would start the app, but you could not inspect any data, because the debugger did not read the info what variable your app has.

Step by step:

1) around line 1100
/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas

Code: Pascal [Select][+]

    FMemManager := Loader.MemManager;
    FDwarfInfo := Loader.DwarfInfo;
    Result := Loader.ReaderErrors;
    Loader.Free;
 
    if FDwarfInfo.Image64Bit then
      FPrettyPrinter := TFpPascalPrettyPrinter.Create(8)
    else
      FPrettyPrinter := TFpPascalPrettyPrinter.Create(4);
    exit;

the line

Code: Pascal [Select][+]

    if FDwarfInfo.Image64Bit then
 

should be

Code: Pascal [Select][+]

    if FDwarfInfo = nil then exit;
    if FDwarfInfo.Image64Bit then
 

I have to do some tests, if there will be further error (crash) after this.

THis leaves the question why the debug info is not read ....

Are you able to debug an empty project /form with just a button , and a button-click handler "caption:='test me';" ?

What settings did you do in your project?
Can you send a copy of the project.lpi file? (Unless the next few question bring up an answer)

Is you debug type set to either "dwarf", "dwarf with sets" or "dwarf 3"
And you follow the settings in
http://wiki.lazarus.freepascal.org/Debugger_Setup

Do you use "external debug symbol" ?
If so, can you try with/without?
After you used it, there will be a folder projectname.DSYM => delete this folder after debugging (before switching off external info)

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 08, 2019, 04:42:17 am

Quote

Step by step:

1) around line 1100
/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas

I made the changes and rebuilt the IDE with no effect.

Quote

What settings did you do in your project?
Can you send a copy of the project.lpi file? (Unless the next few question bring up an answer)

I've create a barebones project with your suggestions; entire project is at the attached Dropbox link

To keep things simple, I've compiled on 32bit only

Also on Dropbox is a PDF of screen dumps of IDE & Project settings

Quote

Is you debug type set to either "dwarf", "dwarf with sets" or "dwarf 3"
And you follow the settings in
http://wiki.lazarus.freepascal.org/Debugger_Setup

I believe so as best as I can figure out since the page describes GDB.

Quote

Do you use "external debug symbol" ?
If so, can you try with/without?
After you used it, there will be a folder projectname.DSYM => delete this folder after debugging (before switching off external info)

I'm going to have to plead ignorance on this one. I don't think I even know what one is :)

Cheers

File here because they're to big to upload ... https://www.dropbox.com/sh/ytkixv0rir29xlk/AACieRZ9x4yF0Edpd2a_MVOma?dl=0 (https://www.dropbox.com/sh/ytkixv0rir29xlk/AACieRZ9x4yF0Edpd2a_MVOma?dl=0)

Title: Re: Problems with Debugger on OSX
Post by: dbannon on April 08, 2019, 04:48:34 am

Quote from: ahnz on April 08, 2019, 04:42:17 am

I believe so as best as I can figure out since the page describes GDB.

I suspect martin may have meant this wiki page - http://wiki.freepascal.org/Installing_Lazarus_on_MacOS_X
gdb can be made work under OSX but its not a simple process. LLdb is ....

Do check the formats you are using.

Davo

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 08, 2019, 06:06:47 pm

Quote from: ahnz on April 08, 2019, 04:42:17 am

Quote
Is you debug type set to either "dwarf", "dwarf with sets" or "dwarf 3"
And you follow the settings in
http://wiki.lazarus.freepascal.org/Debugger_Setup

I believe so as best as I can figure out since the page describes GDB.

I started updating the wiki, to point out the differences with LLDB. Or to mention were the same settings apply to LLDB.

There is also some work to be done in the IDE, where many labels refer to GDB, but setting often apply to both.

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 08, 2019, 06:20:16 pm

Quote from: ahnz on April 08, 2019, 04:42:17 am

Quote
What settings did you do in your project?
Can you send a copy of the project.lpi file? (Unless the next few question bring up an answer)

I've create a barebones project with your suggestions; entire project is at the attached Dropbox link

On a first glance, the settings seem ok.

Quote

To keep things simple, I've compiled on 32bit only

And were you able to run this in the debugger?
Set a breakpoint at "Label1.Caption:='That Tickles';" and see if it stops (when you click the button)?

Or does the debugger crash on this project too?

Quote

Quote
Do you use "external debug symbol" ?
If so, can you try with/without?
After you used it, there will be a folder projectname.DSYM => delete this folder after debugging (before switching off external info)

I'm going to have to plead ignorance on this one. I don't think I even know what one is :)

Menu: Project > Project Options
Page: Debugging

There is a checkbox: "Use external gdb debug symbol file"
(the caption is outdated, it is lldb too)

You can try if your project works, when you change this (i.e. it is likely off now, so you would switch it on)

If you have used it, and you go back to having it switched off:
In the project folder there will be a folder project1.dSYM (much like the project1.app folder). The name follows your project name, but it ends in .dSYM.
This folder is created (during compile) if the option is turned on. But it is never removed. SO if you switch the option off, please remove that folder (*.dSYM) by hand.

More later

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 08, 2019, 10:31:35 pm

Quote

And were you able to run this in the debugger?
Set a breakpoint at "Label1.Caption:='That Tickles';" and see if it stops (when you click the button)?

Or does the debugger crash on this project too?

Quote

There is a checkbox: "Use external gdb debug symbol file"
(the caption is outdated, it is lldb too)

You can try if your project works, when you change this (i.e. it is likely off now, so you would switch it on)

If you have used it, and you go back to having it switched off:
In the project folder there will be a folder project1.dSYM (much like the project1.app folder). The name follows your project name, but it ends in .dSYM.
This folder is created (during compile) if the option is turned on. But it is never removed. SO if you switch the option off, please remove that folder (*.dSYM) by hand.

Cool.. so I've just tried with and without the external symbol file, deleting the directory when the option is turned off. The project fails with the access violation in both cases. I've also run lazarus in lldb and attached is the result... looks like it failed somewhere else this time

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 09, 2019, 08:51:54 pm

Ok, the 2nd crash is already fixed in the fixes branch revision 60649 (and will be gone in 2.0.2)
The line is now:

Code: Pascal [Select][+]

  if (State = dsRun) and (FMemManager <> nil) then

The first crash should be addressed in (also going to be in 2.0.2)
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60900

But that does not solve the main problem.
Both crashes are because the dwarf info was not loaded. And without that, there are no watches, no locals, no value-hints.... In other words the debugger will be useless.

60900 will also add a popup in that case. So at least there is feedback about the problem. (That is unless the user disables those warnings).

I added a try ... except. Just in case.

On top of that, I will be looking through the code, and may ask you to patch in a few "debugln" lines (log output), in order to try and locate were loading fails.

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 09, 2019, 09:18:37 pm

ok, unfortunately the next steps are going to be a bit of a guessing game....

Could you find the file components/fpdebug/fpdbgdwarfdataclasses.pas
Around line 2945

Code: Pascal [Select][+]

constructor TFpDwarfInfo.Create(ALoaderList: TDbgImageLoaderList);
var
  Section: TDwarfSection;
  p: PDbgImageSection;
  i: Integer;
begin
  inherited Create(ALoaderList);
  FImage64Bit := ALoaderList.Image64Bit;
  FCompilationUnits := TList.Create;
  FImageBase := ALoaderList.ImageBase;
 
  SetLength(FFiles, ALoaderList.Count);
  for i := 0 to ALoaderList.Count-1 do
  begin
debugln(['loaderlist ',i,' ',ALoaderList[i]<> nil]); //////////////////////////////
debugln([ALoaderList[i].FileName, ' / ', ALoaderList[i].IsValid]);///////////////////////////////
    FFiles[i].AddressMapList:=ALoaderList[i].AddressMapList;
    for Section := Low(Section) to High(Section) do
    begin
      p := ALoaderList[i].Section[DWARF_SECTION_NAME[Section]];
      if p = nil then Continue;
      FFiles[i].Sections[Section].Section := Section;
      FFiles[i].Sections[Section].RawData := p^.RawData;
      FFiles[i].Sections[Section].Size := p^.Size;
      FFiles[i].Sections[Section].VirtualAddress := p^.VirtualAddress;
    end;
    ALoaderList[i].CloseFileLoader;
  end;
end;
 

Insert the 2 lines, that are marked ////
If possible also apply the try... except from the link in my previous post.

And then do the log again.
Thanks

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 09, 2019, 11:43:08 pm

Hi,

Quote

ok, unfortunately the next steps are going to be a bit of a guessing game....

I'm more than happy to continue to plug away

Quote

The first crash should be addressed in (also going to be in 2.0.2)
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=60900

Quote

If possible also apply the try... except from the link in my previous post

I couldn't figure out from your link to the revision exactly what I need to do and where (something else to add to me "to learn" list).. If you can tell me exactly where and what to change, more than happy to do so

I did however manage to add the debugln lines around line 2945 of components/fpdebug/fpdbgdwarfdataclasses.pas

Quote

Ok, the 2nd crash is already fixed in the fixes branch revision 60649 (and will be gone in 2.0.2)
The line is now:

Code: Pascal [Select][+][-]
if (State = dsRun) and (FMemManager <> nil) then

Ok, I assumed you meant around line 774 of components/fpdebug/fpdmemorytools.pas but when I added as suggested

Code: Pascal [Select][+]

function TFpDbgMemManager.GetCacheManager: TFpDbgMemCacheManagerBase;
begin
  If (State = dsRun) and (FMemManager <> nil) then
    SetCacheManager(TFpDbgMemCacheManagerBase.Create);
  Result := FCacheManager;
end;
 

... the compile failed with

Quote

fpdmemorytools.pas(775,7) Error: Identifier not found "State"
fpdmemorytools.pas(775,15) Error: Identifier not found "dsRun"
fpdmemorytools.pas(775,27) Error: Identifier not found "FMemManager"

so I'm guessing its a different file?

There is no difference in the lldb output (because theres no change to fpdmemorytools.pas, I presume)

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 10, 2019, 12:04:45 am

As for the link, click on "text changed" and it gets you here: https://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/fixes_2_0/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas?root=lazarus&r1=60900&r2=60899&pathrev=60900

You can apply it line by line. (you only need the try except part, line 300-350, making sure any exception will be known)
Or you can download the "patch" (link at top) and then something like
patch -p2 lazarus_inst_dir < patch
I am not sure it may be -p1.

As for the other line (it is the 2nd line in the stack trace)
components\lazdebuggers\lazdebuggerfplldb\fplldbdebugger.pas
line 1120 (yours may differ +/-50)

Code: Pascal [Select][+]

procedure TFpLldbDebugger.DoState(const OldState: TDBGState);
....
      FWatchEvalList.Clear;
    end;
  end;
  if (State = dsRun) and (FMemManager <> nil) then
    TFpLldbDbgMemCacheManagerSimple(FMemManager.CacheManager).Clear;
end;
 

Above already contains the changed line.
After " if (State = dsRun) and (FMemManager <> nil) then"
before " if (State = dsRun) then"

Again, dont worry about that line. If you crash there the problem has happened way before.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 10, 2019, 01:31:36 am

Hi,

*** SUCCESS ***

I think we have it working! - Unless you have any counter ideas and want me to try different things

I tried the patching, applying line by line but I think its become apparent that I don't have the previous revisions and things like FReaderErrors which are there in rev. 60899 (and maybe earlier) don't existing in my base v 2.0.0 install and so a recompile of the IDE failed. Maybe I need to learn how to keep upto date with these revisions rather than waiting for a new stable release such as 2.0.2.

Quote

As for the other line (it is the 2nd line in the stack trace)
components\lazdebuggers\lazdebuggerfplldb\fplldbdebugger.pas
line 1120 (yours may differ +/-50)

Code: Pascal [Select][+][-]
procedure TFpLldbDebugger.DoState(const OldState: TDBGState);
....
FWatchEvalList.Clear;
end;
end;
if (State = dsRun) and (FMemManager <> nil) then
TFpLldbDbgMemCacheManagerSimple(FMemManager.CacheManager).Clear;
end;

Above already contains the changed line.

I did manage to get this done and hey presto, the barebones app compiles and runs with debug without issue

My own app, now compiles with both 32/64bit and runs with debug, but I'm getting a project raised exception class "EInvalidGraphic" with message Unknown picture format'. This is odd because the application works fine without complaint if run without debug.

I just need to now figure out how to use the debugger properly - any suggested links on good tutorials??

Thanks for all your help - much appreciated!!!!

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 10, 2019, 02:29:22 am

Code: Pascal [Select][+]

if (State = dsRun) and (FMemManager <> nil) then

And with that line added, you can see locals, and inspect variables?

About the exception. The debugger will tell you about every exception when it is "raise"d. Even those, that are later caught and handled.
So try continue on the exception, maybe it gets handled.

You can add individual exceptions (by exception class) to an ignore list. But that is independent of they being handled, or if there is an except block or not.
To add them there is a checkbox in the dialog. To see those added, go to Tools > Option >Debugger > Language Exception.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 10, 2019, 04:51:38 am

:( Now that I've had a chance to play with it, I can see that while the Debug stops at the break point and I can step through the app. I can not in fact see any local variables

Of the Debug Windows, only the BreakPoint, Register, Call Stack and Thread windows give any information.

When trying to open an Assembler window lazarus bails with the attached lldb output.

The exceptions with my main app can be "continued" though. However when I close the app I get the attached error - don't know if its relevant or related to any of this, hence whyI include it.

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 10, 2019, 03:04:33 pm

As I expected.
Bit of background.

"DWARF" => This is the name of a debug info format. It is the format used on Mac. (And other OS)
It tells the debugger where variables (and other things) are in your exe.
So if you want to see "Form1" then the debugger looks at the dwarf info, and finds the address at wich Form1 is in memory. It also finds out what fields a "TForm" has.

Now when loading of this fails the debugger in the IDE does not even create instances of some classes. (It has no data to store in them). Maybe that will change in future, but for now...

Some code did/does not check the "nil" value of those objects => crash.
So the crashes can be fixed easy. (And I will look at the asm window)

But the data is still not there. And we need to find out why.

I went through the logfile that you supplied, and compared it against the 2 crashes.
The dwarf is attempted to be loaded in "TDwarfLoaderThread.Execute;". This is the default, and it is confirmed by the log.

Actually the "debugln" I ask you to add are probably in the wrong place. (But leave them in, they are not harmful either)

I just went through the date again, and I made some wrong conclusions the first time.

So here goes again. Lets start with
TDwarfLoaderThread.Execute;
line 290 onwards
components\lazdebuggers\lazdebuggerfplldb\fplldbdebugger.pas

This is the unmodified 2.0.0 prior to applying the "try except"
So it does not have any other fixes branch modification, that you may not yet have.

You may also follow the svn link, and download the entire new file. (keep a backup of your old file).
The new file may compile, but I am not sure, it may need 1 or 2 other files.

In the below I have added some debugln.

Code: Pascal [Select][+]

procedure TDwarfLoaderThread.Execute;
var
  AnImageLoader: TDbgImageLoader;
begin
  debugln(DBG_VERBOSE, ['THREAD TFpLldbDebugger.LoadDwarf ']);
  AnImageLoader := TDbgImageLoader.Create(FFileName);
debugln('THREAD AFTER TDbgImageLoader.Create'); ////////////////////////////////
  if not AnImageLoader.IsValid then begin
    debugln(['THREAD NOT VALID ']); ////////////////////////////////
    FreeAndNil(AnImageLoader);
    exit;
  end;
  debugln(['THREAD VALID ']); ////////////////////////////////
  if Terminated then
    exit;
 
  FImageLoaderList := TDbgImageLoaderList.Create(True);
  AnImageLoader.AddToLoaderList(FImageLoaderList);
  debugln(['THREAD LOADERLIST 1 ']); ////////////////////////////////
  if Terminated then
    exit;
  debugln(['THREAD LOADERLIST 2 ']); ////////////////////////////////
 
{$IFdef WithWinMemReader}
 
 

We probably need more changes.... Including some of the ones already in fixes branch.

Of course 2.0.2 is due in the next 2 weeks. So we can wait. On the otherhand, anything we get done by this Friday (maybe Saturday) may still get into 2.0.2.

As I said you can try to download entire files from the svn link. There are more details on which files to get:
https://forum.lazarus.freepascal.org/index.php/topic,42869.0.html

Or you can checkout from svn:

Code: [Select]

svn co https://svn.freepascal.org/svn/lazarus/fixes_2_0 target_folderTo update later: svn update

And then (IIRC) in that folder just run

Code: [Select]

make bigide LCL_PLATFORM=carbon CPU_TARGET=i386or

Code: [Select]

make bigide LCL_PLATFORM=cocoa CPU_TARGET=x86_64
You can do that in a separate folder. So it will not mess with your install.
In that folder create a file (with a text editor)
lazarus.cfg
containing one line:
--primary-config-path=/Users/yourname/laz_2_conf

You can choose a diff path of course, and you need to create this folder. This file will make sure, that the 2nd Lazarus uses its own config. (You need to configure it from scratch)

This also allows you to follow the fixes branch.

---
One more alternative. Depending on how many patches/changes I would have to ask you to apply for testing, another option may be preferable.
Obviously those testing changes do not go to svn. But I do run my private git mirror, to which I can push them. (So you do not need to apply them by hand)
It is as (almost) simple as the svn above.

Code: [Select]

git clone https://github.com/User4martin/lazarus.git target_dir
cd target_dir
git checkout -f fixes_2_0

The -f to override local changes (if you later have some)
To update: git pull
Or if you have local changes: git stash save; git pull; git stash pop

And then build as above and create the lazarus.cfg file

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 10, 2019, 11:26:42 pm

Quote

Of course 2.0.2 is due in the next 2 weeks. So we can wait. On the otherhand, anything we get done by this Friday (maybe Saturday) may still get into 2.0.2.

Happy to help where I can

This is the option I went for ....

Quote

Or you can checkout from svn:
svn co https://svn.freepascal.org/svn/lazarus/fixes_2_0 target_folder
To update later: svn update

Incidentally, I think the link should be https://svn.freepascal.org/svn/lazarus/branches/fixes_2_0/

Quote

And then (IIRC) in that folder just run
make bigide LCL_PLATFORM=carbon CPU_TARGET=i386

You can do that in a separate folder. So it will not mess with your install.
In that folder create a file (with a text editor)
lazarus.cfg
containing one line:
--primary-config-path=/Users/yourname/laz_2_conf

So I now have rev 60918 running in a seperate directory

My barebones app compiles and runs Ok with Debug, but I get the warning... The debugger encountered some errors/warnings ..... "Failed to load Dwarf debug info"

I can step through the app but still can not view any local variables. The attached lldb4.txt shows lldb output from the point where the app starts run and the breakpoint point has been stepped out of - I don't know what else I can give you to help figure out why local variables aren't viewable

Attempting to open an Assembler windows still bails. The attached lldb5.txt is the lldb output from the exception attempting to open an Assembler debug window

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 11, 2019, 12:12:47 am

Ok, so this weird.

I had a thought that maybe the fact the project was on my NAS might be responsible. I have had strange issues in the past where other, entirely unrelated things worked better locally than over an AFP share on a NAS. So I copied the project to my local machine.

And it worked.. ONCE!

I could step through and watch local variables. So I modified the code to include a call to a new function from a for loop. But then the debugger wouldn't even stop on the break point. So I took the for loop out.. No different. Then after a few attempts I also started to get the message "Oops the debugger entered the error state. Save your work now!"

I've tried copying the project locally again - no different

I've even rebooted - no different!!!!

Now every tie I try and debug, I get the "Oops" message

Is it possible that lldb save something somewhere which is getting corrupted??

UPDATE:

I'm looking to get some lldb output for this and I noticed a lot of these appearing....

Code: [Select]

The timestamp of the object-file "/Users/andy/Lazarus/lcl/units/i386-darwin/carbon/carbontabs.o" does not correspond to the timestamp (11/04/2019 08:51:15 am) stored inside the executable. The debug-info in this file is not loaded.

More to come

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 11, 2019, 12:33:54 am

Quote from: ahnz on April 11, 2019, 12:12:47 am

I had a thought that maybe the fact the project was on my NAS might be responsible. I have had strange issues in the past where other, entirely unrelated things worked better locally than over an AFP share on a NAS. So I copied the project to my local machine.

And it worked.. ONCE!

I will look at why the IDE may not load the files.... and add debugln.

Quote

Now every tie I try and debug, I get the "Oops" message

Is it possible that lldb save something somewhere which is getting corrupted??

UPDATE:

I'm looking to get some lldb output for this and I noticed a lot of these appearing....

Code: [Select]
The timestamp of the object-file "/Users/andy/Lazarus/lcl/units/i386-darwin/carbon/carbontabs.o" does not correspond to the timestamp (11/04/2019 08:51:15 am) stored inside the executable. The debug-info in this file is not loaded.

So that would mean you can't step into the the LCL.

I am assuming that for you (in your timezone) this time was already in the past, at the time you got that msg? (for me it is yet to come)

You may want to try to do a "clean" build of your app. (there should be an entry in the run menu).

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 11, 2019, 01:45:30 am

I attached a patch with some debugln.

If you could apply it

Code: [Select]

cd your_laz_fixes_dir
patch -p1 <debugln.diff

And then create a logfile with the error (no watches) happening.

Thanks

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 12, 2019, 01:58:00 am

Quote

I am assuming that for you (in your timezone) this time was already in the past, at the time you got that msg? (for me it is yet to come)

Yep, I'm in New Zealand and currently we're GMT+12

Quote

You may want to try to do a "clean" build of your app. (there should be an entry in the run menu).

I did a Clean & Build and it init make any difference

Quote

I attached a patch with some debugln.

If you could apply it
cd your_laz_fixes_dir
patch -p1 <debugln.diff

Result:

Quote

patch -p1 <debugln.diff

patching file components/fpdebug/fpdbgdwarfdataclasses.pas
patching file components/fpdebug/fpdbgloader.pp
patching file components/fpdebug/fpimgreaderbase.pas
patching file components/fpdebug/fpimgreadermacho.pas
patching file components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas
Hunk #1 FAILED at 304.
Hunk #2 succeeded at 345 (offset 19 lines).
1 out of 2 hunks FAILED -- saving rejects to file components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas.rej

This is the first time I've applied patches like this, so I'm not sure what to do with this.

Reject file is attached along with the pre and post-patch versions of fplldbdebugger.pas

Regards

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 12, 2019, 10:35:18 am

Oh, I see what happened.

I did create the patch based on the fixes branch. But I had merged another revision to fixes already. And you had not run "svn update" yet.

There are several way forwards.

1) You can update

If you run (cd laz_folder)
svn update

it may either
- work fine
- report a conflict (since you have changes, after applying the patch), if ask answer "tf" (their file / which will give up your local changes)

If it works fine => apply the patch again. It should tell you that some parts were already there, and do the remainder

Or if it works fine, or you get a conflict.
svn -R revert .
will revert all your changes

And then apply the patch again

2) You can leave the patch as it is.
The important bits have been applied, and it should compile.

If you look at the *.rej file, you can open components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas
go to line 300 and add the debugln yourself.

the indent changed, so the line differs on spacing, and patch did not like that. (there must be a way to tell it, to ignore that, but....)

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 14, 2019, 10:42:36 pm

Ok, now I have rev. 60971 plus your patch.

I did get an error when recompiling the IDE after the patch at 210 of FpImgReaderBase.pas. Semi-colon missing ...

Code: Pascal [Select][+]

    if (FileExists(s)) then AFileName := s
debugln(['TDbgFileLoader ',AFileName]);
 

Adding the semi, all compiled Ok.

Clean & Build, followed by Run (with Debug) of the barebones app produced the same "Oops" message, momentarily followed by the main form of the app being displayed

The breakpoint in the app click event shows

Quote

Invalid (On)
Hitcount: 0
Action: Break
Condition:

Code: Pascal [Select][+]

procedure TForm1.Button1Click(Sender: TObject);
var
  s: string;
  i : integer;
begin
  s := 'That Tickles, ';            // <----- Breakpoint is here
  Label1.Caption := s;
end;

The debug log shows only

Quote

TCarbonButton.SetFocus Error: SetKeyboardFocus failed with result -30585
TCarbonButton.SetFocus Error: SetKeyboardFocus failed with result -30585
TCarbonButton.SetFocus Error: SetKeyboardFocus failed with result -30585

An lldb output of the sequence of events is attached

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 15, 2019, 01:21:17 am

Did you start the IDE with the entire

Code: [Select]

 --debug-log=/path/to/yourfiles/laz.log --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

?
Make sure DBG_VERBOSE is in the line.

Because some of the info is missing.

What I found from that log:

1)
Something else went wrong. lldb (the one used by the IDE, not the one you run on the outside) itself refused to start your app. Unfortunately (probably due to the commandline above not present?) the reason why lldb refused, was not captured.

2)
I believe this run did not have the issues that lead to the initial crash (even if that had not been fixed)
The class that would have had to be nil to cause the crash, seems to have been created (there is a log entry that was written very late in its constructor, very small change that it would still have crashed out after that)

3)
Many files were not loaded. (Some were).
I need to add some debuggln what is wrong with that timestamp

components/fpdebug/fpimgreadermacho.pas
line 184
There is a debugln, replace it with

Code: Pascal [Select][+]

          debugln(Format('The timestamp of the object-file "%s" does not correspond to the timestamp (%s) stored inside the executable. The debug-info in this file is not loaded.', [DwarfDebugMap.ObjectFile, DateTimeToStr(FileDatetoDateTime(DwarfDebugMap.ObjFileAge)), ' <> ', DateTimeToStr(FileDatetoDateTime(FileAge(ASubFiles[i])))]))
 

The current debugln start the same, just something added at the end.

I suspect that somehow maybe the time is compared in diff timezones. But lets see.
And also need to find out, if fpc has the same issue.

Or there is an issue in fpc, and it writes the wrong time... That would be a problem...

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 15, 2019, 02:19:37 am

Quote

Did you start the IDE with the entire
--debug-log=/path/to/yourfiles/laz.log --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
?
Make sure DBG_VERBOSE is in the line.

Apologies - my bad

Quote

components/fpdebug/fpimgreadermacho.pas
line 184
There is a debugln, replace it with

Done!

This was run with

Quote

/Users/andy/Lazarus/lazarus.app/Contents/MacOS/lazarus --debug-log=/Users/andy/Desktop/debug_log.txt --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 --primary-config-path=/Users/andy/laz_2_conf

I did a Clean & Build on the barebones app followed by a Run with debug

Local time is 12:15 on 15-April

Debug log is attached

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 15, 2019, 01:45:15 pm

Just for clarification:

It is your project that is on the NAS (except the compiled app?):
/Users/andy/Documents/BareBones/project1.app
/mnt/NAS/Documents/Andy/Pascal/src/BareBones/lib/i386-darwin/project1.o
/mnt/NAS/Documents/Andy/Pascal/src/BareBones/lib/i386-darwin/unit1.o

But not the IDE, neither the packages of the IDE:
/Users/andy/Lazarus/lcl/units/i386-darwin/carbon/carboncalendarview.o

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 15, 2019, 04:47:29 pm

Short update:

1) The problem that caused the original crash (and probably also the inability to watch variables/locals), seems to have gone. At least it was again not present. Anyway the crash is fixed.

2) The reason for the failed launch (debug session aborted before project is started) is a filename matching the IDE trigger for another error message. Working on a fix.

3) The reason some debug info is not loaded (timestamp issues).
Still no good explanation. This is something that likely the linker would have caused. And the linker is part of Apple's tool chain (developer tools). Not much that can be done.
A clean build may help (including clean build of packages). Yet it seems mostly package files (lcl and co) are affected. So if you do not need to step into them, then this may not be an issue.
Also it is possible that this particular part will be better with "external debug info". Though I am not sure.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 15, 2019, 10:34:17 pm

Quote

Just for clarification:

It is your project that is on the NAS (except the compiled app?):

Originally, my project was on the NAS, including the compiled App. But cognisant of strange occurrences with other, entirely unrelated apps, I decided to copy the project to my local drive to eliminate the possibility of issues with an AFP share an the NAS.

When I first tried the things I did for you yesterday I noticed the NAS being referenced in the debug_log so I (a) completely deleted the project from the NAS and (b) checked there was no occurrences of NAS in any of the project files.

Then, when I did the final debug for you I could see no references to NAS so there shouldn't be any reference to it now

Quote

2) The reason for the failed launch (debug session aborted before project is started) is a filename matching the IDE trigger for another error message. Working on a fix.

3) The reason some debug info is not loaded (timestamp issues).

It looks like I've fixed these - though I have said that before and was proven wrong, so I do want to do some ore testing before I confirm completely. What had happened is, when I copied my project from the NAS to the local drive, the Application Bundle which is effectively a symbolic link to the compiled app, was expanded and the then compiled app copied rather than the link. The result being that no matter how many changes and compiles I did, I was always running the same version of the app from days ago. Instead of running the freshly compiled ./BareBones/project1 I was always running BareBones/project1.app/Contents/MacOS/project1

Once the Application Bundles was deleted and recreated I can now compile and run with debug and, step through. though I do have one question.

When I step though this ...

Code: Pascal [Select][+]

function TForm1.GetHe: string;
begin
  GetHe := 'He ';
end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  s: string;
  i: integer;
begin
  s := 'That Tickles, ';
  for i := 1 to 3 do
    s := s + GetHe;
  Label1.Caption := s;
end;
 

... and view the local variables, the string 's' only shows the first character... is that normal?

All up it looks like the issue is resolve - but I say that once before so.. I'm off to do some more testing

Just for good measure, the debug_log is attached

Anything else you want me look at, just let me know

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 15, 2019, 10:47:28 pm

Quote from: ahnz on April 15, 2019, 10:34:17 pm

... and view the local variables, the string 's' only shows the first character... is that normal?

I have to check, so I would expect not.
Does it happen in the watches win too?

Are you using dwarf+sets or dwarf-3 ?

----------------
Just noted something in the log.
That is a 32bit app?

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 16, 2019, 12:23:28 am

I was using dwarf-3. The same thing happened with the watch Window, only the 'T' was shown.

With dwarf-2 and with-sets, it appears to work ok with both the local variables and watch windows correctly showing the string.

I've compiled my bare bones with 32bit and 64bit and all appears well with debug.

I've now got another issue which may or may not be a debug problem, I don't know.

Copied my main project to my local drive, fixed up the application bundle. Its 64bit. Its uses SQLite and works perfectly Ok if compiled with a bog standard Lazarus v2.0.0. However, with rev 60971 ....

Clean & Build, Run without Debug.. It errors with "Can not load SQLite Client library "libsqlite3.dylib". Check you installation" - If I Ok this app runs ok (without access to the DB) and terminates cleanly when I close

Clean & Build, Run WITH Debug.. It errors with "Can not load SQLite Client library "libsqlite3.dylib". Check you installation" - If I Ok this app runs ok (without access to the DB) but when I close the app it error with an exception

/usr/lib/libsqlite3.dylib exists and including /usr/lib with -FI make no difference

Q.

Why would rev 60971 failed to find the SQLlite library, when the same app compiled under Laz 2.0.0 work perfectly Ok

Does this also point to a debugger issue not dealing with another nil object somewhere?

Attached is the debug log from the failed Run with Debug

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 16, 2019, 12:53:06 am

I cant see how the sqlite issue would be debug related. The exception may just be un-noted outside the debugger.

AFAIK sqlite is part of the fpc packages (the stuff in lazarus seems to be just the component editor and registration). Since your updated lazarus use the same fpc, it should use the same code.

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 16, 2019, 01:36:51 am

The string len issue appears to be an fpc issue https://bugs.freepascal.org/view.php?id=35386

It only applies to 32 bit with dwarf-3.

You may be able to inspect the value using (if pchar is used by your app, and the debugger can find it)
pchar(thestring)

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 17, 2019, 05:15:05 pm

I improved error detection during launch. For now in trunk only. (2.0.4 depends on further testing)
Trunk Revision: 61001
LazDebugger(Fp)Lldb: improve checks for errors during launch command. Ignore text in file names.
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=61001

So if the timestamps are wrong, the app should now launch (it did fail in some cases, if certain filename where involved, i.e. the word "process" in a filename).

However debug info for any file with wrong timestamp is not loaded. Not by the IDE, and not by LLDB. So for those files (listed in the something went wrong dialog), neither breakpoints nor watches will work.

As to what exactly causes the wrong timestamps is unclear. And currently all the info suggests that it is done by Apple's toolchain. But that is a guess....

At the very start of this thread (when things were still crashing) there also was an issue that the IDE could not watch variables in files with correct time stamp. This has not been reproducible since the use of fixes branch.
For now I will assume that it was fixed since the release.

If it re-occurs (breakpoint works in a file, but watches do not) then logs for this are welcome.

As for issues with values of watches (such as the string being shortened). Those should be kept to be reported.

Currently known:
- interfaces => do not show / ident not found
- function references (type TFOo= function...) => ident not found
- Most string types will cut off at the first #0
- there are hardcoded length limits (string/array) 3000 or 5000
- ansistring, 32bit dwarf 3 => only first char
- most values of untyped constants are not shown: const a= 5;

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 17, 2019, 10:06:47 pm

Hi,

Quote

As to what exactly causes the wrong timestamps is unclear.

I believe the problem was a mistake on my behalf...

Quote

What had happened is, when I copied my project from the NAS to the local drive, the Application Bundle which is effectively a symbolic link to the compiled app, was expanded and the then compiled app copied rather than the link. The result being that no matter how many changes and compiles I did, I was always running the same version of the app from days ago. Instead of running the freshly compiled ./BareBones/project1 I was always running BareBones/project1.app/Contents/MacOS/project1

The only problem I have now that I need to solve is why my app compiles and runs ok for 2.0.0 but fails to find/load libsqlite3.dylib when compiled and run with/without debug under rev 60971

Thanks for all your help with this - much appreciated

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 24, 2019, 02:58:15 am

Hi,

I have an update.

I've installed 2.0.2 and removed the second install I had.

My app, which is 64bit using cocoa, with project files saved locally to my machine

(1) If I do a Clean & Build and run without debug... all is fine. App executes and terminates normally

(2) If I Clean & Build, and then run with debug. The App executes and debugs fine, but throws a EXC_BAD_ACCESS at winapi.inc line 180 (I've overcome the early issue with an Invalid Image error so don't understand why with not other handled exceptions this would occur)

When my app project files are on my NAS - same app, same files, no mistakes with the application Bundle, same .lpi

(3) I do a Clean & Build and run without debug... all is fine. App executes and terminates normally

(4) However, from the NAS if I Clean & Build and run with debug I get the "Failed loading Dwarf debug info"

Then, in order to help debug the loading problem (4) I run Lazarus from the command line ...

Quote

/Developer/lazarus/lazarus.app/Contents/MacOS/lazarus --debug-log=/Users/andy/Desktop/laz.log --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

.. I hit the problem with unable to load the sqlite3 library. This happens after a Clean Build, Running with and without debug, with both the Local and NAS based project files

Below are the subsequent logs for (4) run with and without Debug

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 24, 2019, 11:38:43 pm

Ok, the log only shows the not found lib. And a crash at exit of the app (LCL cocoa code attempts to free some object)

If the dyLib issue is to do with starting the IDE from command line (I don't know, but it could be that this inherits diff environment from the terminal...), then we need a way to get the log. But start the IDE without using a terminal.

This should be possible.
Afaik you already have created a "lazarus.cfg" file for the primary config path?

Open that file, and put (2 lines) into it

Code: [Select]

--debug-log=/Users/andy/Desktop/laz.log
--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

That should (I hope) do the same job. Otherwise it would be possible to recompile the IDE with some flags, and permanently enable the log.

If you do not want to always write the file, then install the package IdeLazLogger
From the 2 lines above, only add the 2nd ("--debug-enable") line.
No logging should happen. But you can open the Tools menu, and select Logging, and specify a file.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 25, 2019, 10:30:48 pm

Ok, I hadn't created a lazarus.cfg ... we did that as part of an earlier exercise where I had two installs, but now I only have one install of 2.0.2.

I created the file as suggested and yes, it stops the sqlite3 lib error....

Here the log it produces.

Cheers

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 25, 2019, 10:49:13 pm

UPDATE

FWIW, even though I get the "unable to load dwarf info" message, the debug stops ok at the breakpoints but no local variables or watchpoints is shown

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 26, 2019, 12:54:52 am

Maybe this helps with the dylib? https://stackoverflow.com/questions/17703510/dyld-library-not-loaded-reason-image-not-found

Unfortunately the laz.txt (April 25, 2019, 10:30:48 pm) is incomplete.
So the cfg file did not do the trick.

Is that laz.txt for the case: breakpoint works, but watches not? It does not show reaching any breakpoint?

Before I ask for more work:
I am happy if you are willing to contribute your time. And my time is available too.
For some of the issues, the investigation is probably at best (if at all) going to improve error messages. The problem itself may be out of reach. (I.e. the wrong timestamps seem to be down to tools from Apple. Those I can not change.

The best way to get the log working, without needing a console would now be:

Menu: Tools -> Configure build Lazarus
In the big "Options" field add the following:

Code: [Select]

-dDBG_CMD_ECHO -dDBG_STATE -dDBG_DATA_MONITORS -dDBGMI_QUEUE_DEBUG -dFPDBG_DWARF_ERRORS -dFPDBG_DWARF_WARNINGS -dFPDBG_DWARF_VERBOSE_LOAD -dFPDBG_DWARF_DATA_WARNINGS -dDBG_VERBOSE -dDBG_WARNINGS -dDBG_STATE -dDBG_EVENTS -dDBG_THREAD_AND_FRAME

Save the settings, you do not need to build at this time.

Menu: Package -> Install/Unistall Packages
On the right hand find the package "IdeLazLogger" and install it.
"Save and rebuild"
Confirm the next dialog.

When you restart the IDE, the tools menu has an entry "Logging".
It shows all the enabled logging tags (from the list above), the one from the list should all be checked. The others can be ignored (eg Syn*). And you can specify a logfile.

Then hopefully we will get full logs.

Sorry for all the complications.
And as I said, I appreciate any info I can get, even if it may only lead to very small improvements.
But I also understand, if at some stage you have other work to get done.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 26, 2019, 01:21:49 am

Quote

Before I ask for more work:
I am happy if you are willing to contribute your time. And my time is available too.

Sorry for all the complications.
And as I said, I appreciate any info I can get, even if it may only lead to very small improvements.
But I also understand, if at some stage you have other work to get done.

I am more than happy to continue to work through this - I'm semi-retired with plenty of time and I'm learning much... though I do need to cut the grass this afternoon :(

Suggested changes made, and a new log file its attached. This includes executing the application with breakpoint enabled and hit, though to termination. A quick look a the log file and its clear there is much more information, and even I believe an suggestion that the EXC_BAD_ACCESS at the end might be related to my Splash screen

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 26, 2019, 01:57:12 am

Ok, better. Yes the log seems complete.

It does not yet tell me, why watches are empty (and presumingly "locals" vars in the locals window are empty to?).
For that I will have to add more debugln. (i.e. attach a patch for you). Gimme a day or two...

Which version of Lazarus did you use for this?
svn fixes, 2.0.0, or 2.0.2 ? (I can then make sure, I base the patch on the correct version)

As for the dylib issue.
I noted that your environment option are different when starting from a terminal. (the terminal may change them)
Maybe that affects were the dylib is expected?

You can see the env, in the IDE under menu View > ide internals > about IDE (and then scroll down).
Or run "env" in the terminal.

If you run from terminal this is present: DYLD_FALLBACK_LIBRARY_PATH=:/usr/local/mysql/lib
Without terminal this is not set.

Also PWD (working dir) is only set, under the terminal.
And PATH has a lot more entries.

You can try to set/unset it for your app (when running from the IDE), under menu Run > Run Parameters

I do not know if any of that is related to the dylib issue. But it may be worth a shot.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 26, 2019, 03:41:26 am

Thanks

Quote

As for the dylib issue.
I noted that your environment option are different when starting from a terminal. (the terminal may change them)
Maybe that affects were the dylib is expected?

If it's all the same to you, and the logging works ok now, I'll just accept theres a difference and leave it at that. Unless of course you particularly want me to delve in for your interest?

Quote

Which version of Lazarus did you use for this?
svn fixes, 2.0.0, or 2.0.2 ? (I can then make sure, I base the patch on the correct version)

Yes, its a standard 2.0.2 install on OSX and the only version I have installed.

Would I be right in believing the locals and watches having no info is directly related to the "Unable to load Dwarf Debug Info" message I get when running the app with debug???

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 26, 2019, 11:16:56 am

The dylib info was only for if you were interested. Its of no difference to me.

The watches would be down to whatever caused that error.
Btw, the text of the error, is it "The debugger encountered some errors/warnings while launching the target application"?
Because "Unable to load Dwarf Debug Info", I am not aware of.

The error dlg, does it have a "more" button? What info does it provide?

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 26, 2019, 02:10:35 pm

Quote

Btw, the text of the error, is it "The debugger encountered some errors/warnings while launching the target application"?
Because "Unable to load Dwarf Debug Info", I am not aware of.

The error dlg, does it have a "more" button? What info does it provide?

The exact message is attached

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 26, 2019, 08:47:06 pm

Ok, I did a patch with some more debugln output.

To apply it, download then

Code: [Select]

cd /path_to/lazarus
patch -p1 <path_to_download/lldb-debugln.patch

If you can also add
DBG_ERRORS to the list of --debug-enable, or if you added it to "config build laz" then there you add: -dDBG_ERRORS (and recompile the IDE)
Thanks

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 26, 2019, 10:56:47 pm

Thanks

Patch applied, recompile done, application run incl. break point and new log attached

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 26, 2019, 11:26:11 pm

And we are one step closer. This one is probably the reason why you got the crash at the very beginning of this forum-thread.

Now, your project should have (and with the given upper/lower case)
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app

I assume that is the app bundle?
So if looked at from a terminal "ls /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/*" Should list the content of that bundle.

Can you get me the contents of that folder (recursive)?

I would expect
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/ Contents / MacOs / MyStamps

In the given upper/lower case. (without the spaces, they are for human readability only)

This file should be a symlink to
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps

Would be good to do an
ls -la
on each folder.

For some reason the IDE does not find that nested file.

It could also be that the IDE has issues recognizing symlinks on your NAS.

Thanks

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 26, 2019, 11:42:55 pm

Hi.

Here you go ...

Quote

study:~ andy$
study:~ andy$ ls -laR /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app
total 0
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 .
drwxrwxr-x 1 andy wheel 2744 27 Apr 08:52 ..
drwxrwxr-x 1 andy wheel 264 16 Apr 09:17 Contents

/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents:
total 16
drwxrwxr-x 1 andy wheel 264 16 Apr 09:17 .
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 ..
-rwxrwxr-- 1 andy wheel 1231 16 Apr 09:17 Info.plist
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 MacOS
-rwxrwxr-- 1 andy wheel 9 16 Apr 08:56 PkgInfo
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 Resources

/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOS:
total 8
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 .
drwxrwxr-x 1 andy wheel 264 16 Apr 09:17 ..
lrwxrwxrwx 1 andy wheel 17 16 Apr 08:56 MyStamps -> ../../../MyStamps

/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/Resources:
total 0
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 .
drwxrwxr-x 1 andy wheel 264 16 Apr 09:17 ..
study:~ andy$

.. and just for good measure to show the symbolic link points to the executable. ...

Quote

study:~ andy$ ls -l /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps
-rwxrwxr-x 1 andy wheel 51689624 27 Apr 08:46 /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps

study:~ andy$ file /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps: Mach-O 64-bit executable x86_64

I'm going to copy the project to my local drive and try off-NAS. Might take a little longer so I'll get back to you on that

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 26, 2019, 11:46:52 pm

May have to have a look at fpc fileexist....

Just on the off chance, is the folder containing the project
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/
by any chance a sym link?

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 26, 2019, 11:54:22 pm

Also just create a new project, and exectue the following code, and see what output you get:

Code: Pascal [Select][+]

debugln(['fileexist ', fileexists('/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps')])
debugln(['fpgeterrno ', fpgeterrno()]);
debugln([ToSingleByteFileSystemEncodedFileName('/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps')]);
 

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 27, 2019, 01:45:45 am

I copied the project my local drive and the debug works fine locally.

Quote

Just on the off chance, is the folder containing the project /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/ by any chance a sym link?

No it's not.

I have an AFP share on the NAS mounted on the Mac as /mnt/NAS/Documents, all of the folders that make up Andy/Pascal/src/MyStamps are real, none are links

To help eliminate any possibility that I might have missed, or maybe any issue with path length, I created and moved everything to a new mount, but it made no difference

Quote

Also just create a new project, and exectue the following code, and see what output you get:

I've done that, but I don't think anything was logged by debugln's you asked for .. Heres the code .... Have I missed anything?

Code: Pascal [Select][+]

unit Unit1;
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls, LazLogger, LazLoggerBase, FileUtil, BaseUnix;
 
type
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
 
  public
 
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
begin
     debugln(['fileexist ', fileexists('/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps')]);
     debugln(['fpgeterrno ', fpgeterrno()]);
     debugln([ToSingleByteFileSystemEncodedFileName('/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps')]);
     Close;
end;
 
end.
 

The log is attached. I was surprised to see the size of it...its much bigger than previous logs, for a much simpler program

On the up side, my wife is mowing the lawn, so this has saved me from that work :)

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 27, 2019, 01:58:24 am

My bad. I should have been more clear.

I did not need the IDE log for that small app.

Instead, either:
- compile the app
- go to the console
- run the app from the console
It will print its own output

or:
- compile the app
- run it with commandline arg (Run >Run Parameters)
--debug-log=file
And the output will be in the file.

Of course when you run the app, the file
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps
should exist.

The hope is, that the "fileexists" will fail the same way, is it does in the IDE. And that the next line prints why it failed.

The last line, is copied from inside the fpc implementation of fileexists. Just to be sure there is nothing unexpected in that part.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 27, 2019, 02:00:04 am

No worries, I'd just figured that out!...

Quote

fileexist False
fpgeterrno 25
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 27, 2019, 02:06:44 am

Cancel my last post!

I noticed a typo MacOs should have been MacOS ...

Quote

fileexist True
fpgeterrno 25
/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOS/MyStamps

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 27, 2019, 02:36:48 am

Ah!

And yes, Apple documents it as MacOS too.

Though the IDE has several places that do MacOs (that where I copied it from, so it was no type (not in my post, maybe in the IDE though)).

Strange that it works sometimes....
Maybe if files are on a case-insensitive filesystem. Or maybe don't know.

Well, I will look into it.

Thanks a ton, for your persistence.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 27, 2019, 03:14:12 am

I noticed that in one of the logs I sent you that its clearly referencing MacOs ...

Quote

TDbgFileLoader /Users/andy/Documents/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps

So I did a little playing with case... check this out..

Quote

study:Contents andy$ pwd
/Users/andy/Documents/Pascal/src/MyStamps/MyStamps.app/Contents
study:Contents andy$ ls -l
total 16
-rw-r--r-- 1 andy staff 1231 27 Apr 09:56 Info.plist
drwxr-xr-x 3 andy staff 102 27 Apr 09:52 MacOS
-rw-r--r-- 1 andy staff 9 27 Apr 09:52 PkgInfo
drwxr-xr-x 2 andy staff 68 27 Apr 09:52 Resources
study:Contents andy$

study:Contents andy$ cd Macos
study:Macos andy$ pwd

/Users/andy/Documents/Pascal/src/MyStamps/MyStamps.app/Contents/Macos
study:Macos andy$ ls
MyStamps

study:Macos andy$ ls -l
total 8
lrwxr-xr-x 1 andy staff 17 27 Apr 09:52 MyStamps -> ../../../MyStamps
study:Macos andy$

study:Macos andy$ cd /users/andy/documents/pascal/src/mystamps/mystamps.app/contents/macos
study:macos andy$ pwd
/users/andy/documents/pascal/src/mystamps/mystamps.app/contents/macos

study:macos andy$ ls -l
total 8
lrwxr-xr-x 1 andy staff 17 27 Apr 09:52 MyStamps -> ../../../MyStamps

study:macos andy$ ls -l ..
total 16
-rw-r--r-- 1 andy staff 1231 27 Apr 09:56 Info.plist
drwxr-xr-x 3 andy staff 102 27 Apr 09:52 MacOS
-rw-r--r-- 1 andy staff 9 27 Apr 09:52 PkgInfo
drwxr-xr-x 2 andy staff 68 27 Apr 09:52 Resources

study:macos andy$

So while on the surface, OSX appears to be case sensitive, it is clearly tolerant of differences in case. But on the NAS here is no tolerance for errors in case

Quote

study:macos andy$ cd /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/
study:Contents andy$ ls -l
total 16
-rwxrwxr-- 1 andy wheel 1231 16 Apr 09:17 Info.plist
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 MacOS
-rwxrwxr-- 1 andy wheel 9 16 Apr 08:56 PkgInfo
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 Resources

study:Contents andy$ cd Macos
-bash: cd: Macos: No such file or directory

study:Contents andy$ cd MacOs
-bash: cd: MacOs: No such file or directory

study:Contents andy$ cd MacOS
study:MacOS andy$

So I guess it's not surprising that when reference is made to "/Users/andy/Documents/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps", being local to the machine, errors in case are tolerated and the app runs with Debug Ok, where as if a similar attempt were made to access "/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps" on the NAS, errors in case would not be tolerated and it would fail.

Trouble is, I can't find any reference to "/mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/MacOs/MyStamps" in any of the logs I've sent. Maybe there is, maybe I've missed it.

So to maybe prove it I created a symbolic link in the app bundle ...

Quote

study:Contents andy$ cd /
study:/ andy$ cd /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app/Contents/
study:Contents andy$ ls -l
total 24
-rwxrwxr-- 1 andy wheel 1231 16 Apr 09:17 Info.plist
drwxrwxr-x 1 andy wheel 264 27 Apr 12:57 MacOS
lrwxrwxrwx 1 andy wheel 5 27 Apr 12:57 MacOs -> MacOS
-rwxrwxr-- 1 andy wheel 9 16 Apr 08:56 PkgInfo
drwxrwxr-x 1 andy wheel 264 16 Apr 08:56 Resources
study:Contents andy$

Now, when I run run the App with Debug there are no errors or warning about Dwarf info not being found, debugging appears to work fine, including viewing local variables. And I'm left with the EXC_BAD_ACCESS when the app terminates to sort out.

Quote

Strange that it works sometimes....
Maybe if files are on a case-insensitive filesystem. Or maybe don't know.

I think this could be the case (no pun intended) and it would appear the issue is around MacOS v. MacOs.

I'm going to play a bit more with creating a case insensitive share on the NAS

I'll let you know

Quote

Thanks a ton, for your persistence.

and thank you!!!

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 27, 2019, 05:12:01 pm

Should be fixed https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=61066

Interestingly, I found that the "s" at the end of "MacOS" seems case-insensitive, but the "M" at the start case sensitive (on the same filesystem, the same folder even.)

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 28, 2019, 10:33:51 pm

Sorry to have to advice, but I've just updated to rev 61074 and the issue is still there and the same fix (symbolic link MacOs -> MacOS) works

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 29, 2019, 01:02:16 am

Could you look at components/fpdebug/fpimgreaderbase.pas
Line 205
inside
constructor TDbgFileLoader.Create(AFileName: String);
?

And see if it get the correct filename, and what FileExists returns? That is, it is enough to

Code: Pascal [Select][+]

debugln(['AFileName = ',AFileName,'  s = ',s, ' err = ',fpgeterrno()]);

on the next line.

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 29, 2019, 01:08:43 am

One more thing.

Check the timestamp of the lazarus executable. MAke sure you are using the one that you did rebuild.

Usually in the Lazarus directory, inside the Lazarus.app/Contents/MacOS should be a sym link.
When rebuilding, the exe that is replaced is in the same folder as Lazarus.app (and the symlink points to it)

If you however did build, with a user that did not have write permission to that folder, then the exe ends up in your primary conf path. If that is the case, startlazarus should find it.
But care, if you have 2 installs, that this will not be mixed up.

If you add the debugln, then that will also prove that the correct rebuild version is used.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 29, 2019, 02:29:32 am

I've checked the timestamp of lazarus, and the symbolic link is good. Help | About Lazarus shows rev 61074M

I added the debugln ...

Code: Pascal [Select][+]

constructor TDbgFileLoader.Create(AFileName: String);
{$IFDEF MacOS}
var
  s: String;
{$ENDIF}
begin
debugln(['AFileName = ',AFileName,'  s = ',s, ' err = ',fpgeterrno()]);
 

Logs this ..

Quote

AFileName = /mnt/NAS/Documents/Andy/Pascal/src/MyStamps/MyStamps.app s = err = 0

The resultant debug log is attached

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 29, 2019, 09:55:08 am

Sorry I meant a few lines further down:

Code: Pascal [Select][+]

    s := AFileName + PathDelim + 'Contents' + PathDelim + 'MacOS' + PathDelim + copy(s, 1, Length(s) - 4);
    if (FileExists(s)) then AFileName := s
    // debugln goes here
    debugln(['AFileName = ',AFileName,'  s = ',s, ' err = ',fpgeterrno()]);
 

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 29, 2019, 11:08:16 pm

Ok, made the change and reproduced the issue.

The I noticed the MacOs in the first line here ...

Code: Pascal [Select][+]

s := AFileName + PathDelim + 'Contents' + PathDelim + 'MacOs' + PathDelim + copy(s, 1, Length(s) - 4);
if (FileExists(s)) then AFileName := s;
debugln(['AFileName = ',AFileName,'  s = ',s, ' err = ',fpgeterrno()]);

I changed that and recompiled, the issue has now gone away so I haven't included any debug logs

Then I did a quick search for MacOs in other files under ./components and found it

at line 353 of components/fpdebug/fpimgreadermacho.pas:

Code: Pascal [Select][+]

 i := pos('/Contents/MacOs', fname);

and at line 2227 of components /lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas:

Code: Pascal [Select][+]

{$IFDEF MacOs}
 

Are defines case-sensitive?

I haven't changed anything in these two.

I don't know anywhere near enough of the inside of Lazarus, or doing updates with svn etc so can I please leave it to you to the necessary there?

Cheers

Title: Re: Problems with Debugger on OSX
Post by: lucamar on April 30, 2019, 12:33:43 am

Quote from: ahnz on April 29, 2019, 11:08:16 pm

and at line 2227 of components /lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas:
Code: Pascal [Select][+][-]
{$IFDEF MacOs}
Are defines case-sensitive?

No, they aren't; they are like Pascal identifiers in that respect. Change it to MACOS if you feel like it :)

Note, also, that that IFDEF doesn't affect you: the MACOS define is for code intended for "Classical" MacOS (MacOS 1 to 9)

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 30, 2019, 01:36:21 am

Quote from: ahnz on April 28, 2019, 10:33:51 pm

Sorry to have to advice, but I've just updated to rev 61074 and the issue is still there and the same fix (symbolic link MacOs -> MacOS) works

Are you on trunk or fixes branch?

61074 is a revision on trunk.
But "svn up" may show it as result, even if you are on fixes.

The change is currently only in Trunk. It is listed to be merged. http://wiki.lazarus.freepascal.org/Lazarus_2.0_fixes_branch#Submitted_by_developer_.2F_committer.2C_tested.2C_waiting_to_be_merged
But the merge has not yet been done.

So if you updated fixes branch, then indeed you did not have the fix.

"i := pos('/Contents/MacOs', fname);"
Has also been changed in trunk.

Title: Re: Problems with Debugger on OSX
Post by: ahnz on April 30, 2019, 12:33:05 pm

Quote from: Martin_fr on April 30, 2019, 01:36:21 am

Are you on trunk or fixes branch?

To be honest I don't really know, I'm a complete newbie when it comes to using svn.

I installed a new 2.0.2 and then when you told me it should be fixed in 61066 I followed the instruction you gave a while back to update ...

Quote

svn co https://svn.freepascal.org/svn/lazarus/branches/fixes_2_0 /Developer/lazarus

followed by

Quote

make bigide LCL_PLATFORM=carbon CPU_TARGET=i386

Everything is working fine now so I'll trust in your better judgment that the fixes are as you say

Many, many thanks for all the help

Cheers

Title: Re: Problems with Debugger on OSX
Post by: Martin_fr on April 30, 2019, 01:41:25 pm

Quote

svn co https://svn.freepascal.org/svn/lazarus/branches/fixes_2_0 /Developer/lazarus

That is the fixes branch.

In svn there are several lines (branches) of development.

- New code is added to "trunk"

- When a major release is planned, a "branch" is created. It starts as a copy (though internally its a reference to the snapshot).
- Only selected changes are transfered/merged to that copy. That way new features (with new bugs) do not get into the release (and minor releases).

Those copies are called "fixes branch" because we usually only merge bug fixes.

When I fixed the issue I committed it to trunk (as is usual). The merging to the fixes branch can be sometimes delayed.
I have now done the merge, so that change is in the fixes branch.

You can do ("." is the directory, that is if you are inside the lazarus svn dir)
To undo ANY changes you made
svn -R revert .
To update
svn up .