QueueFile crash #172
Labels
bug
This has been identified as a bug.
Comments
|
|
|
The second error is something we've had reported, I'm hoping to have it fixed for v3. |
|
You're correct. I must have checked our latest development build and we have switched to a newer build and from All to Core. Looks like our old version was using |
|
Still have same issue with new newer build.. it crashes my application.. |
|
Which build? Can you send the full stack trace? |
|
I'm using build v2.5.3.. here is the bug report.. |
|
How are you initializing the Analytics client, and how are you sending events? |
|
I have a singleton class for using it.. public class SegmentAnalyticsSingleton
{
private static Analytics analytics;
public static Analytics getInstance(Context context)
{
if (analytics == null)
{
analytics = new Analytics.Builder(context, SegmentIO_key).build();
}
return analytics;
}
}In order to send event I use it like this: |
|
@aman400 , could you try the latest build (3.0.0) and enable logging and post the output here? |
|
okay, I'll give it a try. But the problem is that crash is random. |
|
With 3.0.1 I got this: Consistently prevents the app from starting. This is a major issue for us. Do you have any news about this issue? |
|
@adrien-aubel I think you're missing some logs there. |
|
@f2prateek that's weird, this is what I got from Crashlytics. Release mode btw. |
|
@adrien-aubel weird, let me know if you see a more detailed log by any chance. We're updating the behaviour to handle this better in 3.0.2 (and we have been for a while), but it's hard to get a reproducible case to verify this behaviour. |
|
Could you maybe catch |
|
@f2prateek do you have any ETA for 3.0.2? |
|
Would you have by any chance steps that the user should follow if he wants to fix the problem without uninstalling the app and lose his data? |
|
This issue is constantly on top of our Crashlytics statistics. Using 2.5.3. |
|
@appmagnetics try updating to 3.0.2 |
|
That's not so easy - I see in comments above someone trying 3.0.1 and saying it basically got worse - his app did not start. We cannot reproduce this issue by ourselves and we have 4000 customers for our app - we just cannot allow to release a new version and get the app crashed by them. |
|
@appmagnetics we didn't try 3.0.2 but since we were only using Mixpanel we unfortunately removed Segment.io to use directly Mixpanel SDK for the time being. |
|
@appmagnetics @adrien-aubel How are you initializing the Analytics client - specifically the queueSize? |
|
@f2prateek we do no special settings concerning queueSize or something else: analytics = new Analytics.Builder(context, App.getString03()).build(); |
|
How do you call use the analytics client? If it's through a helper class, can you share the implementation? |
|
The issue can be actually fixed without further understanding, right? Either catch the exception of check boundaries before access. Will you be willing to fix 2.5.x version? If not, the discussion is worthless - if we want to avoid this crash we will have to try 3.x.x. |
|
We can't simply catch the exception - those items will be stuck in the disk queue forever and constantly be uploading. The issue is that queueFile is reporting it's size as 0 - a state that is explicitly disallowed. Either the bug is in our implementation, QueueFile or the data that's you're sending, and we don't know what the core issue is yet. |
|
@drspaceboo @appmagnetics @adrien-aubel @aman400 are you all using proguard? |
|
Yes, we are using proguard |
|
Yeah of course. These are the rules we added for Segment IO: These are the warnings we get if we don't have "dontwarn" turned on: |
|
We've made some improvements in the latest versions that shouldn't cause this issue. Let me know if you still see any. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We recently added the Segment IO SDK into our application. Since then we have seen an increasing number of crashes caused within the SDK due to Tape. It appears that an exception is being thrown but not handled.
This crash is now the 2nd most prevalent crash in our application.
Below is the stack trace we are getting via HockeyApp:
While trying to debug it internally we also hit the following issue, however we're not sure if it is related:
We are using the Core library version 2.5.3.
The text was updated successfully, but these errors were encountered: