After converting from Crashlytics via Fabric to Crashlytics via Firebase, I started seeing the below call stack in debug runs where StrictMode is enabled looking for resource leaks.
StrictMode is in use with this code, only on debug builds:
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedClosableObjects()
.penaltyLog()
.build());
I'm using this versions of Fabric's gradle tools in project-level gradle:
classpath "io.fabric.tools:gradle:1.27.0"
and these versions of Firebase and Crashlytics in module-level gradle:
implementation "com.google.firebase:firebase-core:16.0.7"
implementation "com.crashlytics.sdk.android:crashlytics:2.9.8"
During initialization, the Firebase instrumentation kicks off a background thread that is doing settings calls using okhttp. When it does, StrictMode causes this call stack to pop:
W/CrashlyticsCore: Received null settings, skipping report submission!
D/StrictMode: StrictMode policy violation: android.os.strictmode.LeakedClosableViolation: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
at android.os.StrictMode$AndroidCloseGuardReporter.report(StrictMode.java:1786)
at dalvik.system.CloseGuard.warnIfOpen(CloseGuard.java:264)
at java.util.zip.Inflater.finalize(Inflater.java:398)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:250)
at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:237)
at java.lang.Daemons$Daemon.run(Daemons.java:103)
at java.lang.Thread.run(Thread.java:764)
Caused by: java.lang.Throwable: Explicit termination method 'end' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:221)
at java.util.zip.Inflater.<init>(Inflater.java:114)
at com.android.okhttp.okio.GzipSource.<init>(GzipSource.java:62)
at com.android.okhttp.internal.http.HttpEngine.unzip(HttpEngine.java:473)
at com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:648)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:471)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:407)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:538)
at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:26)
at io.fabric.sdk.android.services.network.HttpRequest.code(HttpRequest.java:1357)
at io.fabric.sdk.android.services.settings.DefaultSettingsSpiCall.handleResponse(DefaultSettingsSpiCall.java:104)
at io.fabric.sdk.android.services.settings.DefaultSettingsSpiCall.invoke(DefaultSettingsSpiCall.java:88)
at io.fabric.sdk.android.services.settings.DefaultSettingsController.loadSettingsData(DefaultSettingsController.java:90)
at io.fabric.sdk.android.services.settings.DefaultSettingsController.loadSettingsData(DefaultSettingsController.java:67)
at io.fabric.sdk.android.services.settings.Settings.loadSettingsData(Settings.java:153)
at io.fabric.sdk.android.Onboarding.retrieveSettingsData(Onboarding.java:126)
at io.fabric.sdk.android.Onboarding.doInBackground(Onboarding.java:99)
at io.fabric.sdk.android.Onboarding.doInBackground(Onboarding.java:45)
at io.fabric.sdk.android.InitializationTask.doInBackground(InitializationTask.java:63)
at io.fabric.sdk.android.InitializationTask.doInBackground(InitializationTask.java:28)
at io.fabric.sdk.android.services.concurrency.AsyncTask$2.call(AsyncTask.java:311)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:458)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:764)
D/FA: Event not sent since app measurement is disabled
I see this happening on pretty much every debug run of my app, during the initial activity startup in the app. However support claims they don't see this.
Does anyone know what conditions cause Fabric to kick off this onboarding/settings thread?
I've seen similar StrictMode call stacks in these other posts. I can't tell if this leak is in Fabric code, or in the okhttp library they are using. Here are links to similar cases where people are seeing what looks to me like the same underlying resource leak:
StrictMode penalising for Firebase Ads
Crashlytics with StrictMode enabled (detect all) gives "untagged socket detected"
https://github.com/cloudant/sync-android/issues/577
Related
I am using Objectify(v5) for accessing Datastore, in App Engine Standard Environment, with Java. Entities are cached by Objectify automatically, and I am also using Memcache separately.
This issue of Datastore APIs timing out started happening exactly post REDIRECT_STRONGLY_CONSISTENT_READS migration step. Strangely, it happens roughly after every hour or 2 hours, lasts for 3-4 mins and then gets back to normal. Since requests latency is going up from ~200ms to more than 60s, lots of new instances are getting created and am getting charged heavily.
here are some of the errors:
com.google.api.server.spi.SystemService invokeServiceMethod: exception occurred while calling backend method
java.util.concurrent.CancellationException: Task was cancelled.
at com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1550)
at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:590)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:467)
at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:122)
at com.google.appengine.tools.development.TimedFuture.get(TimedFuture.java:55)
at com.google.common.util.concurrent.ForwardingFuture.get(ForwardingFuture.java:68)
at com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:89)
at com.google.appengine.api.datastore.Batcher$ReorderingMultiFuture.get(Batcher.java:114)
at com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:89)
at com.googlecode.objectify.cache.TriggerFuture.get(TriggerFuture.java:100)
at com.googlecode.objectify.impl.ResultAdapter.now(ResultAdapter.java:34)
at com.googlecode.objectify.util.ResultWrapper.translate(ResultWrapper.java:22)
at com.googlecode.objectify.util.ResultWrapper.translate(ResultWrapper.java:10)
at com.googlecode.objectify.util.ResultTranslator.nowUncached(ResultTranslator.java:21)
at com.googlecode.objectify.util.ResultCache.now(ResultCache.java:30)
at com.googlecode.objectify.util.ResultWrapper.translate(ResultWrapper.java:22)
at com.googlecode.objectify.util.ResultWrapper.translate(ResultWrapper.java:10)
at com.googlecode.objectify.util.ResultTranslator.nowUncached(ResultTranslator.java:21)
at com.googlecode.objectify.util.ResultCache.now(ResultCache.java:30)
and
com.googlecode.objectify.cache.EntityMemcache getAll: Error obtaining cache for [<dummy-entity-name>]
java.util.concurrent.CancellationException: Task was cancelled.
and
java.lang.InterruptedException
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:460)
I have tried upgrading to latest versions:
implementation 'com.google.appengine:appengine-api-1.0-sdk:2.0.5'
implementation 'javax.servlet:javax.servlet-api:3.1.0'
implementation 'com.googlecode.objectify:objectify:5.1.25'
and also flushed memcache. nothing has worked.
Has anyone faced this issue?
It turned out to be an issue with migration itself. Reached out to Google Cloud support(paid), Datastore/Firestore Product team paused the migration, which I could not do it myself by the way, wasn't allowed for my project. They did some fixing and completed the migration. Now Datastore queries as running as expected.
We have a clone of draw.io. We have made some modifications to the UI for increased functionality. This works on localhost. We then did the Google Drive authentication process. But it was done on version 12.1.7 of draw.io. That integrated with google drive, except when re-opening a previously saved file.[Error with this version discussed here:https://stackoverflow.com/questions/62889536/no-access-control-allow-origin-header-is-present-on-the-requested-resource]
So, we ported our changes to the recent version of draw.io ,version 13.4.5 (https://github.com/jgraph/drawio/releases/tag/v13.4.5). Now, we get a different error. When trying to authenticate <screen shot of pop-up just before error> we get:
Login attempts failed.Please try again later <screenshot of error message>. When we look at developer tools, we see this
HTTP Status 500 - Can't make API call memcache.Set in a thread that is neither the original request thread nor a thread created by ThreadManager
type Exception report
message Can't make API call memcache.Set in a thread that is neither the original request thread nor a thread created by ThreadManager
description The server encountered an internal error that prevented it from fulfilling this request.
exception
com.google.apphosting.api.ApiProxy$CallNotFoundException: Can't make API call memcache.Set in a thread that is neither the original request thread nor a thread created by ThreadManager
com.google.apphosting.api.ApiProxy$CallNotFoundException.foreignThread(ApiProxy.java:800)
com.google.apphosting.api.ApiProxy$1.get(ApiProxy.java:175)
com.google.apphosting.api.ApiProxy$1.get(ApiProxy.java:172)
com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:89)
com.google.appengine.api.memcache.MemcacheServiceImpl.quietGet(MemcacheServiceImpl.java:26)
com.google.appengine.api.memcache.MemcacheServiceImpl.put(MemcacheServiceImpl.java:69)
com.google.appengine.api.memcache.stdimpl.GCache.put(GCache.java:157)
com.mxgraph.online.AbsAuthServlet.doGet(Unknown Source)
javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
note The full stack trace of the root cause is available in the Apache Tomcat/8.0.32 (Ubuntu) logs.
Notice the line in <com.mxgraph.online.AbsAuthServlet>. It says “doGet” is throwing error. I am new to servlets and don’t know how to proceed. I did not find “doGet” in the file AbsAuthServlet.java .
Any help to solve this issue will be great.
While implement Fire-base cloud messaging in browser with help of Service Worker getting an error "DOMException: Registration failed - storage error" please help why i am getting this error
This means that your Service Worker has stored so much data that the storage available to it is full, and upon SW installation it tries to store even more which in turn leads to an error.
You have to either manually remove stuff from your storage or use some library that automatically handles these situations for you in a way or another (eg. removes stuff FIFO style).
In my case the problem was caused by create-react-app's own service worker unregistration logic at the very bottom of index.js:
serviceWorker.unregister();
It was conflicting with the fact of using a service worker in the middle of our own application's logic.
Solution was simple – just removing that line from index.js
I have upgrade my worklight project from worklight 6.1 to mobilefirst 7.1. In previous project (WL6.1), pushnotification is working fine.
For mobilefirst, While checking ibm tutorials, I found this link for Adding Google Play services to your Android project.
http://www.ibm.com/support/knowledgecenter/en/SSHS8R_7.1.0/com.ibm.worklight.dev.doc/devref/t_adding_google_play_services.html
For pushnotification, is this step required? As per link, it will increase my application size. What is the significance of assming Google Service library? Can I skip it?
After configuring android pushnotification in mobilefirst 7.1 (Except adding goole service), I am facing this error on server side
com.ibm.pushworks.server.notification.gcm.GCMMediator addTokenToAndroidKey FPWSE1079W: GCM push token '##TOKEN_ID##' is not added to GCM notification key. GCM Service invocation failed (reason: Error while invoking request)
com.ibm.pushworks.server.exceptions.GCMException: GCM Service invocation failed (reason: Error while invoking request)
at com.ibm.pushworks.server.notification.gcm.GCMSender.sendToGCM(GCMSender.java:392)
at com.ibm.pushworks.server.notification.gcm.GCMSender.addTokenToAndroidKey(GCMSender.java:364)
at com.ibm.pushworks.server.notification.gcm.GCMMediator.addTokenToAndroidKey(GCMMediator.java:206)
at com.ibm.pushworks.server.core.PushServiceImpl.getNotificationKey(PushServiceImpl.java:2160)
at com.ibm.pushworks.server.core.PushServiceImpl.registerDevice(PushServiceImpl.java:613)
at com.worklight.integration.services.impl.DataAccessServiceImpl.updateDeviceToken(DataAccessServiceImpl.java:473)
......
Caused by: org.apache.http.conn.HttpHostConnectException: Connect to android.googleapis.com:443 [android.googleapis.com/216.58.210.202, android.googleapis.com/216.58.210.234] failed: Connection refused: connect
at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:142)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
at com.ibm.pushworks.server.notification.gcm.GCMSender.sendToGCM(GCMSender.java:388)
... 45 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:412)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:271)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:258)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:376)
at java.net.Socket.connect(Socket.java:546)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:244)
at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
... 56 more
Can this be GCM port opening issue or relevant to google play services?
Google has deprecated the use of GCM.jar in a project and from its perspective you should use the Google Play Services library.
For IBM MobileFirst Platform, though, the Google Play Services library is required if you need to use the Cloud Sync feature and others (by Google). If you don't need this feature don't add the library, as there is still a built-in implementation in the MobileFirst SDK for push notifications using GCM.jar.
Notes:
Starting MobileFirst Foundation 8.0, the library is now required.
In v7.1, you can still use the library regardless of the built-in fallback, but you will need to use Android's ProGuard feature to decrease the classes size to prevent the dex error ("too many classes") and in general to reduce to size.
As for the network error, it seems that your network configuration is lacking (connection refused). The documentation also lists addresses/ports that Google requires having them open/accessible to properly function.
I converted a standalone Flex app into a module. Now that it's a module, when I login (and call the backend services), I'm getting a security sandbox violation.
The login handler throws this fault String: 'Send Failed', with a more descriptive: 'Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Failed:url: 'http://myUrl:8080/AppManager/messagebroker/amf'.
Then the FB console throws an 'unhandled security sandbox violation error'.
Can converting an app into a module cause a sandbox violation?
Thanks for any helpful tips.
I'm making extensive use of modules and haven't run into this. There are memory issues I ran into that I had to fix by actually declaring an instance of the modules in the main modules...I didn't have to create an instance, just declare a variable to get the linkage right, then have all the other modules compile against that main module. Memory errors went away, and all the other modules were much smaller too.