Exception logging/reporting on MacOS?

[Brandon Staggs 272]

FMX project with MacOS target. Anyone else doing this, have you found a satisfactory way to get reports of runtime exceptions? On Windows we can choose from madExcept or EurekaLog, and I cannot find anything like that for FMX projects on MacOS.

 

When running via PAServer one can at least read exceptions in the logging output, but more often than not, carefully placed Asserts for debug builds in the hands of testers (no PAServer) which are very helpful in Windows are useless on Mac, just killing threads or silently blowing up with a disappearing window...

Edited May 14 by Brandon Staggs

[Dave Nottage 554]

1 minute ago, Brandon Staggs said:

I cannot find anything like that for FMX projects on MacOS.

https://blog.grijjy.com/2021/10/18/build-your-own-error-reporter-part-3-macos-intel/

 

Note that when this was published, there was yet to be support for ARM, however the last line says:

 

"I may add some missing pieces to get this to work for ARM Mac apps as well"

 

Since the code has not been updated since then, you'd need to either contact Erik or add an issue to the repo, regarding support for ARM.

[Erwin Mouthaan 7]

13 hours ago, Brandon Staggs said:

I cannot find anything like that for FMX projects on MacOS.

SmartCrashLog supports Windows, macOS & Linux platform. Developed by original architect of FireMonkey.

[Lars Fosdal 1790]

22 minutes ago, Erwin Mouthaan said:

supports Windows, macOS & Linux platform

Doesn't mention architecture, though - Intel vs ARM.

[Anders Melander 1780]

27 minutes ago, Erwin Mouthaan said:

SmartCrashLog supports Windows, macOS & Linux platform. Developed by original architect of FireMonkey.

Life-time license. Sounds good but in reality it means the developer has no incitement to maintain the product - at least not a commercial one.

[Erwin Mouthaan 7]

1 hour ago, Lars Fosdal said:

Doesn't mention architecture, though - Intel vs ARM.

Version 1.1: Added: Delphi 11 support with OSXARM64 platform

https://www.smartcrashlog.com/history.html

[Brandon Staggs 272]

5 hours ago, Erwin Mouthaan said:

SmartCrashLog supports Windows, macOS & Linux platform. Developed by original architect of FireMonkey.

Wow, this looks promising. Thanks!!

[Brandon Staggs 272]

4 hours ago, Anders Melander said:

Life-time license. Sounds good but in reality it means the developer has no incitement to maintain the product - at least not a commercial one.

It wouldn't surprise me if he was hoping to have it acquired by Embarcadero like Firemonkey.

[Anders Melander 1780]

2 minutes ago, Brandon Staggs said:

have it acquired by Embarcadero

I can't see why they would do that.

[Brandon Staggs 272]

6 hours ago, Erwin Mouthaan said:

SmartCrashLog supports Windows, macOS & Linux platform. Developed by original architect of FireMonkey.

Are you using this? I've downloaded the trial version and installed it on Delphi 12 Patch 1. After using the stack trace symbolizer it reports line number 1 for every item in the trace. It also appears to disallow using it if the application is built in Debug mode, which is an odd choice.

 

I have sent an email to their support address asking about it, but just in case you're using it, I thought I'd ask.

[Edwin Yip 154]

17 hours ago, Erwin Mouthaan said:

SmartCrashLog supports Windows, macOS & Linux platform. Developed by original architect of FireMonkey.

Why I haven't heard about this before? It seems to be the only one that's cross-platform. I watched the intro video and it sounds very good. How does it compare to madExcept?

[Lars Fosdal 1790]

15 hours ago, Anders Melander said:

I can't see why they would do that.

Well, it would be practical to have a bare bones stack trace tool for all supported platforms.

[Anders Melander 1780]

53 minutes ago, Lars Fosdal said:

it would be practical

They are in business to make money; Not to be practical.

 

I can't imagine that they would sell a single license more because they had a cross-platform stack tracer.

[Lars Fosdal 1790]

Practical - as in practical for the users of their products, i.e. us.

[Erwin Mouthaan 7]

16 hours ago, Brandon Staggs said:

Are you using this? I've downloaded the trial version and installed it on Delphi 12 Patch 1. After using the stack trace symbolizer it reports line number 1 for every item in the trace.

@Brandon StaggsLatest version SmartCrashLog 1.14 is not usable indeed.

 

Maybe TMS Logging is an option.
https://www.tmssoftware.com/site/tmslogging.asp

 

It supports automatic handling and logging of exceptions.
https://doc.tmssoftware.com/biz/logging/guide/tmslogger.html#exceptions

 

The logger exposes an OnHandleException event to handle additional code when an exception occurs.
https://stackoverflow.com/questions/23039510/delphi-obtain-full-stack-trace-on-osx

