hello, Aaron!

how can I help you today?

hey Mark, mainly just one thing today. getting ready to publish, but I ran into a showstopper. I was profiling my app's performance and I discovered that I am leaking an instance of my activity on every config change, and I cannot figure out why. I've looked at your book's list of common scenarios (and others online) and I don't think, at least, that I am doing any of those things. It would be helpful to hear more about what approach I might take to drill down on this

first, how did you determine that you are leaking the activity? second, have you tried LeakCanary (assuming that it's not the answer to my first question)?

LeakCanary gives me a message that I am leaking a Toast, which upon further research, seems to usually mean leaking an activity, not actually leaking a toast. And, in the heap analyzer, the allocation count for MainActivity increases by 1 on each config change. The total RAM usage also appears to grow over time

are you holding onto an actual Toast object somewhere?

no

could you maybe take a screenshot of the LeakCanary stack trace that it shows you in its UI, and post that here?

I show Toasts for a couple types of error message but I'm just doing it normally (AFAIK)

yup, one moment

FWIW, you seem to be using Toast for error messages -- that's not a great use of a Toast, since they are short-lived

better to use a message that has to be explicitly dismissed?

yes, so the user doesn't accidentally miss it and wonder what's going on with the app

OK

makes sense

Toasts are fine for advisory stuff that if the user does not see is not really a problem

that being said, it's not obvious to me how you would be leaking a Toast, either

here are the screenshots, and I noticed something I didn't notice previously - LeakCanary is actually NOT giving me this message on a rotation, it's giving it to me when I navigate to a fragment and then back. But, the heap analyzer does indicate that the number of activities grows by 1 on each rotation. I don't know what to make of that

it's actually saying that you are leaking a SwipeRefreshLayout

when you caused the leak that resulted in these screenshots, did you show a Toast?

ah, I was looking at the Toast, as the LeakCanary instructions say that the red underlined references are the possible causes of the leak

nope

that's what LeakCanary is saying caused the leak, but the actual leaked thing is what's at the bottom

the arrows are showing the chain of references from the cause of the leak (the mNextView in Toast) to the thing that was leaked (the SwipRefreshLayout)

ah, I see

next question: are you testing this on a device or emulator when you get this leak?

same result on both

OK, that's interesting

sometimes, LeakCanary reports leaks that are actually caused by device manufacturer screwups

in this case, that's not the problem, if the standard Android SDK emulator is also resulting in the leak

other than your database, do you have any static fields?

I don't think so, no, just constants

I have one mostly unfounded/uneducated hypothesis that Dagger could have something to do with it, as I do not understand its inner workings very well, and it's one of the few classes that holds a reference to the activity

possibly, but Toast being blamed is a bit odd

also, I don't see Dagger anywhere in that list

according to https://github.com/square/leakcanary/issues/844..., it is possible in this case that anything in the leak trace might be the real cause

yeah, I guess I don't know what to make of that though. I mean, all the objects in that stack trace are from fragments that are hosted by the activity, so when the activity is destroyed and recreated, all of those should be too (right?) so I don't see how that could result in a leak

you can attempt to use the heap analyzer in Android Studio to determine the source of the leak, and see if it gives you something better to work with

"it's giving it to me when I navigate to a fragment and then back" -- is the fragment that you navigated to PostsFragment?

so far I've only used the heap analyzer to look at the number of objects - how do I go beyond that to try to discover the cause? I double checked your memory leaks chapter but I didn't seem to see any further instructions on how to drill down

PostsFragment to PostFragment and then back

i.e., the list of posts, to a post, and back to the list

oh, that's a lie

going BACK is not required

it occurs when PostsFragment kicks off PostFragment

it's been a while since I used the heap analyzer, but in the place where you are seeing the counts of activities, IIRC, there was an arrow to click to fold open a list of what references it

ah yes, I see it

got it

the references tab is what I'm thinking of

if in the instance view you select the activities, you should see what holds onto them

it's gonna be somewhat cryptic

yeah...

I'll throw up a screenshot real quick, maybe you can give me some pointers on interepreting it, and BTW I really am trying to use this as an opportunity to learn a general method I can apply in the future, not just trying to get handholding on this particular bug, hope it doesn't seem like that

sorry, that's what the activity is referencing, not what is referencing the activity

BTW, what version of Android Studio are you using?

3.2.1, should be the latest I believe

latest stable, yes

there should be another pane in your output that has some tabs, one of which is "References"

oops, sorry

not the "References" section on the bototm there?

that's the bottom half of your screenshot

yeah, sorry, I didn't catch the switch

np

there are a lot more references, based on that scrollbar

yeah I'm trying to see how I can export everything, but not sure there is a way

probably there isn't

one sec

look for signs of third-party libraries -- for example, in the screenshot, I see Glide mentioned

in your Instances list, there are two activity instances listed? does the other one have a shorter list of references?

there are 3 as I did two config changes before dumping the heap, and yes, the other two have shorter lists

not THAT much shorter

OK, the one that you did the screenshots for may be the "real" one, with the other two being the leaked ones

overall, for the short term, I wouldn't worry tons about this

in the medium term, though, it's very possible that you're going to need to debug this the old-fashioned way: comment out a bunch of stuff, and see if the leak persists or goes away

if it goes away, the problem is most likely tied into what you commented out, and you can try to narrow things down that way

really? leaking the entire activity seems like a fairly severe bug

yup, OK

it's not great

on the other hand, it does not cause an immediate problem for the user

it's not like your app is crashing outright

OK I see

the bugs that gotta gotta gotta get fixed are the ones that directly and immediately harm users

leaks can harm users over time, due to running out of heap space

and so that's why we try to fix them

yeah, I mean that's a reasonable way to look at it, alright perhaps I'll go ahead and publish and try to sort this out later

if you want to fix this before shipping, that's certainly cool, but if you wanted to ship and then fix this in a patch release, that's also reasonable IMHO

alright, thanks, let me not keep you past the hour, but thanks again, extremely helpful as always

sorry I didn't have a complete solution for you

memory leaks are a major pain

anyway, that's a wrap for the chat

next one is Tuesday at 7:30pm US Eastern

have a pleasant day!

no worries, I mean, it's just very helpful to see how you approach it, as well as what you DON'T have to offer, cause that also informs me that no obvious solution exists

thanks, you too!