AIR Runtime 33.1 and AIR SDK 33.1 - is "stacktrace" output supported in production releases?

[TaS-Sensys]

Hi,

I am able to get stacktrace output from the "adb.exe" launched applications with AIR and SDK 33.1, BUT only get
"null" as the stacktrace when running the "production release"

From my reading of older Adobe documentation, I should be able to get a stacktrace without line numbers, which would
be a big improvement over "null".

(https://stackoverflow.com/questions/4473059/how-can-i-get-stacktrace-for-adobe-air-global-runtime-errors-in-non-debug-mode)

I WANT the stacktrace so application users can report "UncaughtErrorEvents()" popping up deep inside the code that are currently
silently corrupting the running software.

(https://stackoverflow.com/questions/16073357/actionscript-compiler-uncaughterrorevent)

Am I missing any configurations? I am using "true" in frameworks/air-config.xml and "-compiler.verbose-stacktraces=true" arguments in my ant build.xml

Thanks
-Todd

PS: similar issues using very old air compiler v 2.0.2, but this might be too old, but is still running against Air runtime 33.1!

[2jfw]

Quite vague and I cannot tell for sure but we did fail for everything we tried (using compiler args like debug mode, verbose stack traces, ...).
I remember a discussion form the Flex mailing list where this was discussed and the conclusion was that you explicitly need to run the swf with adb and have those (compiler) flags set when building (so the relase build needs to be run with adb)

EDIT: We were never able to see the line numbers in the stacktraces (stacktraces do work well!)

[TaS-Sensys]

Yes, I can confirm the release build will return stacktraces with adb (debug=false), but I need to confirm if the release build can support the feature with the production Harman/AdobeAir.exe installation.

(I don't know if the feature ever worked pre Harman releases, from my reading it seems it did with Adobe Air 3.5+ or even earlier)

I am ALSO open to suggestions for stacktrace alternatives I could put in the UncaughtErrorEvent handler to indicate where in the code the problem occurred - this feature works well, I want my userbase to send me bugs/get prompted to restart the program to avoid corrupting behaviors that NOT catching these errors results in!

Thanks!

[Elintondm]

For us in our release build (debug=false) the stack traces work well but the line numbers are not shown. Anyone already tested if the debug version has a huge impact on performance? Em ter., 25 de out. de 2022 às 14:10, TaS-Sensys ***@***.***> escreveu:

…

Yes, I can confirm the release build will return stacktraces with adb (debug=false), but I need to confirm if the release build can support the feature with the production Harman/AdobeAir.exe installation. (I don't know if the feature ever worked pre Harman releases, from my reading it seems it did with Adobe Air 3.5+ or even earlier) I am ALSO open to suggestions for stacktrace alternatives I could put in the UncaughtErrorEvent handler to indicate where in the code the problem occurred - this feature works well, I want my userbase to send me bugs/get prompted to restart the program to avoid corrupting behaviors that NOT catching these errors results in! Thanks! — Reply to this email directly, view it on GitHub <#2235 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFCZGYMHYXHWHNY45K37FXDWFAICBANCNFSM6AAAAAARNNP6ZQ> . You are receiving this because you are subscribed to this thread.Message ID: <airsdk/Adobe-Runtime-Support/repo-discussions/2235/comments/3962635@ github.com>

[2jfw]

Debug version has a very huge impact on performance - some random tests show at least half or less the performance of the release build.
Our huge (SeMSy 5) app (flex) e.g. runs with ~30fps in debug but will easily reach 60+fps in release.
Performance impact of course depends on the complexity and number of the things which are processed

[waveofthought-code]

fwiw i have been outputting stack traces via uncaught exception events for literally years -- first from flashplayer on the web, then from an Air captive runtime both in debug and release versions. Running from adl you get line numbers, but packed up with adt you don't. My release versions don't have any switch for "debugging = true" anywhere so i've always considered this an intrinsic feature (perhaps ignorantly) .

I publish my main swf via Animate, but the loader (and packaging) is built via VSCode.

[TaS-Sensys]

Thank you for the replies - just like the Internet, it seems the stacktraces are working in the release builds for some users but not others!

To be specific, my AIR targets are the Windows-based AIR Runtimes

[TaS-Sensys]

So to verify the flags I am using, I built with

(in build.xml)
<arg value="-debug=false"/>
and
<arg line="-compiler.verbose-stacktraces=false" />

and my binary size went down to
3884351 Nov 2 12:11 Main.swf
from
5500000+ bytes

WHEN I launch the app with Harman "adl", I can capture uncaught errors (here generated by mouseclick)
and get a simple stacktrace (no numbers) - I get the built-in

and then from my own popup, I also post the stack trace:

WHEN I package the Main.swf into an .exe installable package to run under the Harman Runtime, the
popup alert still appears as in the "adl" run but the stacktrace content posts as NULL:

(I assume there is no built-in/native error window by design?)

ARE there other compiler flags or entries in the air-config.xml or flex-config.xml that could be DISABLING the stacktraces
when I run under the production Harman-Adobe Air Runtime?

It seems to work for some of you so I remain hopeful!

Thank you
-Todd

[TaS-Sensys]

my uncaught capture code, and error generator!

	public function onClickMiddleError(e:MouseEvent):void {
		if (trafficdotSystem.superUserEnabled) {
			trace("MainMediator.as: onClickMiddleError(): MIDDLE, trigger Error()");
			throw new Error();
		} else {
			trace("MainMediator.as: onClickMiddleError(): MIDDLE, need superuser to trigger Error()");
		}
	}

	public function uncaughtErrorHandler(e:UncaughtErrorEvent):void
	{
		if (trafficdotSystem.superUserEnabled) {
			trace("MainMediator.as: uncaughtErrorHandler(): e=" + e.error.getStackTrace());
			TdAlert.show("Uncaught Error Detected:\n\nstack:\n\n" + e.error.getStackTrace() + "\n\nerror:\n\n" + e.toString(), null, null, true, true);
		} else {
			trace("MainMediator.as: uncaughtErrorHandler(): caught, popup w superuser");
		}
	}

[TaS-Sensys]

and the listener call:

		view.root.loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, uncaughtErrorHandler);

[TaS-Sensys]

Bueller? Bueller? Got a nice feature if I get this output going :)

[TaS-Sensys]

okay, answering my own question - the fix is a bit of a hack, but MAYBE SOMETHING THAT CAN BE ADDED TO THE RUNTIME?

THIS works for me UNDER WINDOWS 10
from
https://stackoverflow.com/questions/4473059/how-can-i-get-stacktrace-for-adobe-air-global-runtime-errors-in-non-debug-mode

1. Windows: Browse to its install directory in a file explorer.
2. Navigate to {app-folder}▸META-INF▸AIR▸. Here you can find a file called hash.
3. Duplicate the hash file and rename it to debug.
4. Open the debug file with some text editor and remove the content.
5. Done now you get the stack trace + line numbers.

Again, how/could this be added to the runtime? I might modify my installer to automate this approach.

[ajwfrost]

I think the slight challenge with your first suggestion is that this would change the default behaviour back from what it is now, to something that it was several years ago - and obviously there was a reason that Adobe changed that, so I'm a little reluctant to revert it...

I'd also say that "verbose" stack traces would imply having file information and line numbers whereas "non-verbose" stack traces are just the functions, so the second one doesn't quite sit right to me either!

But yes, there is a difference here between the SWF build and the runtime. The SWF contains instructions for the runtime, so if the SWF says that it should enable debugging, then the runtime goes checking for a debugger.. and then the runtime behaviour is also different based on whether or not a debugger is actually found/connected. I think it's safe to say that for people who are actually debugging, they would (a) be building a SWF with debug mode (hence we'd have file/line info in there) and (b) they'd be using ADL with the expectation of it connecting to a debugger.

By the "release build" of a runtime I mean when you're not using the ADL tool but are using what would actually be run when you're using a deployed application, i.e. an application .exe file on Windows, or a .app bundle on Mac, etc. So there is a potential need to debug things in this scenario, just because there are differences between running via ADL and running via this (AppEntry) mechanism.

Going back to your three options, I agree with these as options, but the configuration settings to get to them I think need to be different:

1. Release Build with no stack traces: this is a change to existing behaviour so I would think we need a custom setting/option for this, i.e. "opt in to remove stack trace capability" hence preserving the default/existing behaviour.
2. Release Build with stack trace but no line numbers/file names -> default setting, as it is now, as long as you have SWF v18+
3. Release Build with stack trace and line numbers/file names -> we could either have this as an opt-in setting, or we could just add line numbers/file names in any call stack where the SWF contains these. And then, to get these, you would either use the "-debug" option, or (if we implemented it in the AIR compiler) the "-verbose-stacktraces" option.

My preference I think, looking at it, would be for applications to specify what behaviour they want via a configuration item e.g.
<stacktraces>none|standard|verbose</stackstraces>
This would be the simplest way of doing it and means that we can avoid changing things for existing applications if they're just updating onto a later runtime.

[2jfw]

Sounds good :) Also thanks for the explanation regarding runtime and SWF, I do now understand what you are meaning.

