Summary: | sched_setaffinity() call freezes Amarok | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Cezary Krzyżanowski <dhubleizh> |
Component: | general | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED NOT A BUG | ||
Severity: | crash | CC: | lemma |
Priority: | NOR | ||
Version: | 1.4.4 | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Cezary Krzyżanowski
2006-11-15 15:09:06 UTC
OK - two more things: 1. I've installed 32 bit version of amarok on that machine, with all it's deps (glibc, kdelibs and aaaaal the stuff), but the result is the same (running on a 64 system, but with all amarok dependant libs in 32 bit) 2. After amarok hangs, other apps are prone to hang as well, i.e. iptables (I've found more of those, but don't remember which programms hung). Yep, I've seen the same reported recently. Seems to a be a problem with sched_setaffinity(). Workaround: Comment out the fixHyperThreading() call at the top of app.cpp. But then Amarok might become somewhat unstable for you, since you have a SMP box. Building 1.4.4 with that function commented out allows me to run amarok. So far so good, but stay put - that isn't a fix to the problem in a strict matter. [root@melchior SPECS]# ps auxwwwt | grep amarok czarny 9294 0.0 0.9 114568 7204 ? S 21:37 0:00 kio_file [kdeinit] file /home/users/czarny/tmp/ksocket-czarny/klauncherpK46Ia.slave-socket /home/users/czarny/tmp/ksocket-czarny/amarokNRbvFb.slave-socket czarny 9314 0.0 1.2 161628 9532 ? S 21:37 0:00 kio_http [kdeinit] http /home/users/czarny/tmp/ksocket-czarny/klauncherpK46Ia.slave-socket /home/users/czarny/tmp/ksocket-czarny/amarokdfREjc.slave-socket czarny 9348 5.8 20.0 516860 153800 ? Sl 21:38 0:16 amarokapp [root@melchior SPECS]# file /usr/bin/amarok /usr/bin/amarok: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.12, dynamically linked (uses shared libs), for GNU/Linux 2.6.12, stripped [root@melchior SPECS]# uname -a Linux melchior 2.6.18.2-0.2smp #1 SMP Mon Nov 13 11:26:19 CET 2006 x86_64 AMD_Athlon(tm)_64_X2_Dual_Core_Processor_3600+ unknown PLD Linux [root@melchior SPECS]# gcc -v Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.1.2/specs Target: x86_64-pld-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-shared --enable-threads=posix --enable-languages=c,c++,fortran,objc,obj-c++,ada,java --enable-c99 --enable-long-long --enable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib64 --without-system-libunwind --enable-cmath --with-long-double-128 --with-gxx-include-dir=/usr/include/c++/4.1.2 --disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=new --with-qt4dir=/usr/lib64/qt4 --disable-libjava-multilib --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo --enable-java-awt=qt,gtk,xlib --enable-jni --enable-xmlj --enable-alsa --enable-dssi x86_64-pld-linux Thread model: posix gcc version 4.1.2 20060928 (prerelease) (PLD-Linux) I don't understand. What happens? As You've mentioned before, commenting out that functions leeds to unstability ond smp platofrms and as said it is reality. I mainly listen to internet radios, in the evening some mp3 and (espiecially with the radios) I get a random hang. Just the player stops playing, needs killing and restarting, sometimes more then once to get the stream back. I just mentioned with the post above, that commenting out the function isn't a real resolution to the problem, just a temporary fix. Got that same problem (I've mentioned it (my nickname was vipw) on #amarok freenode channel two days ago, talked with sebr and with You Mark). My straces were at http://chimera.one.pl/amarok/. That problem exists on current svn and 1.4.4. After commenting that line, amarok works well (haven't noticed any problems). comment from KDE bugsquad member Does that problem still happen for you with a vanilla compile of Amarok? I'm running 1.4.9.1 on a 2.6.23.9 SMP kernel and I'm not having any crashes. (Same for current Amarok2 trunk r820602. Closing due to lack of feedback. |