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
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.
On Fri, Dec 11, 2009 at 6:45 AM, marc hoffman <m...@elitedev.com> wrote:
> > 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.
> > 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:
> >>> 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 220.127.116.11_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.