No, since building installing the debug packages, I'm still waiting to
reproducing this bug...
--
gconfd-2 doesn't stop for previous user logged into GNOME
https://bugs.launchpad.net/bugs/85521
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug
** Attachment added: The clearlooks engine displays the problematic widgets as
expected
http://librarian.launchpad.net/6634576/acroread-dapper-clearlooks%2B.png
--
Scroll-thumb badly drawn in acroread
https://launchpad.net/bugs/37415
--
desktop-bugs mailing list
Besides the corrupted scroll-bar, in Adobe Reader (7.0.9, tar.gz from
adobe.com) I've also observed somewhat garbled minimize, maximize,
and close buttons within the main window (see attached image). This
seems to affect to a different degree only cairo-enabled gtk2 engines --
ubuntulooks
The problem appeared again, so here are the (hopefully helpful)
backtrace (attached) and the output of strace:
~$ strace -p 7238
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
[EMAIL PROTECTED]:~$ sudo strace -p 7238
Process 7238 attached - interrupt to quit
gettimeofday({1172324704,
Thank you for your work on that. Marking unconfirmed. What
is that relict program doing?
The relict process is /usr/lib/libgconf2-4/gconfd-2 that runs for the
previously logged-in user, and I don't know what it's doing but it eats
all the CPU activity (100%).
--
gconfd-2 doesn't stop for
Please also note that my above post (providing the backtrace and strace)
was a little overzealous -- in my effort to get a useful backtrace (with
the built debug-packages) I have been unable to preproduce the described
situation since the bugreport, but when I noticed the mentioned 100% CPU
Since my bugreport I hadn't experienced the unusually high CPU usage for
gconfd-2, but I noticed that the respective process for previously
logged user(s) still persists. I don't know if this behaviour is normal
or not, but I assume that the high CPU usage comes when the relict
process has
Public bug reported:
Binary package hint: libgconf2-4
After a user logged out of a GNOME-session (is-1 in the example
below), the next user that logs in (is) may experience very high CPU-
usage caused by the unstopped gconfd-2 process for the first user.
Although I experience this behaviour
I'm glad that I still haven't rebooted since then to get rid of the
annoying situation and the observed anomaly still eats almost all of my
CPU cycles, so here is the requested info.
First of all, I am unable to do successfully (gdb) attach PID as
described in the wiki -- I get no permission. Is
Well, I have tried to run the described steps (for an already running
program) with sudo and here the output is attached.
It is interesting that after issuing attach 5771 the CPU usage dropped
to normal levels (2-3%), but when I said quit at the gdb prompt and
exited anyway, the CPU was again at
I'm affraid that I'm not proficient with building debs, but I'll try to
do my best to resolve this issue.
If I face the described situation again, should I post here the same
type of info as I already did? Or is there something else to have in
mind while using the debug package?
--
gconfd-2
Building the debug packages turned out to be much easier than I thought,
but after installing them the update-manager wants to update these -- I
suppose that I don't want to do that unless I've finished using the
debug version.
Waiting for the bug to come again;)
Thanks for the help sofar,
I confirm this bug in Ubuntu 6.06 LTS and provide a screenshot of the
situation.
** Attachment added: Evolution compose window showing the vestigial dropdown
menu
http://librarian.launchpad.net/5408786/evolution-compose-window.png
--
Dropdown from collapsed evolution toolbar is not
I can confirm this bug in Ubuntu 6.06 LTS, but for me a simple restart
didn't solve the problem -- I had to run evolution --force-shutdown
before starting Evolution again (as suggested in Bug #47329).
I hope Dapper will be fixed soon, as this bug is really annoying.
--
Evolution need to be
Public bug reported:
Steps to reproduce:
1) Set up a remote CUPS printer relative to an up-to-date Dapper machine
(in my case I used RAW and a queue via IPP);
2) make the CUPS host inaccessible for the client (e.g. via
disconnecting it from the network, switching it off, etc.);
3) try to
15 matches
Mail list logo
