Better MonoTouch crashes with TestFlight - c#

We've hooked up TestFlight and the TestFlight SDK with MonoTouch and so far it's working great.
One thing we've noticed is that the crash reports are more geared towards Obj-C apps.
They look like this after you upload a zipped dSYM file:
0 OurApp 0x007a7116 testflight_backtrace + 170
1 OurApp0x007a7c3c TFSignalHandler + 208
2 libsystem_c.dylib 0x34f68538 _sigtramp + 48
3 libsystem_c.dylib 0x34f5df5a pthread_kill + 54
4 libsystem_c.dylib 0x34f56fea abort + 94
5 OurApp 0x007793b3 monoeg_g_logv (goutput.c:137)
6 OurApp 0x0077941f monoeg_g_log (goutput.c:147)
7 OurApp 0x005f1393 get_numerous_trampoline (aot-runtime.c:3447)
8 OurApp 0x005f1b2f mono_aot_get_imt_thunk (aot-runtime.c:3576)
9 OurApp 0x006e2c83 initialize_imt_slot (object.c:1247)
10 OurApp 0x006e321f build_imt_slots (object.c:1371)
11 OurApp 0x006e356f mono_vtable_build_imt_slot (object.c:1439)
12 OurApp 0x005fcf83 mono_convert_imt_slot_to_vtable_slot (mini-trampolines.c:198)
13 OurApp 0x005fd50f common_call_trampoline (mini-trampolines.c:333)
14 OurApp 0x005fe573 mono_vcall_trampoline (mini-trampolines.c:644)
15 OurApp 0x0056a68f generic_trampoline_vcall (mscorlib.dll.6.s:194345)
16 OurApp 0x00416b4f System_Collections_Generic_List_1__ctor_System_Collections_Generic_IEnumerable_1_T (mscorlib.dll.6.s:32014)
17 OurApp 0x0026955b System_Linq_Enumerable_ToList_TSource_System_Collections_Generic_IEnumerable_1_TSource (System.Core.dll.6.s:1917)
So you can tell the general C# function where the crash occurred. (Note: this crash was a bug in MonoTouch 5.0.1 where Linq generics were messed up, seems to be fixed in 5.0.2)
It would be nice to get the full C# stack trace in here, any thoughts on how to do that? I could hook into AppDomain.UnhandledException and put a try-catch around my static void Main method, but wondered if there is a way to report the stack trace out to TestFlight.

I'm not familiar with MonoTouch, but what about using the Remote Logging features of the TestFlight SDK?

Related

Exception: Application initializing document picker is missing the iCloud entitlement. Is com.apple.developer.icloud-container-identifiers set?

I am using file picker from below link: 2.0.8-beta
https://github.com/jfversluis/FilePicker-Plugin-for-Xamarin-and-Windows
I have setup my iOS xamarin project and sets all the data in my application mentioned in below link:
https://learn.microsoft.com/en-in/xamarin/ios/data-cloud/intro-to-cloudkit
But now I am getting below error for iOS. Any body have any idea?
Exception:
Foundation.MonoTouchException: Objective-C exception thrown. Name: NSInternalInconsistencyException Reason: Application initializing
document picker is missing the iCloud entitlement. Is
com.apple.developer.icloud-container-identifiers set?
Native stack trace:
0 CoreFoundation 0x0000000185ace37c + 148
1 libobjc.A.dylib 0x0000000184d14528 objc_exception_throw + 56
2 CoreFoundation 0x0000000185ace238 + 0
3 Foundation 0x00000001864697f4 + 112
4 UIKit 0x000000018f77ff0c + 300
5 UIKit 0x000000018f77f788 + 228
6 XamarinFilePickerTest.iOS 0x0000000102e038e8 XamarinFilePickerTest.iOS + 38582504
7 XamarinFilePickerTest.iOS 0x0000000102245904 XamarinFilePickerTest.iOS + 26269956
8 XamarinFilePickerTest.iOS 0x000000010321dfd0 XamarinFilePickerTest.iOS + 42885072
9 XamarinFilePickerTest.iOS 0x000000010321f4e4 XamarinFilePickerTest.iOS + 42890468
10 XamarinFilePickerTest.iOS 0x000000010322f334 XamarinFilePickerTest.iOS + 42955572
Application initializing document picker is missing the iCloud entitlement. Is com.apple.developer.icloud-container-identifiers set?
Refer to Enabling CloudKit in a Xamarin Application
Enable iCloud in Entitlements.plistand ensure the Ubiquity Container exists for the application.

