An update on the Mono 2.6 RC. As expected the thread_get_state crash still exists with Monobjc 2.0.413.0. I have not tried with 2.0.436.0.
I do have the MD soft debugger working with my embedded monobjc app. It is not perfect as sometimes the app freezes but this could be a cause of the thread issue. I will try later today (but more likely tomorrow) to provide the MD addins that enable debugging embedded applications. Being able to run a test case for the thread issue in the debugger might prove useful to resolving it. Duane On Fri, Dec 11, 2009 at 6:45 AM, marc hoffman <m...@elitedev.com> wrote: > Laurent, > > > I understand your point and also think that providing a custom runtime > > can be awkward. I am still working hard to have a clean an acceptable > > solution to the problem. > > > > The Monobjc 4.0.436 (dylib inside) has solved some crash problems but > > not all. That makes me say that there are other cases when the bridge > > is crossed outside the thread management scope of Mono: > > - the first solution is to identify all theses possible paths (that > > lead to crash) and forbid them. > > - the second solution is to provide a patched Mono runtime that do a > > proper thread management. > > > > I need to provide both a short-term and a long-term solution to > > Monobjc's users. So I am open to any suggestions on how to do it well. > > me, im perfectly happy with the dylib solution, if that can fix all the > issues. if later on official Mono distros will get fixes that make the dylib > obsolete - great. but until then. i'd prefer needing the dylib to needing a > custom Mono runtime, a thousand-fold. > > the dylib is pretty much a non-issue. Apps get .app-bundled anyways, so > copying two more files is a no-brainer (especially if MacPac does it for > you). needing a custom runtime to test and debug Monobjc aps is a real > showstopper for us telling our customers to use Monobjc (and mkbundle - all > comments for or against it, aside - only helps with final deployment. the > developer (our customer ;) still needs the custom runtime, which will get > confusing and problematic, once newer Mono's come out (as the one that just > did, which is a critically important update that users wot wanna skip). > > so my vote is on keeping the dylib, until such time that we can make do > entirely without it, on a new vanilla Mono. > > hth, > marc > > > 2009/12/6 marc hoffman <m...@elitedev.com>: > >> Am i the only one who thinks this custom runtime thing is not really > acceptable for anyone who wants to - oh, say - *deploy* applications to > regular users who can't/won't just patch their Mono install? what's the > short-term plan for enabling people to actually ship apps based on Monobjc, > and why can't we stick to the unmanaged dylib that can easily be deployed > alongside the app, at least until an official Mono is out that contains > these patches (if that will ever happen)? > >> > >> just thinking out loud, here. > >> > >> On Dec 2, 2009, at 12:15 AM, Laurent Etiemble wrote: > >> > >>> Hello, > >>> > >>> Sorry for the late update, but I had some busy nights trying to find > >>> another work-around for the Snow Leopard crash. The 4.0.436 release of > >>> the Monobjc bridge has brought mixed results regarding the Snow > >>> Leopard crash: some users have reported success while others have > >>> reported nasty crashes. > >>> > >>> So, I have resumed my work on the Mono runtime patching to find an > >>> acceptable way to do it (not too hacky so Novell would accept it). > >>> During my tests, I have discover that the conditions of the bug are > >>> already present under Leopard. Why it does not crash seems linked to > >>> the way TSD (Thread Specfic Data) are destroyed. So I have changed my > >>> approach and I have come to a workaround that seems to prevent the > >>> crash. > >>> > >>> The archive of the patched Mono runtime is available at: > >>> > http://build.monobjc.net/releases/2.4.2.3_M/MonoFramework-2.4.2.3_M-universal.tar.bz2 > >>> > >>> In order to use the archive: > >>> - you need to have a working installation of Mono. > >>> - uncompress the archive in /Library/Frameworks/Mono.framework/Versions > >>> - relink the Current symlink to the archive (sudo rm Current && sudo > >>> ln -s 2.4.2.3_M Current) > >>> > >>> Some points about this runtime: > >>> - The runtime is universal. I have made some tests under some > >>> OS/Processor combinations, but I cannot cover all hardware. > >>> - The runtime contains Mono, Visual Basic and NAnt. It does not > >>> contains libgdiplus or any of the third-party packages. > >>> - The runtime contains all what is needed to run mkbundle or the > >>> packaging tasks. > >>> - The runtime also contains other patches: embedded "machine.config" > >>> and "app.config" are now usable. > >>> > >>> If you decide to test this runtime, please provide the following: > >>> - hardware/system full version > >>> - kind of application/complexity > >>> - anything that can help in case of crash > >>> > >>> Regards, Laurent Etiemble. > >> > >> > >
