When running in debugger, freeze requires shut down with power button

[guoyiz23]

When I put breakpoints in certain places, this happens.

I have realized that in the above, there is locking of X server between xcb_grab_server and xcb_ungrab_server. However, even when I first breakpoint reached in the line right after xcb_ungrab_server, there is freeze. I am running a gdb process within VSCode.

Can someone explain what is causing this and/or suggest another way to use debugger?

[wengxt]

use log, not debugger.
or, debug via ssh.
or, avoid break in that code.

[wengxt]

No available usually means the addon library fails to load.

Are you compiling yourself?

[wengxt]

Also for debugging tips: https://fcitx-im.org/wiki/Debug_fcitx5#Start_Fcitx_within_a_nested_X_server

[guoyiz23]

No available usually means the addon library fails to load.

Are you compiling yourself?

Yes, with debug symbols in order to set breakpoints.

[wengxt]

Then you are likely not install to a consistent prefix and it can not locate the addon library.

[guoyiz23]

Then you are likely not install to a consistent prefix and it can not locate the addon library.

So pinyinhelper addon is not actually included in this code base. However, it is pointed to in the form of a .conf file.

After

env FCITX_ADDON_DIRS=/usr/lib/x86_64-linux-gnu/fcitx5/ /usr/bin/fcitx5

it works.

        addonDirs_ = defaultPaths("FCITX_ADDON_DIRS", FCITX_INSTALL_ADDONDIR,
                                  builtInPathMap, nullptr);

results in the execution of

    static std::vector<std::string> defaultPaths(
        const char *env, const char *defaultPath,
        const std::unordered_map<std::string, std::string> &builtInPathMap,
        const char *builtInPathType) {
        std::vector<std::string> dirs;

        std::optional<std::string> dir;
        if (env) {
            dir = getEnvironment(env);
        }
        if (!dir) {
            dir = defaultPath;
        }
        assert(dir.has_value());

        auto rawDirs = stringutils::split(*dir, ":");
        for (auto &rawDir : rawDirs) {
            rawDir = fs::cleanPath(rawDir);
        }
        std::unordered_set<std::string> uniqueDirs(rawDirs.begin(),
                                                   rawDirs.end());

        for (auto &s : rawDirs) {
            auto iter = uniqueDirs.find(s);
            if (iter != uniqueDirs.end()) {
                uniqueDirs.erase(iter);
                dirs.push_back(s);
            }
        }
        if (builtInPathType) {
            std::string builtInPath;
            if (const auto *value =
                    findValue(builtInPathMap, builtInPathType)) {
                builtInPath = *value;
            } else {
                builtInPath = StandardPath::fcitxPath(builtInPathType);
            }
            std::string path = fs::cleanPath(builtInPath);
            if (!path.empty() &&
                std::find(dirs.begin(), dirs.end(), path) == dirs.end()) {
                dirs.push_back(path);
            }
        }

        return dirs;
    }

Currently, in config.h, there is

#define FCITX_INSTALL_ADDONDIR "/usr/local/lib/fcitx5"

and though I have not actually checked, I would expect that this is generated by CMake based on install PREFIX. I presume that when I simply run /usr/bin/fcitx5, it still expects /usr/local/lib/fcitx5 as the location for searching .so files.

dpkg-query -L fcitx5

does not give any .h files for apt the installed package. So the questions are 1) how is the apt installation different? 2) thru what mechanism is my custom installation into /usr/local/ telling the apt installation to search /usr/local/lib/fcitx5 for the shared libraries.

Though I can probably figure it out eventually myself, maybe you can also explain what is going here that might be less obvious to a person still not especially familiar with this ecosystem. I had tried to use strace, but it actually results in freezing to the point of having to shut down with power button.