Crash in [@ java.lang.Error: at com.sun.jna.Structure.getFields(Structure.java)]
Categories
(Firefox for Android :: General, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox143 | --- | unaffected |
firefox144 | --- | fixed |
firefox145 | --- | fixed |
People
(Reporter: RyanVM, Assigned: bdk)
References
Details
(Keywords: crash, topcrash, Whiteboard: [fxsync-])
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/3c19878f-1fa8-42d3-9c5a-f9f700250923
Top 10 frames:
0 com.sun.jna.Structure getFields Structure.java:212
1 com.sun.jna.Structure deriveLayout Structure.java:3
2 com.sun.jna.Structure calculateSize Structure.java:9
3 com.sun.jna.Structure allocateMemory Structure.java:2
4 com.sun.jna.Structure ensureAllocated Structure.java:3
5 com.sun.jna.Structure access$2300 Structure.java:1
6 com.sun.jna.Structure$FFIType <init> Structure.java:11
7 com.sun.jna.Structure$FFIType get Structure.java:23
8 com.sun.jna.Structure$FFIType get Structure.java:6
9 com.sun.jna.Structure getTypeInfo Structure.java:3
Reporter | ||
Comment 1•27 days ago
|
||
Related to the recent viaduct changes from last week?
Comment 2•27 days ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 AArch64 and ARM crashes on nightly
For more information, please visit BugBot documentation.
Comment 3•26 days ago
•
|
||
I've been seeing this with Reference Browser too and it's currently a perma-crash early enough that we can't report the crash.
Assignee | ||
Comment 4•26 days ago
|
||
I've taken a hard look at this one and the only thing I can come up with is "JNA is flakey".
The exception message is:
java.lang.Error: Structure.getFieldOrder() on class mozilla.appservices.viaduct.UniffiForeignFutureStructRustBuffer$UniffiByValue returns names ([callStatus, returnValue]) which do not match declared field names ([callStatus])
However, we definitely declare the returnValue
field in the generated code. Also, if we didn't declare a field then we should unconditionally crash rather than only crash sometimes. Here's the a snippet from the current main:
@Structure.FieldOrder("returnValue", "callStatus")
internal open class UniffiForeignFutureStructRustBuffer(
@JvmField internal var `returnValue`: RustBuffer.ByValue = RustBuffer.ByValue(),
@JvmField internal var `callStatus`: UniffiRustCallStatus.ByValue = UniffiRustCallStatus.ByValue(),
) : Structure() {
class UniffiByValue(
`returnValue`: RustBuffer.ByValue = RustBuffer.ByValue(),
`callStatus`: UniffiRustCallStatus.ByValue = UniffiRustCallStatus.ByValue(),
): UniffiForeignFutureStructRustBuffer(`returnValue`,`callStatus`,), Structure.ByValue
internal fun uniffiSetValue(other: UniffiForeignFutureStructRustBuffer) {
`returnValue` = other.`returnValue`
`callStatus` = other.`callStatus`
}
}
Crash stats shows a wide variety of android versions and devices, so I don't think we can chalk it up to some old/buggy Java version.
Long-term, I think we should move away from JNA + reflection to handle our FFI types. Maybe to JNI, maybe direct mapping or maybe something else.
Short term, we only have bad options as far as I can see:
- Backout the viaduct changes until we get a long-term fix. I'm pretty sure this would push back the OHTTP schedule significantly. Also it means we need to pull someone off of other work to check out JNI.
- Accept the crashes. The numbers seem high to me, but maybe acceptable? I'm not a good judge of this.
- Try to implement a hack/workaround. I think this requires figuring out a way to reliable reproduce the crash and I don't know how to do that.
Reporter | ||
Comment 5•26 days ago
|
||
This is topcrash-level volume. It would probably be high enough to drive an incident if it shipped to Release. Sadly, I think we need to do something proactive here.
Assignee | ||
Updated•26 days ago
|
Updated•26 days ago
|
Reporter | ||
Updated•24 days ago
|
Reporter | ||
Comment 6•18 days ago
|
||
Calling this fixed by the JNA update. No crashes all day when we were seeing very steady volume in previous builds. While we haven't seen these crashes on Beta, I'm going to backport the update there as well rather than shipping 144 with a known-buggy 5.17.0 release just to play it safe.
Reporter | ||
Updated•18 days ago
|
Comment 8•17 days ago
|
||
Copying crash signatures from duplicate bugs.
Reporter | ||
Updated•15 days ago
|
Description
•