search

NativeScript / ios-jsc

NativeScript for iOS using JavaScriptCore
http://docs.nativescript.org/runtimes/ios
Apache License 2.0
298 stars 59 forks source link

App crashes on launch after building app in release mode with dist profile IOS #924

Open VimalKumarS opened 6 years ago

VimalKumarS commented 6 years ago

App crashes on launch after building app in release mode with dist profile IOS

App work well in debug mode, over simulator and using nativescirpt side kick over phone, but after building the app in release mode with distribution profile it doesn't work. I am using firebase notification and finger auth plugin

Please, provide the following version numbers that your issue occurs with:

"@angular/compiler-cli": "4.4.5", "@ngtools/webpack": "~1.5.3", "@types/jasmine": "^2.6.0", "babel-traverse": "6.26.0", "babel-types": "6.26.0", "babylon": "6.18.0", "copy-webpack-plugin": "~4.0.1", "cross-env": "^5.1.4", "extract-text-webpack-plugin": "~3.0.0", "fs": "0.0.1-security", "jasmine-core": "^2.7.0", "json": "^9.0.6", "karma": "^1.7.0", "karma-jasmine": "^1.1.0", "karma-nativescript-launcher": "^0.4.0", "lazy": "1.0.11", "mkdirp": "^0.5.1", "nativescript-css-loader": "~0.26.0", "nativescript-dev-android-snapshot": "^0..", "nativescript-dev-typescript": "~0.6.0", "nativescript-dev-webpack": "^0.7.3", "path": "^0.12.7", "raw-loader": "~0.5.1", "resolve-url-loader": "~2.1.0", "tns-platform-declarations": "3.4.0", "typescript": "~2.4.2", "webpack": "~3.2.0", "webpack-bundle-analyzer": "^2.8.2", "webpack-sources": "~1.0.1"

Please, tell us how to recreate the issue in as much detail as possible.

Crash report after installing it on iphone

Incident Identifier: CEEE7668-17A7-483F-9E54-1021D65BC92B CrashReporter Key: 715dacf781dc48860bfb9c8d3c5574440289b051 Hardware Model: iPhone9,3 Process: warpapp [6150] Path: /private/var/containers/Bundle/Application/4C4BE408-4BDF-4760-B1B9-231E09BBE1AF/warpapp.app/warpapp Identifier:
Version: 1.0 (1.0) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition:

Date/Time: 2018-05-19 09:32:11.6686 -0700 Launch Time: 2018-05-19 09:32:10.2838 -0700 OS Version: iPhone OS 11.3.1 (15E302) Baseband Version: 2.03.12 Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x00000000deaddead VM Region Info: 0xdeaddead is not in any region. Bytes before following region: 629694803 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START --->

lschaffer commented 6 years ago

Me too .. Using the IOS Cloud Build from the latest Sidekick TNS CLI 4.1.2 tns-ios@4.1.1

Date/Time: 2018-06-28 18:43:07.2052 -0700 Launch Time: 2018-06-28 18:43:03.8712 -0700 OS Version: iPhone OS 11.4 (15F79) Baseband Version: 6.60.00 Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000018 VM Region Info: 0x18 is not in any region. Bytes before following region: 4304027624 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START --->
__TEXT 00000001008a4000-00000001008a8000 [ 16K] r-x/r-x SM=COW ...b.app/dacomob

Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0] Triggered by Thread: 9

Filtered syslog: None found

Last Exception Backtrace: (0x181736d8c 0x1808f05ec 0x181744098 0x18173c5c8 0x18162241c 0x187f0f978 0x181028aa0 0x181028a60 0x1810329b4 0x1810332fc 0x181033cc8 0x18103c098 0x18135be70 0x18135bb08)

Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 NativeScript 0x0000000101648a74 0x100e04000 + 8669812 1 NativeScript 0x0000000101648c04 0x100e04000 + 8670212

toddanglin commented 5 years ago

I have run in to this same issue in a large vanilla {N} app (using TypeScript) that I recently converted to work with Webpack. I'm using {N} CLI 5.4.0 and tns-core-modules 5.4.1 and iOS runtime 5.4.0.

The app bundle builds and runs fine in standard debug mode, both in simulator and on real devices.

When I build the app for publishing (release mode), the app crashes on startup with the cryptic undefined is not an object (evaluating 'b.prototype') error.

@vakrilov @rosen-vladimirov What is changing between debug and release builds with Webpack that could cause this kind of error? Clearly, with everything working in debug bundle builds, I'm inclined to think all TypeScript __extends are properly configured. Is something else different happening in release builds that could cause an uncaught configuration problem to manifest like this during?

Just looking for a sane place to start further debugging this problem...appreciate any ideas...

uvigii commented 5 years ago

Same here. Moreover, it happens mostly on iPhone X (on 7,8 seems fine for me. iOS is latest 12.3.1 everywhere). Try to disable one by one uglify & AOT. Go carefully trough build log: watch for warnings from webpack.

toddanglin commented 5 years ago

@uvigii Is uglify enabled by default with release builds?

I'm using {N} core (with TypeScript), so I don't think AOT applies. I have tried doing release builds with and without the --env.uglify flag, but if it's enabled by default, perhaps I need to take a different action to disable. That was a leading candidate in my mind for causing this kind of problem...

Would still love to know if there are any other build behaviors that change when doing a --bundle release build to help track this down.

FWIW, this app is being deployed to iPads (Air, Pro, Mini), and the behavior is consistent (works with debug builds, crashes on start with b.prototype error with release builds).

toddanglin commented 5 years ago

Okay. I fixed my build error! Here's what helped...

I admit I'm no Webpack expert, so this overview of the Webpack automatic optimization steps that happen for production (aka {N} --release) builds helped: https://medium.com/webpack/webpack-4-mode-and-optimization-5423a6bc597a.

In case you didn't know, like me, webpack automatically applies a number of optimizations when it runs a production mode build. You can override them, but if you provide no configuration in your webpack.config, they still get applied (again, see the blog post). Further, if you do a {N} release build OR provide the --env.uglify flag, it will trigger the Webpack production build process.

Using the info in that post, I was able to set the namedModule and namedChunk attributes to true (forcing them to remain enabled during a production build). I also set the minimize optimization option to false so my production build would still produce readable code.

All of this helped me see the actual file that was triggering the b.prototype undefined error.

From there, it because clear that the problem was indeed circular references CAUSED BY use of barrel files (that is, a file used to consolidate TypeScript exports/imports). I had several unintentional cases where a module listed as an export in a barrel, was also requiring that barrel file to import a different module. Cleaning-up these imports to avoid using the offending barrel files ultimately fixed the problem.

Hope this helps future troubleshooters.