Consumer closed input channel or an error occurred. events=0x8 - android

01-03 11:28:47.499: ERROR/InputDispatcher(164): channel '4085fe50 com.bce.tip/com.bce.tip.core.MenuActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x8
01-03 11:28:47.499: ERROR/InputDispatcher(164): channel '4085fe50 com.bce.tip/com.bce.tip.core.MenuActivity (server)' ~ Channel is unrecoverably broken and will be disposed!`
When I click on Imageview action calling but I am calling this onclick to another layer class

It was happening with me at some minutes ago and I found the reason!
This was the code that was causing it:
Canvas pattern = new Canvas();
Bitmap bitmapPattern = Bitmap.createBitmap(pattern.getWidth(),canvas.getHeight(),Bitmap.Config.ARGB_8888);
pattern.setBitmap(bitmapPattern);
pattern.drawLine(0, 0, 1, 1, paintStroke);
paintFill.setShader(new BitmapShader(bitmapPattern, TileMode.REPEAT, TileMode.REPEAT));
and the reason is: "pattern.getWidth(),canvas.getHeight()", those parameters may be infinite, I didn't define nothing on canvas yet! CHanging it to numbers I get free from that error!

Resolved :
1) Basically this Errors occurs couple of times
if your running number of process at a time in single thread .
This is like a Deadlock situation.So any Scheduled tasks are there make it Synchronized particular burden objects.
2) Kill the unused processes at the time of Burden happens on MainThread.

Related

Unable to debug JNI code doing simple jarray manipulations

Note: I am using Android Studio, compiling the C code with the NDK outside of Android Studio.
The following C code:
jintArray Java_com_xxx_yyy_MainActivity_processFrame(
JNIEnv* env, jobject thiz, jbyteArray inArray)
{
int i;
jsize inLength = (*env)->GetArrayLength(env, inArray);
int outLength = inLength/3*2; // YYYYUV
jbyte in[outLength];
(*env)->GetByteArrayRegion(env, inArray, 0, outLength, in);
jint out[outLength];
jintArray outArray = (*env)->NewIntArray(env, outLength);
int alpha = 255 << 24;
for (i=0;i<outLength;i++) {
// just use the Y to set the B for now
out[i]=alpha | in[i];
}
// No release needed since using GetXXXRegion
//(*env)->ReleaseByteArrayElements(env, inArray, in, JNI_ABORT);
(*env)->SetIntArrayRegion(env, outArray, 0, outLength, out);
return outArray;
}
is called from Java as follows:
System.out.println("Calling processFrame");
int[] rgb = processFrame(imageData);
System.out.println("Call completed");
Yet, I do see "Calling processFrame" on my console but do not get "Call completed." Instead, I get
07-14 15:41:20.219 25810-25945/com.xxx.yyy A/libc﹕ Fatal signal 11 (SIGSEGV) at 0x5ef78000 (code=2), thread 25945 (CAMERA_THREAD)
07-14 15:41:20.219 25810-25814/com.xxx.yyy D/dalvikvm﹕ GC_CONCURRENT freed 1K, 6% free 8579K/9048K, paused 2ms+1ms, total 13ms
07-14 15:41:20.299 128-415/? W/CameraService﹕ Disconnecting camera client 0x427b09a8 since the binder for it died (this pid 128)
07-14 15:41:20.299 493-784/? I/WindowState﹕ WIN DEATH: Window{413fb7d0 u0 com.xxx.yyy/com.xxx.yyy.MainActivity}
07-14 15:41:20.299 493-493/? I/ActivityManager﹕ Process com.xxx.yyy (pid 25810) has died.
07-14 15:41:20.299 493-784/? W/WindowManager﹕ Force-removing child win Window{41685140 u0 SurfaceView} from container Window{413fb7d0 u0 com.xxx.yyy/com.xxx.yyy.MainActivity}
07-14 15:41:20.299 493-493/? W/ActivityManager﹕ Force removing ActivityRecord{41397308 u0 com.xxx.yyy/.MainActivity}: app died, no saved state
07-14 15:41:20.309 493-493/? D/WindowManager﹕ adjustConfigurationLw, config:{1.0 ?mcc?mnc ?locale ?layoutDir sw800dp w1280dp h752dp 240dpi xlrg land ?uimode ?night finger -keyb/v/h -nav/v} mLidState:-1 mHasDockFeature:true mHasKeyboardFeature:true mHasHallSensorFeature:true config.hardKeyboardHidden:2
07-14 15:41:20.309 493-493/? W/NvCpuClient﹕ Failed to bind to service
Is there something inherently wrong with the way my C code is written and called from Java that could explain this error?
How do I debug errors occurring in the C code from Android Studio?
Note: Replacing the C function body with just:
return (*env)->NewIntArray(env, 1000);
allows the call to be made to C and to return, so the binding itself works, suggesting that the error "Failed to bind to service" is simply there because the process died and cannot be invoked again from Java a second time around (I am calling this processFrame in a loop).
UPDATE: Occasionally but not always, I do also get
Consumer closed input channel or an error occurred. events=0x9
as part of the error message. I really do not see why but that does seem related to my problem somehow. I shouldn't have to release outArray from the C code. Should I?
UPDATE 2: I isolated the issue: the error is caused by a memory allocation. The code executes properly for outLength=320*480 (or anything smaller than that), but when I got to SD (640*480), I get the error I described. Is any of my memory allocation incorrect in the C code I provided? Is there a more appropriate way of allocating a larger chunk of memory from the C code? Should malloc be used instead for out? Do I need to increase heap memory and if so, how?
The error is caused by
jint out[outLength];
This does not work for too large an array. Using malloc solved my problem. If there are other issues in my code, please let me know. Otherwise I will accept the answer and move on.

Ouya - dimensions too large

I'm testing my video player on an OUYA device and it crashes almost immediately with the "dimension too large" error (see logcat dump below). If anyone knows of a work-around or a way to set a maximum dimension, I'll be grateful.
D/MySurface(2651): surfaceCreated
W/InputDispatcher(319): Attempted to unregister already unregistered input channel '41daf688 tv.ouya.console.wallpaper.OozeService (server)'
I/WindowState(319): WIN DEATH: Window{41daf688 tv.ouya.console.wallpaper.OozeService paused=false}
I/WindowManager(319): WINDOW DIED Window{41daf688 tv.ouya.console.wallpaper.OozeService paused=false}
E/SurfaceFlinger(109): dimensions too large 2560 x 1472
E/SurfaceFlinger(109): createNormalSurfaceLocked() failed (Invalid argument)
W/WindowStateAnimator(319): OutOfResourcesException creating surface
I/WindowManager(319): Out of memory for surface! Looking for leaks...
W/WindowManager(319): No leaked surfaces; killing applicatons!
W/ActivityManager(319): Killing processes Free memory at adjustment 0
W/ActivityManager(319): Killing ProcessRecord{41d9cae8 2651:example.android.player/u0a37} (adj 0): Free memory
W/WindowManager(319): Looks like we have reclaimed some memory, clearing surface for retry.
W/WindowManager(319): Due to memory failure, waiting a bit for next layout
I've tried changing the resolutions via this post as well without any success: http://forums.ouya.tv/discussion/2170/setting-resolution-not-working
I found a work around for this using a Surface callback with a pre-set max for width and height:
#Override
public void surfaceCreated(SurfaceHolder holder) {
Rect rect = holder.getSurfaceFrame();
if (rect.width() > maxWidth || rect.height() > maxHeight) {
holder.setFixedSize(maxWidth, maxHeight);
}
}

Getting low memory warning but I don't appear to be leaking memory

My application is closing without any error messages and re-launching automatically after switching activities approximately 20 or 30 times. I'm testing this by tapping a button that relaunches the current activity with different data (and cycles back around to the beginning once the end of the data is reached). The activity is launched with the FLAG_ACTIVITY_CLEAR_TOP flag so there should only ever be one instance of the activity in memory at a time. If I set FLAG_ACTIVITY_NO_HISTORY the problem still occurs.
This appears in the logcat output when the app crashes:
06-28 19:32:10.472: I/ActivityManager(115): Process com.mypackage.myapp (pid 3718) has died.
06-28 19:32:10.476: I/WindowManager(115): WIN DEATH: Window{406d06e0 com.mypackage.myapp/com.mypackage.myapp.welcome.LoginActivity paused=false}
06-28 19:32:10.480: E/InputDispatcher(115): channel '406ade20 com.mypackage.myapp/com.mypackage.myapp.matchup.MatchUpActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x8
06-28 19:32:10.480: E/InputDispatcher(115): channel '406ade20 com.mypackage.myapp/com.mypackage.myapp.matchup.MatchUpActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
06-28 19:32:10.535: I/WindowManager(115): WIN DEATH: Window{406ade20 com.mypackage.myapp/com.mypackage.myapp.matchup.MatchUpActivity paused=false}
06-28 19:32:10.539: I/WindowManager(115): WIN DEATH: Window{407a8230 com.mypackage.myapp/com.mypackage.myapp.fightcard.FightCardActivity paused=false}
06-28 19:32:10.566: I/ActivityManager(115): Start proc com.mypackage.myapp for activity com.mypackage.myapp/.fightcard.FightCardActivity: pid=3915 uid=10053 gids={3003}
06-28 19:32:10.574: I/ActivityManager(115): Low Memory: No more background processes.
Normally this would tell me that the app is leaking memory, however if I perform this test while watching the DDMS perspective in Eclipse, I can see that the allocated memory is stable, and in fact the app will often crash even when the % used is sitting around 50% (which is where it sits most of the time). The heap size and allocated memory are not increasing.
I have extensively used MAT on the app and while I did find memory leaks previously, I have solved them and can no longer find any other problems with that tool.
I've been able to recreate this problem on a Nexus S running Gingerbread, but it doesn't appear to be reproducible on a Galaxy Nexus running 4.0.4 (however that might be due to the fact that the heap is larger on the Galaxy).
What am I missing?
David Wasser's suggestion above led me to the solution. I noticed when I ran the command mentioned, I was getting a whole bunch of custom font asset allocations:
zip:/data/app/com.mypackage.myapp-2.apk:/assets/DINNextLTPro-MediumCond.otf: 98K
These allocations appeared to be increasing very quickly as I changed activities. Some googling led me to this link: http://code.google.com/p/android/issues/detail?id=9904
So it appears that there is an Android bug related to using custom fonts. The following workaround was taken from the link above:
public class Typefaces {
private static final String TAG = "Typefaces";
private static final Hashtable<String, Typeface> cache = new Hashtable<String, Typeface>();
public static Typeface get(Context c, String assetPath) {
synchronized (cache) {
if (!cache.containsKey(assetPath)) {
try {
Typeface t = Typeface.createFromAsset(c.getAssets(),
assetPath);
cache.put(assetPath, t);
} catch (Exception e) {
Log.e(TAG, "Could not get typeface '" + assetPath
+ "' because " + e.getMessage());
return null;
}
}
return cache.get(assetPath);
}
}
}
Essentially we're caching the instances of the custom font asset so each one only needs to be instantiated a single time.

Android intent takes a long time to be received

In my app I am sending an intent to update an appWidget. The problem is, from the logcat I can see that the intent is taking on average ten seconds to be received.
05-16 18:12:54.070: DEBUG/PHCA_Variable(7580): Broadcast sent
05-16 18:12:54.080: INFO/ActivityManager(274): Starting: Intent { flg=0x10000000 cmp=com.skipmorrow.phca/.WidgetDialogResponseActivity (has extras) } from pid 7580
05-16 18:12:54.100: WARN/ActivityManager(274): Trying to launch com.skipmorrow.phca/.WidgetDialogResponseActivity
05-16 18:12:54.170: DEBUG/InputTransport(274): Input channel constructed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (server)', ashmemFd=299, receivePipeFd=311, sendPipeFd=310
05-16 18:12:54.170: DEBUG/InputTransport(274): Input channel constructed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=304, receivePipeFd=309, sendPipeFd=313
05-16 18:12:54.170: DEBUG/InputTransport(274): Input channel destroyed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=304, receivePipeFd=309, sendPipeFd=313
05-16 18:12:54.180: DEBUG/InputTransport(7580): Input channel constructed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=66, receivePipeFd=67, sendPipeFd=68
05-16 18:12:54.460: INFO/ActivityManager(274): Displayed com.skipmorrow.phca/.WidgetDialogResponseActivity: +362ms
05-16 18:12:56.140: INFO/InputDispatcher(274): Delivering key to current input target: action: 0, channel '40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (server)'
05-16 18:12:56.260: INFO/InputDispatcher(274): Delivering key to current input target: action: 1, channel '40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (server)'
05-16 18:12:56.390: DEBUG/InputTransport(7580): Input channel destroyed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=66, receivePipeFd=67, sendPipeFd=68
05-16 18:13:03.350: DEBUG/PHCA_PhcaAppWidgetProvider(7580): onReceive(); action = android.appwidget.action.APPWIDGET_UPDATE
The only thing I see that looks a little fishy is a warning that an activity is starting. Why would that be a warning? Other than that, everything seems ok.
The code to send the intent is nothing special:
Log.d(MY_DEBUG_TAG, "UpdateAppWidgets()");
Intent i = new Intent();
i.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
ComponentName phcaWidget = new ComponentName(ctx, PhcaAppWidgetProvider.class);
i.putExtra("appWidgetIds", AppWidgetManager.getInstance(ctx).getAppWidgetIds(phcaWidget));
ctx.sendBroadcast(i);
Log.d(MY_DEBUG_TAG, "Broadcast sent");
And the onReceive in the appWidgetProvider is nothing special either. The Log statement is the first command.
What could cause an intent to take upwards of ten seconds to be received?
Skip
If the Activity you are sending the intent to does not yet exist, it has to be started. 10 seconds seems like a long time for starting an app, but not insane.
I have apps which run 5 times or more slower when in debug mode. If you are in debug mode, it could be that it will run much faster if not in debug mode. Generally, you can see logcat messages when not in debug mode, for a device connected to PC running eclipse IDE. If you can get that working, you should try running that way and see if it is faster. Also try running with phone unplugged from Eclipse entirely, it will be harder to tell if its faster but it might be.

Handing multiple scenes in andengine is cause "Consumer closed input channel" exception

I am doing a simple POC of andengine Scene handling. I have written a simple code, that adds and remove a scene to parent scene as a child.
After doing several time this action, game crashes with following logs.
ANy information or details about these logs and its reasons would be of great help.
04-18 23:43:12.410: D/AndEngine(9346): SpeedyMindActivity.onSurfaceChanged(Width=800, Height=480) #(Thread: 'GLThread 8919')
04-18 23:45:04.824: W/InputDispatcher(136): channel '418640c8 com.aqif.speedyMind.activity/com.aqif.speedyMind.activity.SpeedyMindActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x8
04-18 23:45:04.824: E/InputDispatcher(136): channel '418640c8 com.aqif.speedyMind.activity/com.aqif.speedyMind.activity.SpeedyMindActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
04-18 23:45:04.840: I/WindowManager(136): WIN DEATH: Window{418640c8 com.aqif.speedyMind.activity/com.aqif.speedyMind.activity.SpeedyMindActivity paused=false}
04-18 23:45:04.929: W/ActivityManager(136): Force removing ActivityRecord{418f6170 com.aqif.speedyMind.activity/.SpeedyMindActivity}: app died, no saved state
04-18 23:45:04.972: W/InputDispatcher(136): Attempted to unregister already unregistered input channel '418640c8 com.aqif.speedyMind.activity/com.aqif.speedyMind.activity.SpeedyMindActivity (server)'
04-18 23:45:05.031: W/WindowManager(136): Force-removing child win Window{41951328 SurfaceView paused=false} from container Window{418640c8 com.aqif.speedyMind.activity/com.aqif.speedyMind.activity.SpeedyMindActivity paused=false}
04-18 23:45:05.203: I/WindowManager(136): WINDOW DIED Window{418640c8 com.aqif.speedyMind.activity/com.aqif.speedyMind.activity.SpeedyMindActivity paused=false}
regards,
Aqif Hamid
i didn't came up with a solution for this problem. But better approach is to cache your Scenes and replace your Scenes from your engine.

Categories

Resources