EXC_BAD_ACCESS in GCDWebServer after clean

[mfikes]

@dmotz reports, with respect to downstream work with new CLI-based Natal:

"I'm running into one issue though where subsequent builds hit a EXC_BAD_ACCESS error from GCDWebServer

But it looks like that's an Xcode 7 issue that's been fixed in version 3.3 of GCDWebServer”

[mfikes]

Hey @dmotz, I've tried reproducing the EXC_BAD_ACCESS. Looking at the latest commits to GCDWebServer, there appears to be a fix in the works for Swift2 apps. So, I tried a little harder, adding a Swift translation unit to a project created using the Natal CLI branch, but haven't been able to repro. (I tried ../index.js launch, cleaning within Xcode first, etc.)

[dmotz]

I've found it's intermittent. I haven't found a pattern that reproduces it every time, but it usually occurs when I create a new project, build it, then quit the simulator, rebuild, and attempt to connect the REPL. The app crashes as soon as the REPL connects.

I noticed it happening occasionally with the previous version of Natal, but it seems to be much more frequent since I upgraded to Xcode 7.

Maybe this is due to some side effects of me compiling dozens of test projects in fairly quick succession? I'll keep looking for a pattern and maybe see what happens on OSX 10.11.

Here's the stack trace and line I'm seeing the error on:

[mfikes]

@dmotz Hrm. I wonder if that is potentially a different issue (with a different block) in GCDWebServer. I've tried reproducing the issue on another Mac, with no luck yet.

GCDWebServer hasn't even released version 3.3 yet, but one way to check if it might fix it in the interim is to edit some-app-name/native/ios/Podfile so that it looks like this:

source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'

pod "GCDWebServer/WebDAV", :git => 'https://github.com/swisspol/GCDWebServer.git'
pod "Ambly", :path => '~/Projects/ambly'

where Ambly is set to point to a clone on your local filesystem where you delete the line in Ambly.podspec that looks like

   s.dependency "GCDWebServer/WebDAV", "~> 3.2.2"

There might be an easier way, but doing the above, followed by doing

pod update

from within some-app-name/native/ios will cause it to set up things to use master of GCDWebServer.

[dmotz]

@mfikes After a lot of trial and error I figured out what causes the issue I've been seeing.

My first hunch was wrong since trying manual updates using the latest master branch of GCDWebServer did nothing to help.

After trying things completely independently of Natal using the manual Ambly project procedure, I continued to see the same pattern where the app would run perfectly with the REPL on the first build and crash with any later Xcode build upon REPL connection.

The culprit seems to be simply running clean on a project. If I do subsequent builds without a clean, the REPL connects with no problem. If I run clean at some point (via either the Xcode GUI or CLI), all subsequent builds crash on REPL connection.

I'm not sure what this implies, but I don't think it's necessarily a blocker for releasing the next version of Natal.

[mfikes]

@dmotz Cool. I'm still unable to reproduce. Here is what I've been trying:

1. natal TestProject
2. Run it in Xcode and then start.sh to connect REPL.
3. :cljs/quit in REPL.
4. Stop the app in Xcode by hitting the square stop button.
5. Product > Clean.
6. Run it again and then start.sh and successfully connect REPL.

[dmotz]

Yeah unfortunately I get the same fatal error every time following those steps.

Oddly enough, if I duplicate the project directory and open the duplicated Xcode project, I can run it and connect the REPL (even after cleaning the original). As soon as I run clean on the duplicate, I get the crash on REPL connection.

I assume this has to do with some Xcode side effects somewhere but I don't know enough about what it's doing to know where to start. I tried deleting the builds in /Library/Developer/Xcode/DerivedData/ after a clean, but that didn't work.

I know this is a nebulous issue to look into since it's not even happening for you.

Running Xcode 7.0.1 on OSX 10.11.

I may try setting up a VM next to see if I can reproduce this there.

[mfikes]

@dmotz I'm also running Xcode 7.0.1 on OSX 10.11. (I tried it on another mac with the same with no luck.)

Here's something to consider: The crash is occurring in a block of code that ostensibly should only be conditionally compiled when running on a device, right?

[dmotz]

I think I figured this out finally Mike.

I noticed socketfilterfw eating a lot of CPU after builds so I disabled the OS X firewall completely and the issue with post-clean crashes seems to disappear.

My guess is that the firewall is analyzing the new binary after a clean build and is taking too long and interfering with the connection?

Earlier I figured that since I wasn't having discoverability issues, the firewall wasn't a suspect.

[mfikes]

Ahh cool. In the Ambly Connectivity Wiki I recommend turning off the firewall. But I haven't revisited that since Apple addressed the discoveryd issues I bet. Good find! I'll try to repro. Someone else is likely to encounter this as well.

[mfikes]

@dmotz I gave it a shot on a circa-2009 iMac running El Capitan and failed to reproduce any problems.

Specifically, I did System Preferences > Security & Privacy > Turn On Firewall, along with granting the app permission to accept incoming network connections when prompted, going through the repo steps

Earlier, I had questioned the TARGET_OS_IPHONE aspect: It turns out that code enclosed in such a block also runs in the simulator, so we can scratch that off.

[dmotz]

Thanks for all your help and patience diagnosing this Mike.

I think at this point we can chalk it up to something weird with my system.

I'm cool with closing the issue and reopening later if we hear of anybody else hitting this behavior.

[scttnlsn]

@mfikes I have my firewall disabled but I'm still running into this issue (details here: https://github.com/dmotz/natal/issues/45)

[mfikes]

@scttnlsn We are essentially stuck on this one in that we can't find a mechanism to reproduce it.

[scttnlsn]

@mfikes I actually got things working by using the master version of GCDWebServer. Added this to my Podfile:

pod "GCDWebServer/WebDAV", :git => 'https://github.com/swisspol/GCDWebServer.git'
pod "Ambly", :git => 'https://github.com/scttnlsn/Ambly', :branch => '3.3'

And changed Ambly's podspec to include:

s.dependency "GCDWebServer/WebDAV", "~> 3.3"

[mfikes]

@scttnlsn OK. #109 could make use of GCDWebServer 3.3, so when it is available, we can revise things to use it.