Hello, Can you test Monobjc 4.0.436 + Mono 2.6 RC together ?
Regards, Laurent Etiemble. 2009/12/13 Duane Wandless <du...@wandless.net>: > 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. >> >> >> >> >> > >
