Version: (using KDE KDE 3.1) Installed from: Gentoo Packages Compiler: various OS: Linux while rendering http://www.rpgworldcomic.com/, konqueror uses >100MB of Ram, which is freed after the page is displayed completely. The page has about 50kb html code, nearly no CSS, and some javascript code which works correctly on other pages in the keenspot network (www.keenspot.com) So I guess the problem lies somewhere in the html, but I could not find any strange html parts which could be responsible for this behavior.
Forgot to mention: Tried it with various kde versions (3.0.x, 3.1rc6 and 3.1.0), SuSE RPMs, gentoo compiled packages, redhat RPMs and various self-compiled versions on Solaris all with the same result.
Just checked the page again, the reason is a 1500x6000 pixels background image. So I suggest merging this bug with Bug #39693
What I did note was that this page seems to load a flash-movie (swf_play over nspluginviewer) what does take some ram away till it's loaded. I use cvs from today and wasn't able to reproduce the 100mb ram-usage anyway. Maybe it's already fixed or the plugin is the reason? I guess it would help if you could try it again with disabled plugins and later with javascript to be able to say where the problem could be located.
Its definitly the background image. But there seems to be some progress on this issue (not sure if its the 3.2 QT or in kdelibs) Kuickshow handles large images quite nicely now, xpertmud (a kde mud client) could save a 5000x5000 pixels map image using only like 90megs of ram (compared to like 500MB with kdelibs 3.1), but konqi still doesn't handle them well... Simple do-it-yourself testcase: generate a large image file (like 5000x5000 pixels, all white), test.png write a small html file: <html><body background="test.png">Test</body></html> open it with konqueror. watch it consume like 150MB of ram while rendering, releasing the memory after the page is rendered. (tested it on 3.2beta1, the bug was still there)
Well, rpgworldcomic.com had a redesign, and isn't using that large background image any more. I'll mark this report as resolved, but the bug is of course still there (but already adressed in Bug #39693)