The OutOfMemoryException can sometimes be predicted in advance with
special code that uses the MemoryFailPoint class in the .NET Framework.
http://msdn.microsoft.com/en-us/library/system.runtime.memoryfailpoint.aspx
You may also want to look at lazy initialization to help some of that
memory issue
though you found your problem, this might be helpful in the future.
if you get this email twice, it's because jon is not letting my emails
through so I will be emailing directly then. I proved him wrong and he is
now sulking or some shit.
On Tue, Jun 12, 2012 at 10:33 AM, l0nestar <allan.bent...@thumbstar.com>wrote:
> I think I may of found the cause,
>
> In my inner render loop I had:
>
> float[] m = new float[]
> {
> tm.M11, tm.M12, tm.M13, tm.M14,
> tm.M21, tm.M22, tm.M23, tm.M24,
> tm.M31, tm.M32, tm.M33, tm.M34,
> tm.M41, tm.M42, tm.M43, tm.M44,
> };
> GLES11.GlLoadMatrixf(m, 0);
>
> I now allocate m once and reuse it and the debugger stays connected. w00t!
>
> Of course allocating a new float[16] for every single draw is very poor,
> but
> the question is why do I not get an out of memory error or equivalent
> though?
>
> (incidentally this probably explains why enabling tracing didn't reveal any
> clues as the frequency of the allocations dropped accordingly)
>
> --
> View this message in context:
> http://mono-for-android.1047100.n5.nabble.com/debugger-constantly-detaches-tp5710262p5710304.html
> Sent from the Mono for Android mailing list archive at Nabble.com.
> _______________________________________________
> Monodroid mailing list
> Monodroid@lists.ximian.com
>
> UNSUBSCRIBE INFORMATION:
> http://lists.ximian.com/mailman/listinfo/monodroid
>
--
Extreme Knowledge is not something for which he programs a computer but for
which his computer is programming him.
-Wozniak
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