So, where would the configuration item be placed?

[TaS-Sensys]

Does anything need to change here? The only thing I am wondering is whether you'd want a release build of the runtime to display the filenames/line numbers should the SWFs contain those details. That would need some changes in the runtime and JIT code but could be added if there's a big need for it...

For my OLD Flex compiler 4.1x output then (and I will be staying with this ancient one - your suggestion ;) ), I am leveraging the presence of the empty "debug" file to trigger "filename/function" stacktraces in the current(ie Harman) AIR Runtime. I built a "toggle" to enable/disable the file, requiring the user to "Run As Administrator" and restart the application for the mode to take place.

MY runtime "feature request" would be to have a non-file mechanism to enable or disable the "debug" state of the AdobeAIR.exe runtime. Not sure if there is a precedent for any other flags passed into the AdobeAIR.exe runtime?

A remaining question is how much overhead does the "debug" state of the runtime add to the code, if any? Is the dynamic tracking
of file/function occurring all the time or just under runtime "debug"? I can do some timing tests here too, we are debating leaving this
"debug" file/state on as the default. Could I actually speed up my code using version 18+ of the SDK or would my Flex app not be affected?

Thank you for the analysis!

[ajwfrost]

In your case, I think the debug file would trigger the full 'debugger' capabilities within the runtime, which means that you'd potentially get a little bit more overheads at each function call - but the worst bit might be at start-up, if the runtime is sat briefly to see if it can connect to an active debugger process (fdb).

