Militantly FREE software support.
Militantly FREE software support.
NavigationUser loginLinux NewsClick the above for your daily dose of Linux news. Food for ThoughtWindows Error: 002 - No error yet ... Spam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. |
Major application resource leaks in EtchWhile copying 30MB of text from a backuppc (web-based) log on a remote server, I 1) Selecting the text using the Iceape edit->select-all menu option pegs the 2) Each repetition causes two 60MB clipboard cache files to appear in /tmp. 2) Pasting the text into kedit, or cutting it, pegs the CPU from 10s of seconds Since I am aware of the clipboard files I probably could probably safely delete It doesn't appear to be Etch-specific. I duplicated the problem in Sarge using -- Bookmark/Search this post with: 
|
• Debian Weekly News - Essential reading for any Debian fan. • Documentation - Debian's own authoritative documentation, including installation docs. • FAQ - Got questions about Debian GNU/Linux? • From Windows to Debian - Tips for converting from Windows to Debian GNU/Linux • Package of the Day. • Security - Security information and alerts! • Bug System - Bug tracking and instructions on reporting bugs. • CD Images - Where/how to get Debian GNU/Linux CD images. • Mailing List Subscription - Dozens of Debian-specific support mailing lists! • Mailing List Archives - Searchable archives of Debian's mailing lists. • Free Software Guidelines - Learn Debian's idea of what "free" software really is. • Package Listings - A very valuable tool: searchable, integrated with bug reports. • Apt-Get Sources - Sources for *.debs which are not official Debian packages. • Backports - Unofficial new software packages that have been "back-ported" to work with the Debian stable/official release. • Developer's Corner - Info about the people behind Debian, policies, and how to package *.deb files.
Major application resource leaks in Etch
On Sun, Sep 30, 2007 at 06:59:03PM -0400, Marty wrote:
> While copying 30MB of text from a backuppc (web-based) log on a remote
> server, I ran into several problems:
>
> 1) Selecting the text using the Iceape edit->select-all menu option pegs
> the 2.8GB CPU at 100% for tens of seconds, although it is much faster in
> subsequent attempts.
>
> 2) Each repetition causes two 60MB clipboard cache files to appear in /tmp.
> They persist after logging out of Gnome.
>
Are you sure that this is a resouce leak? Think of what Iceape is
trying to do: download 30 MB of text and render it all ready to show
you. Was Iceape designed to handle 30 MB pieces of text?
If you can't pull the data with ftp or somethin, what about using lynx?
Text browsers don't have to render. Download the text and save it to a
file. Or if its already being viewed, 'Print' it to a file. Once you
have your 30 MB text file, then you can edit it if you really want.
Doug.
--
Major application resource leaks in Etch
Douglas A. Tutty wrote:
> On Sun, Sep 30, 2007 at 06:59:03PM -0400, Marty wrote:
>> While copying 30MB of text from a backuppc (web-based) log on a remote
>> server, I ran into several problems:
>>
>> 1) Selecting the text using the Iceape edit->select-all menu option pegs
>> the 2.8GB CPU at 100% for tens of seconds, although it is much faster in
>> subsequent attempts.
>>
>> 2) Each repetition causes two 60MB clipboard cache files to appear in /tmp.
>> They persist after logging out of Gnome.
>>
>
>
> Are you sure that this is a resouce leak?
I have reproduced it on two systems, with different distributions and different
browsers, but there is still some uncertainty since all my systems have similar
configurations, so I can't rule out misconfiguration.
Think of what Iceape is
> trying to do: download 30 MB of text and render it all ready to show
> you. Was Iceape designed to handle 30 MB pieces of text?
I don't know.
>
> If you can't pull the data with ftp or somethin, what about using lynx?
> Text browsers don't have to render. Download the text and save it to a
> file. Or if its already being viewed, 'Print' it to a file. Once you
> have your 30 MB text file, then you can edit it if you really want.
True, but that doesn't address the potential resource leak issue. Moreover,
since it appears in different browsers, and seems to affect kedit, it seems
likely that the problem involves Gnome's clip board (which reminds me that I
forgot to mention that I am using Gnome).
--
Major application resource leaks in Etch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/30/07 21:42, Marty wrote:
> Douglas A. Tutty wrote:
>> On Sun, Sep 30, 2007 at 06:59:03PM -0400, Marty wrote:
>>> While copying 30MB of text from a backuppc (web-based) log on a
>>> remote server, I ran into several problems:
>>>
>>> 1) Selecting the text using the Iceape edit->select-all menu option
>>> pegs the 2.8GB CPU at 100% for tens of seconds, although it is much
>>> faster in subsequent attempts.
>>>
>>> 2) Each repetition causes two 60MB clipboard cache files to appear in
>>> /tmp. They persist after logging out of Gnome.
>>>
>>
>>
>> Are you sure that this is a resouce leak?
>
> I have reproduced it on two systems, with different distributions and
> different browsers, but there is still some uncertainty since all my
> systems have similar configurations, so I can't rule out misconfiguration.
>
> Think of what Iceape is
>> trying to do: download 30 MB of text and render it all ready to show
>> you. Was Iceape designed to handle 30 MB pieces of text?
>
> I don't know.
>
>>
>> If you can't pull the data with ftp or somethin, what about using lynx?
>> Text browsers don't have to render. Download the text and save it to a
>> file. Or if its already being viewed, 'Print' it to a file. Once you
>> have your 30 MB text file, then you can edit it if you really want.
>
> True, but that doesn't address the potential resource leak issue.
> Moreover, since it appears in different browsers, and seems to affect
> kedit, it seems likely that the problem involves Gnome's clip board
> (which reminds me that I forgot to mention that I am using Gnome).
Doug is absolutely correct. Putting a 30MB file into the clipboard
is going to is a lot of resources.
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHAG0wS9HxQb37XmcRAlf6AJ9bwPmQUOhPm7EaUuTi9bCemu6E7gCgi+tb
Qi8UAUXnbnhwQTEpZsXuqZ0=
=Ae0W
-----END PGP SIGNATURE-----
--
Major application resource leaks in Etch
On Sun, 30 Sep 2007, Ron Johnson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/30/07 21:42, Marty wrote:
>> Douglas A. Tutty wrote:
>>> On Sun, Sep 30, 2007 at 06:59:03PM -0400, Marty wrote:
>>>> While copying 30MB of text from a backuppc (web-based) log on a
>>>> remote server, I ran into several problems:
>>>>
>>>> 1) Selecting the text using the Iceape edit->select-all menu option
>>>> pegs the 2.8GB CPU at 100% for tens of seconds, although it is much
>>>> faster in subsequent attempts.
>>>>
>>>> 2) Each repetition causes two 60MB clipboard cache files to appear in
>>>> /tmp. They persist after logging out of Gnome.
>>>>
>>>
>>>
>>> Are you sure that this is a resouce leak?
>>
>> I have reproduced it on two systems, with different distributions and
>> different browsers, but there is still some uncertainty since all my
>> systems have similar configurations, so I can't rule out misconfiguration.
>>
>> Think of what Iceape is
>>> trying to do: download 30 MB of text and render it all ready to show
>>> you. Was Iceape designed to handle 30 MB pieces of text?
>>
>> I don't know.
>>
>>>
>>> If you can't pull the data with ftp or somethin, what about using lynx?
>>> Text browsers don't have to render. Download the text and save it to a
>>> file. Or if its already being viewed, 'Print' it to a file. Once you
>>> have your 30 MB text file, then you can edit it if you really want.
>>
>> True, but that doesn't address the potential resource leak issue.
>> Moreover, since it appears in different browsers, and seems to affect
>> kedit, it seems likely that the problem involves Gnome's clip board
>> (which reminds me that I forgot to mention that I am using Gnome).
>
> Doug is absolutely correct. Putting a 30MB file into the clipboard
> is going to is a lot of resources.
>
> - --
> Ron Johnson, Jr.
> Jefferson LA USA
>
> Give a man a fish, and he eats for a day.
> Hit him with a fish, and he goes away for good!
>
Just did a little test here, I made up a 30M file, loaded it up in firefox
.. takes forever to load it and then a while to copy it. I tested this out
on a debian system and on mac book (even tested out safari, which was even
worse). But I also ran the same open/copy/paste in gvim, that did it like
a charm, system barely broke a sweat.
-+-
8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno.
--
Major application resource leaks in Etch
>Just did a little test here, I made up a 30M file, loaded it
>up in firefox .. takes forever to load it and then a while
>to copy it. I tested this out on a debian system and on mac
>book (even tested out safari, which was even worse). But I
>also ran the same open/copy/paste in gvim, that did it like
>a charm, system barely broke a sweat.
The HTML viewers will attempt to load absolutely everything into memory and render one giant bitmap to scroll through because that's how web pages generally work (unless you stream data to a plugin in which case the data may in turn be streamed to a temporary file).
I don't know if gvim loads parts at a time only, but it certainly only renders one screen at a time so you don't have an enormous bitmap.
You're using the browser for something it was not designed for - although you may want to bring this behavior to the attention of browser developers, I doubt that they'll do anything unless it poses some risk (like effective denial of service) - otherwise they're likely to just say browsers aren't made for that job. In fact I doubt this is an issue that a particular browser team would want to address on their own - sounds like something for the W3C.
Major application resource leaks in Etch
On Sun, Sep 30, 2007 at 10:44:48PM -0500, Ron Johnson was heard to say:
> Doug is absolutely correct. Putting a 30MB file into the clipboard
> is going to is a lot of resources.
It'll use a lot of resources -- but if I understood the OP correctly,
the resources weren't being released when the file was removed from the
clipboard. That sounds like a bug to me.
Daniel
--
Major application resource leaks in Etch
On Wed, Oct 03, 2007 at 06:14:03PM -0700, Daniel Burrows wrote:
> On Sun, Sep 30, 2007 at 10:44:48PM -0500, Ron Johnson was heard to say:
> > Doug is absolutely correct. Putting a 30MB file into the clipboard
> > is going to is a lot of resources.
>
> It'll use a lot of resources -- but if I understood the OP correctly,
> the resources weren't being released when the file was removed from the
> clipboard. That sounds like a bug to me.
not following this thread, but putting 30M in the clipboard is sure to
be a little, ummmm, strenuous. And pasting it somewhere doesn't remove
it from the clipboard, just copies into whatever poor app happened to
get the paste. So in theory, there are now three copies of that
monster clipboard floating around 1) in the original app, 2) in the
clipboard, and 3) in the new app. THat's 90M of extra stuff just
floating around in memory.
A
Major application resource leaks in Etch
On Sun, Sep 30, 2007 at 09:36:54PM -0400, "Douglas A. Tutty" was heard to say:
> If you can't pull the data with ftp or somethin, what about using lynx?
> Text browsers don't have to render. Download the text and save it to a
> file. Or if its already being viewed, 'Print' it to a file. Once you
> have your 30 MB text file, then you can edit it if you really want.
Of course, the preferred tool would be wget. :-)
Daniel
--