[mono-android] 4.2.2 Samsung Galaxy SII Turns off at runtime
I've been developing for my Motorola XOOM and my Samsung. Have for the past week just been debugging on the XOOM. Note that my application runs perfectly fine on it without crashes/freezes. However on my Samsung, the device freezes for a random amount of time for like 1 second, then actually dies. Only output i get from debugger is The program 'Mono' has exited with code 255 (0xff). I believe it's coming from this code snippet. My application is a image gallery in which i fetch byte arrays from a service. // Code BitmapFactory.Options op = new BitmapFactory.Options(); //Checks the size of the fetched byte[]. op.InJustDecodeBounds = true; op.InPurgeable = true; op.InInputShareable = true; bitmap = BitmapFactory.DecodeByteArray(byteArray, 0, byteArray.Length, op); op.InJustDecodeBounds = false; //If the Bitmap is to big resample it with a different sampleSize if (op.OutWidth > 500) op.InSampleSize = sampleSize; double divider = (double)op.OutWidth / (double)imageWidth; int imageHeight = (int)((double)op.OutHeight / divider); //Decode the byte[] to the Bitmap bitmap = Bitmap.CreateScaledBitmap(BitmapFactory.DecodeByteArray(byteArray, 0, byteArray.Length, op), imageWidth, imageHeight, true); //If both threads for this id have returned continue. if (++threadPublicationIds[myId] != valueToReach) return; // Code This piece of code is used pretty much. I found it weird that it works without problems on my XOOM when obviously something is very wrong with the SG SII. Any others with the same problem when using BitmapFactory? -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/4-2-2-Samsung-Galaxy-SII-Turns-off-at-runtime-tp5710290.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
Re: [mono-android] Error in GL.GetInteger(All.BlendSrc, out m_PrevBlendSrc);
Hi Sri, If you refer to this page http://www.khronos.org/opengles/documentation/opengles1_0/html/glGetInteger.html, you will see the list of enums that are valid for GL.GetInteger under ES 1.0. All.BlendSrc is not listed there. Worth noting (though you may know this already) is that most hardware today that supports both ES 1.1 and ES 2.0, handles the programmable pipeline( ES 2.0) natively and that ES 1.0 and ES 1.1 calls are converted to ES 2.0 under the hood, before being executed. I hope this helps. Dominique. On 2012-06-11 03:58, SRI wrote: 4. Re: Error in GL.GetInteger(All.BlendSrc, out m_PrevBlendSrc); Hi, I am running in Mono for Android OpenTK-1.0 using OPEN GL ES 1.0 where they use the All Enumeration and hence I am not able to compile your code. I am not sure why they combined all the Enumeration Values in various functions into one Giant All Enumeration. Anyway, Thanks for your help. ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] 4.2.2 Samsung Galaxy SII Turns off at runtime
I would start to insert bitmap.Recycle() statements to exclude memory issues. On Tue, Jun 12, 2012 at 1:19 PM, SweetLou wrote: > I've been developing for my Motorola XOOM and my Samsung. Have for the past > week just been debugging on the XOOM. Note that my application runs > perfectly fine on it without crashes/freezes. However on my Samsung, the > device freezes for a random amount of time for like 1 second, then actually > dies. Only output i get from debugger is The program 'Mono' has exited with > code 255 (0xff). > > I believe it's coming from this code snippet. My application is a image > gallery in which i fetch byte arrays from a service. > > // Code > > BitmapFactory.Options op = new BitmapFactory.Options(); > > //Checks the size of the fetched byte[]. > op.InJustDecodeBounds = true; > op.InPurgeable = true; > op.InInputShareable = true; > bitmap = BitmapFactory.DecodeByteArray(byteArray, 0, byteArray.Length, op); > op.InJustDecodeBounds = false; > > //If the Bitmap is to big resample it with a different sampleSize > if (op.OutWidth > 500) > op.InSampleSize = sampleSize; > > > double divider = (double)op.OutWidth / (double)imageWidth; > int imageHeight = (int)((double)op.OutHeight / divider); > > //Decode the byte[] to the Bitmap > bitmap = Bitmap.CreateScaledBitmap(BitmapFactory.DecodeByteArray(byteArray, > 0, byteArray.Length, op), imageWidth, imageHeight, true); > > //If both threads for this id have returned continue. > if (++threadPublicationIds[myId] != valueToReach) > return; > > // Code > > This piece of code is used pretty much. I found it weird that it works > without problems on my XOOM when obviously something is very wrong with the > SG SII. > > Any others with the same problem when using BitmapFactory? > > -- > View this message in context: > http://mono-for-android.1047100.n5.nabble.com/4-2-2-Samsung-Galaxy-SII-Turns-off-at-runtime-tp5710290.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 > ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] Renaming EventHandlers and Properties in JavaBindling projects (Rules and recommendations)
Done #5614 (sorry for the delay) >Perhaps; is there any other output? Could you please file a bug and attach > the project (with javadocs) at >bugzilla.xamarin.com? > > Thanks, > - Jon > > ___ > Monodroid mailing list > Monodroid@lists.ximian.com > > UNSUBSCRIBE INFORMATION: > http://lists.ximian.com/mailman/listinfo/monodroid > ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] 4.2.2 Samsung Galaxy SII Turns off at runtime
Tried with the same result :( Was checking for available memory before so it doesn't exceed it. Now i also tried application on Sony Xperia, worked like a charm.. -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/4-2-2-Samsung-Galaxy-SII-Turns-off-at-runtime-tp5710290p5710294.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
Re: [mono-android] 4.2.2 Samsung Galaxy SII Turns off at runtime
In your comment you have a strong indication that your multithreading, i would focus in that area. In the past i had random crashes like, turned out the code was reading the same file accross threads. I initially suspected some sort of memory leak. On Tue, Jun 12, 2012 at 2:36 PM, SweetLou wrote: > Tried with the same result :( Was checking for available memory before so > it > doesn't exceed it. Now i also tried application on Sony Xperia, worked like > a charm.. > > -- > View this message in context: > http://mono-for-android.1047100.n5.nabble.com/4-2-2-Samsung-Galaxy-SII-Turns-off-at-runtime-tp5710290p5710294.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 > ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] 4.2.2 Samsung Galaxy SII Turns off at runtime
Yes multithreading is used, however it's really hard to find some error since it works great on other devices with same specifikations. I'll keep looking.. -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/4-2-2-Samsung-Galaxy-SII-Turns-off-at-runtime-tp5710290p5710296.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
Re: [mono-android] 4.2.2 Samsung Galaxy SII Turns off at runtime
Try/catch, try/catch and even more try/catch or step through your application with the debugger until you hit the error so you can narrow it down. A bit cumbersome, but hopefully it will help in the long end. On Tue, Jun 12, 2012 at 3:05 PM, SweetLou wrote: > Yes multithreading is used, however it's really hard to find some error since > it works great on other devices with same specifikations. I'll keep > looking.. > > -- > View this message in context: > http://mono-for-android.1047100.n5.nabble.com/4-2-2-Samsung-Galaxy-SII-Turns-off-at-runtime-tp5710290p5710296.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 -- Med Venlig Hilsen / With Best Regards Tomasz Cielecki http://ostebaronen.dk ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] debugger constantly detaches
That was using 4.2.3 :-/
I rolled back to 4.1 which appeared to fixed the breakpoint issue (maybe it
hadn't installed correctly?). I'm not quite brave enough to try 4.2.3 again
just yet.
It's still disconnecting however.
I've done a test with a new android project:
public void RecursiveStupidity()
{
RecursiveStupidity();
}
protected override void OnCreate(Bundle bundle)
{
base.OnCreate(bundle);
// Set our view from the "main" layout resource
SetContentView(Resource.Layout.Main);
// Get our button from the layout resource,
// and attach an event to it
Button button =
FindViewById(Resource.Id.MyButton);
button.Click += delegate { RecursiveStupidity();
button.Text =
string.Format("{0} clicks!", count++); };
}
and the log (including clicking on the button) produces:
06-12 14:32:33.720 D/dalvikvm(23637): Late-enabling CheckJNI
06-12 14:32:33.785 I/dalvikvm(23637): Turning on JNI app bug workarounds for
target SDK version 8...
06-12 14:32:33.850 I/ActivityThread(23637): Pub
AndroidApplication1.AndroidApplication1.__mono_init__:
mono.MonoRuntimeProvider
06-12 14:32:33.855 D/dalvikvm(23637): Trying to load lib
/data/data/AndroidApplication1.AndroidApplication1/lib/libmonodroid.so
0x40d84438
06-12 14:32:33.855 D/dalvikvm(23637): Added shared lib
/data/data/AndroidApplication1.AndroidApplication1/lib/libmonodroid.so
0x40d84438
06-12 14:32:33.860 W/MonoDroid-Debugger(23637): Trying to initialize the
debugger with options:
--debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8867,server=y,embedding=1
06-12 14:32:33.940 W/MonoDroid-Debugger(23637): Accepted stdout connection:
44
06-12 14:32:34.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:34.330 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:34.720 E/mono(23637): WARNING: The runtime version supported
by this application is unavailable.
06-12 14:32:34.720 E/mono(23637): Using default runtime: v2.0.50727
06-12 14:32:34.800 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:34.805 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:35.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:35.300 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:35.795 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:35.800 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:36.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:36.305 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:36.795 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:36.800 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:37.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:37.310 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:37.795 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:37.815 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:38.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:38.320 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:38.795 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:38.800 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:39.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:39.305 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:39.795 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:39.815 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:40.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:40.305 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:40.795 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:40.820 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:41.295 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:41.310 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
06-12 14:32:41.695 I/monodroid-gc(23637): environment supports jni
NewWeakGlobalRef
06-12 14:32:41.695 W/monodroid-gc(23637): GREF GC Threshold: 46800
Loaded assembly:
/data/data/AndroidApplication1.AndroidApplication1/files/.__override__/AndroidApplication1.dll
Loaded assembly: Mono.Android.dll [External]
Loaded assembly: System.Core.dll [External]
06-12 14:32:41.795 I/dalvikvm(23637): threadid=3: reacting to signal 3
06-12 14:32:41.800 I/dalvikvm(23637): Wrote stack traces to
'/data/anr/traces.txt'
Loaded assembly: MonoDroidConstructors [External]
06-12 14:32:42.300 I/dalvikvm(23637): thr
Re: [mono-android] debugger constantly detaches
Just to clarify - My app could be throwing any old exception and it isn't trapped. Not that I think my app is throwing a stack overflow exception in particular. -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/debugger-constantly-detaches-tp5710262p5710299.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
Re: [mono-android] 4.2.2 Samsung Galaxy SII Turns off at runtime
On Jun 12, 2012, at 7:19 AM, SweetLou wrote: > I've been developing for my Motorola XOOM and my Samsung. Have for the past > week just been debugging on the XOOM. Note that my application runs perfectly > fine on it without crashes/freezes. However on my Samsung, the device freezes > for a random amount of time for like 1 second, then actually > dies. Only output i get from debugger is The program 'Mono' has exited with > code 255 (0xff). Two things: 1. What is the output of the following command on each of your devices? adb shell getprop dalvik.vm.heapsize I'll bet that they're not the same, and that the Xoom has a larger value than your Samsung. 2. View the Android Debug Log output: http://docs.xamarin.com/android/advanced_topics/android_debug_log I suspect that the Android Debug Log will contain GC_EXTERNAL_ALLOC messages, stating that it's run out of heap space, e.g. http://lists.ximian.com/pipermail/monodroid/2012-April/009717.html If this is correct, the solution is to reduce lifetime of the managed wrapper (if possible; it should be here) by calling Dispose(): http://docs.xamarin.com/android/advanced_topics/garbage_collection > I believe it's coming from this code snippet. My application is a image > gallery in which i fetch byte arrays from a service. > > // Code ... > //Decode the byte[] to the Bitmap > bitmap = Bitmap.CreateScaledBitmap(BitmapFactory.DecodeByteArray(byteArray, > 0, byteArray.Length, op), imageWidth, imageHeight, true); What is the lifetime of the `bitmap` instance, and does it need to live that long? Rephrased, what are you doing with it, and do you need to maintain a C# reference to it? If you're doing something akin to: bitmap = GetBitmap (); canvas.SetBitmap (bitmap); // never use bitmap again... then you should Dispose() of the bitmap ASAP: using (bitmap = GetBitmap ()) canvas.SetBitmap (bitmap); Disposing of the instance will allow Dalvik to collect the bitmap instance faster, and as Bitmap instances can be very large, allowing Dalvik to collect the Java-side data will reduce your memory footprint (and hopefully keep your app from crashing). - Jon ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
[mono-android] Intel Emulator with maps?
I love the Intel Emulator - makes the code actually run :) However, I don't seem to be able to get an Intel x86 emulator image with Google maps also installed. Does anyone know how to achieve this? Thanks Stuart ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] Intel Emulator with maps?
On Jun 12, 2012, at 10:22 AM, Stuart Lodge wrote: > However, I don't seem to be able to get an Intel x86 emulator image with > Google maps also installed. > > Does anyone know how to achieve this? You don't, as far as I can tell. If you open the AVD manager, create a New device, and select a Target of Google APIs (Google Inc.) - API Level 15, the CPU/ABI drop-down is ARM (armeabi-v7a) and cannot be changed to Intel Atom (x86). This suggests that x86 isn't a valid Google APIs target at this time. Thanks, - Jon ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] debugger constantly detaches
On Jun 12, 2012, at 9:51 AM, l0nestar wrote: > Just to clarify - My app could be throwing any old exception and it isn't > trapped. Not that I think my app is throwing a stack overflow exception in > particular. Mono has historically had issues with StackOverflowExceptions, so I wouldn't be surprised if they weren't properly handled. If other exceptions aren't trapped in the debugger, that would be a problem. If that's the case, please file a bug at bugzilla.xamarin.com. Thanks, - Jon ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] debugger constantly detaches
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
[mono-android] 4.2.3 - problem renaming axml file
Trying to rename an axml file in VS2010 Error message is about the file being locked - I think it is locked by Java Platform SE - is this something to do with the designer? Do you want me to log this on bugzilla? Stuart ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
[mono-android] MonoDroid App Developer/Consultant
Hello, We have just recently published our first MonoTouch application into the AppStore. We are now looking to for a person/person(s) to take our existing MonoTouch application and convert it to MonoDroid. We have separated the code in such a way that much of the code exists in its own libraries for re-use, and the task at hand will be focus a lot on the UI for Android and incorporation of the existing code and new code as required for Android. The existing application supports both iPhone and iPad, and our need is to have both available on Android as well. Interested parties please email at developer (@) proxy (dot) com, with a little about your knowledge and experience with MonoTouch and MonoDroid, and we will also be able to send you back some screencasts to give you an idea of the existing application. Work will be done remotely and maintained in github, and should be able to start very soon if not immediately. Look forward to hearing back from folks. Shawn http://www.proxy.com ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] The GenerateJavaStubs task failed unexpectedly.
On Jun 11, 2012, at 4:46 AM, Terry151151 wrote: > My problem was that the Javascript interface was is in a library, and so was > the reference to Mono.Android.Export. This has been filed as: https://bugzilla.xamarin.com/show_bug.cgi?id=5618 > I also have another question related to the Javascript interface. Can the > interface return values back to the Javascript? Yes, but you can only use builtin types and Java.Lang.String as parameter & return types. The JavaScript/Java binding doesn't appear to support any other types, from what I've seen. - Jon ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
Re: [mono-android] [SOLVED]Re: Smashing Planets is on the Google Play Store but...
On Jun 8, 2012, at 5:00 AM, johnHolmes wrote: > Guys, it is confirmed, when you upload an .apk to the Google Play store and > enabling "*Copy Protection*", the size of the .apk will double. > > http://stackoverflow.com/questions/7318810/growing-apk-file-size Are you sure this is the right URL? The above URL is about creating a .apk from within Eclipse, which isn't the case with Mono for Android... Do you know what was causing the .apk to be bigger? Presumably there was something within the .apk which caused it to be larger; a comparison between the contents of the original 13MB .apk and the "bloated" 26MB .apk might be interesting. Perhaps we're doing something wrong with the .apk contents which is causing stuff to be duplicated? Thanks, - Jon ___ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
