Crash in ChannelListFragment

Sendbird Chat API/SDK Android
,
#1

Hi!

I use the latest version of UIKit (com.sendbird.sdk:uikit:2.2.3), and I have crash in production when user switches between ChannelListFragment and other fragment a bit fast than regular user.

This the log of the crash:

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: health.alike.app, PID: 11531
    java.lang.NullPointerException: Attempt to invoke interface method 'void com.sendbird.android.handlers.GroupChannelCollectionHandler.onChannelsUpdated(com.sendbird.android.handlers.GroupChannelContext, java.util.List)' on a null object reference
        at com.sendbird.android.GroupChannelCollection$7.run(GroupChannelCollection.java:542)
        at android.os.Handler.handleCallback(Handler.java:938)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:223)
        at android.app.ActivityThread.main(ActivityThread.java:7656)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

Likely it happens inside ChannelListViewModel.

Also, I noticed that when a user switches between fragments a bit faster initChannelCollection() and disposeChannelCollection() don’t go one after another as they supposed to. Hence, I think that’s why crash appears:

D/SBUIKIT: [19:21:11.812 ChannelListViewModel:initChannelCollection():36] >> ChannelListViewModel::initChannelCollection()
D/SBUIKIT: [19:21:11.959 ChannelListViewModel:initChannelCollection():36] >> ChannelListViewModel::initChannelCollection()
D/SBUIKIT: [19:21:12.292 ChannelListViewModel:disposeChannelCollection():45] >> ChannelListViewModel::disposeChannelCollection()
D/SBUIKIT: [19:21:12.745 ChannelListViewModel:disposeChannelCollection():45] >> ChannelListViewModel::disposeChannelCollection()

Normal call stack is supposed to look like this:

D/SBUIKIT: [19:32:46.707 ChannelListViewModel:initChannelCollection():36] >> ChannelListViewModel::initChannelCollection()
D/SBUIKIT: [19:32:48.123 ChannelListViewModel:disposeChannelCollection():45] >> ChannelListViewModel::disposeChannelCollection()
D/SBUIKIT: [19:32:49.775 ChannelListViewModel:initChannelCollection():36] >> ChannelListViewModel::initChannelCollection()
D/SBUIKIT: [19:32:50.848 ChannelListViewModel:disposeChannelCollection():45] >> ChannelListViewModel::disposeChannelCollection()
#2

@Vladislav_Karpman thanks for the reporting! I will let our android team to know and get back to you soon

1 Like
#3

@Woo It’s a pretty much important since we’re having crash in production.
Hopefully, soon you will find a solution

#4

@Vladislav_Karpman Thank you for reporting!.

  • NPE problem has been fixed, and it will be released next regular release.

And regarding the problem of order, there are two cases where A is disposed.

  • If an existing collection exists when trying to retrieve a channel list through the loadInitial, previous collection will dispose
  • If the View Model is clear, it is disposed.
    So please check if loadInitial is being called twice in a row.
1 Like
#5

@LeoShin Thanks!
Hopefully the issue is resolved.

Regarding your comment:
loadInitial() is private method and is under UIKit control, so you have to make sure that order is correct.

#6

loadInitial, which I mentioned above, is a method of the ChannelListViewModel, which is a public method.
Since the initChannelCollection from the log is called only when loadInitial is called, I was wondering when loadInitial is called.
How can I reproduce what’s shown in the log?

#7

I have 2 fragments:
One is just regular fragment from our app and another one is ChannelListFragment.

If I start switching between these 2 fragments pretty fast, I will get error pretty soon.

#8

We will include this in the regular release. The regular release will be around mid-February.

#9

Thanks, hopefully it will be fixed

#10

We have released v2.2.4 uikit that fixed this issue today. please check it out. hopefully, it will have been fixed.

1 Like