Skip to content

Commit

Permalink
[android] crash fix on array out of bounds.
Browse files Browse the repository at this point in the history
  • Loading branch information
@gubatron
gubatron committed Feb 17, 2016
1 parent 4c670ec commit 15fcb77
Showing 1 changed file with 20 additions and 8 deletions.
28 changes: 20 additions & 8 deletions android/apollo/src/com/andrew/apollo/utils/MusicUtils.java
View file
Original file line number Diff line number Diff line change
Expand Up @@ -42,12 +42,10 @@
import com.frostwire.android.R;
import com.frostwire.android.gui.util.UIUtils;
import com.frostwire.logging.Logger;
import org.apache.commons.lang3.ArrayUtils;

import java.io.File;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.WeakHashMap;
import java.util.*;


/**
Expand Down Expand Up @@ -1541,12 +1539,26 @@ private static long[] getSongListForAdapter(final ArrayAdapter<Song> adapter) {
if (adapter == null) {
return sEmptyList;
}
long[] list;

int count = adapter.getCount() - (adapter.getViewTypeCount() > 1 ? 1 : 0);
list = new long[count];
List<Long> songList = new LinkedList<>();
for (int i = 0; i < count; i++) {
list[i] = adapter.getItem(i).mSongId;
try {
long songId = adapter.getItem(i).mSongId;
songList.add(songId);
} catch (Throwable ignored) {
// possible array out of bounds on adapter.getItem(i)
}
}
return list;

if (songList.size() == 0) {
return sEmptyList;
}

// until Java supports primitive types as generics, we'll live with this double copy. O(2n)
Long[] list = new Long[songList.size()];
long[] result = ArrayUtils.toPrimitive(songList.toArray(list));
songList.clear();
return result;
}
}

3 comments on commit 15fcb77

@aldenml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for this problem, that's it, and I left this class there just in case.

@aldenml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I know this is the alternate branch, but I rather understand the problem to fix it accordingly. It seems to my that the reason is that ProfileSongAdapter.VIEW_TYPE_COUNT is 3 and then one needs to subtract 2 to the count instead of 1. If that's the case, we should be able to replicate it.

@gubatron
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, I'm also starting to believe that this is the real cause of the issue (not the adapter being altered on a parallel thread), I was thinking about it in the supermarket, but because of something that started manifesting later with the player. On my branch, now by (bad) luck I'm able to replicate a bug that I sometimes see in the master branch.

Use the music player, and slide the music progress bar all the way to the right. On the main branch, most of the times the player will continue playing the next song, but sometimes, the next song doesn't start.

On this branch, now it won't play further, my guess is that it has to do with a similar issue as this one, with the faux element at 0.

I'll give it a try on this part of the code and see. Going back to this specific fix, perhaps I should just always subtract ProfileSongAdapter.VIEW_TYPE_COUNT - 1

Please sign in to comment.