So hopefully it would be possible to leave out this file but to get the stack traces by setting this new configuration flag to standard/verbose..?

I am thinking this would be in the XML configuration file as a top level option...

thanks

[ajwfrost]

FYI, added this in the latest release, https://airsdk.harman.com/download/50.1.1.1

[bobaoapae]

are this new config working? i don't find anything related in the releases notes. @ajwfrost

[ajwfrost]

Hi
From the above link to the 50.1.1.1 download, you can get at the relevant release notes (search then for "2235" for this issue..)
Relevant text:

A new app descriptor setting has been introduced at the top level, “”, which can be set to one of the following values:
• none: no stack traces will be available in release builds
• standard: a stack trace listing the call stack will be provided
• verbose: a stack trace that includes file name and line number information (where available from the SWF) will be provided
If the item is missing, the runtime falls back to the previous default behaviour which is to use “none” for pre-v18 SWFs and “standard” for SWF v18+

And I just checked, we even have updated the documentation for the app descriptor elements:
https://airsdk.dev/docs/building/application-descriptor-files/elements/application#stacktraces

thanks

[bobaoapae]

Thanks

[Menard1965]

Thx a lot. I can see the line numbers now, but is there a trick or method to write the Error to a file for later debug?

So if a customer has problemes with an APP i could lead them to a logfile on their harddrive ?
At the moenmt I use uncoughterror Handler to get the Info. But in the Adobe runbtime errors are not shown ?

Thx a lot
Michael