Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2019-02] [watchOS] mini/debug fails on armv7k #14223

Closed
lewurm opened this issue Apr 25, 2019 · 1 comment · Fixed by #14310 or xamarin/xamarin-android#3105
Assignees
Labels

Comments

@lewurm
Copy link
Member

@lewurm lewurm commented Apr 25, 2019

https://gist.github.com/lewurm/207cfdf6fd69a0908f183e06a8f64856

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: EXC_ARM_DA_ALIGN at 0x00d99838
VM Region Info: 0xd99838 is in 0xca0000-0xd9c000;  bytes after start: 1022008  bytes before end: 10183
      REGION TYPE              START - END     [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      Stack Guard            00c9c000-00ca0000 [   16K] ---/rwx SM=NUL  
--->  Stack                  00ca0000-00d9c000 [ 1008K] rw-/rwx SM=PRV  thread 0
MALLOC guard page 00d9c000-00da0000 [ 16K] ---/rwx SM=ZER 

looks similar to #13672 but bumping mono to include the fix didn't fix this crash. but might be in a similar area.

/cc @rolfbjarne

@lewurm

This comment has been minimized.

Copy link
Member Author

@lewurm lewurm commented May 2, 2019

Some notes on debugging watchOS:

  • This was probably due to the bug itself (LR location wasn't in sync with CFI anymore?), but some frames were missing on backtraces. If the backtrace doesn't make sense, keep an close eye the stack pointer for each frame that lldb shows. If the stack pointer gap is too big between frames, unwinding probably did something wrong.
  • I hit an lldb bug: https://bugs.llvm.org/show_bug.cgi?id=41709 it's possible to workaround by creating a dummy function, call that where the breakpoint should be and put the breakpoint on the dummy function instead (breakpoints on symbol names are still working).
  • call mono_pmip ((gpointer) $pc) doesn't work 😢 crashes with a SIGSEGV and I didn't figure out why. I ended up putting mono_pmip () all over the code base, which worked. Seems to be related to call not fully working on Apple Watch. It isn't completely broken as call printf ("hi\n") works for example.
  • some helper scripts:
$ rm -f /tmp/mtouch-lldb-prep-cmds; while ! test -f /tmp/mtouch-lldb-prep-cmds; do sleep 1; date; done; echo "settings set auto-confirm 1" >> /tmp/mtouch-lldb-prep-cmds; echo "continue" >> /tmp/mtouch-lldb-prep-cmds; lldb -s /tmp/mtouch-lldb-prep-cmds; say execution complete
  • Probably the most important tip for MSFT employees: Enrolled devices enforce stricter security guidelines, which among other things do not allow to turn off the passcode on the Apple Watch. This makes the iteration loop much more painful because deployment needs an unlocked device and on the charger "wrist unlocking" doesn't work, thus the device locks after 20s. So to avoid entering passcode all the time at the right time (keep in mind deploying takes relatively long), I highly recommend to use a device that isn't enrolled in order to keep your sanity.
  • Keeping the Apple Watch on the charger makes the lldb session more reliable. This is subjectively, I don't have numbers on that.
  • Not using the sysdiagnose profile on the Apple Watch makes the lldb session more reliable as well. Again, this is subjectively, but I assume without the profile there is less traffic on the bluetooth channel which is used by lldb too. You still see messages from stdout/stderr on the terminal where mlaunch is started from (or in the VS4M window).
  • Figuring out the exact mlaunch line can be cumbersome, suggested short-cut: Use VS4M once and then figure out the full command line invocation via ps auxw | grep mlaunch. There is one "deploy" invocation and one "run" invocation.
monojenkins added a commit that referenced this issue May 2, 2019
[2019-02] [arm] amend stack pointer properly in exception trampoline

The previous attempt ( #14078 ) only fixed it for ABIs where the stack pointer alignment is 8 bytes. ABIs, such as watchOS, require 16 byte alignment.

Fixes #14223

Backport of #14310.

/cc @lewurm
monojenkins added a commit that referenced this issue May 3, 2019
[2019-04] [arm] amend stack pointer properly in exception trampoline

The previous attempt ( #14078 ) only fixed it for ABIs where the stack pointer alignment is 8 bytes. ABIs, such as watchOS, require 16 byte alignment.

Fixes #14223

Backport of #14310.

/cc @lewurm
grendello added a commit to grendello/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: xamarin@1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
jonpryor added a commit to xamarin/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: 1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
jonpryor added a commit to xamarin/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: 1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.