search

airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
202 stars 11 forks source link

fdb: Unexpected error while processing command, in DebugCLI.setInitialSourceFile #1232

Open j3k0 opened 3 years ago

j3k0 commented 3 years ago

Problem Description

The app connects to the debugger, but the latest fails (from the stacktrace, it looks like the problem is with loading source files).

$ fdb
Adobe fdb (Flash Player Debugger) [build development]
Copyright (c) 2004-2007 Adobe, Inc. All rights reserved.
(fdb) r
Waiting for Player to connect
Player connected; session starting.
Unexpected error while processing command.
For diagnostic purposes stack trace follows:
java.lang.NullPointerException
        at flex.tools.debugger.cli.DebugCLI.setInitialSourceFile(DebugCLI.java:5108)
        at flex.tools.debugger.cli.DebugCLI.doRun(DebugCLI.java:5032)
        at flex.tools.debugger.cli.DebugCLI.processLine(DebugCLI.java:7052)
        at flex.tools.debugger.cli.DebugCLI.process(DebugCLI.java:828)
        at flex.tools.debugger.cli.DebugCLI.execute(DebugCLI.java:669)
        at flex.tools.debugger.cli.DebugCLI.main(DebugCLI.java:461)
ajwfrost commented 3 years ago

What OS + version are you running FDB on here? And was the Android application built on this same machine? Wondering also what the source code path involves...

My guess is that you're on a recent macOS version, and that the source code path that's passed to the debugger is in a location that it doesn't have permissions to read. Hence the resulting null pointer exception after it assumes it can open the source file...

If that is the case, can you go into Settings -> Security & Privacy -> Privacy section -> Full Disk Access item.. then click the padlock and enter your password, click the "+" symbol, and browse for the fdb application to add this.

thanks

j3k0 commented 3 years ago

It's on macOS 11.5.1, same machine for building and running.

I tried the Full Disk Access trick just in case, didn't do anything... I have no idea how to debug, so after testing random things I found a combination that works, the problem is when compiler.optimize is set to false, in all cases. See my notes:

mxmlc -compiler.debug mxmlc -compiler.optimize adt target RESULT
false false apk App hangs forever
false true apk Works fine
true false apk not tested
true true apk not tested
false false apk-debug fdbdoes Null pointer insetInitialSourceFile, app andfdb` hang forever until the app is force killed
false true apk-debug fdb does Null pointer in setInitialSourceFile, the app crashes
true false apk-debug fdb connected, enter continue but then app and fdb hang forever until the app is force killed
true true apk-debug Works fine

So eventually, it looks like the problem is with setting compiler.optimize to false because it also breaks the release build. Too bad, as it takes 3 times as much time to generate the SWF.

Setting compiler.debug to false in an apk-debug build is probably fine to expect failing, this was a mistake in my build chain, it was what was causing the setInitialSourceFile error in fdb, maybe it could be caught more graciously.

ajwfrost commented 3 years ago

Thanks for the detailed investigation! We'll have to look into this and see if we can reproduce it with the different optimize settings. I would have thought that things might have been the other way round i.e. including the optimization step would cause issues..

Can I check, are you just using the full AIR SDK on its own, or is this Flex-based i.e. a Flex SDK plus the stripped-back AIR SDK overlay?

thanks

j3k0 commented 3 years ago

Are you just using the full AIR SDK on its own

Yes, full AIR SDK, on its own. 33.1.1.633.

To compile the SWF, we're using mxmlc on the command-line with an mxmlc-config.xml file which I can provide if needed. Same for adt, it's used from the command-line and I can provide the application descriptor.

BMGMobile commented 2 years ago

We are seeing this as well with 64-bit Android builds on the full AIR SDK versions 33.1.1.743 and 33.1.1.929. We are compiling through Haxe and packaging this with the command line adt -package -target apk-debug -arch armv8.

Here is the FDB log from 33.1.1.929:

(fdb) r
Waiting for Player to connect
Player connected; session starting.
Unexpected error while processing command.
For diagnostic purposes stack trace follows:
java.lang.NullPointerException
        at flex.tools.debugger.cli.DebugCLI.setInitialSourceFile(DebugCLI.java:5108)
        at flex.tools.debugger.cli.DebugCLI.doRun(DebugCLI.java:5032)
        at flex.tools.debugger.cli.DebugCLI.processLine(DebugCLI.java:7052)
        at flex.tools.debugger.cli.DebugCLI.process(DebugCLI.java:828)
        at flex.tools.debugger.cli.DebugCLI.execute(DebugCLI.java:669)
        at flex.tools.debugger.cli.DebugCLI.main(DebugCLI.java:461)
Player session terminated
BMGMobile commented 2 years ago

This turned out to be a problem with using an older version of BlueStacks for us. 33.1.1.743 is working correctly with the latest BlueStacks 5.