Crash: g_variant_serialised_n_children: code should not be reached #894
Comments
|
Hi, I have another way to trigger this bug: change the name of "Menu" in Cinnamon Settings by holding down any character button, you can see the letters slowly appearing (it does it on my system). While the Menu word is still "growing", click it. I saw this bug on github and checked the log with cinnamon --replace, same "serialised_n_children" bug. |
|
@pmarcelll: Great catch! Now that we have a sure way to trigger the crash, it should be easy to get a stack dump. Could somebody please instruct me on how to build a debug-enabled Cinnamon? |
|
@autarkper : To get a stack trace for cinnamon, you can use gdb by following the instructions given there : https://live.gnome.org/GettingTraces/Details Basically, what you need to do is switch to tty (or at least a different display) and run :
(adapt the value of DISPLAY to the correct one if needed)
Once the crash has occured, typing :
will show you the stack trace. I managed to trigger the crash and get a stack trace here, using the method suggested by @pmarcelll (Thanks !). I haven't had time to look closely into it, but it seems to be related to gsettings. So here is it :
|
|
@autarkper : BTW, we already had such an issue with gsettings, which apparently doesn't like us to get or set the value of settings too often. There was another crash that was fixed a few weeks ago that caused by the fact that we did write the value of a setting every time we opened/closed the expo. The issue with changing the menu label seems to also very likely be the same issue (as we do change the value of an entry in gsettings for each letter). |
|
Maybe we should add an 'apply' button for the settings app? |
|
@mtwebster : that would be on way of handling it. Another one would be to change the event on which we submit the change from "changed" to "focus-out-event" |
|
@glebihan, @mtwebster : Thanks for your input! Re the stack trace, the interesting thread is the last one, unless there is a thread collision somewhere (which seems unlikely, since the other threads are all in a wait state). It would be interesting to know what is happening at frame #10; what value is muffin trying to get? |
|
I have built a debug version of muffin and tried running cinnamon in a debugger (in tty1), as suggested by @glebihan. However, after a few seconds it crashes: As a matter of fact I can't run "DISPLAY=:0 cinnamon --replace" from tty1 either! Update: I have worked around the debugging problem by running a batched debugging session from within a terminal window. But I'm still not getting a function name for stack frame #10. |
|
I was thinking more on the settings issue - would it be totally redundant to have a global settings 'cache' exist in cinnamon? Sort of a high level layer that the rest of Cinnamon accesses to read and write settings, then this layer, in a more orderly fashion, writes changes to gsettings directly. i.e. XX Applet wants the setting 'menu-activate-on-hover', it calls: CinnamonSettings,get_boolean('menu-activate-on-hover') CinnamonSettings checks its cache (an array of key: value properties) - if it's in the cache, it returns the value immediately. If no, it goes to gsettings and gets the value, stores it in its cache, and returns the value. XX Applet then wants to change that value: CinnamonSettings.set_boolean('menu-activate-on-hover', true) CinnamonSettings immediately changes its cached value, then queues up the change for gsettings. On its next 'write pulse,' it writes the new value to gsettings. It could also handle signaling for setting changes, so all connections to settings goes through CinnamonSettings, which chains on down to gsettings. This would require code changes wherever settings are currently accessed and written, but would keep gsettings from getting over-used and possibly causing this crashy behavior? The additional advantage would be speed - any subsequent access of a particular setting after the first time would be quick. Just an idea that popped in my head, like I said, may be redundant and unnecessarily complicate things. |
|
Oh, I see that the sole instance of muffin calling g_settings_get_value directly is in prefs.c. |
|
I feel I'm getting closer. I put a log statement inside muffin's settings_changed function. Here is the output from when I use the menu-settings trick to trigger a crash: So, the key that triggers the crash appears to be "keybindings/". |
|
By returning immediately when the key is "keybinding/" I can get a little further before crashing: 236 Window manager warning: key: attach-modal-dialogs I'm going to fix the error in the menu applet and see what happens. |
|
Sorry, didn't mean to close the issue! Yes, fixing the JS error, made cinnamon survive! But still, I wish somebody could figure out why there is what appears to a global refresh of all settings all of a sudden. |
|
I have been playing with gsettings_delay, http://developer.gnome.org/gio/2.28/GSettings.html#g-settings-delay, attempting to cut down on the disk access that occurs whenever a setting is changed, the idea being to have an idle task periodically calling gsettings_apply, but that does not seem to have any effect, neither on the disk access pattern nor on the occurrence of the global settings refresh phenomenon. |
|
I'm wondering whether the problem lies not in gsettings but in the backend it uses. I'm not getting these crashes with the "memory" backend, but that backend has a lot of other drawbacks. |
|
It also happens when clicking a favourite in the menu that has only just been added. The mouse hover over such a favourite does not work either. |
|
Sorry to be spamming you on this issue, but I have found the cause of the crash: the panel-launchers applet gets over-excited every time there is a settings update and reloads itself inside the handler function. The fix is easy: offload the reload to a timer event and return immediately. |
|
While waiting for either a quick fix or a thorough rewrite of the panel-launchers applet, you can just remove it from the panel for the time being. |
I'm suffering quite badly from Cinnamon (current master) crashing a lot. One of the surest ways to produce a crash is to open and close Expo a few times, but sometimes just moving the mouse pointer down to the panel can trigger a crash. Whenever this happens, the following is printed to the console:
One strange thing is that just before the crash, the following is output to the looking-glass log:
Now, why would opening or closing Expo trigger a theme change?
See also: #785, which I opened when I thought the problem was related to Expo.
The text was updated successfully, but these errors were encountered: