android api 30 Fatal signal 6 (SIGABRT) - java

My app worked fine at api29. Now getting this native error. No clue otherwise.
D/TransportRuntime.SQLiteEventStore: Storing event with priority=DEFAULT, name=FIREPERF for destination cct
V/FA: Connection attempt already in progress
V/FA: Connection attempt already in progress
D/TransportRuntime.JobInfoScheduler: Scheduling upload for context TransportContext(cct, DEFAULT, MSRodHRwczovL2ZpcmViYXNlbG9nZ2luZy1wYS5nb29nbGVhcGlzLmNvbS92MS9maXJlbG9nL2xlZ2FjeS9iYXRjaGxvZ1xBSXphU3lDY2traUg4aTJaQVJ3T3MxTEV6RktsZDE1YU9HOG96S28=) with jobId=-546033166 in 30000ms(Backend next call timestamp 1639520060629). Attempt 1
D/mainact: buildDisplayDataBase:
A/libc: fdsan: attempted to close file descriptor 75, expected to be unowned, actually owned by FILE* 0xf108246c
Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 20661 (eymoreau.fitlog), pid 20661 (eymoreau.fitlog)
Disconnected from the target VM, address: 'localhost:60917', transport: 'socket'

If you are displaying images try eliminating them to see of it fixes the error.
It did for me and I ended up changing my image loading from:
mainMenu_viewHolder.getImageView().setImageResource(R.drawable.gear);
to...
Bitmap checkImg = BitmapFactory.decodeResource(fragment.getResources(), R.drawable.check);
mainMenu_viewHolder.getImageView().setImageBitmap(checkImg);
The issue is buried very deep so if this doesn't work for you don't try stepping through your code or researching the native error. It will be wasted time. Just disable your fragments entire view structure and add back in piece by piece.

Related

Deque Full Exception - Thingsboard

Im having trouble using Thingsboard platform (IoT) when simulating 7.5K devices sending data to the platform. I have the following error in the logs as soon as I start sending data (over MQTT):
2020-08-01 01:17:06,946 [ForkJoinPool-12-worker-0] ERROR c.g.c.u.concurrent.AggregateFuture - Got more than one input Future failure. Logging failures after the first
java.lang.IllegalStateException: Deque full
at java.util.concurrent.LinkedBlockingDeque.addLast(LinkedBlockingDeque.java:335)
at java.util.concurrent.LinkedBlockingDeque.add(LinkedBlockingDeque.java:633)
at org.thingsboard.server.dao.util.AbstractBufferedRateExecutor.submit(AbstractBufferedRateExecutor.java:109)
at org.thingsboard.server.dao.nosql.CassandraAbstractDao.executeAsync(CassandraAbstractDao.java:93)
at org.thingsboard.server.dao.nosql.CassandraAbstractDao.executeAsyncWrite(CassandraAbstractDao.java:76)
at org.thingsboard.server.dao.timeseries.CassandraBaseTimeseriesDao.savePartition(CassandraBaseTimeseriesDao.java:434)
at org.thingsboard.server.dao.timeseries.BaseTimeseriesService.saveAndRegisterFutures(BaseTimeseriesService.java:153)
at org.thingsboard.server.dao.timeseries.BaseTimeseriesService.save(BaseTimeseriesService.java:144)
at org.thingsboard.server.service.telemetry.DefaultTelemetrySubscriptionService.saveAndNotify(DefaultTelemetrySubscriptionService.java:124)
at org.thingsboard.rule.engine.telemetry.TbMsgTimeseriesNode.onMsg(TbMsgTimeseriesNode.java:89)
at org.thingsboard.server.actors.ruleChain.RuleNodeActorMessageProcessor.onRuleChainToRuleNodeMsg(RuleNodeActorMessageProcessor.java:107)
at org.thingsboard.server.actors.ruleChain.RuleNodeActor.onRuleChainToRuleNodeMsg(RuleNodeActor.java:97)
at org.thingsboard.server.actors.ruleChain.RuleNodeActor.doProcess(RuleNodeActor.java:60)
at org.thingsboard.server.actors.service.ContextAwareActor.process(ContextAwareActor.java:45)
at org.thingsboard.server.actors.TbActorMailbox.processMailbox(TbActorMailbox.java:121)
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
I have try to google and see the reason behind it, but i havent found anything.
While simulating with 5K devices, this error came like 3 times each day (over a 4 day period), but it stopped showing that error eventually. However, when increasing the number of devices, the error is constant. Im using Kafka as the broker, but I dont see any Kafka related error. I just want to know why the error appears, is it related to memory, or any other limit?
Thanks in advance
Francisco P

