OSX Debugging Issue - How?

[Cirrus22 0]

Hi,

 

First time here (just got the Google Groups and it has died).

 

Look, this might be a simple issue and if it is I apologise, but it is driving me spare. 

 

Reading the literature I was under the impression you could build for OSX and use the debugger as you would in say a Win32 app,ication, ie. you would have breakpoints and could single step through the code if required. When I build for OSX I have never seen anything like this. The Event Log always says 'No Debug Info'. The best I have been able to do is to use log.d from FMX.Types to show log messages in the PAServer window. I really have tried searching everywhere and anywhere and cannot see anything that would enable what I would call 'normal' Delphi debugging. I think I have all of the necessary debug options set (the debugger certainly works as expected when I build the code for Win32/Win64).  Specifically this was a working 32 bit application and DLL that I have converted to a macOS app and DYLIB. I can get the DYLIB to load and functions called if I have a simple test application as the host NOT the converted application.

 

The reason it is now quite desperate  is that I'm getting an AV and here's the scenario:

1. Delphi 10.2.3
2. OSX 10.13.6
3. PAServer 19.0
4. Xcode 9.4.1

 

So my issue with code:

1. Main Program and My Dylib
2. Both call a common unit that generates log file (log4pascal as modified by me)
3. At startup I get Log.d message that now in Initialize Block of log4pascal (it sets up logging for the DYLIB and main application)
4. I then get a Log.d message code is in the Initialize Block of the DYLIB
5. I then get a log.d message that code is leaving the Initialize Block of the DYLIB (all good so far)
6. I SHOULD now get a log.D message that it is entering the Initialize Block of the Unit associated with the main application
7. Instead I get an AV - see attached OSX AV
8. And the PASERVER log shows the same - See log-lines below

9. Quote

   1.  
   2. [Log4Pascal] initialize
   3. [DLL] Initialize DbXConnect
   4. [DLL] Initialize DbXConnect Complete
   5.  

10. So the Initialize Block code for the main unit for the application itself is a Log.d line, it NEVER gets executed, ie. the AV occurs before it gets to Initialize?

 

I am having significant difficulty tracking this error. So my initial problem is essentially ...how do i get the debugger to work when running an OSX application so that I can track down that AV (ie. with features like setting breakpoints and single stepping through the code???

 

Or do I have this all wrong, is there some other way I should be doing it (the Embarcadero documentation suggests I should be able to debug OSX in the same way as I debug Win32 apps).

 

Again, if this is simple stuff I apologies, but it has me stuck....

 

Kevin

[Sherlock 663]

I get all the logging I need in the PAServer using the regular built in log.d. Just out of curiosity: Why the dylib? If it is your own, just compile it into your program and make it monolithic...the good old Delphi way.

[Cirrus22 0]

@Sherlock Thanks for taking the time to reply. The DYLIB is for use by others that have code in C++ and Swift, the good old Delphi way, simple as it would be, and I wish I could avoid doing the DYLIB thing because there is little information and almost no one knows how to build DYLIBs, just would not cut it. For example I contacted TMS about their FMX cloud pack and they said they had never even considered DYLIB testing and would not consider it, too much effort. So cross-platform is cross-platform with serious limitations. I’m actually evaluating whether Delphi is a viable tool for OSX, because it does not live up to the hype, that’s for sure. 

 

I have ave a Log.d statement in the last line of the DYLIB initialisation statement which gets executed first when the DYLIB is loaded and as the first line of the initialisation section of the main app unit. It never gets to the main app units initialisation section.  Log.d in this case is pretty useless. 

Edited January 7, 2019 by Cirrus22

[Dave Nottage 557]

5 hours ago, Cirrus22 said:

Instead I get an AV - see attached OSX AV

Is there a callstack?

[Cirrus22 0]

Hi Dave,

 

Thanks for the reply. As noted I don't seem to be getting ANY debug info other than what's logged by log.d calls in the PASever windows:

 

I get this in the PAServer terminal (the unknown compressor happens whether it works or not):

Quote

>/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Common/ChunkCompression.cpp:49: Error: unsupported compressor 8

/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist'

/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Common/ChunkCompression.cpp:49: Error: unsupported compressor 8

/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist'

[Log4Pascal] initialize

[DLL] Initialize DbXConnect

[DLL] Initialize DbXConnect Complete

And when I run the application there is nothing in the Debug Stack Trace Window. That was part of my original question. I thought I have done everything to setup debugging on OSX, but I just don't get any debug information other than what I actually write through Log.d or show message? Is / are these some 'magic' settings that I need to turn on? I've been through the docs and I 'thought' I had done what was required (obviously not). This was the same when I had the FMXApplicationDelegate registration error reported via stack exchange, you asked for the callstack which I don't seem to be able to get? Any ideas hints how I might get the callstack, this seems key to solving most problems if you can identify where they occur?

 

Win32

 

Oh, and as noted, same code works fine in win32, no sign of an AV, BUT I also get nothing in the stack trace windows. If I run the app Win 32 if I put in a breakpoint I can single step through the code and the CallStack for the current thread is visible, but still NOTHING in the stack trace Window. 

 

Thanks.....

 

OSX BUILD WINDOW:

Edited January 7, 2019 by Cirrus22

[Cirrus22 0]

And I might be getting confused because when I read the Embarcadero documentation (for Tokyo), it quite explicitly states that to get a stack trace you need to use one of the stack trace providers. All of the stack trace providers only works on Windows, I don't see any of them that actually work on OSX. Am I just reading this incorrectly?

[Cirrus22 0]

And again, at the risk of too much info, I can and have used MadExcept successfully in the Windows environment. Here I force an AV and the error is logged, but NOTHING in the Delphi stack trace window (Line 325 is the function declaration, the actual error is at line 931 calling that non-existent DLL function). So, yes, MadExcept (and I'm sure the others) works fine, but they don't translate to the OSX world:

program DropboxDLLTest;

uses
  {$IFDEF MSWINDOWS}
  madExcept,
  madLinkDisAsm,
  madListHardware,
  madListProcesses,
  madListModules,
  {$ENDIF MSWINDOWS}
  FMX.Forms,
  EmpyreanMain in 'EmpyreanMain.pas' {frmEmpyreanMain};

[Dave Nottage 557]

19 hours ago, Cirrus22 said:

I can get the DYLIB to load and functions called if I have a simple test application as the host NOT the converted application

I've just noticed this from your first post. I can only suggest checking what the differences are between the two. Perhaps make a copy of the converted application, and start removing parts of it until the problem is resolved.

[Cirrus22 0]

Hi Dave,

 

Quote

I've just noticed this from your first post. I can only suggest checking what the differences are between the two. Perhaps make a copy of the converted application, and start removing parts of it until the problem is resolved.

That was one of the options. Basically the test calls two of the functions in the DYLIB. The 'actual' main app is far more complex and I use TMultiThread2 with callbacks etc etc. Works fine in the Windows world. I had initially started by commenting out great slabs of code and it did work with only the two functions called, but it's messy.

 

What I don't get is why I get an AV on initial load - OSX loads the DYLIB first (successfully) then before it can get to the initialise block in the main app an AV occurs - I don't get what code could be generating this. But yes, cut code and see where it actually works....

 

Did you see my myriad of comments about a stack trace? I'm happy to send you the stack trace, but can you tell me how to actually get one?