Jump to content
Brandon Staggs

Exception logging/reporting on MacOS?

Recommended Posts

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 by Brandon Staggs

Share this post


Link to post
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.

  • Like 2
  • Thanks 1

Share this post


Link to post
22 minutes ago, Erwin Mouthaan said:

supports Windows, macOS & Linux platform

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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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 by Brandon Staggs

Share this post


Link to post
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 by Brandon Staggs
  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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 by Brandon Staggs
  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×