App crash while frequent requesting mediafile with exoplayer instances

I am getting this error why frequently try to tap exoplayer instances.
normally instances releases and nulls itself on everytime.
But after some tries app freezes and crashes. I am trying to find where is the problem related
2019-04-04 11:40:36.002 540-1196/? E/BufferQueueProducer: [com..app.musicplayer/com..app.musicplayer.dashboard.DashboardMusicActivity#0] dequeueBuffer: attempting to exceed the max dequeued buffer count (2)
2019-04-04 11:40:36.110 13761-15052/com..app.musicplayer E/NativeCrypto: AppData::create pipe(2) failed: Too many open files
2019-04-04 11:40:36.121 13761-15052/com..app.musicplayer E/AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
Process: com..app.musicplayer, PID: 13761
java.lang.RuntimeException: javax.net.ssl.SSLException: Unable to create application data
at com.android.org.conscrypt.ConscryptFileDescriptorSocket.newSsl(ConscryptFileDescriptorSocket.java:161)
at com.android.org.conscrypt.ConscryptFileDescriptorSocket.<init>(ConscryptFileDescriptorSocket.java:152)
at com.android.org.conscrypt.OpenSSLSocketFactoryImpl.createSocket(OpenSSLSocketFactoryImpl.java:149)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:288

java.lang.OutOfMemoryError: Could not allocate JNI Env always android java

i am running AsyncTask
java.lang.OutOfMemoryError: Could not allocate JNI Env
at java.lang.Thread.nativeCreate(Native Method)
at java.lang.Thread.start(Thread.java:1063)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:921)
at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:989)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
i get this error the next time i run the app and do the same task,first time task is completed without any porblem and no crashes and when i back press and exit the app and come back and do the same task it shows this error
[ 11-06 22:20:02.741 1174: 1219 D/ ]
NULL ==
surf->write_back_color_buffer
11-06 22:20:02.741 1174-1219/com.package A/OpenGLRenderer: Encountered EGL error 12291 EGL_BAD_ALLOC during rendering
11-06 22:20:02.741 1174-1219/com.package A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 1219 (RenderThread)
never had this problem before
okay that error was due to inputstream i forgot to close in one module,so if you guys use any stream,double check it and make sure you close all stream you open :)

Why does android logcat not show the stack trace for a runtime exception?