Failed to open a handle to the device when opening GPIO pin

Everytime I open a GPIO pin I get this exception:
WinRT information: Failed to open a handle to the device.
A resource required for this operation is disabled.
I can't seem to find much information for this on the internet. Probably because UAP is still in a preview. And I don't think something is wrong with my code, it is almost the same one from the Blink example:
GpioController gpio = GpioController.GetDefault();
if (gpio != null)
{
var ledpin = gpio.OpenPin(11);
ledpin.Write(_light ? GpioPinValue.High : GpioPinValue.Low);
ledpin.SetDriveMode(GpioPinDriveMode.Output);
}
Only a subset of pins are available to usermode. Most pins are reserved by the system and cannot be accessed from usermode.
As far as I know pin 11 is not available. Try pin 12 or 13.
List of available Pins:
GPIO# Power-on Pull Header Pin
4 PullUp 7
5 PullUp 29
6 PullUp 31
12 PullDown 32
13 PullDown 33
16 PullDown 36
17 PullDown 11
18 PullDown 12
19 PullDown 35
20 PullDown 38
21 PullDown 40
22 PullDown 15
23 PullDown 16
24 PullDown 18
25 PullDown 22
26 PullDown 37
27 PullDown 13
35 PullUp Red Power LED
47 PullUp Green Activity LED
Edit: Added missing GPIOs

HtmlAgilityPack Save Process Not Letting Go Of File

