FS#37617 - [kdenlive] Issue with glibc lock elision implementation for Haswell CPU
Attached to Project:
Community Packages
Opened by Alphazo (alphazo) - Sunday, 03 November 2013, 10:17 GMT
Last edited by Sergej Pupykin (sergej) - Monday, 24 February 2014, 08:50 GMT
Opened by Alphazo (alphazo) - Sunday, 03 November 2013, 10:17 GMT
Last edited by Sergej Pupykin (sergej) - Monday, 24 February 2014, 08:50 GMT
|
Details
I just installed ArchLinux on a brand new Intel i7 4770S
(Haswell) because my old laptop was unable to handle HD
content properly under Kdenlive. I have the exact package
versions on both machines but when disabling a simple effect
in Kdenlive I get a seg fault on the new machine.
You can see my bug report on Kdenlive bug tracker here: http://www.kdenlive.org/mantis/view.php?id=3186 I then looked at the trace and found this stuff about lock elision that seems very (hardware) specific to Haswell CPU. http://lwn.net/Articles/534758/ http://halobates.de/adding-lock-elision-to-linux.pdf http://www.phoronix.com/scan.php?page=n … px=MTQzNDk http://www.anandtech.com/show/6290/maki … tensions/2 I looked at the PKGBUILD for the current glibc 2.18-9 and it has the "--enable-lock-elision" so I used ABS to recompile it without support for it to see if it would make my Kdenlive work again. And yes problem is gone. Is this a problem with Kdenlive code or lock elision implementation in current glibc when ran on Haswell processors ? Don't know if this is related but I also had some issues with Digikam when using the default glibc. |
This task depends upon
Closed by Sergej Pupykin (sergej)
Monday, 24 February 2014, 08:50 GMT
Reason for closing: Fixed
Additional comments about closing: patch applied
Monday, 24 February 2014, 08:50 GMT
Reason for closing: Fixed
Additional comments about closing: patch applied
Thread 1 (Thread 0x7ffff7f957c0 (LWP 8517)):
#0 0x00007ffff48dd1b8 in __lll_unlock_elision () from /usr/lib/libpthread.so.0
#1 0x00000000006cec6b in ?? ()
#2 0x000000000058355c in ?? ()
#3 0x000000000046ea4f in _start ()
Can you rebuild kdenlive without stripping debug symbols - options=('!strip') - and post the backtrace again.
I'll also need clarification on whether the digikam issue is related at all...
No symbol table info available.
We don't strip that library so why is there no information here?
Anyway - I don't know how to take this further. Hopefully the bug report I see you opened on the glibc tracker gets some traction.
pacman -U http://allanmcrae.com/tmp/glibc-2.18.90.20140105-1-x86_64.pkg.tar.xz
https://retrace.fedoraproject.org/faf/problems/1450092/
https://retrace.fedoraproject.org/faf/problems/1469298/
https://retrace.fedoraproject.org/faf/problems/1446340/
Did you manage to test if it was just kdenlive having issues on your system?
http://quickgit.kde.org/?p=kdenlive.git&a=commitdiff&h=d049b327afc02b499266b5c895b13e438490b7c0&o=plain