GNOME Bugzilla – Bug 171372
background properties can crash with fullscreen mag
Last modified: 2005-07-18 21:21:30 UTC
Distribution/Version: JDS Rel3 B31 Using gnome 2.6 and gnopernicus 0.10.4 - Start gnopernicus with full screen magnifier enabled (using the dummy driver). - Start up gnome-background-preferences from the main menu: prefereces->desktop preferences->display->Desktop Background - Change the background a couple of times. - Change the "Style" combobox to "centered" - Under Desktop Colours, change the combobox to "Vertical Gradient" - Select a colour for the first pushbutton. - Close the window. The Desktop Background Preferences window sometimes crashes. This is not reproducible every time. Also, once it happens, it cannot be reproduced without logging out and back in again. When it happens, it can disturb the operation of the magnifier aswell. After some effort, I got a gdb trace: (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault.
+ Trace 57226
Thread 1094618032 (LWP 5872)
(gdb) q The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/bin/gnome-background-properties, process 5871
Why is this a gnopernicus bug? Clearly gnopernicus/gnome-mag is tickling the problem, but gnopernicus isn't in the stack trace and isn't what is dying.
this is all orbit code and any actual crash is probably a duplicate of one of the crashes that was fixed for 2.10.0.
Rodney: can you point us to some of the relevant ORBit bugs?
I don't know any other bugs. I was just saying that all of the code in this backtrace is pointing at ORBit methods that the background capplet doesn't directly use itself. Perhaps the actual crash here is in gail? All of the crashers that have been reported against the background capplet, were all due to the fact that it wasn't handling !utf-8 filename encodings. Lacking a suitable fix to make it handle them, I made it ignore them, and not crash. None of those crashes were in ORBit methods though. Perhaps this should be REOPENed and reassigned to gail or somewhere?
no, gail doesn't directly call these ORBit methods. The stack trace is not terribly helpful, I admit.
Well, the background capplet doesn't call these ORBit methods either. It's crashing in some library under the capplet, perhaps within ORBit itself. However, the background capplet doesn't do anything special as a program here. Perhaps this should be moved to ORBit then?
I think we should leave this in control-center until a root cause can be identified; everything else so far has been speculation.
Then as appropriate, I'm marking this NEEDINFO until you can get more info that tells me how this is actually a crash because of code in the background capplet. It's an a11y issue, and all the backtrace is internal ORBit code.
I don't think the backtrace is necessarily relevant - certainly it's uninformative in this case. Whatever is going wrong is going wrong well before the stack trace we see here.
This is an Orbit2 issues which has been fixed. Stack trace matches Bug #149371 *** This bug has been marked as a duplicate of 149371 ***