An android application that I am currently developing was crashing (fixed that), due to what should have raised an IndexOutOfBoundsException. I was accessing a string in the doInBackground method of a class that extends AyncTask, from the variable arguments parameter (ie String...). I was accidentally accessing index 1 (not 0) of a one element variable argument string (mildly embarrassing...). When the application first crashed I looked at my logcat, (and many times again to confirm that I wasn't insane) and there was no stack trace for a RuntimeException to be found. I crash my phone quite often and there is always a nice little stack trace for me to look at and fix with, but I was puzzled by this. Here is the pertinent section of my logcat (which contains no stack trace for a runtimeexception), following a debug statement right before the line of code that was causing the crash:
W/dalvikvm(25643): threadid=11: thread exiting with uncaught exception (group=0x40c281f8)
D/dalvikvm(25643): GC_CONCURRENT freed 1249K, 25% free 12433K/16455K, paused 2ms+6ms
W/dalvikvm(25643): threadid=15: thread exiting with uncaught exception (group=0x40c281f8)
I/Process (25643): Sending signal. PID: 25643 SIG: 9
I/ActivityManager( 5905): Process com.trade.nav.ges (pid 25643) has died.
W/ActivityManager( 5905): Force removing r: app died, no saved state
I/WindowManager( 5905): WIN DEATH: win
I/WindowManager( 5905): WIN DEATH: win
I/SurfaceFlinger( 1746): id=3848 Removed idx=2 Map Size=4
I/SurfaceFlinger( 1746): id=3848 Removed idx=-2 Map Size=4
I/WindowManager( 5905): WIN DEATH: win
I/power ( 5905): *** acquire_dvfs_lock : lockType : 1 freq : 1000000
D/PowerManagerService( 5905): acquireDVFSLockLocked : type : DVFS_MIN_LIMIT frequency : 1000000 uid : 1000 pid : 5905 tag : ActivityManager
W/ActivityManager( 5905): mDVFSLock.acquire()
And after that, another activity starts.
For reference, here is the code that caused the crash:
private class LoadImage extends AsyncTask<String, Integer, Bitmap> {
String url = "";
//...
public LoadImage(ImageView iv, Context c) {
//...
}
protected Bitmap doInBackground(String... urls) {
// urls has one element
url = urls[1];
//...
}
//...
}
Any insight into what is happening would please me greatly, as I am curious about having never seen anything like this on the internet.
Thanks.
Edit: I have no filter set
Your threads are clearly crashing (note the thread exiting with uncaught exception on two different threads in the same process). The process is cleaning up after itself -- Sending signal indicates the process is sending a fatal signal to itself. So the question is why you aren't seeing a stack dump between these two.
The stack dump comes from RuntimeInit$UncaughtHandler, which is the framework-provided global uncaught exception handler. The process self-annihilation happens in the finally block. It's hard to see a way to get out of this without logging "FATAL EXCEPTION", unless something in Slog.e fails and throws.
I would guess that either something is failing in Slog.e, or somebody has replaced the framework's uncaught exception handler. The latter could happen if you've incorporated some external library into your app, such as a crash log catcher or an ad network, and the new handler doesn't log the exception but does kill the process.
You can track it down by attaching a Java-language debugger (e.g. Eclipse). By default it will stop on uncaught exceptions. From there you can trace it around, set breakpoints and single-step through the uncaught exception handler (if you have full sources), and so on.
As per fadden's suspect that external library could override uncaught exception handler, I started to investigate any possible libs. Turned out that GoogleAnalytics throttles crashes and prevents the stack trace from being displayed in logcat if you turn on enableExceptionReporting. I remove this line of code then everything gets back on track!! That could be the first time I was so happy to see crashes!!

crashing GoogleWrapperSample (OpenStreetMap)

I have a problem with GoogleWrapperSample for OpenSteetMap (I use osmdroid latest jar - 3.0.8). It is compiling fine, but the emulator (Google API 2.2 device) throws a toast with "Activity is not responding" message and nothing else. There are no errors/warnings and as it is a logger in osmdroid classes I can only receive some logging information. LogCat gives something like this:
02-14 13:21:20.246: W/System.err(968): 38 [main] INFO org.osmdroid.views.MapView - Using tile source: org.osmdroid.tileprovider.tilesource.XYTileSource#44eb5260
02-14 13:21:20.316: W/System.err(968): 113 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-14 13:21:20.336: W/System.err(968): 129 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-14 13:21:30.166: I/dalvikvm(968): threadid=3: reacting to signal 3
02-14 13:21:30.207: I/dalvikvm(968): Wrote stack traces to '/data/anr/traces.txt'
Has anyone got this sample working? I have no ideas how to solve this problem.
Maybe, it is somehow connected with getting OSM tiles via network or something like that - we have a proxy connection so https and SSL port are not available (but all in all network on the device is ok).
UPD.
On HTC Desire it works properly but OSM map is not available - there is only a grid. On the other hand, Google map is ok.
LogCat contains this:
02-15 14:47:00.074: W/System.err(2106): 6 [main] INFO org.osmdroid.views.MapView - Using tile source: org.osmdroid.tileprovider.tilesource.XYTileSource#46361618
02-15 14:47:00.084: W/System.err(2106): 23 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-15 14:47:00.094: W/System.err(2106): 26 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-15 14:47:00.184: D/dalvikvm(2106): GC_FOR_MALLOC freed 4349 objects / 315536 bytes in 33ms
02-15 14:47:00.214: D/dalvikvm(2106): GC_EXTERNAL_ALLOC freed 317 objects / 14952 bytes in 28ms
02-15 14:47:00.224: W/System.err(2106): 160 [main] INFO org.osmdroid.tileprovider.MapTileProviderBase - rescale tile cache from 0 to 14
02-15 14:47:00.234: W/System.err(2106): 170 [main] INFO org.osmdroid.tileprovider.MapTileProviderBase - Finished rescale in 10ms
02-15 14:47:00.284: I/MapActivity(2106): Handling network change notification:CONNECTED
02-15 14:47:00.284: E/MapActivity(2106): Couldn't get connection factory client
On emulator there is no progress.
I think that "Couldn't get connection factory client" is the reason of my problem but have no idea about the way to fix this.
There are two situations where an Application Not Responding (ANR) may occur:
No response to an input event (e.g. key press, screen touch) within 5 seconds.
A BroadcastReceiver hasn't finished executing within 10 seconds.
Common causes of an ANR are (stalled) networking operations or expensive calculations.
There are a number of posts on SO on how to solve it (e.g. here or here), but the biggest help is probably the Android API.
I took a quick look at the sample code, I'm not sure but perhaps the setMapView() method that is called in onResume() takes too long. You may be able to test this by commenting that line out. Otherwise, check the traces.txt file on the emulator for clues and/or add logging statements to your code to pinpoint which operation is taking too long.
As for your "Couldn't get connection factory client" error, that question has already been answered here

Categories

Resources