FORUMS
Remove All Ads from XDA

[Xposed] Scoop - Catch the stack trace when an app crashes

1,209 posts
Thanks Meter: 4,933
 
Post Reply Email Thread
27th December 2016, 04:23 PM |#21  
Junior Member
Thanks Meter: 4
 
More
Yes!
1.4.2 is working; good job, thanks a lot.
27th December 2016, 04:41 PM |#22  
MrWasdennnoch's Avatar
OP Recognized Developer
Thanks Meter: 4,933
 
More
Quote:
Originally Posted by KaMyKaSii

Thanks, now it's working. Can you explain to me how the grouping that you implemented works? When I suggested, I wanted to say that after clicking on the crash group of the app, a list of all the crashs with information like date and time appears, and that they expand in the full log when they are clicked. And about the deletion, I'm talking about a button to clear any individual log after a long click on it. At this time it is only possible to clear all logs at once

The grouping that's currently enabled only groups the entries when they have an identical stack trace so that you don't see the item with the same log over and over again, it's not grouped by apps right now, but I can add that too. I'll add the option to delete individual crashes as well.
The Following 2 Users Say Thank You to MrWasdennnoch For This Useful Post: [ View ]
27th December 2016, 07:14 PM |#23  
daoudedy's Avatar
Senior Member
Flag Batroun
Thanks Meter: 335
 
More
Gj mate, you're doing great.

Sent from my SM-N920S using Tapatalk
29th December 2016, 01:11 PM |#24  
XlAfbk's Avatar
Senior Member
Thanks Meter: 405
 
More
I get a lot of stack traces from Google Play Music app at random intervals. These aren't really crashs or anything. Is it possible to ignore these / add a configurable ignore-filter?

Code:
java.lang.IllegalStateException: could not connect to GoogleApiClient: ConnectionResult{statusCode=API_UNAVAILABLE, resolution=null, message=null}
at com.google.android.wearable.datatransfer.internal.DefaultPeerProvider.blockingConnect(DefaultPeerProvider.java:73)
at com.google.android.wearable.datatransfer.internal.DefaultPeerProvider.getConnectedPeers(DefaultPeerProvider.java:30)
at com.google.android.wearable.datatransfer.internal.DataSyncServiceHelper.processIntent(DataSyncServiceHelper.java:380)
at com.google.android.wearable.datatransfer.internal.DataSyncServiceHelper.access$000(DataSyncServiceHelper.java:49)
at com.google.android.wearable.datatransfer.internal.DataSyncServiceHelper$IntentProcessor.run(DataSyncServiceHelper.java:727)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
30th December 2016, 04:06 PM |#25  
~El Julio~'s Avatar
Senior Member
Flag Paris
Thanks Meter: 46
 
Donate to Me
More
Despite having the "Show stack trace in notification" option disabled, each notification I get is already expanded and showing it anyway.

(YotaPhone 2 running 5.0)
30th December 2016, 04:49 PM |#26  
MrWasdennnoch's Avatar
OP Recognized Developer
Thanks Meter: 4,933
 
More
Quote:
Originally Posted by XlAfbk

I get a lot of stack traces from Google Play Music app at random intervals. These aren't really crashs or anything. Is it possible to ignore these / add a configurable ignore-filter?

I just added an option to blacklist apps, there you can blacklist GPM.

Quote:
Originally Posted by ~El Julio~

Despite having the "Show stack trace in notification" option disabled, each notification I get is already expanded and showing it anyway.

I can't reproduce this. Are you sure what you are seeing isn't just the description but the "real" stack trace?
The Following User Says Thank You to MrWasdennnoch For This Useful Post: [ View ]
30th December 2016, 05:02 PM |#27  
~El Julio~'s Avatar
Senior Member
Flag Paris
Thanks Meter: 46
 
Donate to Me
More
Quote:
Originally Posted by MrWasdennnoch

I can't reproduce this. Are you sure what you are seeing isn't just the description but the "real" stack trace?

Good question I wouldn't give a bad answer to.

All I can tell is that when opening it, I only see the same thing obviously longer (but not entirely though : there always seem to have more trace collected than displayed since it shows a non-clickable "...10 more" at the end).

And speaking of the description per se, I may not have yet seen one displayed anyway : It displays the same first information in the notification that good old cracker used to display too.

How should it look like ?
30th December 2016, 05:58 PM |#28  
MrWasdennnoch's Avatar
OP Recognized Developer
Thanks Meter: 4,933
 
