Hi Conway, Thanks for tracking it down, I've been able to reproduce it and I've created a bug report for it: http://bugzilla.xamarin.com/show_bug.cgi?id=952, you can CC yourself on that bug to get updates when it's fixed.
Rolf On Tue, Sep 20, 2011 at 3:55 PM, Conway Wieler <[email protected]> wrote: > 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
