monitor
monitor copied to clipboard
stsdc
Segmentation fault after upgrading to 0.12.0
Monitor now segfaults immediately after upgrading to 0.12.0 on my machine (by having run apt update && apt upgrade):
Here is the output when I attempt to launch it from the terminal:
$ com.github.stsdc.monitor
Monitor 0.12.0
Segmentation fault
Please run with: G_MESSAGES_DEBUG=all GTK_DEBUG=interactive com.github.stsdc.monitor
Here is the output:
$ G_MESSAGES_DEBUG=all GTK_DEBUG=interactive com.github.stsdc.monitor
Monitor 0.12.0
(com.github.stsdc.monitor:3786): GLib-GIO-DEBUG: 15:34:20.877: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(com.github.stsdc.monitor:3786): dconf-DEBUG: 15:34:20.877: watch_fast: "/com/github/stsdc/monitor/settings/" (establishing: 0, active: 0)
(com.github.stsdc.monitor:3786): GLib-DEBUG: 15:34:20.878: unsetenv() is not thread-safe and should not be used after threads are created
(com.github.stsdc.monitor:3786): dconf-DEBUG: 15:34:20.890: watch_established: "/com/github/stsdc/monitor/settings/" (establishing: 1)
(com.github.stsdc.monitor:3786): GLib-GIO-DEBUG: 15:34:20.982: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
(com.github.stsdc.monitor:3786): Gtk-DEBUG: 15:34:21.333: Using display (null) for GtkInspector
(com.github.stsdc.monitor:3786): GLib-DEBUG: 15:34:24.052: unsetenv() is not thread-safe and should not be used after threads are created
(com.github.stsdc.monitor:3786): Gtk-DEBUG: 15:34:24.053: Connecting to session manager
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.088: HwmonPathsParser.vala:58: Found unknown HWMON Interface: radeon
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.089: HwmonPathsParser.vala:58: Found unknown HWMON Interface: ACAD
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.089: HwmonPathsParser.vala:42: Found HWMON CPU Interface: k10temp in: /sys/class/hwmon/hwmon3/name
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.089: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_crit
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.090: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_input
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.090: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_crit_hyst
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.090: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_max
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.090: HwmonPathsParserCPU.vala:46: 🌡️ Parsed HWMON CPU temperature interface:
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.091: HwmonPathsParser.vala:58: Found unknown HWMON Interface: BAT1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.119: CPU.vala:182: Parsed file /usr/share/com.github.stsdc.monitor/database/cpu_features.csv
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.120: CPU.vala:182: Parsed file /usr/share/com.github.stsdc.monitor/database/cpu_bugs.csv
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.120: CPU.vala:66: Number of cores: 2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.186: Storage.vala:83: Found drive: C300-CTFDDAC256MAG 0007 C300-CTFDDAC256MAG-0000000011020301CD93 /dev/sda
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.187: Storage.vala:83: Found drive: Flash Disk 8.01 Generic-Flash-Disk-04275422000187 /dev/sdb
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.187: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/sdb1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.187: Storage.vala:113: device: /dev/sdb1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.188: Storage.vala:137: Adding volume /dev/sdb1 to /dev/sdb
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/dm_2d1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: Storage.vala:113: device: /dev/dm-1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: Storage.vala:148: Found logical volume: /dev/dm-1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: StorageParser.vala:13: Found slave: sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: Volume.vala:43: First slave: sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: Storage.vala:148: Found logical volume: /dev/dm-1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: StorageParser.vala:13: Found slave: sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.189: Volume.vala:36: Slave volume sda2 of /dev/dm-1 is on the same disk as all other slave volumes
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.190: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.190: Storage.vala:113: device: /dev/sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.190: Storage.vala:137: Adding volume /dev/sda2 to /dev/sda
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.190: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/dm_2d0
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.190: Storage.vala:113: device: /dev/dm-0
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.190: Storage.vala:148: Found logical volume: /dev/dm-0
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.190: StorageParser.vala:13: Found slave: sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.191: Volume.vala:43: First slave: sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.191: Storage.vala:148: Found logical volume: /dev/dm-0
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.191: StorageParser.vala:13: Found slave: sda2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.191: Volume.vala:36: Slave volume sda2 of /dev/dm-0 is on the same disk as all other slave volumes
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.191: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/sda1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.191: Storage.vala:113: device: /dev/sda1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.191: Storage.vala:137: Adding volume /dev/sda1 to /dev/sda
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/dm_2d2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: Storage.vala:113: device: /dev/dm-2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: Storage.vala:148: Found logical volume: /dev/dm-2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: StorageParser.vala:13: Found slave: dm-1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: Volume.vala:43: First slave: dm-1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: Storage.vala:148: Found logical volume: /dev/dm-2
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: StorageParser.vala:13: Found slave: dm-1
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.192: Volume.vala:36: Slave volume dm-1 of /dev/dm-2 is on the same disk as all other slave volumes
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.203: Resources.vala:67: GPU: AMD PALM (DRM 2.50.0 / 5.11.0-41-generic, LLVM 12.0.0)
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.330: ProcessUtils.vala:5: sh
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.358: ProcessUtils.vala:5: sh
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.373: ProcessUtils.vala:5: sh
Segmentation fault
Probably because of GPU. What GPU are You using?
You may confirm if that's because of GPU by commenting out these lines and compile the code: https://github.com/stsdc/monitor/blob/2cb1f9f2a3fb0b680e91a55ccaab69dfbf467a79/src/Resources/Resources.vala#L33-L36
Make sure to install these dependencies: https://github.com/stsdc/monitor/blob/dev/debian/control
This will prevent GPU object from creating.
The GPU is the one integrated into the Acer Aspire notebook. The debug log I attached above reports it as:
** (com.github.stsdc.monitor:3786): DEBUG: 15:34:24.203: Resources.vala:67: GPU: AMD PALM (DRM 2.50.0 / 5.11.0-41-generic, LLVM 12.0.0)
So it is reported as AMD PALM. The manufacturers specs for that machine say that is an ATI Radeon HD 6250 (see here).
I have commented out lines 34-36 as you suggested, and compiled, but I still get the segfault and the same debug log when I run with G_MESSAGES_DEBUG=all GTK_DEBUG=interactive com.github.stsdc.monitor.
As an additional test, I also checked whether the constructor completes without problems. I added a print statement after the call to update (); on line 43 (i.e., the last line of the constructor), and it printed to the terminal when I ran with G_MESSAGES_DEBUG=all GTK_DEBUG=interactive com.github.stsdc.monitor. So the segfault must be caused by something else.
To be clear, when the constructor in Resources.vala reads as follows:
construct {
hwmon_path_parser = new HwmonPathParser ();
memory = new Memory ();
cpu = new CPU ();
swap = new Swap ();
network = new Network ();
storage = new Storage ();
SessionManager session_manager = get_sessman ();
string gpu_name = session_manager.renderer.down ();
if (gpu_name.contains ("intel")) {
} else if (gpu_name.contains ("nvidia") || gpu_name.contains ("geforce")) {
gpu = new GPUNvidia ();
gpu.session_manager = session_manager;
} else if (gpu_name.contains ("amd")) {
gpu = new GPUAmd ();
gpu.session_manager = session_manager;
gpu.hwmon_temperatures = hwmon_path_parser.gpu_paths_parser.temperatures;
} else {
warning ("GPU: Unknown");
}
cpu.temperatures = hwmon_path_parser.cpu_paths_parser.temperatures;
update ();
debug ("I HAVE FINISHED THE CONSTRUCTOR!");
}
The output was the following:
$ G_MESSAGES_DEBUG=all GTK_DEBUG=interactive com.github.stsdc.monitor
Monitor 0.12.0-3-g2cb1f9f-dirty
(com.github.stsdc.monitor:16497): GLib-GIO-DEBUG: 22:23:29.361: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(com.github.stsdc.monitor:16497): dconf-DEBUG: 22:23:29.361: watch_fast: "/com/github/stsdc/monitor/settings/" (establishing: 0, active: 0)
(com.github.stsdc.monitor:16497): GLib-DEBUG: 22:23:29.363: unsetenv() is not thread-safe and should not be used after threads are created
(com.github.stsdc.monitor:16497): dconf-DEBUG: 22:23:29.389: watch_established: "/com/github/stsdc/monitor/settings/" (establishing: 1)
(com.github.stsdc.monitor:16497): GLib-GIO-DEBUG: 22:23:29.557: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
(com.github.stsdc.monitor:16497): Gtk-DEBUG: 22:23:29.960: Using display (null) for GtkInspector
(com.github.stsdc.monitor:16497): GLib-DEBUG: 22:23:32.755: unsetenv() is not thread-safe and should not be used after threads are created
(com.github.stsdc.monitor:16497): Gtk-DEBUG: 22:23:32.755: Connecting to session manager
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.793: HwmonPathsParser.vala:58: Found unknown HWMON Interface: hidpp_battery_2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.793: HwmonPathsParser.vala:58: Found unknown HWMON Interface: radeon
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.793: HwmonPathsParser.vala:58: Found unknown HWMON Interface: ACAD
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.794: HwmonPathsParser.vala:42: Found HWMON CPU Interface: k10temp in: /sys/class/hwmon/hwmon3/name
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.794: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_crit
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.794: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_input
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.795: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_crit_hyst
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.795: HwmonPathsParserCPU.vala:20: Found HWMON CPU temperature interface path: temp1_max
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.795: HwmonPathsParserCPU.vala:46: 🌡️ Parsed HWMON CPU temperature interface:
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.796: HwmonPathsParser.vala:58: Found unknown HWMON Interface: BAT1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.821: CPU.vala:182: Parsed file /usr/share/com.github.stsdc.monitor/database/cpu_features.csv
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.827: CPU.vala:182: Parsed file /usr/share/com.github.stsdc.monitor/database/cpu_bugs.csv
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.827: CPU.vala:66: Number of cores: 2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.885: Storage.vala:83: Found drive: C300-CTFDDAC256MAG 0007 C300-CTFDDAC256MAG-0000000011020301CD93 /dev/sda
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.886: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/dm_2d1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.886: Storage.vala:113: device: /dev/dm-1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.886: Storage.vala:148: Found logical volume: /dev/dm-1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.887: StorageParser.vala:13: Found slave: sda2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.888: Volume.vala:43: First slave: sda2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.888: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/sda2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.888: Storage.vala:113: device: /dev/sda2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.888: Storage.vala:137: Adding volume /dev/sda2 to /dev/sda
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.888: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/dm_2d0
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.888: Storage.vala:113: device: /dev/dm-0
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.889: Storage.vala:148: Found logical volume: /dev/dm-0
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.889: StorageParser.vala:13: Found slave: sda2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.889: Volume.vala:43: First slave: sda2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.889: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/sda1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.889: Storage.vala:113: device: /dev/sda1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.890: Storage.vala:137: Adding volume /dev/sda1 to /dev/sda
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.890: Storage.vala:110: path: /org/freedesktop/UDisks2/block_devices/dm_2d2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.890: Storage.vala:113: device: /dev/dm-2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.890: Storage.vala:148: Found logical volume: /dev/dm-2
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.890: StorageParser.vala:13: Found slave: dm-1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.890: Volume.vala:43: First slave: dm-1
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.907: Resources.vala:68: GPU: AMD PALM (DRM 2.50.0 / 5.13.0-25-generic, LLVM 12.0.0)
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:32.908: Resources.vala:44: I HAVE FINISHED THE CONSTRUCTOR!
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:33.081: ProcessUtils.vala:5: sh
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:33.110: ProcessUtils.vala:5: sh
** (com.github.stsdc.monitor:16497): DEBUG: 22:23:33.120: ProcessUtils.vala:5: sh
Segmentation fault
You can see that the the constructor completed before the segfault.
Thanks for testing and debugging. Much appreciated.
You may also try to use gdb:
Run gdb /path/to/monitor in your terminal. Type run and then press Enter to run an app. When we get a segfault type bt and press Enter to see a backtrace.
Another option is to comment out widgets that might ask for object attributes that might be null :man_shrugging: . In that case: https://github.com/stsdc/monitor/blob/dev/src/Views/SystemView/SystemView.vala or https://github.com/stsdc/monitor/blob/dev/src/Views/ProcessView/ProcessView.vala
Running gdb com.github.stsdc.monitor and then run revealed the problem. The relevant lines from the gdb output:
Thread 1 "com.github.stsd" received signal SIGSEGV, Segmentation fault.
0x0000555555574082 in monitor_system_cpu_info_popover_general_page (self=0x555555cfdbe0)
at ../src/Views/SystemView/SystemCPUInfoPopover.vala:67
67 listbox.add (label (_("L3 Cache size:") + " " + cpu.core_list[0].caches.get ("L3").size));
In file src/Views/SystemView/SystemCPUInfoPopover.vala we have the following lines:
if (cpu.core_list[0].caches.has_key ("L1")) {
listbox.add (label (_("L1 cache:") + " " + cpu.core_list[0].caches["L1"].size));
}
listbox.add (label (_("L2 Cache size:") + " " + cpu.core_list[0].caches.get ("L2").size));
listbox.add (label (_("L3 Cache size:") + " " + cpu.core_list[0].caches.get ("L3").size));
The problem is that the CPU of this machine does not have an L3 cache and therefore the last line causes the segfault.
For some reason the code checks whether there is an L1 cache, but it does not check whether there is an L2 and L3 cache. It assumes that there is an L3 cache and then it segfaults.
I will create a PR to fix this.
@stsdc Yes, I tested it on that machine at the time and it fixed the issue.
@stsdc I have just upgraded to 0.13.0, but it appears that this issue is back again.
Looking at the file history for SystemCPUInfoPopover.vala, I can see that this issue was fixed in my PR which you merged in commit 078db2e, but then these changes were then overwritten in the next commit ef59884.
Perhaps this was because of a merge gone wrong? Either way, this segmentation fault still exists in 0.13.0.
Could we please reopen this issue until this fixed? Many thanks!
I can confirm that testing with version 0.14.0 the segfault bug is now fixed. (I have tested on the same hardware as when I originally reported the problem, i.e. the Acer Aspire notebook.)
Therefore this bug can be closed. Thanks!