Over the past two months, my app has become significantly more complex. I use Transactions to complete 90% of all document writes client side. I have added quite a few listeners recently as well. Over the apps development, a linear increase in transaction and listener usage has caused an exponential spike in crashes. These crashes are just from testing using one device! Furthermore, the crashes happen exclusively on Android devices...
These are the four causes of every crash my app has seen:
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:613)
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$DocumentObserver.onEvent (CloudFirestorePlugin.java:429)
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$EventObserver.onEvent (CloudFirestorePlugin.java:451)
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground (CloudFirestorePlugin.java:633)
The information provided doesn't help in narrowing down the problem. I would normally assume that I am doing something wrong, but the fact that this occurs exclusively on android devices leads me to believe something is wrong at the package level. Digging online through forums and documentation it appears I am not alone with this Firestore Transaction/Listener related issue.
Has anybody had similar issues and found a solution? This isn't only a problem for me, it's a show stopper.
Is it possible that since introducing listeners I have created this problem?
This seems to be a known issue on github, please confirm but the issue only occurs on Android -Fluter with the listeners.
They mentioned:
Just waiting for the green signal to make sure this doesn't catch some other edge cases and I can go ahead with a fix patch.
You shoudl post that your are being affected also and followup there.
Related
What is the logic behind calculating the tags such as Early crashes, repetitive crashes, regression issue, Fresh issue, etc which appear on crashlytics dashboard?
Is there any reference available as I am unable to find out any information in the documentation.
I need this information for filtering out my crashes and giving them priority.
Regressed issues are documented in what is a regressed issue:
An issue has had a regression when you've previously closed the issue but Crashlytics gets a new report that the issue has re-occurred. Crashlytics automatically re-opens these regressed issues so that you can address them as appropriate for your app.
Click the link for an example too.
Aside from that, the best I can find it this description in the release notes:
You can now see Signals appearing in the Crashlytics console to indicate that certain issues have interesting characteristics that may be more important to your app health. We’re launching three Signals to start:
"Fresh issue" - new issues within the last week.
"Early crashes" - the majority of these crashes happened near app start.
"Repetitive crashes" - crashes your users are encountering over and over.
You can also find details about each of these signals in the Firebase console, when you hover over a crash of that specific type.
I have implemented firebase crashlytics in my unity game to receive the reports of the crashes and It is working half-fuel. It is reporting some crashes but for some reason,It is not reporting all crashes. I have numerous report from users crashing at the same part of the game but I am unable to reproduce the problem or find it in the crashlytics report.
Is anything more that I can do in order to receive all of the crashes?
There are two types of crashes that Crashlytics will track: fatal and non-fatal. For the most part, crashes on iOS and Android are fatal crashes (the entire app/game crashed and the user is looking at their phone's home screen). On Unity, Crashlytics actually registers a LogCallback and reports uncaught exceptions. Typically these do not fully crash your game, but still indicate bad and crashy behaviour. I've written a two part series on what different crashes look like there.
So the first (easy) answer is to make sure you're showing "non fatal" crashes.
The second answer is a little more difficult. A crash may occur in native code (I've typically forced a stack overflow to simulate this or run Unity out of memory, but there's a ForceCrash call I've seen developers using recently). How this gets reported gets a little hairy, partially because C++ is not officially supported by Crashlytics.
In my experience, these tend to show up as fatal crashes but poorly labelled. On iOS, they appear symbolicated but tend to select the wrong part of the stack frame to display. On Android I tend to see just a non-symbolicated crashed report (something that looks like it could be run through ndk-stack).
If you don't see your crash when you're looking at non-fatal crashes, try looking at just fatal crashes and seeing if you see anything that looks like a raw crash log. Technically Crashlytics can symbolicate native symbols on iOS and Android, and the team is aware that there are issues. If this represents your experience, I'd recommend filing an issue on GitHub or with Firebase Support to see if there either is an issue with your setup or if this is another use case that needs to get tracked.
I have a QProcess which has to be paused and resumed. I use
kill(pid_t(process->pid()), SIGSTOP);
and
kill(pid_t(process->pid()), SIGCONT);
to pause/resume the process.
However, once it is done, the process can no longer be terminated, even by QProcess:kill(). Basically, no QProcess::waitForFinished() ever succeeds and the process becomes zombie.
Does someone know the reason for this and is there any solution?
Note: I tried the answer to this question and it doesn't help. I am doing this on Mac, but googling suggest the problem also happens on Linux.
In general, lots of things can happen when SIGSTOP and a subsequent SIGCONT are sent to a process. Related processes (child or parent processes for instance) are not co-stopped when stopping a process. This may lead to weird anomalies like the breaking of pipes or delays which lead to timeouts. So in general, these signals aren't well supported. Only for very simple architectures (no forking, no child processes, etc.) they should work. Also, since a process can react upon SIGCONT, any framework (like QT) might do so and re-initialize some of its facilities. This makes also sense, of course, because after being stopped, some things might have changed which otherwise might have been noticed at the time of their change.
Unfortunately, the case is so rare and encompasses so many different aspects that this is normally not completely test-covered, so bugs are rather likely, compared to other parts of the same library. I would assume that you just found an issue in the QT code or that the framework just doesn't support these signals. Do you have any documentation which states that it should?
Steps you could do now:
Search for an already filed bug report in the bug tracking system of the related library.
Create an mcve showing the issue.
If nothing is filed, file a bug report ;-)
But I wouldn't expect the maintainers of the libraries to react very quickly, if at all. As I said, SIGSTOP and SIGCONT often aren't supported on more complex scenarios. Their implications just are too complex.
I've search high and low for an answer, damn near going through every possible Firebase question on Stackoverflow. So here we go.
I have a webapp and cordova app that uses Firebase throughout. Everything works flawlessly, except occasionally the apps lose connection (usually after being in the background for a while) and everything stops working. No offline mode, no loading additional data, even Firebase.goOnline() doesn't kick it back in to gear. The only thing I can do is refresh the entire app and all is right in the world again.
But I can not for the life of me reproduce this on my own - it seems completely random.
Can anyone thing of any possible cause of this - or at least point me in a direction that I can keep trying to actively reproduce this?
I've got a flex-based swf, which is loading an AS 2-based swf and then, negotiating further activity via a LocalConnection.
From time to time, the AS 2-swf can request that the flex-based swf load a movie.
I've arranged this via on(release){} functions.
The AS 2-swf, I'm making in Swish Max. In Swish, when i set the on (release) on a text field, (to invoke .send() on my localconnection), it works splendidly. However, when I attempt to perform the same calls for an on(release) attached to a movieclip, it actually causes the Flash player, and even the browser plugin to crash.
In fact, the browser (IE) crashes as well.
I checked the debug trace that ie asked me to send to microsoft at the last IE crash, and i noticed a StackOverflow exception embedded deep in the trace, but I couldn't determine its source.
Can you help me understand what's going on here?
Are you having more than one LocalConnection connect to the same channel? This will cause the browser to crash.
Are you sending lots of requests at the same time, this will make it crash, and some browsers are more sensitive for those things than other.
This earlier post might have some helpful tips for you.
That's a wrong way to debug your application. Use your Flex Builder's debugging tool instead. You tend to lay blame on LocalConnection as it is the most complex part of the operation, when it could just as easily be an infinite loop.
You don't seem to be using the right tools either. I'd trust FF's FireBug over IE's dump. Besides, we'll need to see some more code before we can accurately tell you what's wrong.
Are you sure the crash is not only in your computer? Try running the FlashUtil??.exe at \WINDOWS\system32\Macromed\Flash\ to fix/update the Flash installaction. There are some known issues that corrupt Flash installation so it become unstable when using some objects.