| 2023-05-16 03:06:04 |
Yao Wei |
bug |
|
|
added bug |
| 2023-05-16 03:07:03 |
Yao Wei |
bug |
|
|
added subscriber OEM Solutions Group: Engineers |
| 2023-05-16 03:07:11 |
Yao Wei |
tags |
|
oem-priority originate-from-2017628 somerville |
|
| 2023-05-16 03:07:15 |
Yao Wei |
bug watch added |
|
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6698 |
|
| 2023-05-16 03:07:15 |
Yao Wei |
bug task added |
|
gnome-shell |
|
| 2023-05-16 11:42:31 |
Bug Watch Updater |
gnome-shell: status |
Unknown |
New |
|
| 2024-05-01 00:00:28 |
Marco Trevisan (Treviño) |
gnome-shell (Ubuntu): importance |
Undecided |
Medium |
|
| 2024-05-01 00:00:31 |
Marco Trevisan (Treviño) |
gnome-shell (Ubuntu): assignee |
|
Marco Trevisan (Treviño) (3v1n0) |
|
| 2024-05-01 00:00:35 |
Marco Trevisan (Treviño) |
gnome-shell (Ubuntu): status |
New |
In Progress |
|
| 2024-05-03 17:02:14 |
Marco Trevisan (Treviño) |
gnome-shell (Ubuntu): status |
In Progress |
Confirmed |
|
| 2024-05-03 17:02:18 |
Marco Trevisan (Treviño) |
gnome-shell (Ubuntu): status |
Confirmed |
In Progress |
|
| 2024-05-03 17:02:43 |
Marco Trevisan (Treviño) |
nominated for series |
|
Ubuntu Noble |
|
| 2024-05-03 17:02:43 |
Marco Trevisan (Treviño) |
bug task added |
|
gnome-shell (Ubuntu Noble) |
|
| 2024-05-25 13:52:26 |
Bug Watch Updater |
gnome-shell: status |
New |
Fix Released |
|
| 2024-05-27 06:19:57 |
Daniel van Vugt |
tags |
oem-priority originate-from-2017628 somerville |
fixed-in-gnome-shell-47 fixed-upstream oem-priority originate-from-2017628 somerville |
|
| 2024-05-27 06:20:15 |
Daniel van Vugt |
tags |
fixed-in-gnome-shell-47 fixed-upstream oem-priority originate-from-2017628 somerville |
fixed-in-gnome-shell-46.2 fixed-upstream oem-priority originate-from-2017628 somerville |
|
| 2024-06-14 04:56:22 |
Marco Trevisan (Treviño) |
description |
If gnome-shell is launched directly instead of launched through gnome-session, the process spawning `ibus-daemon` might cause deadlock and unable to start the graphics.
Since `ibusManager.js` checks whether service `org.freedesktop.IBus.session.GNOME.service` exists. In our case with Ubuntu ubiquity, we've turned off `gnome-session.service` so that the check failed and gnome-shell spawns `ibus-daemon` after the check.
I tried using gdb to gnome-shell and discovered it's hanging in a child process spawning `ibus-daemon`, but is still in child_setup of `Glib.spawn_async` function:
```
root@dell-desktop:/home/oem# cat /tmp/log
== Stack trace for context 0x5584da793180 ==
#0 5584dbd2d478 i resource:///org/gnome/shell/misc/ibusManager.js:119 (2776aa47bfb0 @ 12)
#1 5584dbd2d3a8 i resource:///org/gnome/shell/misc/ibusManager.js:114 (2776aa47bf60 @ 426)
#2 5584dbd2d308 i resource:///org/gnome/shell/misc/ibusManager.js:90 (2776aa47bec0 @ 162)
#3 5584dbd2d268 i self-hosted:689 (34e3dc212650 @ 15)
```
which is, in ibusManager.js:
```
const [success_, pid] = GLib.spawn_async(
null, cmdLine, env,
GLib.SpawnFlags.SEARCH_PATH | GLib.SpawnFlags.DO_NOT_REAP_CHILD,
() => {
try {
global.context.restore_rlimit_nofile(); # <- here
} catch (err) {
}
}
);
```
Further code tracing found out that the deadlock is not during the execution of the function (`restore_rlimit_nofile`) but the access to the GObject (probably `global.context`).
Currently my propose to work around this issue is to add a 5 second `setTimeout` to the caller of `_spawn` function in `ibusManager.js`.
I've lost debugging information but I can try reproducing the issue and give the backtrace from gdb if needed. |
[ Impact ]
If gnome-shell is launched directly instead of launched through gnome-session, the process spawning `ibus-daemon` might cause deadlock and unable to start the graphics.
Since `ibusManager.js` checks whether service `org.freedesktop.IBus.session.GNOME.service` exists. In our case with Ubuntu ubiquity, we've turned off `gnome-session.service` so that the check failed and gnome-shell spawns `ibus-daemon` after the check.
[ Test case ]
- In a terminal launch
- env XDG_RUNTIME_DIR=/tmp/nested-runtime \
dbus-run-session gnome-shell --nested --wayland
- The shell should start without hanging
- Repeat this multiple times and ensure it works reliably
[ Regression potential ]
- Shell (and or its extensions) may not be able to spawn child processes
- Applications launched by the shell may inherit the rlimits of mutter
---
I tried using gdb to gnome-shell and discovered it's hanging in a child process spawning `ibus-daemon`, but is still in child_setup of `Glib.spawn_async` function:
```
root@dell-desktop:/home/oem# cat /tmp/log
== Stack trace for context 0x5584da793180 ==
#0 5584dbd2d478 i resource:///org/gnome/shell/misc/ibusManager.js:119 (2776aa47bfb0 @ 12)
#1 5584dbd2d3a8 i resource:///org/gnome/shell/misc/ibusManager.js:114 (2776aa47bf60 @ 426)
#2 5584dbd2d308 i resource:///org/gnome/shell/misc/ibusManager.js:90 (2776aa47bec0 @ 162)
#3 5584dbd2d268 i self-hosted:689 (34e3dc212650 @ 15)
```
which is, in ibusManager.js:
```
const [success_, pid] = GLib.spawn_async(
null, cmdLine, env,
GLib.SpawnFlags.SEARCH_PATH | GLib.SpawnFlags.DO_NOT_REAP_CHILD,
() => {
try {
global.context.restore_rlimit_nofile(); # <- here
} catch (err) {
}
}
);
```
Further code tracing found out that the deadlock is not during the execution of the function (`restore_rlimit_nofile`) but the access to the GObject (probably `global.context`).
Currently my propose to work around this issue is to add a 5 second `setTimeout` to the caller of `_spawn` function in `ibusManager.js`.
I've lost debugging information but I can try reproducing the issue and give the backtrace from gdb if needed. |
|
| 2024-06-14 07:50:23 |
Launchpad Janitor |
gnome-shell (Ubuntu): status |
In Progress |
Fix Released |
|
