Closed Bug 1990134 Opened 27 days ago Closed 18 days ago

Crash in [@ java.lang.Error: at com.sun.jna.Structure.getFields(Structure.java)]

Categories

(Firefox for Android :: General, defect)

Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
145 Branch
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
Flags: needinfo?(bdeankawamura)

Related to the recent viaduct changes from last week?

See Also: → 1989865

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.

Keywords: topcrash

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.

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.

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.

Flags: needinfo?(bdeankawamura)
Whiteboard: [fxsync-]
See Also: → 1990945
Depends on: 1991454
Depends on: 1991811
See Also: 1989865

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.

Assignee: nobody → bdeankawamura
Status: NEW → RESOLVED
Closed: 18 days ago
Resolution: --- → FIXED
Target Milestone: --- → 145 Branch
Duplicate of this bug: 1992149

Copying crash signatures from duplicate bugs.

Crash Signature: [@ java.lang.Error: at com.sun.jna.Structure.getFields(Structure.java)] → [@ java.lang.Error: at com.sun.jna.Structure.getFields(Structure.java)] [@ split_config.armeabi_v7a.apk]
No longer duplicate of this bug: 1992149
Crash Signature: [@ java.lang.Error: at com.sun.jna.Structure.getFields(Structure.java)] [@ split_config.armeabi_v7a.apk] → [@ java.lang.Error: at com.sun.jna.Structure.getFields(Structure.java)]
You need to log in before you can comment on or make changes to this bug.