Created attachment 2031006 [details]
File: proc_pid_status

Created attachment 2031007 [details]
File: maps

Created attachment 2031008 [details]
File: limits

Created attachment 2031009 [details]
File: environ

Created attachment 2031010 [details]
File: open_fds

Created attachment 2031011 [details]
File: mountinfo

Created attachment 2031012 [details]
File: os_info

Created attachment 2031013 [details]
File: cpuinfo

Created attachment 2031014 [details]
File: core_backtrace

Created attachment 2031015 [details]
File: dso_list

Created attachment 2031016 [details]
File: var_log_messages

Created attachment 2031017 [details]
File: backtrace

I think your /home/zdalny/.cache/ibus has wrong permission but it was not generated by the current ibus.
If you move or delete the directory, I think the problem won't happen.

(In reply to S.J. from comment #12)
> Created attachment 2031017 [details]
> File: backtrace

#0  g_log_structured_array (log_level=<optimized out>, fields=0x7ffef11069b0, n_fields=4) at ../glib/gmessages.c:426
#1  0x00007f11f6c61377 in g_log_default_handler (log_domain=log_domain@entry=0x561abb83002c "IBUS", log_level=log_level@entry=6, message=message@entry=0x561abcec3aa0 "mkdir is failed in: /home/zdalny/.cache/ibus: Brak dost\304\231pu", unused_data=unused_data@entry=0x0) at ../glib/gmessages.c:3357
#2  0x00007f11f6c58249 in g_logv (log_domain=0x561abb83002c "IBUS", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=args@entry=0x7ffef1106b10) at ../glib/gmessages.c:1246
        msg_alloc = 0x561abcec3aa0 "mkdir is failed in: /home/zdalny/.cache/ibus: Brak dost\304\231pu"
        msg = 0x561abcec3aa0 "mkdir is failed in: /home/zdalny/.cache/ibus: Brak dost\304\231pu"
#3  0x00007f11f6c585b3 in g_log (log_domain=log_domain@entry=0x561abb83002c "IBUS", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x561abb83157c "mkdir is failed in: %s: %s") at ../glib/gmessages.c:1315
#4  0x0000561abb816d2c in bus_server_init () at /usr/src/debug/ibus-1.5.30~rc3-1.fc40.x86_64/bus/server.c:295
        socket_address = 0x561abced36c0 "unix:tmpdir=/home/zdalny/.cache/ibus"

"(...) mkdir is failed in: /home/zdalny/.cache/ibus: Brak dost\304\231pu", unused_data=unused_data@entry=0x0) at ../glib/gmessages.c:3357 (...)"

There is also a problem with what was supposed to point to the "/home/remote" directory when it did not exist at all and was not previously marked anywhere and in any configuration of any program - this is definitely puzzling... the mentioned path has simply never existed in system .

(In reply to S.J. from comment #14)
> There is also a problem with what was supposed to point to the
> "/home/remote" directory when it did not exist at all and was not previously
> marked anywhere and in any configuration of any program - this is definitely
> puzzling... the mentioned path has simply never existed in system .

If "/home/remote" does not exist, probably your $HOME is not valid.

ibus-daemon tries:
1. $XDG_CACHE_HOME/ibus if XDG_CACHE_HOME environment variable is available.
2. $HOME/.cache/ibus if HOME environment variable is available.
3. <HOME>/.cache/ibus <HOME> is pulled from /etc/passwd.

"/home/zdalny/" (Polish translate from backtrace) or "/home/remote" never existed with any Fedora or other Linux installation - maybe I don't understand what's going on.
There is only a directory "/home/$SAMPLE_USER/.cache/ibus"

You should have the home direcotry otherwise ibus continue to cause the SEGV.

I will write this clearly once again - my home directory is "/home/slawek" - I do not have and never have had a "/home/remote" directory.
Neither on a physical computer nor on a virtual computer.
It seemed to me that the bug reporting system works automatically since it is turned on and I can't even control what it sends to https://bugzilla.redhat.com.
There is clearly a problem since my agent reports such an event to the server.

I already explained your configuration was bad.
See https://bugzilla.redhat.com/show_bug.cgi?id=2278828#add_comment how to resolve your issue.

The correct suggestion:
https://bugzilla.redhat.com/show_bug.cgi?id=2278828#c15

Sorry, but due to your complete lack of understanding of the problem, this time I will refer you to my suggestion https://bugzilla.redhat.com/show_bug.cgi?id=2278828#c18.
I doubt that my sarcasm will change anything, but other users of this system also read it - I'll call it a pure example of your incompetence and disregard for me personally and for the programming problem, which should not happen in the bug reporting system.
Thx :)

(In reply to S.J. from comment #21)
> Sorry, but due to your complete lack of understanding of the problem, this
> time I will refer you to my suggestion
> https://bugzilla.redhat.com/show_bug.cgi?id=2278828#c18.
> I doubt that my sarcasm will change anything, but other users of this system
> also read it - I'll call it a pure example of your incompetence and
> disregard for me personally and for the programming problem, which should
> not happen in the bug reporting system.
> Thx :)

Hi S.J.

I happen to read your message and I think it is unnecessary harsh.

We can only try to guess the problem you reported from the data we have on the file.

In the environ file attached in https://bugzilla.redhat.com/show_bug.cgi?id=2278828#c4
There is clearly a user `zdalny` whose user id is `1001`

    LOGNAME=zdalny
    HOME=/home/zdalny
    USERNAME=zdalny
    USER=zdalny
    MAIL=/var/spool/mail/zdalny
    SSH_AUTH_SOCK=/run/user/1001/keyring/ssh
    XAUTHORITY=/run/user/1001/.mutter-Xwaylandauth.2RK3M2
    XDG_RUNTIME_DIR=/run/user/1001
    DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus

From the mountinfo in https://bugzilla.redhat.com/show_bug.cgi?id=2278828#c6
There is also a user id `1000`, which I believe is your user id.

Maybe you can try to run `id 1001` to find out who is this mysterious user.

For example this is the output from my system:

    $ id 1000
    uid=1000(kanru) gid=1000(kanru) groups=1000(kanru),10(wheel)

Unfortunately, I will not get this information anymore - in the meantime I created the user "MSI" (a long time after the error/problem was reported).
At the moment, the situation is as follows:

slawek@maszyna:~$ id 1000
uid=1000(slawek) gid=1000(slawek) grupy=1000(slawek),10(wheel),971(vboxusers)
slawek@maszyna:~$ id 1001
uid=1001(msi) gid=1001(msi) grupy=1001(msi)

Generally, if the "/home/zdalny" user existed, the newly created user "msi" would obtain Id 1002.
The matter is even more strange.I don't think it's possible to get any more relevant information at the moment.
I manually delete the contents of /var/log from time to time.

Thank you, however, for trying to help explain the problem. The conclusion is that someone may have tried to do something remotely in my system - just in case, I will reinstall Fedora 40 after resetting the disk in some known and simple way, e.g.

dd if=/dev/zero of=/dev/sdX

Did you reproduce the issue recently?

As expected, of course, this error no longer appeared... cleaning the disk and reinstalling the entire system with add-ons did the trick.

Then you had a bad configuration.
Please reopen when you reproduce the issue again.