airsdk / Adobe-Runtime-Support

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

No ARMv7 dSYM file #1551

Open dampgnat opened 2 years ago

dampgnat commented 2 years ago

The dSYM generated by AIR SDK 33.1.1.713 is only ARM64, no ARMv7. There was a bug preventing AIR from generating ARMv7 symbol - https://tracker.adobe.com/#/view/AIR-4073680 This bug appears to remain.

I'm receiving thousands of crash reports via Bugsnag but with no way of interpreting the error codes without a workable dSYM file.

Context: Using AIR SDK 33.1.1.713 When building IPA for appstore on a M1 Mac Mini

ajwfrost commented 2 years ago

Hi - we don't support ARMv7 iOS targets any more, since it's impossible to generate the 32-bit bytecode when using a mac with Catalina or beyond...

dampgnat commented 2 years ago

Hey Andrew, after further investigation my engineers have concluded that 32bit wasn't necessary after all, so apologies for the unnecessary report.

However, they are requesting an archive that includes the dSYM: "One of the important settings in Xcode is to build release with DWARF with dSYM"

Since AIR bypasses the Xcode project packaging process, is there an ADT command that can include the above?

ajwfrost commented 2 years ago

Hi

My understanding is that there is a dSYM file created for any ANEs but I don't think we can do this for the AIR binary itself as the symbols are meant to be "Adobe Confidential". That said, I think the way they have to do things with iOS means that there are at least some symbols available anyway (the ones from the core avmplus engine which are required to link against during AOT compilation) .. so we may be able to create a file that has partial symbols included. I will check with one of the iOS devs here to see what could be done...

thanks

dampgnat commented 2 years ago

Ooooh... so the dSYM file that AIR is currently generating only contains symbols for the ANEs anyway?

This Bugsnag ANE claims to report even unhandled actionscript errors - https://github.com/DigitalStrawberry/ANE-Bugsnag Does this somehow get around the confidential symbols and generate its own?

Regardless, I don't think I could use this ANE anyway, as one of my ANEs already contains an instance of bugsnag. So your partial symbols idea might be my only option.

dampgnat commented 2 years ago

Hi @ajwfrost, any word from your iOS devs on the partial symbols?

pnico commented 8 months ago

Hi @ajwfrost, would it be possible for you to ask about this, to verify that it is indeed forbidden for AIR developers to know what happened when an app crashes in framework code? 😇

The most common crashes we see on iOS by far have always been ones for which the crash reports tell us basically nothing because of this restriction. Someone just asked me about it again, and there are a few old issues here about it so I thought I'd ask

Edit: if it were possible to license just some symbol file that we could use to get better information to improve the quality of our app, we would probably consider it.