[Anders Melander 1780]

2 hours ago, Lars Fosdal said:

Practical - as in practical for the users of their products, i.e. us.

You are not really addressing the point I made; How is the fact that something is useful to the user relevant to Embarcadero if they are not going to make money acquiring it? It's not as if it's a strategic feature.

 

Besides that, I don't see the benefit from the users standpoint. Embarcadero does not have the resources to properly maintain something like this and they would just hurt the other existing exception handlers (madExcept, EurekaLog, etc.) which in turn would hurt the users.

[Anders Melander 1780]

1 hour ago, Erwin Mouthaan said:

The logger exposes an OnHandleException event to handle additional code when an exception occurs.
https://stackoverflow.com/questions/23039510/delphi-obtain-full-stack-trace-on-osx

There's really no point in using a third-party logger if you are going to resolve the stack trace manually like that. It would just add overhead and complexity.

[Lars Fosdal 1790]

6 minutes ago, Anders Melander said:

existing exception handlers (madExcept, EurekaLog,

do not support ARM64. 

 

I also pointed out "bare bones stack trace". The two mentioned offer so much more functionality for those that need it.

I wonder how many people that don't use such tools as they don't want to take the cost?

 

But this still is a purely academical discussion. That said, they already have the code to unwind the stack in the debugger, which they need to maintain, so the step is not that huge.

[Brandon Staggs 272]

7 hours ago, Anders Melander said:

They are in business to make money; Not to be practical.

 

I can't imagine that they would sell a single license more because they had a cross-platform stack tracer.

And did they sell one extra license when they acquired Raize components and eventually made them available at no extra cost? Doubtful, but who knows. Your argument here makes no sense to me, because Embarcadero has a track record of acquiring components and integrating them into the IDE. (Not saying this is a great track record, it's just a fact.)

 

Anyways, the lack of even a bare-bones call stack reporting window in the base product is a ridiculous large gaping hole, and they could plug that hole by acquiring this component, as they have acquired so many others in the past. But, as has been pointed out already, they already have code that unwinds the stack on every supported target, so it seems like they are making an active choice to exclude this functionality. I can't understand that. Debugging and testing on MacOS is many orders of magnitude more difficult than it needs to be, and adding bare-bones call stack reporting would go a long way to improving the situation. Sometimes I get the feeling I am the only one even using FMX on MacOS.

Edited May 16 by Brandon Staggs

[Brandon Staggs 272]

5 hours ago, Erwin Mouthaan said:

Latest version SmartCrashLog 1.14 is not usable indeed.

The other problem I have in testing the trial version is that I can't use it in projects that have bug fixes to RTL/VCL/FMX source files, because the source is not available to recompile against the ones I am using. I don't blame him for not including source in the trial version, but the order page does not say whether or not you get source. In fact he doesn't even show what the license is. I've emailed him for clarification on these issues, and also asked about the bugs with the current trial version (no line numbers or function names), but haven't heard back.

 

I looked into how SmartCrashLog installs and works, which you have to puzzle out yourself since there is literally no documentation (just silent youtube videos showing someone making a prokect). It looks like every time you build a Release version of your project, it stashes a copy of the EXE into a data folder and adds it to a local SVN repository. This is how he's able to manage getting crash logs from any released version and match it up. That's an interesting idea, but I also need this to work on my own debug builds that I am deploying to other machines on my network, and he explicitly blocks using this in a debug build, probably to avoid filling up the SVN repo. It would be good if I could at least maintain the most recent debug build in there so I can use this in my own iterative debugging.

 

This seems like a promising project but in the end I would be satisfied with a simple call stack with line numbers that is copied to the clipboard when an exception is encountered.

Edited May 16 by Brandon Staggs

[Anders Melander 1780]

31 minutes ago, Brandon Staggs said:

And did they sell one extra license when they acquired Raize components and eventually made them available at no extra cost?

They probably thought it was a good idea at the time (wasn't this before they fired everybody?) but unsurprisingly that didn't work out for them and now it appears to be in "maintenance mode". So, a good example of why it isn't a good idea.

 

44 minutes ago, Brandon Staggs said:

Your argument here makes no sense to me, because Embarcadero has a track record of acquiring components and integrating them into the IDE. (Not saying this is a great track record, it's just a fact.)

So because they have done something in the past, and it has mostly turned out to be a bad idea, it would make sense for them to continue to do it? Interesting viewpoint.

 

48 minutes ago, Brandon Staggs said:

Anyways, the lack of even a bare-bones call stack reporting window in the base product is a ridiculous large gaping hole, and they could plug that hole by acquiring this component, as they have acquired so many others in the past.

Sure, it would be nice if the feature was built-in but I don't really think acquiring a 3rd party product (and that product in particular) is the best way for them to cover that. I think it would be better if they simply provided the framework to make it possible instead.

 

This could be the miraculous exception to the rule, but acquiring something to plug a hole (or whatever the reason) doesn't just end once the rights has been transferred. There's also integration, branding, documentation, infrastructure, education, support, etc. And then there's the cost of maintaining it once you have made it a core part of the product.

 

1 hour ago, Brandon Staggs said:

they already have code that unwinds the stack on every supported target, so it seems like they are making an active choice to exclude this functionality. I can't understand that.

Entering straw-man territory. We don't know how the debugger does stack tracing and we don't know if or why they might have made a choice or what choice they made.

[Brandon Staggs 272]

21 minutes ago, Anders Melander said:

Sure, it would be nice if the feature was built-in but I don't really think acquiring a 3rd party product (and that product in particular) is the best way for them to cover that. I think it would be better if they simply provided the framework to make it possible instead.

You have likely lost sight of my original comment, which was simply that it would not surprise me if the guy who wrote this component is hoping to have it acquired. I am not and will not argue that they would or should. It is plainly obvious that they have done things just like this in the past, is what I am saying. And since he's already sold stuff to Emba that is now part of Delphi, and he's not making much of an effort to make this a long term viable product by itself (you pointed out the lifetime license)... It's all speculation, of course.

 

21 minutes ago, Anders Melander said:

This could be the miraculous exception to the rule, but acquiring something to plug a hole (or whatever the reason) doesn't just end once the rights has been transferred. There's also integration, branding, documentation, infrastructure, education, support, etc. And then there's the cost of maintaining it once you have made it a core part of the product.

Again, they have done this many times. Some of the basic functionality we now have in the IDE came from Castalia. The entire FMX framework was originally acquired from the guy who wrote SmartCrashLog. They recently acquired Parnassus tools filling gaps in their IDE functionality. They pulled in Skia code they didn't write. It's not far-fetched to posit they could acquire more functionality they don't want to make for themselves especially to fill such a wide, gaping, black hole like this. Should they do it that way, in this instance? I don't know. I didn't say they should.

Edited May 16 by Brandon Staggs

[Alexander Halser 26]

Bringing up this topic again...  I have managed to get a stack trace report on macOS, but I am not entirely sure what to do with it.

 

There is a Windows app called "addr2line.exe", which I assume is supposed to parse the file that contains the debug symbols (for macOS that would be MyAppName.dSYM, right?). Then I have to feed it the addresses that I got from the error log. And it should return unit and line number where the error actually occurred.

 

However, addr2line.exe doesn't seem to understand the format of the .dSYM file. Is this because it expects a Windows executable? Probably yes. Do I have to do this on the Mac with a macOS version of this tool? If yes, which is it?

 

My stack trace looks like this:
 

OS Version: macOS (Version 11.6.7)
Product Version: 1.0.0
Product Name: FmxApp
Platform: OSXARM64
Config: Debug
DateTime: 31_10_24 10_41_00
Log-File: FmxApp-31_10_24-10_41_00.log

Stack trace: 
00000001024C8000:000000010254298C: FmxApp
00000001024C8000:0000000102D1EC24: FmxApp
00000001024C8000:0000000102A20750: FmxApp
00000001024C8000:0000000102A85428: FmxApp
00000001024C8000:0000000102A20D98: FmxApp
00000001024C8000:0000000102C8A50C: FmxApp
00000001024C8000:0000000102C2A308: FmxApp
00000001024C8000:0000000102C2A66C: FmxApp
00000001024C8000:0000000102C17394: FmxApp
00000001024C8000:00000001024CB438: FmxApp
0000000192AA5000:0000000192C69DC8: AppKit
0000000192AA5000:0000000192C6915C: AppKit
0000000192AA5000:0000000192C68034: AppKit
0000000192AA5000:0000000192F35194: AppKit
0000000192AA5000:0000000192AD78A0: AppKit
00000001024C8000:00000001024CB260: FmxApp
00000001024C8000:0000000102C10CCC: FmxApp
00000001024C8000:0000000102C10C14: FmxApp
00000001024C8000:0000000102C7E464: FmxApp
00000001024C8000:0000000102D1EF24: FmxApp

Modules: 
AppKit:
FmxApp:304f03e2f8d59eb00757a868fa075d26

Title: Application Error

Message: Access violation at address 0000000102D1EE30, accessing address 0000000000000000

 

[vfbb 285]

@Alexander Halser A few years ago I made a tutorial on how to explore iOS app crash, but the same applies to macOS as well. Take a look especially at Step 4 - Symbolizing the crash file.

[Alexander Halser 26]

The error reporting solution from JustAddCode that you mention in your tutorial does work reasonably well. While the line numbers are pretty odd, it at least delivers the function name. I was able to solve the problem on macOS with this tool.