Hi, a Debian user reported (and I can confirm it) that running multiple mousepad instances currently leads to a lot of dbus traffic (shown in dbus-monitor), which is apparently about dconf settings. That also use a lot of CPU, so setting the severity to major. The downstream bug is at http://bugs.debian.org/795192
Weird. It should only be sending GSettings stuff when the settings are accessed. The linked bug shows it's the color-scheme setting, which is even more puzzling as it should only be accessed very rarely compared to some stuff like keeping track of the windows' positions as they move around and whatnot. I'll try and see if I can reproduce here. In the meantime, a "workaround" is to not use the Dbus backend of GSettings (using `--enable-keyfile-settings` option to `configure` script). There's existing non-GSettings code that uses Dbus in Mousepad too, which I think can also be disabled (probably `--disable-dbus` option to `configure` script), that I believe is used for single-instance multi-window support. Hopefully it's not related to that code, as I've never looked at it and have no idea how it works.
Sorry I didn't get any email on the Debian bug so I didn't realise anything had happened (control messages aren't sent to subscribers). I can confirm '--enable-keyfile-settings' alone to configure is enough to kill off this problem.
Hi, I can confirm that this bug exists ( in debian testing ). Running a 'dconf watch /' command in a separate terminal shows that mousepad is trying to change a color scheme related settings, apparently hundreds of times each second. $ dconf watch / """ /org/xfce/mousepad/preferences/view/color-scheme '[Invalid UTF-8]' /org/xfce/mousepad/preferences/view/color-scheme '[Invalid UTF-8]' """ System starts showing high amount of disk writes caused by 'dconf-service' and 'jbd2/ext4', eventually stalling everything. I am worried about SSD write cycle wastage due to this bug. :( $ mousepad -v """ Mousepad 0.4.0 Copyright (c) 2007 The Xfce development team. All rights reserved. Please report bugs to <http://bugzilla.xfce.org/>. """ $ dpkg -l mousepad """ ||/ Name Version Architecture Description +++-==============-============-============-================================== ii mousepad 0.4.0-3 amd64 simple Xfce oriented text editor """
I can repeat it too, though here the CPU load is only around 1% when the bug occurs. There must be some cycle or something, maybe weird interaction between the low-level DBus single-instance code and the new GSettings stuff added later. The bug doesn't occur when you open a new window using File->New Window.
I added a fix for this: http://git.xfce.org/apps/mousepad/commit/?id=f07cc75f2aa77d14f16b5506321ac6a2413706ba As mentioned in the commit message, I'm not entirely sure what's going on, but it seems to fix the problem here. Can anyone confirm?
(In reply to Matthew Brush from comment #5) > I added a fix for this: > > http://git.xfce.org/apps/mousepad/commit/ > ?id=f07cc75f2aa77d14f16b5506321ac6a2413706ba > > As mentioned in the commit message, I'm not entirely sure what's going on, > but it seems to fix the problem here. > > Can anyone confirm? It doesn't seem to work here.
(In reply to Yves-Alexis Perez from comment #6) > (In reply to Matthew Brush from comment #5) > > I added a fix for this: > > > > http://git.xfce.org/apps/mousepad/commit/ > > ?id=f07cc75f2aa77d14f16b5506321ac6a2413706ba > > > > As mentioned in the commit message, I'm not entirely sure what's going on, > > but it seems to fix the problem here. > > > > Can anyone confirm? > > It doesn't seem to work here. You definitively don't have any existing Mousepad instances open before testing? I have installed into `/opt/mousepad` prefix, and tested by running `/opt/mousepad/bin/mousepad` twice and watching output of `dconf watch /`. It just does the expected DBus activities for me, in this case, to keep settings in sync. Before this change it just spammed an infinite number of messages about the 'color-scheme'.
(In reply to Matthew Brush from comment #7) > (In reply to Yves-Alexis Perez from comment #6) > > It doesn't seem to work here. > > You definitively don't have any existing Mousepad instances open before > testing? I have installed into `/opt/mousepad` prefix, and tested by running > `/opt/mousepad/bin/mousepad` twice and watching output of `dconf watch /`. > It just does the expected DBus activities for me, in this case, to keep > settings in sync. Before this change it just spammed an infinite number of > messages about the 'color-scheme'. I still have the infinite number of message, and yes it's a clear start. Mousepad is built with: * D-BUS support: no * Debug Support: minimum * Use keyfile backend: default * Build with GTK+ 3: no
(In reply to Yves-Alexis Perez from comment #8) > (In reply to Matthew Brush from comment #7) > > (In reply to Yves-Alexis Perez from comment #6) > > > It doesn't seem to work here. > > > > You definitively don't have any existing Mousepad instances open before > > testing? I have installed into `/opt/mousepad` prefix, and tested by running > > `/opt/mousepad/bin/mousepad` twice and watching output of `dconf watch /`. > > It just does the expected DBus activities for me, in this case, to keep > > settings in sync. Before this change it just spammed an infinite number of > > messages about the 'color-scheme'. > > I still have the infinite number of message, and yes it's a clear start. > Mousepad is built with: > > * D-BUS support: no > * Debug Support: minimum > * Use keyfile backend: default > * Build with GTK+ 3: no Not sure if it matters but the only difference here is using DBUS-support enabled (for proper multi-instance support) and GTK+3 enabled.
I'll try to rebuild with DBus support forced and report back.
The true cause of this problem is inside mousepad-action-group.c. This is the code for the color theme menu. In it there are two functions: 1. mousepad_action_group_style_scheme_action_activate This is called when the user uses the menu to change the theme. It's job is to change the g_setting. 2. mousepad_action_group_color_scheme_setting_changed This is called whenever the g_setting changed. It's job is to change the currently selected item in the menu. The problem is that both these functions do more than just their job. They both call: 3. mousepad_action_group_set_active_style_scheme This function activates a lock so it will only be called once. Then it updates both the menu and the g_setting. The lock prevents the resulting triggered events from running. The problem comes when you have more than one window open. The lock means that each window will only try to update the menu and the setting once. But updating the setting will trigger every other unlocked window to update the menu and the setting. So then the next unlocked window locks itself and then triggers another event in all the remaining windows. This causes a huge cascade of events which will all (eventually) get ignored by the lock. The solution is to change the logic so that updating the setting only triggers a menu update, and updating the menu only triggers a setting update. Each will in turn trigger an attempt at updating the other, but now the lock will prevent it from happening, and therefore prevent a setting change from being propagated back out to other windows.
This isn't the full extent of the problem though. Whenever the setting or the menu changed, the action group also sends an event to the window, which passes it to the view. But the view is also bound directly to the setting. So when the setting changes this happens: 1. View gets a notification and updates. 2. Menu gets a notification and and manually tells the view to update. 3. Menu unnecessarily updates the g_setting. 4. View gets another notification and updates for a third time. So for every spam caused by the loop described in the previous comment, the view_set_color_theme function gets called three times, which means even more queued events. It's possible for mousepad to get OOM killed because the event queue just grows exponentially with the number of open windows.
Created attachment 6632 Revert original patch
Created attachment 6633 Prevent the menu item/g_setting cycle.
Created attachment 6634 Don't manually update the view. This just removes mousepad_window_action_group_style_scheme_changed completely as it doesn't seem to do anything useful.
Created attachment 6635 Prevent the menu item/g_setting cycle - fixed Some unintentional changes got through in the old version of this patch.
I'm a bit lost here, can one mark obsolete the insufficient patches and check the right one(s) (even better would be to commit it to git but I understand it might not be that easy.
(In reply to Yves-Alexis Perez from comment #17) > I'm a bit lost here, can one mark obsolete the insufficient patches and > check the right one(s) (even better would be to commit it to git but I > understand it might not be that easy. I've already done this. You need all three remaining patches. I tried to push this to my user repository, but it didn't work. So I pushed it to github instead, and then created a pull request (against my own repository in order to prevent noise on the semi-official mirror): https://github.com/ali1234/mousepad/pull/1
*** Bug 11927 has been marked as a duplicate of this bug. ***
Applying the patch from Alistair's comment #18 fixes the issue for me on Arch. Patch file: https://patch-diff.githubusercontent.com/raw/ali1234/mousepad/pull/1.patch
I confirm that this bug still continues/exists on xubuntu 16.04 with dconf-service. It happens on my machine when I open more than one instance of mousepad, the I/O disk write increments and the HDD led doesn't stop blinking, until I close one of the instances of mousepad.
Can this be pulled please?
This is finally merged, sorry for the extremely long delay. Thanks for the fix! https://git.xfce.org/apps/mousepad/commit/?id=309f6177d2c47070676d6c733e29952c63c110ba
...won't let me change to resolved-fixed without comment...