Version: 2.2rc1 (using KDE KDE 3.4.0) Installed from: Mandriva RPMs Compiler: gcc-3.4.3 OS: Linux top shows me that, while kmix is running, it is conistantly taking 5-8% of my 2GHz CPU. Should this be expected and why? PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND ... 18779 ddurham 15 0 26224 11m 9664 S 5.8 4.7 0:49.00 kmix ...
This is a bug reporting and tracking site, not a discussion forum. If you believe this to be a bug, phrase it like so. Your report is asking for information, so you should be going to a mailing list or web forum. PS: I don't see the same happening in my system.
Sorry.. I thought the bug-ness of this description would be seen in the fact that kmix is taking substantial CPU time while perhaps the only thing it needs to be doing is polling the mixer device every so often. One thing that might need to be know is that this linux install is running on vmware. Perhaps there are some extra expenses in querying the mixer device.. I might try to build kmix myself and debug it.
same thing here... running kdelibs 3.5rc1, and everything else in beta2 (sorry process of upgrading) even though KDE has been compiled with full debugging symbols (tested). my system seems to have lost communication with the process and I can't get a real backtrace... although the result from GDB is still interesting.. something that looks like an infite loop.... Attaching to program: /usr/kde/3.5/bin/kmix, process 9506 Failed to read a valid object file image from memory. 0xb77e335f in ?? () (gdb) bt #0 0xb77e335f in ?? () #1 0xbfc6db18 in ?? () #2 0xb7296cb6 in ?? () ...... many pages later .... #1404 0x00000000 in ?? () #1405 0x00000000 in ?? () #1406 0x00000000 in ?? () #1407 0x00000000 in ?? () #1408 0x00000000 in ?? () #1409 0x00000000 in ?? () #1410 0x00000000 in ?? () #1411 0x00000000 in ?? () ...... many pages later .... #2372 0x00000000 in ?? () #2373 0x00000000 in ?? () #2374 0x00000000 in ?? () #2375 0x2f000000 in ?? () #2376 0x2f727375 in ?? () #2377 0x2f65646b in ?? () #2378 0x2f352e33 in ?? () #2379 0x2f6e6962 in ?? () #2380 0x6965646b in ?? () #2381 0x0074696e in ?? () #2382 0x00000000 in ?? () Cannot access memory at address 0xbfc70000 (gdb) (gdb) so many HOP .... so many zeros..... ... I'd reclassified this bug a crash with a major severity. cuz the only solution is to kill the program. it made my system unsuable and .... kdebase try to compil over night and after more than 7h... no success... (usually takes 90mins top) which means... kmix was just taking it all ....
sorry for second email, keep forgetting the CC: maybe a checkmark (check by default) that says add me too CC: on comment would be the best ;) heeh
Matthieu, please try this: 1a) Kill all kmix processes 1b) Start KMix like this: kmix --nofork --nocrashhandler Then try to attach to the KMix process (probably early). Then please report what you find. If it doesn't work, try this alternative: 2a) Kill all kmix processes 2b) Start KMix like this: LD_BIND_NOW=true export LD_BIND_NOW gdb kmix # Use a "sensible" kmix executable here, like .libs/kmix # On the gdb prompt run --nofork --nocrashhandler
Mathieu, my original problem is kmix's CPU usage.. I can't tell from your description if that's your issue too or not.
sorry, I was about to create a new ticket and I saw yours and I just jumped on it .... if it's unrelated and you guys prefer so, I can create a separate ticket for my bug (Christian?)
Davy: You are reporting versions KMix 2.2rc1 and KDE 3.4.0. These versions are *not* compatible. It looks like Mandriva has done a strange built. For seeing the correct revison, open http://websvn.kde.org/tags/KDE/3.4.0/kdemultimedia/kmix/ , and click the "Rev." column in the "version.h" row. Result: APP_VERSION "2.4". I really cannot support this version, as I have no idea, what version Mandriva actually picked (probably something between 2.2rc1 and 2.4). So my advice for you is to upgrade to a clean version.
Mathieu: The originial report is not about a crash, but that KMix takes n% of processing time on a fast processor. Is this the case for you? My advice: Please upgrade also kdemultimedia to RC1, and if the problem persist, then follow my instructions from comment 5. In any case, please report back (in this bug report for now).
For clarity reasons: I am only dealing with Davy Durham's original bug report here. Anybody else: If there is a KMix problem left in KDE3.5 or newer, please open a new bug report. Thanks. Davy: KMix used to be "polling" the soundcard for changes. On a slow processor (100-200MHz), and many controls, this could lead to processor usage. But I don't believe this. I'd like to state two comments: 1) There was a bug in the "polling" code, that could lead to all kind of weirdnesses, including (but not limited to) a crash of KMix. I believe that this could be the reason for the CPU load problem. 2) Polling has been changed (for operating systems using ALSA) in KDE3.5 to an event-driven approach. This puts down load, and is very laptop friendly. Thus I am quite sure the problem is fixed. Davy, when you update to KDE3.5 or newer, please report back here. In the meantime I am closing this bug report (we can reopen in the unlikely case that the problem persists).