[Xposed Framework Modules] Roughy:
Logcat would contain more useful information, but going by the symptoms there is a fair chance are you encountering this issue.

The relevant logcat message:

time: 1549376649918
msg: Native crash: Segmentation fault
stacktrace: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'xiaomi/mido/mido:7.0/NRD90M/V8.5.4.0.NCFMIED:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 10630, tid: 10641, name: HeapTaskDaemon >>> <pre-initialized> <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x13240000
x0 0000000013a40008 x1 000000001323ffb8 x2 000000001341508c x3 0000000013f2e740
x4 0000000026655094 x5 000000002734381c x6 0000000000000000 x7 0000000000000000
x8 0000000000000000 x9 0000000000000000 x10 0000000000000000 x11 0000000000000000
x12 0000000000000000 x13 0000000000000000 x14 000000000000051e x15 0000000000000000
x16 00000074cafe2140 x17 000000754dfddbf0 x18 0000000000000008 x19 00000074cb390000
x20 0000000013a40000 x21 0000000012d51878 x22 0000000013940000 x23 000000001390381c
x24 0000000013940000 x25 00000074cb2677c0 x26 0000000013904ae8 x27 0000000000000000
x28 000000749b844588 x29 000000749b843a30
sp 000000749b843980 lr 00000074cab6d94c pc 000000754dfddd1c

backtrace:
#00 pc 000000000001dd1c /system/lib64/libc.so (memcpy+300)
#01 pc 00000000001ca948 /system/lib64/libart.so (art::gc::collector::ConcurrentCopying::Copy(art::mirror::eek:bject*, art::mirror::eek:bject*, art::MemberOffset)+280)
#02 pc 00000000001cf98c /system/lib64/libart.so (void art::gc::collector::ConcurrentCopying::MarkRoot<false>(art::mirror::CompressedReference<art::gc::collector::ConcurrentCopying::MarkRoot<false>::eek:bject>*)+180)
#03 pc 00000000001cf2d0 /system/lib64/libart.so (_ZN3art6mirror6Object15VisitReferencesILb1ELNS_17VerifyObjectFlagsE0ELNS_17ReadBarrierOptionE1ENS_2gc9collector17ConcurrentCopying16RefFieldsVisitorES8_EEvRKT2_RKT3_+2472)
#04 pc 00000000001c65a0 /system/lib64/libart.so (art::gc::collector::ConcurrentCopying::ProcessMarkStackRef(art::mirror::eek:bject*)+200)
#05 pc 00000000001c5f3c /system/lib64/libart.so (art::gc::collector::ConcurrentCopying::ProcessMarkStackOnce()+1020)
#06 pc 00000000001c5b24 /system/lib64/libart.so (art::gc::collector::ConcurrentCopying::ProcessMarkStack()+28)
#07 pc 00000000001bef14 /system/lib64/libart.so (art::gc::collector::ConcurrentCopying::MarkingPhase()+1748)
#08 pc 00000000001bd304 /system/lib64/libart.so (art::gc::collector::ConcurrentCopying::RunPhases()+1188)
#09 pc 00000000001d38e4 /system/lib64/libart.so (art::gc::collector::GarbageCollector::Run(art::gc::GcCause, bool)+316)
#10 pc 00000000001f6814 /system/lib64/libart.so (art::gc::Heap::CollectGarbageInternal(art::gc::collector::GcType, art::gc::GcCause, bool)+3428)
#11 pc 0000000000208140 /system/lib64/libart.so (art::gc::Heap::ConcurrentGC(art::Thread*, art::gc::GcCause, bool)+128)
#12 pc 000000000020d890 /system/lib64/libart.so (art::gc::Heap::ConcurrentGCTask::Run(art::Thread*)+40)
#13 pc 0000000000230064 /system/lib64/libart.so (art::gc::TaskProcessor::RunAllTasks(art::Thread*)+68)
#14 pc 000000000007856c /system/framework/arm64/boot-core-libart.oat (offset 0x76000)

I only installed EdXposed to debug one specific issue and am not using it as my daily driver, but I did encounter this same problem once. Swiftkey would repeatedly crash with the same stacktrace as above, but eventually sorted itself out (possibly after another reboot). I was messing with debug builds at the time which may have angered it.

For both me and the quoted user this was a one-time or intermittent issue. Since it appears to be a bit more severe for you it may be a different issue. You should confirm this by checking your logcat.

Having said that, there isn't really anything I can do about this particular issue, as it's running into an problem... way outside of this module's territory.

Going by the message it is likely a concurrency issue, though it evidently only affects some users, and it happens outside of javaland. This doesn't necessarily mean that it has anything to do with /us/ doing anything concurrently, since it's the garbage collector rather than us, but we do fire off a bunch of concurrent actions when the keyboard is opened to load settings and such. Running all that stuff on the main thread might be something to try, if it does indeed turn out to be the same issue.

If I could reliably reproduce it I might be able figure out exactly what is triggering it and try to do things different to work around the issue, but for better

or worse it was a one-time issue for me.

So before anything, a dump of the logcat with whatever is being printed there when it crashes.

Following that, if you are running an older version of EdXposed or Riru Core you'll probably want to try updating them first, but failing that your best bet is hitting up the EdXposed dev, and depending on their response maybe also the Riru dev.