When running a GeckoView-consuming application in a native debugger, a SIGSEGV is generated and then immediately trapped around https://searchfox.org/mozilla-central/rev/c9272ef398954288525e37196eada1e5a93d93bf/mozglue/linker/ElfLoader.cpp#1393. Unfortunately in a native debugger, this is pretty frustrating -- you need to manually continue through the SIGSEGV. snorp tells me that this can be avoided in some builds. Presumably, it is safe to skip the check in builds where DEVELOPER_OPTIONS is set. Since the check is a function of the device and Android OS, it shouldn't change much (really, at all) over time on a fixed device.

snorp: is my understanding of the situation here accurate? This would be a nice papercut to avoid.

Yup, sounds right. I was thinking we'd only do the check on official builds, but DEVELOPER_OPTIONS could be ok too.

Practically speaking, we don't care about the latency test anymore. The "SignalHandlingBroken" case is more interesting. It makes us disable the segfault handler entirely afterwards, which means if a device has SignalHandlingBroken *and* has a system library registering its own segfault handler, then we may actually have problems with the asmjs segfault handler on those devices. That said, I'm not sure we still actually benefit from registering our segfault handler at all. I'd need to do some archeology to see what exact kind of problem it worked around and whether they would apply to the asmjs segfault handler.