[Bug 67476] Re: Dialogs of background applications pop up in the foreground
If you look at my original comment, you'll see that the reason I commented here is because someone made my earlier bug report a duplicate of this bug. So if you're not happy, find that person and tell him/her to stop doing that. -- Dialogs of background applications pop up in the foreground https://bugs.launchpad.net/bugs/67476 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 132612] Re: memory leak in evince?
I'm currently running Intrepid and the problem is *not* fixed. I was wondering why my system was still using a lot of memory despite the fact I didn't have that many apps running. So I closed all by one of the evince documents and checked memory use: % free total used free sharedbuffers cached Mem: 40454523975256 70196 0 126200 617356 -/+ buffers/cache:3231700 813752 Swap: 390378414337922469992 I count only the used -/+ buffers/cache plus the used swap, so that's 4.4 GB used by the system. I then close the last evince document and check memory again. % free total used free sharedbuffers cached Mem: 40454523057952 987500 0 126304 613112 -/+ buffers/cache:23185361726916 Swap: 3903784 5331843370600 Using the same method, that's 2.7 GB use (still too much, but that's another issue). So evince was *effectively* using 1.7 GB just to display one document (plus most likely the leaks from the documents I opened and closed). No, there was nothing special about the document I had open. -- memory leak in evince? https://bugs.launchpad.net/bugs/132612 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
I also believe it's related to copy-paste, because it always triggers a bit after a paste. -- Runaway leak in composer https://bugs.launchpad.net/bugs/51662 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
Sebastien, I *did* try valgrind. The problem was that evolution generates so many warnings that valgrind's useless. It's also incredibly slow (evo+valgrind) that you can't run that all the time. Some people also gave stack traces, so don't say there was no info provided. Also, in my case, I wasn't using any plugin or anything like that when I had the problem. I'm glad the bug seems to be fixed with Hardy, though I'm staying with Thunderbird anyway. -- Runaway leak in composer https://bugs.launchpad.net/bugs/51662 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
I think the main reason you're getting no more information is that: 1) No information has been provided by the developers 2) Most people really affected by this bug have probably switched to another client just like I've done. You need to understand that the bug's been around for years now and that it makes evolution so much of a pain to use when you're effected by it, that switching is pretty much the only viable option (I resisted about 9 months). -- Runaway leak in composer https://bugs.launchpad.net/bugs/51662 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 158177] Re: Evince presentations start in a window if evince is fullscreen and compiz is enabled
I'm having similar problems with evince when I enable compiz. Basically, evince will open with the wrong geometry (slightly higher than the screen) and more than half its window would be outside the screen (top- left corner almost at the centre of the screen). But evince is not the only application that screws up. Lyx opens all its dialogs so far in the top-left corner of the screen that I can't see the title bar. Same thing for openoffice.org which not only does that but also has completely wrong geometry for the dialog in the first place (a simple save before quitting dialog takes half the screen). None of those problems happen with compiz disabled, which brings two possibilities: 1) compiz is horribly broken when it comes to window placement/geometry or 2) compiz exposes the fact that most X applications are horribly broken when it comes to placement/geometry. In any case, it's not pretty. -- Evince presentations start in a window if evince is fullscreen and compiz is enabled https://bugs.launchpad.net/bugs/158177 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for evince in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 158177] Re: Evince presentations start in a window if evince is fullscreen and compiz is enabled
Just a minor correction: the openoffice.org do you want to save your changes? dialog is actually created as full-screen, which is really annoying to say the least. I've also found the behaviour to be intermittent. -- Evince presentations start in a window if evince is fullscreen and compiz is enabled https://bugs.launchpad.net/bugs/158177 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for evince in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
I didn't observe the problem again because I'm no longer using evolution (mainly because of this bug). All I can remember is that the bug was often triggered by pasting some text into the compose window. Also, if I saved the message before killing evolution (it was sometimes possible), then trying to edit it again after restarting evolution would often trigger the bug again. -- Runaway leak in composer https://bugs.launchpad.net/bugs/51662 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 66188] Re: Big memory leak
How about applying the fix to Dapper? Looks like bug #92143, which I filed. -- Big memory leak https://launchpad.net/bugs/66188 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 92143] Re: gnome-session leaks huge amounts of memory on Dapper
*** This bug is a duplicate of bug 66188 *** Seems to fit the pattern. I had set up a script to check the memory every minute and it turns out that it leaked exactly 6752 KB every time I brought up the logout dialog today (and did an xlock, but I don't think the xlock is the problem here). -- gnome-session leaks huge amounts of memory on Dapper https://launchpad.net/bugs/92143 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 92143] gnome-session leaks huge amounts of memory on Dapper
Public bug reported: Binary package hint: gnome-session There is a memory leak in gnome-session that is causing it to slowly fill all available memory. My machine has now been up for 50 days and ps shows 523MB: jm5249 0.0 4.8 536232 49752 ?Ss Jan24 1:30 x-session-manager Using pmap, I see: % pmap 5249 5249: x-session-manager 08048000112K r-x-- /usr/bin/gnome-session 08064000 4K rw--- /usr/bin/gnome-session 08065000 3128K rw---[ anon ] 96973000 465888K rw---[ anon ] b3703000 33760K rw---[ anon ] b58e9000 9112K r /usr/share/icons/gnome/icon-theme.cache ... [the rest looks normal] The offending like is obviously 96973000 465888K rw---[ anon ], which unfortunately isn't very useful (except maybe to exclude some dso). The leak grows at a slow, steady pace (or so it seems) over time, until I kill the X session or shutdown the machine. Even if I close all applications (e.g. firefox, gnome-terminal, ...), the memory use doesn't go down. Machine info: Dell D810 laptop Pentium-M 2.13 GHz, 1 GB RAM 1 GB swap Dapper 6.10 with up-to-date patches Gnome environment ** Affects: gnome-session (Ubuntu) Importance: Undecided Status: Unconfirmed -- gnome-session leaks huge amounts of memory on Dapper https://launchpad.net/bugs/92143 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
Actually, I originally filed this bug against Dapper... In any case, installing thunderbird solved the problem permanently for me and I'm not looking back (took about an hour to copy mail around and configure). It's not perfect, but it's much more stable and has never crashed my machine. -- Runaway leak in composer https://launchpad.net/bugs/51662 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 30146] Re: gnome-panel doesn't show all menu items
I confirm that the bug is *still* present in Edgy. And it's *really* annoying! -- gnome-panel doesn't show all menu items https://launchpad.net/bugs/30146 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 67476] Re: Dialogs of background applications pop up in the foreground
I don't know why the bugs I filed *earlier* are being marked as duplicates of this bug -- especially considering that what I reported is much more general than this. The problem is not restricted to dialogs. New windows -- in general -- should not steal the focus. Not only can this be a security issue when entering a password (notice how gksu prevents any window from opening), but it's also inconsistant with the focus follows mouse policy. -- Dialogs of background applications pop up in the foreground https://launchpad.net/bugs/67476 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
Yes, that would make sense because if it's a modal dialog, you can't type in the main application window anyway. That's the only case I see where stealing the focus is OK, and it's not really stealing because that's what a modal dialog does *by definition*. The only question remaining is what would make sense when a new window opens right where the mouse is currently located (assuming focus follows mouse). My best guess would be to not give it focus until the mouse moves. -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
The consisteny issue is about having consistent *security* behaviour. I can't see why some passwords are deemed more important than others. I didn't they that was not a bug, I just wrote that is was not the same issue than the focus issue initially described so it could use a different bug, any issue with that? OK, so I've followed your advice and filed Bug #62893 to have the password security feature of the update-notifier applet removed for consistency reasons (because metacity stealing my ssh password seems to be considered as an important feature). -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
I totally agree. What I don't get is that there's simply no logical justification to the current behaviour (at least when focus follows mouse is selected), yet they still don't want to change it. Sure, maybe Windows does it like that, but Windows doesn't have focus follows mouse either. Two minutes ago, I again accidently typed my ssh password in a newly open window. Fortunately, that window was from a local application (thunderbird), but it's only a matter of time before I get screwed by that. Would anyone who disagrees with fixing the problem care answering these simple questions: 1) Why would anyone want newly open windows to take focus? 2) Why would anyone want that to happen when focus follows mouse is selected? 3) Why should that even be enabled by default? 4) Why should there be no way to even disable the feature? -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
Because your admin password can be immediately used to compromize your computer, whereas your ssh or gpg passwords may or may not be used that way. I would argue the opposite. The sudo password is *by default* useless because ubuntu doesn't install a local ssh server by default. Your outgoing ssh password (on the remote machine) on the other hand can almost always be exploited. However, if you type 'sudo' in the shell, it does not protect your admin password in such a way. So by this argument we should go for consistency and make sure that all apps support the password can be stolen feature in the same way, i.e. remove the shading/blocking of the display when config tools ask for the admin password? I still think this isn't a bug. It might be a feature request, but I would never support it as one either. No matter how you look at it, it *is* a bug. Even if you don't care about sensitive info being released, the fact remains that: 1) giving focus to a new window breaks the focus follows mouse rule if you have it selected (the focus is given to a window that isn't under the mouse pointer). 2) The gconf option to disable the auto-stealing has no effect, so I'm stuck with that bad behaviour even if I'm willing to dig up gconf-editor. Last thing, may I ask what would be so bad with metacity doing the right thing and not letting any new window steal the focus? -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
when you open a new folder with nautilus spatial or an application from the panel menu you probably want them taking the focus instead of having the previous nautilus window of the panel keeping it This may (or may not) be handled as an exception to the don't steal focus rule. Even then, it would be wrong when the user selects focus follows mouse. It's called focus follows mouse, not focus follows mouse, except what a window feels like it should get focus. But at this point, nautilus is actually the only app that (in some circumstances) doesn't steal focus. Still, I see no reason justifying that a window opening unpredictably (e.g. error message, web popup, IM popup) automatically gains focus. The consistency issue is a a bug but that's a different topic of the one discussion initially here so please use a new bug for it so the discussion can be kept on track The consisteny issue is about having consistent *security* behaviour. I can't see why some passwords are deemed more important than others. -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
One thing I would like to point out. A new feature in Dapper is that when starting up an config tool that requires the admin password (e.g. update manager), then the screen goes dark to prevent other windows from opening (and steeling focus) at the same time. Why is it considered that the admin password is worth protecting, but not my ssh password, or my gpg password, ...? -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
Funny, doing the 'sleep 5; nautilus' *and* typing in another window is the first case of things (sort of) behaving correctly. Any process other than nautilus steals the focus. If I try the same with xterm, gnome- terminal, konsole, gimp, ... the new window steals the focus. Clearly, it should be the WM's responsability to enforce sane focus policies, or else we'll end up filing thousands of upstream bugs. Even if it worked, one second timeout isn't very useful because it typically takes more than that between the time you type ssh remote.machine.net and the time you type your password. -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: auto-hidden panel sometime jumps to the top of the screen
The first and third issues are indeed covered in the bugs you linked. The second, however isn't: 2) When clicking on the main menu button, sometimes the panel hides itself and the menu pops up too low -- the bottom of the menu is aligned with the bottom of the screen instead of the top of the (still un-hiden) panel. If you look at the screenshots I attached, they show two bugs at the same time. The one from bug #30146 is that the menus are truncated. The one I had in 2) is that the toplevel menu opened too low (hiding part of the panel). These may or may not be related. -- auto-hidden panel sometime jumps to the top of the screen https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] New windows stealing focus -- and passwords?
Public bug reported: Binary package hint: metacity I'm resubmitting bug #51242 because I'm now convinced it has potential to be successfully exploited remotely to steal user passwords. It basically comes down to the fact that metacity gives by default (which is impossible to change for me) the focus to a newly open window. This can have many hazardous consequences (e.g. typing rm -rf * in the wrong window), but also security implications: Consider Alice logging on to Bob's server with ssh. Malicious user Mallory is already logged on to the server, detects the login attempt (e.g. seeing sshd starting with ps) and automatically sends an IM message to Alice (Hi Alice, how are you?). There is a non-zero probability that Alice will not notice the new IM window instantly and accidently type his/her password right into Mallory's IM window, giving away her password. I think there may also be a way for rogue websites to open unexpected popups. It could be even more effective in some way because the new window can be made very small (unnoticeable if not for the change of the focus) and send the typed text to the attacker directly without the user needing to press the enter key. ** Affects: metacity (Ubuntu) Importance: Untriaged Status: Unconfirmed ** Visibility changed to: Public -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
So your argument is that if a vulnerability has been there for long enough (or affects another OS), it's OK to leave it there? If a user want to be affected by that, it's his/her choice, but the sane behaviour should be the default. Or, in the minimal case, applications that can be controlled remotely (e.g. IM, web browser, IRC client) should *never* grab focus by default. It's just asking for (remotely exploitable) trouble. As to whether it's a good idea to automatically give focus to a window that was explicitly requested by the user, I guess it's debatable. I personally think it's dangerous, especially when your machine is slow because you can open a terminal, not seeing it come up for several seconds (I've seen minutes for a machine swapping heavily) and then go back to another terminal. When the terminal you tried opening shows up, it'll get whatever text you were typing at the moment. Technically, that part wouldn't be a security issue because the worst you can do is deleting your home directory (rm -rf ending up in the wrong terminal window) but nodoby can remotely get you to do that. BTW, I tried: gconftool-2 --set /apps/metacity/general/focus_new_windows --type string strict as suggested by another user and it didn't change anything. Any new window I open still grabs the focus. -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
Have you ever typed your password in clear in another window that just opened? I have -- several times. Usually, it just goes into a local window and only the people around me could see it (which is bad already), but I don't see why it couldn't happen accidently or deliberately through IM or a web browser. We're not talking movie plots -- accidents are bound to happen and I'm sure have happened in the past because of that. In terms of remote exploit, it sure wouldn't be that hard to have a script automatically IM when they attempt to log in. Still requires knowing the person, but it's certainly not a good thing. The chances of succes would probably be in the order of 1-5%: small, but significant if you try several times. Put another way, would you feel safe telling me what your IM nick is and giving me an account on a machine you often ssh to with a password (not ssh key)? It's not like I'm advocating removing a feature or drastically changing anything, just changing the default to something a bit more sane. Stealing focus by default is just plain stupid. It's also totally counter-intuitive when you have the focus follows mouse or sloppy focus policy because you end up with the focus not going to the window that has the mouse in it. So even if it weren't a general hazard, it would still be the wrong behaviour for sloopy/follows mouse focus. So basically, I see many reasons for fixing it and not many for leaving it is (except for everybody else is doing it). -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54741] Re: New windows stealing focus -- and passwords?
that this doesn't seem to be a general nautilus issue I assume you meant metacity issue here. I think there must be some soft of confusion in here. On all three Dapper machines I have, I have yet to see a *single* case of a window opening *without* getting focus. Click on the panel to open a terminal? New terminal opens with the focus. I type xterm in an existing terminal, a new xterm opens with focus. Start any application, either from the panel of from a terminal command line? It comes up with focus. Gaim does that too, so does firefox, *everything*. Even if I try setting metacity to strict focus. It seems like I am not the only why seeing that (see bug #51242), so the only thing I don't understand is why you don't seem to see that. Comes down to two options: 1) we're talking about something different or 2) somehow the problem is triggered by some combination of config options. -- New windows stealing focus -- and passwords? https://launchpad.net/bugs/54741 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51242] Re: New windows shouldn't steal focus
Having a key in gconf is nice, but it doesn't change the fact that automatically giving focus to a new window (by default!) constitutes not only a security issue (typing a passwd in the wrong window), but a potential for data loss (typing rm -rf * in the wrong terminal). Maybe I should file it under security so it gets some attention. The security issue is very real and probably wouldn't be that hard to exploit remotely. Consider Alice logging on to Bob's server with ssh. Malicious user Mallory is already logged on the server and detects the attempt (seeing sshd starting with ps) and automatically sends an IM message to Alice (Hi Alice, how are you?). There is a non-zero probability that Alice will not see the IM window open and accidently type his/her password right into Mallory's IM window, giving away her password. -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51242] Re: New windows shouldn't steal focus
Not sure what's going on with metacity/gconf, but I tried: gconftool-2 --set /apps/metacity/general/focus_new_windows --type string strict and though the setting was changed (checked with gconf-editor), there's no change in metacity's behaviour. -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: Autohide bugs
I've seen the same problem on a panel with default size and with a panel of size 52. I've been trying a bit with the panel at the top. I've tried with the panel up and I haven't been able to reproduce the jumping panel bug. Maybe the bug is only with panel at the bottom or maybe it's because of the way I use it when it's at the bottom. In any case, the bug happens for me about once a day or so. The more vm activity there is, the more the bug happens, which is why I think it's related to timing issues. For example, say the panel has a hide timeout of 300 ms and is currently hidden. I touch it with the mouse pointer to make it show up, but quickly move my pointer away. It seems like the panel starts counting (hide timeout) at the moment I ask it to unhide. If it takes more than 300 ms for the panel to appear (machine swaps), it actually tries to hide itself before it has even unhidden itself from the first action. That leads to strange behaviour like what I describe in this bug report (and other oddities as well). -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: Autohide bugs
Anything else needed to confirm this bug? I would think the screenshots should be enough to see what's going on. -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 36581] Re: gam_server consumes lots of cpu time
Until the problem is fixed, I think Ubuntu should include an option to just disable gamin without having to remove the binary. Considering the little benefit it provides (haven't really noticed a difference after removing it), gamin causes far more harm than it helps. Actually disabling it by default would be even better. -- gam_server consumes lots of cpu time https://launchpad.net/bugs/36581 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
How do I do that? Sorry, not familiar with that bug tracking system. -- Runaway leak in composer https://launchpad.net/bugs/51662 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
I'm running Dapper, but I remember seeing the problem on Breezy (and IIRC earlier) as well. AFAIK, I don't use any special plugin and I don't use the exchange connector. I tried running valgrind but not only is that incredibly slow, but there are hundreds of errors and leaks reported. The summary is: ==17420== ERROR SUMMARY: 10757 errors from 583 contexts (suppressed: 211 from 1) ==17420== malloc/free: in use at exit: 19,248,789 bytes in 292,773 blocks. ==17420== malloc/free: 4,834,032 allocs, 4,541,259 frees, 280,995,543 bytes allocated. ... ==17420== LEAK SUMMARY: ==17420==definitely lost: 26,492 bytes in 541 blocks. ==17420==indirectly lost: 67,047 bytes in 1,625 blocks. ==17420== possibly lost: 375,893 bytes in 557 blocks. ==17420==still reachable: 18,779,357 bytes in 290,050 blocks. ==17420== suppressed: 0 bytes in 0 blocks. As I mentioned earlier, the problem only happens once every few weeks (but crashes my machine 50% of the time), so it's hard to reproduce. Unfortunately, it's just not feasible to run evolution under valgrind all the time. -- Runaway leak in composer https://launchpad.net/bugs/51662 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Re: Runaway leak in composer
Well, any suggestion as to how to obtain debug info? It's not like using valgrind+evolution as my main mail client for weeks is a realistic option. Not to mention the fact that even if that was possible, valgrind would have reported so many errors already that the real one would be buried in Megabytes of data. I'm open to other methods, though. -- Runaway leak in composer https://launchpad.net/bugs/51662 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51662] Runaway leak in composer
Public bug reported: Binary package hint: evolution Every once in a while, the evolution composer becomes out of control while leaking memory. This usually makes my system completely unresponsive within about 10-30 seconds. Evolution's memory footprints grows at a very fast rate until it gets killed by the OOM or I hit the power button (whichever comes first depending on the amount of swap space I have). I have noticed that this tends to happen just after I paste some text in the window, but I have not found a way to reliably reproduce the problem. This is quite a severe problem because the leak happens so fast that I don't have time to react and kill evolution before the system becomes unresponsive. On any machine with more than 1 GB swap, the result is a complete lockup -- there's no way out of this than to reboot the machine because the swapping goes on forever. ** Affects: evolution (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Runaway leak in composer https://launchpad.net/bugs/51662 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51242] Re: New windows shouldn't steal focus
I sometimes use the panel, sometimes the terminal. I don't see what it changes. In all cases, the windows that open get focus automatically, which is just plain bad. -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51242] Re: New windows shouldn't steal focus
OK, just trying to understand... Are you telling me that on your machine, the windows popup without gaining focus automatically? This happens on all three Dapper (and previous releases) machines I have, so I just assumed that it was the case for everyone. -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51242] Re: New windows shouldn't steal focus
Bug #43760 was more about the fact that evolution shouldn't make warnings pop all the time. I think this bug is more fundamental in the sense that even if popping up a window is justified, it is *never* (I still haven't found a counter-example) justified to make the new window steal focus. It's a very dangerous thing to do. Most (older) window managers used to have an option to control that. Not only did metacity remove that option, but it left the bad behaviour as the only option available. Here's another case to consider -- a bit unlikely, but quite catastrophic. 1) My system has a high load and is slow 2) I fire up a terminal, but it takes a long time before showing up 3) I go back to another terminal and in some directory, I type rm -rf * 4) A fraction of a second before 3) happens, my new terminal pops up and steals focus (without me noticing) 5) I just deleted my entire home directory because I didn't notice 4) fast enough. I'd basically call this a user-based race condition. -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 51242] New windows shouldn't steal focus
Public bug reported: Binary package hint: metacity Whenever a new window pops up on Dapper, metacity assigns the focus to it. This is bad behaviour. While Dapper solved the problem for some password entries, it remains that whenever typing in a terminal or text editor, one never knows if/when a popup will appear and where the text will end up. For example, I could by typing my ssh password in a terminal and a browser window pops up -- next thing I know, I just hit return and submitted my password to some random site. ** Affects: metacity (Ubuntu) Importance: Untriaged Status: Unconfirmed -- New windows shouldn't steal focus https://launchpad.net/bugs/51242 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: Autohide bugs
** Attachment added: Screenshot http://librarian.launchpad.net/3153315/panel_bug.png ** Attachment added: screenshot (no bug) http://librarian.launchpad.net/3153327/panel_nobug.png -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 50852] gam_server eats all CPU on Dapper
Public bug reported: Binary package hint: gamin It seems like gamin is still not fixed in Dapper. It would eat all available CPU on my machine and would respawn automatically when killed (killing it on Breezy used to at least work for a while). The only way I've been able to solve my problem is to remove the binary. Would be nice if it was either fixed or finally eliminated from the distribution. ** Affects: gamin (Ubuntu) Importance: Untriaged Status: Unconfirmed -- gam_server eats all CPU on Dapper https://launchpad.net/bugs/50852 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 50854] gnome-cups-icon memory leak in Dapper
Public bug reported: Binary package hint: gnome-cups-manager I think I've encountered a bad memory leak in gnome-cups-icon. Basically, ps gives me: % ps aux | grep cups-icon jm 27444 0.2 7.6 217880 79300 ?Ss Jun07 64:34 gnome-cups-icon --sm-config-prefix /gnome-cups-icon-ZEJuRy/ --sm-client-id 1030a3bec80001132633350007725 --screen 0 To make sure it's not just shared (virtual) mem, I tried killing it and seeing the impact of free (real) memory: % free total used free sharedbuffers cached Mem: 1036000 805184 230816 0 3104 87528 -/+ buffers/cache: 714552 321448 Swap: 1023992 977464 46528 % killall gnome-cups-icon % free total used free sharedbuffers cached Mem: 1036000 722640 313360 0 3392 91068 -/+ buffers/cache: 628180 407820 Swap: 1023992 890556 133436 This means that gnome-cups-icon was really using about 160 MB of memory, which it totally unacceptable even if it's not a leak. ** Affects: gnome-cups-manager (Ubuntu) Importance: Untriaged Status: Unconfirmed -- gnome-cups-icon memory leak in Dapper https://launchpad.net/bugs/50854 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: Autohide bugs
Not sure if would be part of the same bug because it's not only with auto-hide. When the icons on the main menu take too long to load, the menu shows up with the size it would take without the icons. Then, when the icons appear, the menu does not grow and a vertical scrollbar appears on the menu. This means that the appearance of the menus ends up depending on the speed of the disk you have -- at least the first time you use them. -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: Autohide bugs
The following setup should make it easier to reproduce the bug: 1) Turn auto-hide on (of course) with an un-hide timeout of 0 2) Turn the HD DMA off 3) Make sure that the machine is swapping a bit 4) Lower the CPU frequency (e.g. 600 MHz - 1 GHz) This is obviously extreme, but it should make the problem happen more often. My actual setup (where the bug still happens) is: Pentium-M 2.13 GHz (with powernowd often reducing speed to 800 MHz) 1 GB RAM, no swap HD DMA on. -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: Autohide bugs
One note about the second one. Because the menu is displayed too low, it sometimes happen that simply clicking on the main menu ends up selecting Quit (which is the first element) at the same time. Quite annoying. -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Re: Autohide bugs
Oh and 3) The Deskbar applet doesn't cope well with auto-hide at all. When moving the cursor on the popup list, the panel hides itself. When moving the cursor back to the panel, the list disappears. -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48226] Autohide bugs
Public bug reported: Binary package hint: gnome-panel I'm noticing two (probably related) problems with the panel in autohide mode. Both seem to have to do with timing: 1) Sometimes when the panel un-hides, it jumps to the top of the screen (I have it at the bottom) so I need to move it down. This typically happens about twice a day. 2) When clicking on the main menu button, sometimes the panel hides itself and the menu pops up too low -- the bottom of the menu is aligned with the bottom of the screen instead of the top of the (still un-hiden) panel. In both these cases, it seems to happen when un-hiding the panel (or bringing up the menu) requires a disk access (swap or files not in OS cache), causing a slight delay. That's why I'd say it's probably timing-related. ** Affects: gnome-panel (Ubuntu) Severity: Normal Priority: (none set) Status: Unconfirmed -- Autohide bugs https://launchpad.net/bugs/48226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
