In general, the getFields logic is protected by a read-write locks to prevent threading issues. However, sortFields() seems to be called without any locking which can lead to multiple threads mutating the field list at once -- specifically when it calls Collections.swap().
I'm pretty sure we're running into this issue in the wild with Firefox Android. We've been getting a crash with the following message:
java.lang.Error: Structure.getFieldOrder() on class mozilla.appservices.viaduct.UniffiForeignFutureStructRustBuffer$UniffiByValue returns names ([callStatus, returnValue]) which do not match declared field names ([callStatus])
Note that this is the second error case in getFields, which means that the check that the field list sizes were equal passed. However the second check failed. Now that we're using the names hash set rather than the flist list, the sizes are no longer equal.
I believe this was caused at some point in the past when 2 threads called Collections.swap() at the same time, causing the field list to have a duplicate item ([callStatus, callStatus] in our case).
In general, the
getFieldslogic is protected by a read-write locks to prevent threading issues. However, sortFields() seems to be called without any locking which can lead to multiple threads mutating the field list at once -- specifically when it callsCollections.swap().I'm pretty sure we're running into this issue in the wild with Firefox Android. We've been getting a crash with the following message:
Note that this is the second error case in
getFields, which means that the check that the field list sizes were equal passed. However the second check failed. Now that we're using thenameshash set rather than theflistlist, the sizes are no longer equal.I believe this was caused at some point in the past when 2 threads called
Collections.swap()at the same time, causing the field list to have a duplicate item ([callStatus, callStatus]in our case).