More
Quote:
Originally Posted by ~El Julio~

Good question I wouldn't give a bad answer to.

All I can tell is that when opening it, I only see the same thing obviously longer (but not entirely though : there always seem to have more trace collected than displayed since it shows a non-clickable "...10 more" at the end).

And speaking of the description per se, I may not have yet seen one displayed anyway : It displays the same first information in the notification that good old cracker used to display too.

How should it look like ?

Looks fine to me.
The description of a typical crash starts with the type of crash (like "java.lang.NullPointerException") followed by an optional message (like "Attempted to invoke virtual method blablabla on a null object reference"). If you disable the stack trace preview that's what gets shown in the notification (same in Cracker). The same text is shown in the overview.
When you click on the notification (or a crash in the overview) you get to the detail view which displays the whole stack trace which includes the description at the beginning followed by the actual stack (like "at package.Class#method(Class.java:38)"). If you enable the stack trace preview you also see those "at..." in the notification.

I'll see if I can get it to display the whole stack trace without the "...12 more"
The Following 3 Users Say Thank You to MrWasdennnoch For This Useful Post: [ View ]
30th December 2016, 06:11 PM |#29  
~El Julio~'s Avatar
Senior Member
Flag Paris
Thanks Meter: 46
 
Donate to Me
More
Quote:
Originally Posted by MrWasdennnoch

Looks fine to me.
The description of a typical crash starts with the type of crash (like "java.lang.NullPointerException") followed by an optional message (like "Attempted to invoke virtual method blablabla on a null object reference"). If you disable the stack trace preview that's what gets shown in the notification (same in Cracker). The same text is shown in the overview.
When you click on the notification (or a crash in the overview) you get to the detail view which displays the whole stack trace which includes the description at the beginning followed by the actual stack (like "at package.Class#method(Class.java:38)"). If you enable the stack trace preview you also see those "at..." in the notification.

Well, then I guess disabling the stack trace preview doesn't act as expected because I get some of those first "at.." lines in the notifications.

I had first installed your previous build and enabled the option to see the difference with cracker. After seeing it, I didn't want to use the option so I disabled it. Rebooted once after that, still having the stack trace in notifications. Same after last update.

Description is always shown as expected though.

Quote:
Originally Posted by MrWasdennoch

I'll see if I can get it to display the whole stack trace without the "...12 more"

Great !
31st December 2016, 12:41 AM |#30  
MrWasdennnoch's Avatar
OP Recognized Developer
Thanks Meter: 4,933
 
More
Quote:
Originally Posted by ~El Julio~

Well, then I guess disabling the stack trace preview doesn't act as expected because I get some of those first "at.." lines in the notifications.

...Rebooted once after that, still having the stack trace in notifications. Same after last update.

I'll do some tests but afaik it works fine on my phone and in my emulators.

Edit: Does the module respect other settings such as completely disabling notifications? (you don't actually have to reboot for any setting)

Edit 2: I can't change and won't change the "... x more" because it indicates that the hidden part of the stack trace is the same as the previously shown trace. From the docs:
Quote:

Note the presence of lines containing the characters "...". These lines indicate that the remainder of the stack trace for this exception matches the indicated number of frames from the bottom of the stack trace of the exception that was caused by this exception (the "enclosing" exception).

This shorthand can greatly reduce the length of the output in the common case where a wrapped exception is thrown from same method as the "causative exception" is caught.

Also see here.
The Following 2 Users Say Thank You to MrWasdennnoch For This Useful Post: [ View ]
31st December 2016, 12:15 PM |#31  
~El Julio~'s Avatar
Senior Member
Flag Paris
Thanks Meter: 46
 
Donate to Me
More
Quote:
Originally Posted by MrWasdennnoch

I'll do some tests but afaik it works fine on my phone and in my emulators.

Edit: Does the module respect other settings such as completely disabling notifications? (you don't actually have to reboot for any setting)

Not showing the notification works fine. Still waiting for another crash to happen to know if not showing copy & share buttons in notification works, but showing these does work.
(Rebooting is useful for me because I can collect without doubt one crash happening each time it finished booting rather than waiting for a random crash of another app)
Search in package name works as expected. Combine same crashes too.
Don't know about the blacklisting, haven't used it yet.
Automatic line wrap up is ok despite the "... n more" thing talked about earlier.
Can't tell for the Ignore ThreadDeath Errors. I keep it active.

Edit: Not showing the copy & share buttons in notification does work.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes