Incomplete stacktrace

[LeoColman]

Apparently, when the stacktrace is too big it gets cut. I'm not sure if there's anything that we can do here in scoop, but maybe it's an easy fix.

Sample:

FATAL EXCEPTION: main
Process: br.com.colman.petals, PID: 25519
java.lang.RuntimeException: java.lang.NoSuchMethodException: B.J0.values []
	at java.lang.Enum.enumValues(Enum.java:272)
	at java.lang.Enum.-$$Nest$smenumValues(Unknown Source:0)
	at java.lang.Enum$1.create(Enum.java:279)
	at java.lang.Enum$1.create(Enum.java:277)
	at libcore.util.BasicLruCache.get(BasicLruCache.java:63)
	at java.lang.Enum.getSharedConstants(Enum.java:291)
	at java.lang.Enum.valueOf(Enum.java:245)
	at java.io.ObjectInputStream.readEnum(ObjectInputStream.java:1869)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1437)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
	at android.os.Parcel.readSerializableInternal(Parcel.java:5098)
	at android.os.Parcel.readValue(Parcel.java:4639)
	at android.os.Parcel.readValue(Parcel.java:4347)
	at android.os.Parcel.readListInternal(Parcel.java:5329)
	at android.os.Parcel.readArrayListInternal(Parcel.java:5348)
	at android.os.Parcel.readValue(Parcel.java:4597)
	at android.os.Parcel.readValue(Parcel.java:4347)
	at android.os.Parcel.-$$Nest$mreadValue(Unknown Source:0)
	at android.os.Parcel$LazyValue.apply(Parcel.java:4445)
	at android.os.Parcel$LazyValue.apply(Parcel.java:4404)
	at android.os.BaseBundle.getValueAt(BaseBundle.java:394)
	at android.os.BaseBundle.getValue(BaseBundle.java:374)
	at android.os.BaseBundle.getValue(BaseBundle.java:357)
	at android.os.BaseBundle.getValue(BaseBundle.java:350)
	at android.os.Bundle.getParcelableArrayList(Bundle.java:1046)
	at androidx.compose.ui.platform.a0.a(SourceFile:273)
	at androidx.compose.ui.platform.t1.a(SourceFile:36)
	at androidx.compose.ui.platform.t1.U(SourceFile:17)
	at M.f.U(SourceFile:59)
	at F.M.a(Unknown Source:29)
	at androidx.compose.ui.platform.t1.a(SourceFile:194)
	at androidx.compose.ui.platform.t1.U(SourceFile:29)
	at M.f.U(SourceFile:59)
	at F.y.p(SourceFile:64)
	at F.k1.c(SourceFile:41)
	at F.L.K(SourceFile:130)
	at F.L.C(Unknown Source:13)
	at F.S.m(SourceFile:18)
	at F.V0.a(SourceFile:50)
	at F.S.k(Unknown Source:10)
	at androidx.compose.ui.platform.Y.g0(SourceFile:124)
	at androidx.compose.ui.platform.AndroidComposeView.F0(Unknown Source:9)
	at androidx.compose.ui.platform.WrappedComposition.k(Unknown Source:13)
	at androidx.compose.ui.platform.WrappedComposition.e(Unknown Source:18)
	at androidx.lifecycle.w.a(SourceFile:23)
	at androidx.lifecycle.x.a(SourceFile:111)
	at androidx.compose.ui.platform.Y.g0(SourceFile:86)
	at androidx.compose.ui.platform.AndroidComposeView.onAttachedToWindow(SourceFile:114)
	at android.view.View.dispatchAttachedToWindow(View.java:21308)
	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3491)
	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3498)
	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3498)
	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3498)
	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3498)
	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2879)
	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2350)
	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9194)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1231)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239)
	at android.view.Choreographer.doCallbacks(Choreographer.java:899)
	at android.view.Choreographer.doFrame(Choreographer.java:832)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214)
	at android.os.Handler.handleCallback(Handler.java:942)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:201)
	at android.os.Looper.loop(Looper.java:288)
	at android.app.ActivityThread.main(ActivityThread.java:7884)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Caused by: java.lang.NoSuchMethodException: B.J0.values []
	at java.lang.Class.getMethod(Class.java:2103)
	at java.lang.Class.getDeclaredMethod(Class.java:2081)
	at java.lang.Enum.enumValues(Enum.java:269)
	... 69 more

Would it be possible to get the 69 more lines as well?

[drogga]

intentional maybe, IDK...
Either way, you can perhaps tag\mention Taco and lets hope that he will finally start caring about his own repo\projects (this one in particular), rather than other's and make the necessary changes sooner than later...

BTW, Scoop doesn't capture\catch exceptions, where some apps crash in such a way that the OS\System might show a dialog that the app "stopped", but it might not and Scoop doesn't catch \ capture anything in those cases, like nothing happened (and that's not because it's not "activated", active, running or perms. not being granted or something like that during the crash).

[TacoTheDank]

@drogga For the past many months I've had my hands full with work as well as college classes, and I'm trying to take care of myself too. I do care about this project, but I haven't exactly had the motivation to work on it for a while. Please mind your manners.

[LeoColman]

Adding to your comment, @TacoTheDank

There's always the option to fork and do whatever one wants

[TacoTheDank]

@LeoColman

Would it be possible to get the 69 more lines as well?

I don't think this would be possible. There is no code in Scoop that truncates stacktraces. This cut-off is the result of how stacktraces are generated by the system itself (if it is too long, the system cuts off additional lines). Apparently it is possible to show the full lines, but as far as I can tell, that's something that the other apps would need to implement themselves, and not something that is useful on Scoop's end.

[TacoTheDank]

@LeoColman I looked at this issue again, and I'd like to point out that this stacktrace wouldn't be of much use anyway because the code is obfuscated.

I would recommend adding a "-dontobfuscate" line to your proguard file like mine, so that you can debug your release builds more easily. As far as I remember, it doesn't really add much, if at all, to the app size.