The previous default (Wifi) would never work; only Http mode works on watchOS
devices. This means that unless debugging was explicitly disabled (for
instance when running without debugging from the IDE), we'd try to connect in
WiFi mode (and gracefully fail, but showing error messages that are
unnecessary and potentally scary/confusing).
* [runtime] Clean up public symbols. Fixes#5124.
Clean up public symbols, by:
* Symbols that don't need to be public (most of them), can be private.
* Prefix all public symbols with `xamarin_`.
* Add a test to ensure we don't introduce new public symbols.
* Use C symbols instead of mangled C++ symbols, since those are easier to
handle in the test.
This minimizes the chance of getting into a symbol clash with another native library.
Fixes https://github.com/xamarin/xamarin-macios/issues/5124.
* Some test fixes.
When debugging watchOS apps on device, we wait forever [1] for a connection to
be established to the IDE (iOS apps wait for only 2 seconds, but that's
because the app will be killed after a while, which we avoid on watchOS by
attaching the native debugger).
Unfortunately our error handling was not quite optimal, which meant that if
the connection to the IDE failed, we'd wait forever instead of launching the
app without attaching the debugger.
So improve this, by printing "Waiting for connection to the IDE..." messages
while trying to connect, and printing detailed log messages if the
connection attempt fails (as well as terminating the wait and launching the
watch app).
[1] In this case forever technically means "1 hour".
Store the launch mode in a static variable instead of storing if we're an
extension (since the launch mode also contains that information).
Also pass the launch mode around in Xamarin.Mac's initialization data.
* Bump maccore to get fix for launching the simulator for app extensions.
* [runtime] Don't look in shared memory for debug data in normal apps.
Don't look in shared memory for debug data in normal apps, because it
interferes when debugging extensions from the same solution as a container
app:
Example, for a keyboard extension:
1. Run extension in XS.
2. Manually launch the extension's container app (which contains a textbox
that can be used to launch the keyboard).
3. The container app reads the debug data in shared memory which was intented
for the extension, and takes over the debugger.
4. Launch keyboard, which will not be able to connect to the IDE because the
container app already connected to the IDE.
Clang's static analyzer tought me something new today: 'copy' properties are
not automatically deallocated 😒:
monotouch-debug.m:237:1: warning: 'XamarinHttpConnection' lacks a 'dealloc' instance method but must release '_completion_handler' and others
@implementation XamarinHttpConnection
^
At the beginning of dawn, not long after the big bang, we used to vibrate the
phone if there was a problem when connecting to the debugger in the IDE, and
the number of times the phone vibrated indicated a certain error condition.
This innovative debugging technique was at some point replaced with more
intuitive (albeit less innovative) error reporting, however the *_connect_*
family of functions continued returning the number of times the phone should
vibrate, even if the caller was now soundlessly ignoring this information.
After many years someone had the wonderful idea of running a static analyzer
on the code, and now the unused return value is not so silent anymore:
monotouch-debug.m:663:5: warning: Value stored to 'rv' is never read
rv = monotouch_connect_usb ();
^ ~~~~~~~~~~~~~~~~~~~~~~~~
monotouch-debug.m:665:5: warning: Value stored to 'rv' is never read
rv = monotouch_connect_wifi (hosts);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
monotouch-debug.m:667:5: warning: Value stored to 'rv' is never read
rv = xamarin_connect_http (hosts);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So fix the warning by removing the return value.
The completion handler block must be copied to the XamarinHttpConnection
instance, otherwise we'll just store a pointer to a stack block, and once we
invoke the block we'll access stack memory (probably from another thread),
which is really not what we want to do.
https://bugzilla.xamarin.com/show_bug.cgi?id=44568
At startup we send a request to all the IP addresses we have,
so we must make sure to not get confused if we get responses
from more than one of them.
This fix also requires an updated mlaunch.
https://bugzilla.xamarin.com/show_bug.cgi?id=44568
* [runtime] Use printf on watchOS, NSLog doesn't shown up (by default).
* [runtime] Use a wrapper function for logging.
So that we can chose between printf and NSLog at runtime,
depending on where we're running.
The watchOS device has limited networking support; in particular
it does not allow inbound/output network connections using 'bind'
(kernel-level sandbox restrictions).
This means that we can't use BSD sockets to connect to the debugger
in the IDE on the desktop. Instead we create an http tunnel that
knows how to convert socket send/recv data into http requests on
both sides.
https://bugzilla.xamarin.com/show_bug.cgi?id=41554
Launching a watchOS extension on device with the managed debugger
attached is slow, which means that the launch watchdog will kick in
and kill the app before it has launched.
So we attach the native debugger as well, which prevents the launch
watchdog from killing the app. Incidentally it also makes watchOS
not background the app.
We're using private API to determine whether a native debugger is
attached, but it's only in debug code, and as such would not be
included in release builds for customer apps. Also the code is
currently limited to watchOS since it's not needed on other
platforms for now.
Rolf Bjarne Kvinge
Sebastien Pouliot
Sebastien Pouliot
Zoltan Varga