I am saving some of the rendered html of a web site by overriding the Render method and using HtmlAgilityPack. Here is the code:
protected override void Render(HtmlTextWriter writer)
{
using (HtmlTextWriter htmlwriter = new HtmlTextWriter(new StringWriter()))
{
base.Render(htmlwriter);
string output= htmlwriter.InnerWriter.ToString();
var doc = new HtmlDocument();
doc.LoadHtml(output);
doc.Save(currDir + "\\" + reportDir + "\\dashboardTable.html");
}
}
However, some process does not let go of the saved file and I am unable to delete it from the server. Does anyone know of an HtmlAgilityPack issue that would cause this?
Any advice is appreciated.
Regards.
EDIT:
I have tried both of the methods suggested. I can't tell if they are the solution yet because my app is frozen on the server due to the files I can't delete. However, when I use these solutions on my own machine, the rendered HTML does not save as an HTML table anymore but rather like this:
INCIDENT MANAGEMENT
Jul '12 F'12
Trend F'12 2011
(avg)
Severe Incidents (Sev1/2): 3 2.1 4.16
Severe Avoidable Incidents (Sev1/2): 1 1.3 1.91
Incidents (Sev3): 669 482 460.92
Incidents (Sev4) - No business Impact: 1012 808 793
Proactive Tickets Opened: 15 19.3 14
Proactive Tickets Resolved/Closed: 14 17.3 11
CHANGE MANAGEMENT
Total Planned Changes: 531 560 583.58
Change Success Rate (%): 99.5 99.4 99
Non-Remedial Urgent Changes: 6 11 47.08
PROBLEM MANAGEMENT
New PIRs: 2 1.4 2
Closed PIRs: 0 2 3
Overdue Action items: 2 3.2 0
COMPLIANCE MEASUREMENTS
Jul Trend Jun
Total Number of Perimeter Devices: 250 258
Perimeter Devices - Non Compliant: 36 31
Total Number of Internal Devices: 6676 6632
Internal Devices - Non Compliant: 173 160
Unauthorized Perimeter Changes: 0 0
Unauthorized Internal Changes 0 0
LEGEND
ISP LINKS
July June Trend
SOC CPO DRP SOC CPO DRP
40% 34% 74% 39% 35% 74%
BELL MPLS HEAD ENDS
July June Trend
SOC CPO SOC CPO
8% 5% 7% 10% 8% 5.5% 7% 10%
ENTERPRISE NETWORK (# of issues called out)
July June Trend
CORE FW/DMZ CORE FW/DMZ
1 0 1 0
US & INTL (# of issues called out)
July June Trend
US Intl US Intl
2 2 2 3
LINE OF BUSINESS BELL WAN MPLS
<> 50%-65% >65% <> 50%-65% >65% Trend
Retail: 2272 0 1 2269 4 0
Business Banking: 59 1 0 60 0 0
Wealth: 122 2 0 121 2 1
Corporate: 51 0 0 49 2 0
Remote ATM: 280 0 0 280 0 0
TOOLS
Version Currency Vulnerability Status Health Status
Key Messages:
where only the text data has been saved and all of the HTML and CSS is missing. If I just use doc.Save() I get an exact representation of the table as it displays on the website.
Try this instead. Maybe the Save method isn't closing the underlying stream.
using( FileStream stream = File.OpenWrite( currDir + "\\" + reportDir + "\\dashboardTable.html" ) ){
doc.Save(stream);
stream.Close();
}
Edit
Per #L.B's comments it appears that HtmlAgilityPack does use a using block as in my example so it will be ensuring that the stream gets closed.
Thus as I suggested at the end of my original answer this must be a server environment problem
Original Answer
This may be some sort of bug with HtmlAgilityPack - you may want to report it to the developers.
However to eliminate that possibility you may want to consider explicitly controlling the creation of the StreamWriter for the file so you are explicitly closing it yourself. Replace this line:
doc.Save(currDir + "\\" + reportDir + "\\dashboardTable.html");
With the following:
using (StreamWriter fileWriter = new StreamWriter(currDir + "\\" + reportDir + "\\dashboardTable.html"))
{
doc.Save(fileWriter);
fileWriter.Close();
}
If the issue still persists even with this change then that would suggest an issue with your server environment rather than an issue with HtmlAgilityPack. Btw to test if this change makes a difference you should start from a clean server environment rather than one where you are already having issues deleting the file in question.

Using RedLaser SDK via MonoTouch crashing as soon as BarcodePickerController shown

I'm using Chris Branson's RedLaser MonoTouch bindings and sample from here:
https://github.com/chrisbranson/RedLaserSample
Firstly, to help out those also having trouble with this sample project, I had to update both the makefile to build the RedLaser.dll MonoTouch bindings and the sample MonoDevelop csproj to get the actual app compiling.
Makefile
The makefile supplied by Chris unzipped the RedLaser SDK download, but RedLaser changed their naming convention and so it was no longer working. I simplified it, instead requiring the user to put the libRedLaserSDK.a file into the build directory manually:
BTOUCH=/Developer/MonoTouch/usr/bin/btouch
BUILDVER=build139
VERSION=3.2.4
BINDIR=./bin/
all: $(BINDIR)RedLaser.dll
$(BINDIR)libRedLaserSDK.a:
#echo "You'll need to obtain a copy of RedLaserDevSDK-$(VERSION).zip from"
#echo "http://redlaser.com/sdk/index.php"
#echo Locate the libRedLaserSDK.a file and place within
#echo $(BINDIR)
#echo
#open http://redlaser.com/sdk/index.php
#exit 1
$(BINDIR)RedLaser.dll: Makefile AssemblyInfo.cs RedLaser.cs enums.cs $(BINDIR)libRedLaserSDK.a
$(BTOUCH) --out=$# -e RedLaser.cs enums.cs AssemblyInfo.cs --link-with=$(BINDIR)libRedLaserSDK.a,libRedLaserSDK.a
clean:
-rm -rf $(BINDIR)*.dll
The directory containing the makefile should also contain the files redlaser.cs, enums.cs and AssemblyInfo.cs (i.e. the same as Chris's).
MonoDevelop project build settings
I think the reason this stopped working was a bug in MonoDevelop or MonoTouch and the way it expands the 'Additional mtouch arguments' when they contained quotation marks. Chris's original arguments looked like this:
-cxx -gcc_flags="-framework SystemConfiguration -framework CFNetwork -framework CoreVideo -framework CoreMedia -framework AVFoundation -framework OpenGLES -framework Security -L${ProjectDir}/Lib -lRedLaserSDK -ObjC"
MonoDevelop doesn't parse this correctly, instead inserting quotation marks around each option separated by a space. Looking in the build output (under 'Compiling to native code') showed that this got expanded to:
"/Users/tyson/Downloads/chrisbranson-RedLaserSample-1a5545f-1/RedLaserSample/Lib/RedLaser.dll" -debug -nolink -sdk "5.1" -targetver "5.1" --armv7 "-cxx" "-gcc_flags=\"-framework" "SystemConfiguration" "-framework" "CFNetwork" "-framework" "CoreVideo" "-framework" "CoreMedia" "-framework" "AVFoundation" "-framework" "OpenGLES" "-framework" "Security" "-L/Users/tyson/Downloads/chrisbranson-RedLaserSample-1a5545f-1/RedLaserSample/Lib" "-lRedLaserSDK" "-ObjC\""
The solution involves adding explicit quotation marks around the whole 'gcc_flags' option, manually escaping the inner quotation marks. e.g:
"-cxx" "-gcc_flags=\"-framework SystemConfiguration -framework CFNetwork -framework CoreVideo -framework CoreMedia -framework AVFoundation -framework OpenGLES -framework Security -L${ProjectDir}/Lib -lRedLaserSDK -ObjC\""
This expands correctly into:
"/Users/tyson/Downloads/chrisbranson-RedLaserSample-1a5545f-1/RedLaserSample/Lib/RedLaser.dll" -debug -nolink -sdk "5.1" -targetver "5.1" --armv7 "-cxx" "-gcc_flags=\"-framework SystemConfiguration -framework CFNetwork -framework CoreVideo -framework CoreMedia -framework AVFoundation -framework OpenGLES -framework Security -L/Users/tyson/Downloads/chrisbranson-RedLaserSample-1a5545f-1/RedLaserSample/Lib -lRedLaserSDK -ObjC\""
Ok, so now that I had it compiling I attempted to run it on my phone. The app loads up fine, and successfully calls into the RedLaser SDK via the RedLaserSDK.CheckReadyStatus() function. But as soon as I hit the scan button (which loads the BarcodePickerController) it crashes with a native exception deep within the RedLaser SDK:
terminate called throwing an exception
Native stacktrace:
0 RedLaserSample 0x0159d62d mono_handle_native_sigsegv + 244
1 RedLaserSample 0x015b6251 sigabrt_signal_handler + 112
2 libsystem_c.dylib 0x319b67ed _sigtramp + 48
3 libsystem_c.dylib 0x319ac20f pthread_kill + 54
4 libsystem_c.dylib 0x319a529f abort + 94
5 libc++abi.dylib 0x34fb1f6b abort_message + 46
6 libc++abi.dylib 0x34faf34d _ZL17default_terminatev + 24
7 libobjc.A.dylib 0x358e536f _objc_terminate + 170
8 libc++abi.dylib 0x34faf3c5 _ZL19safe_handler_callerPFvvE + 76
9 libc++abi.dylib 0x34faf451 _ZdlPv + 0
10 libc++abi.dylib 0x34fb079f __cxa_throw + 122
11 RedLaserSample 0x000404a9 _ZN5zxing6qrcode19FinderPatternFinder18selectBestPatternsEv + 172
12 RedLaserSample 0x000415e9 _ZN5zxing6qrcode19FinderPatternFinder4findERKNS_11DecodeHintsE + 512
13 RedLaserSample 0x0003a7f7 _ZN5zxing6qrcode8Detector6detectERKNS_11DecodeHintsE + 366
14 RedLaserSample 0x00046b97 _ZN5zxing6qrcode12QRCodeReader6decodeENS_3RefINS_12BinaryBitmapEEENS_11DecodeHintsE + 130
15 RedLaserSample 0x0004ec35 _ZN5zxing6Reader6decodeENS_3RefINS_12BinaryBitmapEEE + 240
16 RedLaserSample 0x00058455 -[FormatReader decode:] + 116
17 RedLaserSample 0x00013835 -[ZXingDecoder findCodesInBitmap:bytesPerRow:width:height:] + 656
18 RedLaserSample 0x0005f6af -[BarcodePhotoEngine zxingFindBarcodesInPixmap:] + 222
19 RedLaserSample 0x00055f25 __38-[BarcodeEngine findBarcodesInPixMap:]_block_invoke_059 + 76
20 libdispatch.dylib 0x34635c59 _dispatch_call_block_and_release + 12
21 libdispatch.dylib 0x34637d0f _dispatch_queue_drain + 274
22 libdispatch.dylib 0x34637b75 _dispatch_queue_invoke$VARIANT$mp + 40
23 libdispatch.dylib 0x346387e7 _dispatch_worker_thread2 + 210
24 libsystem_c.dylib 0x31967dfb _pthread_wqthread + 294
25 libsystem_c.dylib 0x31967cd0 start_wqthread + 8
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Running the very similar RedLaser Xcode sample project (i.e. no MonoTouch involvement, all objective-c) works fine.
Also, if it is of any significance, disabling all barcode scan types allows the BarcodePickerController to load up and display the camera view. Obviously it never detects a barcode though.
The crash you mention has been fixed in the bindings now.
It was related to QR's usage of C++ exceptions and incorrect linking arguments.
According to the Makefile you pasted, this RedLaser binding uses the LinkWith[1] feature supported by MonoTouch to eliminate the need to use any "Additional mtouch arguments".
Just wipe out any arguments needed for RedLaser from your additional mtouch arguments configuration in your Project Options and things will likely build & work properly.
If not, try using the RedLaser binding from https://github.com/xamarin/monotouch-bindings which may be more up-to-date?
Notes:
http://blog.xamarin.com/2011/11/02/monotouch-native-libraries-made-easy/

Can somebody make sense of that crash in Monotouch 5.2.6 happening with SGen on?

Randomly I'm getting the crash below in the iOS5 Simulator with Monotouch 5.2.6 and SGen being enabled. This is a debug build.
It is happening after clicking a button. That click spins off a new thread that shows a little progress indicator. When it is done thinking, it will exchange two views with animation (running all this on the UI thread).
I would like to know where to start because I don't get a managed stack trace. Am I right that it is trying to layout a UITableViewCell that no longer exists?
Native stacktrace:
0 MobileApp 0x00094fbc mono_handle_native_sigsegv + 284
1 MobileApp 0x0000be72 mono_sigsegv_signal_handler + 178
2 libsystem_c.dylib 0x9c5ee59b _sigtramp + 43
3 ??? 0xffffffff 0x0 + 4294967295
4 QuartzCore 0x04176891 -[CALayer actionForKey:] + 89
5 QuartzCore 0x0417982d _ZL12actionForKeyP7CALayerPN2CA11TransactionEP8NSString + 82
6 QuartzCore 0x0417c9c3 _ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 131
7 QuartzCore 0x04181f82 _ZN2CA5Layer12set_positionERKNS_4Vec2IdEEb + 388
8 QuartzCore 0x04178205 -[CALayer setPosition:] + 68
9 QuartzCore 0x04177cba -[CALayer setFrame:] + 675
10 UIKit 0x021d8590 -[UIView(Geometry) setFrame:] + 198
11 UIKit 0x022e1731 -[UILabel setFrame:] + 233
12 UIKit 0x02439731 -[UITableViewCellLayoutManager layoutSubviewsOfCell:] + 4511
13 UIKit 0x02390e34 -[UITableViewCell layoutSubviews] + 2650
14 UIKit 0x021e3322 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 178
15 CoreFoundation 0x011d6e72 -[NSObject performSelector:withObject:] + 66
16 QuartzCore 0x0417392d -[CALayer layoutSublayers] + 266
17 QuartzCore 0x0417d827 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 231
18 QuartzCore 0x04103fa7 _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 377
19 QuartzCore 0x04105ea6 _ZN2CA11Transaction6commitEv + 374
20 QuartzCore 0x041059d3 _ZN2CA11Transaction14release_threadEPv + 65
21 libsystem_c.dylib 0x9c5dfe0c _pthread_tsd_cleanup + 85
22 libsystem_c.dylib 0x9c59864c _pthread_exit + 146
23 libsystem_c.dylib 0x9c5989a0 pthread_exit + 33
24 MobileApp 0x0020434e thread_exit + 30
25 MobileApp 0x00203d03 thread_start_routine + 163
26 MobileApp 0x001aeb20 gc_start_thread + 80
27 libsystem_c.dylib 0x9c596ed9 _pthread_start + 335
28 libsystem_c.dylib 0x9c59a6de thread_start + 34
Native code is trying to access something that has been freed.
This is the key line:
4 QuartzCore 0x04176891 -[CALayer actionForKey:] + 89
you need to figure out what [CALayer actionForKey:] is trying to do (and on which object) - have in mind that this can be a number of things (calling a delegate / event, calling a virtual method, fetching a property). It's however difficult to be specific without seeing your actual code.

Categories

Resources