This fixes the local failure

This fixes luci failure

This LGTM, but what was happening previously? Calling getWeakPtr on nil when we're unsetting it actually produces a WeakPtr instance which crashes on .get()?

@dnfield might have some opinions too.

viewController is nil with type FlutterViewController. We call the WeakPtrFactory on a undefined reference which try to wrap itself. I guess it just some garbage, and observation will break the compiler for some reason which prevent me from observe what is inside.

schrodinger's cat

Hm. Sending a message to nil results in nil. But we expect the weak ptr to be a reference. I think this is ok.

When I tried viewController.get(), it does try to grab what is inside except it fails the thread check. I am not familiar with objective c. If viewController is nil, will viewController.get() still work?

it is a driver test calls this

Can we check (via xcode debugger or something) whether the remaining issue is indeed a threading issue? If so, let's use the right threads in the test via something like https://github.com/flutter/engine/blob/master/fml/synchronization/count_down_latch_unittests.cc#L24

We end up doing something similar on Android too when running instrumentation tests (which drives from a different thread while the engine expects main thread access). https://github.com/flutter/engine/blob/master/testing/scenario_app/android/app/src/androidTest/java/dev/flutter/scenarios/EngineLaunchE2ETest.java

I think the code here is correct. The weakptr is created in test thread and unwrapped in the same thread. It is because the nil vc will cause some issue.
consider this case

FlutterViewController* testvc = nil;
fml::WeakPtr<FlutterViewController> test = [testvc getWeakPtr];

I believed [testvc getWeakPtr] will return a static_cast<fml::WeakPtr> version of nil. this will result in a unintialized weakptr whose creating thread is 0x0;
When you later do test.get(), it tries to compare creating thread 0x0 with current thread and failed.

either way, I think this is tangential to this pr.