Rolf, thanks for the quick response. After your email, I started done the path of trying to find out who was calling the method that you highlighted below. I quickly realized that it was in startup code because the FinishLaunching routine was the first time any of my program's code gets run (other than the UIApplication.Main(args, null, "AppDelegate") line in Main.cs that kicks off the app), and creating the Initialize thread and calling Thread.Start() on it was the first thing that my code did.
I have done more investigation and the culprit is the "--armv7" command line arg to the mtouch command. We had some C++ libraries that were built in Xcode with the Optimized(armv7) Architecture. To have these included during the mtouch linking, the --armv7 command line argument needs to be present. If you take a HelloWorld type program and put the "--armv7" command line arg into the project's Options->iPhone Build->Additional mtouch arguments field, you will get at least two problems when running the application in the debugger: 1. If you create a System.Threading.Thread object and call Thread.Start() on it, the app will crash. 2. If you set a breakpoint on any C# line of code, it will also crash the app. The crashes are very similar. Now that I think of it, my colleague was complaining of other bizarre problems that he couldn't explain; I wonder if they are related to this? I can send my HelloWorld solution if you like; just let me know. We have switched to using all armv6 and these problems have gone away; not a permanent solution but it will do for now. Regards, Conway -----Original Message----- From: Rolf Bjarne Kvinge [mailto:[email protected]] Sent: September 16, 2011 4:22 PM To: Conway Wieler Subject: Re: [MonoTouch] debugger issues Hi Conway, I don't think it's the size, since I've seen applications almost 10x that size. The crash looks very much like a managed object has been collected by the GC, but that doesn't match with what you say about the thread start. Do all crashes have the same stack trace? Maybe you can attach the entire crash report file, there might be more information there. In any case I think the best way to continue is trying to find out what managed code this objective c code tries to execute: 6 UIKit 0x30a1781a -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 766 and make sure that you keep a reference to whatever managed object or delegate is being called. Rolf On Fri, Sep 16, 2011 at 9:04 PM, Conway Wieler <[email protected]> wrote: > Hello, > > Our app runs properly when run directly on an iPod Touch, but it crashes > when I run it in the MonoDevelop debugger. I've tracked it down to starting > a thread by calling System.Threading.Thread.Start(). The new thread just has > a Debug.WriteLine() in it. With the Thread.Start() call active, the app > crashes in the debugger; with the Thread.Start() commented out, the app runs > in the debugger. Specifically, in the AppDelegate::FinishedLaunching() > routine, I am creating a thread and calling Start() on it: > > > > public override bool FinishedLaunching(UIApplication app, NSDictionary > options) > > { > > initThread = new System.Threading.Thread(Initialize); > > initThread.IsBackground = true; > > initThread.Start(); > > } > > private void Initialize() > > { > > Debug.WriteLine("testing"); > > } > > > > If instead I use BeginInvokeOnMainThread(Initialize), the Initialize routine > (the real version, not just the Debug.WriteLine() version) will run but then > a subsequent thread create and Start() causes the same crash. > > > > The crash report (from Xcode-Organizer, below) says that the exception type > is EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE. I also get a nearly identical > crash if I set a breakpoint on any line of C# code in the case where the > code does run. > > > > Other possibly relevant information: > > 1. MonoDevelop v2.6.0.1, Mono v2.10.5, MonoTouch v4.0.7 > > 2. I've written a HelloWorld app that similarly creates a Thread and calls > Thread.Start() on it. It runs as expected and I see the Debug.WriteLine > output. I can also set Breakpoints and step through code. I doubt the issue > is with the actual thread or threading mechanism; it just seems like a > trigger or we're reaching some threshold (perhaps memory?). > > 3. Our app is large. The core part of our app is a large C++ DLL, and we use > C# for the UI and non-core support functionality. Right now the amount of C# > code is small but growing as we continue to port our existing Windows/WinCE > app. Are there issues with having a large application? Right now, the app is > 29.5MB for Debug and about 14MB for Release. > > > > Has anyone seen similar behaviour? Does anyone have ideas or things to try? > > Thanks, > > Conway > > > > > > Crash Log: > > --------------------------------------------------------------- > > Exception Type: EXC_BAD_ACCESS (SIGSYS) > > Exception Codes: KERN_PROTECTION_FAILURE at 0x01cfc000 > > Crashed Thread: 0 > > > > Thread 0 name: Dispatch queue: com.apple.main-thread > > Thread 0 Crashed: > > 0 Main 0x00dd0a5c process_single_step > (debugger-agent.c:3993) > > 1 ??? 0x01cfbff8 0 + 30392312 > > 2 Main 0x008ed92c > wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr > + 192 > > 3 Main 0x00da9412 mono_jit_runtime_invoke > (mini.c:5754) > > 4 Main 0x00e53d5a mono_runtime_invoke > (object.c:2756) > > 5 Main 0x00ebfcac monotouch_trampoline > (monotouch-glue.m:652) > > 6 UIKit 0x30a1781a -[UIApplication > _callInitializationDelegatesForURL:payload:suspended:] + 766 > > 7 UIKit 0x30a11b5e -[UIApplication > _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 266 > > 8 UIKit 0x309e67d0 -[UIApplication > handleEvent:withNewEvent:] + 1108 > > 9 UIKit 0x309e620e -[UIApplication sendEvent:] > + 38 > > 10 UIKit 0x309e5c4c _UIApplicationHandleEvent + > 5084 > > 11 GraphicsServices 0x30269e70 PurpleEventCallback + 660 > > 12 CoreFoundation 0x30957a90 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 20 > > 13 CoreFoundation 0x30959838 __CFRunLoopDoSource1 + 160 > > 14 CoreFoundation 0x3095a606 __CFRunLoopRun + 514 > > 15 CoreFoundation 0x308eaebc CFRunLoopRunSpecific + 224 > > 16 CoreFoundation 0x308eadc4 CFRunLoopRunInMode + 52 > > 17 UIKit 0x30a10d42 -[UIApplication _run] + 366 > > 18 UIKit 0x30a0e800 UIApplicationMain + 664 > > 19 Main 0x0063da8c > wrapper_managed_to_native_MonoTouch_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr > + 232 > > 20 Main 0x0068a4c4 methods + 75556 > > 21 Main 0x008ed92c > wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr > + 192 > > 22 Main 0x00da9412 mono_jit_runtime_invoke > (mini.c:5754) > > 23 Main 0x00e53d5a mono_runtime_invoke > (object.c:2756) > > 24 Main 0x00e55be4 mono_runtime_exec_main > (object.c:3939) > > 25 Main 0x00e55214 mono_runtime_run_main > (object.c:3561) > > 26 Main 0x00db0bac mono_jit_exec > (driver.c:1102) > > 27 Main 0x00da2f9e main (main.m:2110) > > 28 Main 0x005caba0 start + 32 > > > > > > > > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch > > _______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
