This is for the Fcitx 5 based full cloud pinyin. When I type too fast, it crashes. The stack trace is:
Fcitx 5.0.19 -- Get Signal No.: 11
Date: try "date -d @1666271367" if you are using GNU date ***
ProcessID: 7764
fcitx5(+0x12d9c)[0x55a39f4c4d9c]
/usr/lib/libc.so.6(+0x38a00)[0x7ff5a297aa00]
/usr/lib/libFcitx5Core.so.7(_ZN5fcitx20UserInterfaceManager5flushEv+0x7e)[0x7ff5a2f0f2be]
/usr/lib/libFcitx5Core.so.7(_ZNK5fcitx8Instance9postEventERNS_5EventE+0x3c8)[0x7ff5a2ebd578]
/usr/lib/libFcitx5Core.so.7(_ZN5fcitx12InputContext8keyEventERNS_8KeyEventE+0xa6)[0x7ff5a2edfbb6]
/usr/lib/fcitx5/libdbusfrontend.so(+0x12cca)[0x7ff5a1338cca]
/usr/lib/fcitx5/libdbusfrontend.so(+0x133d4)[0x7ff5a13393d4]
/usr/lib/libFcitx5Utils.so.2(+0x3e2ea)[0x7ff5a2dfe2ea]
/usr/lib/libsystemd.so.0(+0x36d6d)[0x7ff5a284bd6d]
/usr/lib/libsystemd.so.0(+0x460b3)[0x7ff5a285b0b3]
/usr/lib/libsystemd.so.0(+0x4dfe8)[0x7ff5a2862fe8]
/usr/lib/libsystemd.so.0(+0x799ab)[0x7ff5a288e9ab]
/usr/lib/libsystemd.so.0(sd_event_dispatch+0x116)[0x7ff5a2898ff6]
/usr/lib/libsystemd.so.0(sd_event_run+0x119)[0x7ff5a2899279]
/usr/lib/libsystemd.so.0(sd_event_loop+0x60)[0x7ff5a2899450]
/usr/lib/libFcitx5Utils.so.2(_ZN5fcitx9EventLoop4execEv+0x16)[0x7ff5a2dfceb6]
/usr/lib/libFcitx5Core.so.7(_ZN5fcitx8Instance4execEv+0x57)[0x7ff5a2ec00e7]
fcitx5(+0x10fa0)[0x55a39f4c2fa0]
/usr/lib/libc.so.6(+0x23290)[0x7ff5a2965290]
/usr/lib/libc.so.6(__libc_start_main+0x8a)[0x7ff5a296534a]
fcitx5(+0x12375)[0x55a39f4c4375]
fish: Job 1, 'fcitx5' terminated by signal SIGSEGV (Address boundary error)
I couldn't figure out why. So I asked the author of Fcitx 5. He helped me (really appreciate!) and here his analysis:
We don't need to use immediate when calling InputContext::updateUserInterface (I did so to solve the candidate not updated to latest issue)
We shouldn't not call any functions from fcitx instance.
call_async here is just multi-threading (can be seen from stacktrace below).
==146789== by 0x4DE62F2: execute_native_thread_routine (thread.cc:82)
==146789== by 0x50D58FC: start_thread (pthread_create.c:442)
==146789== by 0x5156C73: clone (clone.S:100)
Also, from https://en.cppreference.com/w/cpp/thread/async,
The function template async runs the function f asynchronously (potentially in a separate thread which might be a part of a thread pool) and returns a std::future that will eventually hold the result of that function call.
This is for the Fcitx 5 based full cloud pinyin. When I type too fast, it crashes. The stack trace is:
I couldn't figure out why. So I asked the author of Fcitx 5. He helped me (really appreciate!) and here his analysis:
immediatewhen callingInputContext::updateUserInterface(I did so to solve the candidate not updated to latest issue)call_asynchere is just multi-threading (can be seen from stacktrace below).If we need to call anything on fictx instance, call it on the main thread using: https://codedocs.xyz/fcitx/fcitx5/classfcitx_1_1EventDispatcher.html
Also, from https://en.cppreference.com/w/cpp/thread/async, The function template async runs the function f asynchronously (potentially in a separate thread which might be a part of a thread pool) and returns a std::future that will eventually hold the result of that function call.