|
Bugzilla – Full Text Bug Listing |
| Summary: | knotify - RES 314m | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Karl Eichwalder <ke> |
| Component: | KDE | Assignee: | E-mail List <kde-maintainers> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | al4321, edwardsg |
| Version: | Preview 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Documentation | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | backtrace of running knotify | ||
|
Description
Karl Eichwalder
2005-07-21 11:40:36 UTC
The "how to reproduce" part seems to be insufficient. I logged into l23, ran gnome-session, started the "SUSE help center", viewed a couple of GNOME apps documents and I don't even get knotify running let alone consuming lots of memory. Can you really reproduce it just by doing that? Thanks for checking. Unfortunately I do not know what actually causes knotify to eat that much memory. Some weeks ago I observed a similar behavior on my workstation that runs "STABLE" (10.0 ~snapshot1). IIRC, I triggered it on a GNOME desktop by starting kprinter or the helpcenter. If you cannot reproduce it feel free to resolve the report with WORKSFORME or REMIND. It just occured again, this time on preview3. For testing the SUSE helpsystem and the integration of the manuals I called "susehelp" approx. 10 x; and then I saw: ke@L23:~> ICE default IO error handler doing an exit(), pid = 24649, errno = 32 ke@L23:~> logout And L23 was nearly frozen (I couldn't exit from my ssh session): top - 14:05:42 up 21:06, 1 user, load average: 2.19, 1.36, 1.03 Tasks: 60 total, 1 running, 59 sleeping, 0 stopped, 0 zombie Cpu(s): 4.1% us, 0.2% sy, 0.0% ni, 95.2% id, 0.4% wa, 0.0% hi, 0.0% si Mem: 515840k total, 509612k used, 6228k free, 1120k buffers Swap: 1048784k total, 524728k used, 524056k free, 5596k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12840 root 16 0 78344 1048 624 S 2.0 0.2 0:44.29 X 24649 ke 18 0 717m 425m 1164 D 2.0 84.5 37:12.53 knotify 25143 root 15 0 2092 876 672 R 2.0 0.2 0:00.01 top Still no luck. Can you impose memory ulimit on it and provide a backtrace after it crashes due to insufficient memory[*]? [*] Something like 'ulimit -c unlimited -v 256000' could do, then simply 'gdb knotify core', 'bt'. "[16:02:54] <coolo> Seli: add to the bug report, that gdb won't work after the ulimit :)" *** Bug 103947 has been marked as a duplicate of this bug. *** Would a backtrace from attaching to the process with gdb be worth anything? If so I can install the debuginfo packages and get a backtrace. absolutely. another possibility would be to notify one of us and let it debug it on your machine (if its accessible somehow). Marcus Schaefer has a similar issue on his system. I have a vague idea that it can be caused, when kdemm isn't able to load any module for unknown reason. I will look inside this. I think kdemm not being started in a GNOME session may be the problem. I got a backtrace of a running knotify. It appears to repeat over and over again. Most of the functions having to do with KDE multimedia. I will attach a sample of the backtrace. Created attachment 45814 [details]
backtrace of running knotify
kdemm is not a process, it is an API. I fixed some issues inside it, maybe also this one. I am not sure yet, if the fixes will be part of beta2. possible this bug and bug #104410 are duplicates. If this bug is the one that causes my sound system to fail after some time, then Please change the priority to high and severity to critical. we believe it's kind of fixed. *** This bug has been marked as a duplicate of 104410 *** |