Bug 59372 - Execution randomly crashing
Summary: Execution randomly crashing
Status: NEEDINFO
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 8.0 (15.4)
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2017-09-09 10:33 UTC by Paul Johnson
Modified: 2017-10-16 13:35 UTC (History)
2 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
IDE log (29.24 KB, application/zip)
2017-09-09 10:33 UTC, Paul Johnson
Details
throwback from IDE (27.91 KB, text/plain)
2017-09-09 10:35 UTC, Paul Johnson
Details

Description Paul Johnson 2017-09-09 10:33:15 UTC
Created attachment 24669 [details]
IDE log

I have an app that works for the majority of the time, but on some occasions will crash. I've attached both the throwback and the IDE log from VS for Mac.

There doesn't seem to be any sort of pattern to the crashing which makes it even more annoying!
Comment 1 Paul Johnson 2017-09-09 10:34:08 UTC
=== Visual Studio Community 2017 for Mac (Preview) ===

Version 7.2 Preview (7.2 build 540)
Installation UUID: b208641e-c3fd-4701-902a-0f9f31ded127
Runtime:
	Mono 5.4.0.167 (2017-06/6b8abfeb7cc) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 504000167

=== NuGet ===

Version: 4.3.0.4199

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	1.1.1
	1.0.4
SDK: /usr/local/share/dotnet/sdk/1.0.1/Sdks
SDK Version: 1.0.1
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.4.0/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.5.6
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Xamarin.Android ===

Version: 7.5.0.13 (Visual Studio Community)
Android SDK: /Users/PFJ/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)
		7.0    (API level 24)
		7.1    (API level 25)

SDK Tools Version: 25.2.5
SDK Platform Tools Version: 26.0.0
SDK Build Tools Version: 26.0.1

Java SDK: /usr
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Apple Developer Tools ===

Xcode 8.3.3 (12175.1)
Build 8E3004b

=== Xamarin.iOS ===

Version: 10.14.0.24 (Visual Studio Community)
Hash: 43c281b4
Branch: d15-4
Build date: 2017-08-23 15:23:10-0400

=== Xamarin Inspector ===

Version: 1.3.0-rc2
Hash: fab36d8
Branch: 1.3-release
Build date: Wed, 30 Aug 2017 21:15:37 GMT
Client compatibility: 1

=== Xamarin.Mac ===

Version: 3.8.0.3 (Visual Studio Community)

=== Build Information ===

Release ID: 702000540
Git revision: 937feef24e2d1caad12f34780602b39a33c44ece
Build date: 2017-08-17 08:32:35-04
Xamarin addins: 9bbcd5509a57e89460cafd47eb52bdb2a26d2437
Build lane: monodevelop-lion-d15-4

=== Operating System ===

Mac OS X 10.12.6
Darwin 16.7.0 Darwin Kernel Version 16.7.0
    Thu Jun 15 17:36:27 PDT 2017
    root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===

Redth's Addins 1.0.9
Comment 2 Paul Johnson 2017-09-09 10:35:19 UTC
Created attachment 24670 [details]
throwback from IDE
Comment 3 Jon Douglas [MSFT] 2017-09-18 15:34:28 UTC
Hi Paul,

This bug will be a bit trickier to pinpoint without a sample project or reproduction steps. Based on the crash log you've provided, I see:

[libc] Fatal signal 11 (SIGSEGV), code 1, fault addr 0x87 in tid 9089 (Threadpool work)

Which to me sounds like this is failing in libc / native code. Based on the definition:

This signal is generated when a program tries to read or write outside the memory that is allocated for it, or to write memory that can only be read. (Actually, the signals only occur when the program goes far enough outside to be detected by the system’s memory protection mechanism.) The name is an abbreviation for “segmentation violation”.

Common ways of getting a SIGSEGV condition include dereferencing a null or uninitialized pointer, or when you use a pointer to step through an array, but fail to check for the end of the array. It varies among systems whether dereferencing a null pointer generates SIGSEGV or SIGBUS.

To help diagnose this issue further, we will need a reliable way to reproduce this, and also "adb logcat" logs if possible.

Given that your version information looks like Preview items, is this the same case with the application? In other words, is the application currently out on the store or are you encountering this while debugging?

Thank you!
Comment 4 Paul Johnson 2017-10-16 13:35:43 UTC
I have a feeling it was because I was using the alpha branch that this was happening. Not seen it in stable.

Note You need to log in before you can comment on or make changes to this bug.