[opensuse-factory] Calligra: core dumped
I am getting this message whenever I try to start any calligra package in Tumbleweed: ~ calligraflow [1] 5686 illegal hardware instruction (core dumped) calligraflow This happens with every calligra package, but I have no idea how to even begin figuring out what the problem is. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
You can get a bit more information from dmesg. But the really useful thing is the core dump. Unfortunately, systemd loves to mess around with coredumps (because that's what systemd does) so you'll have to sue coredumpctl or look inside /var/lib/systemd/coredump to find it. You could also play around with the kernel.core_pattern sysctl. Anyway, once you have the coredump you can run gdb on it and debug to your heart's content. Specifically you can look at the state of the registers and disassemble the instructions you were trying to execute. You could also try running calligraflow in a gdb session to get even more information. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Sonntag, 23. Oktober 2016, 09:03:03 CEST schrieb Todd Rme:
I'm far from being an expert on coredump handling, but I can at least get you started. I'd guess you have the coredump in /var/lib/systemd/coredump/ If so, coredumpctl list should list it, and coredumpcctl gdb calligraflow should open gdb with the coredump loaded. (I'm not sure about the exact "coredumpctl gdb" syntax - if the above doesn't work, use the result from "coredumpctl list" as parameter.) Inside gdb, run bt to get a backtrace. (You might need to install some debuginfo packages to get a useful backtrace, and gdb will even tell you the zypper command to install them.) If the backtrace doesn't tell you anything, poste it here - or open a bugreport and include it, because you'll probably end up with a bugreport anyway ;-) (as usual, please report back the bug number here) Regards, Christian Boltz --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I have taken the debuging information as far as I can, but I am concerned something is still missing. I don't know how to make much sense of this, but it keeps mentioning this Vc program. Vc only provides a -devel and -devel-static package. I can't find any -debuginfo or -debugsource packages. So I am not sure if this backtrace is useful or not. (gdb) exec-file /usr/bin/calligrawords (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/calligrawords [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. Vc::CpuId::init () at /usr/src/debug/Vc-0.7.5/src/cpuid.cpp:135 135 /usr/src/debug/Vc-0.7.5/src/cpuid.cpp: No such file or directory. (gdb) bt #0 0x00007fffef9ced85 in Vc::CpuId::init() () at /usr/src/debug/Vc-0.7.5/src/cpuid.cpp:135 #1 0x00007fffef9ce2d8 in Vc::isImplementationSupported(Vc::Implementation) (impl=impl@entry=Vc::AVXImpl) at /usr/src/debug/Vc-0.7.5/src/support.cpp:57 #2 0x00007fffef99af13 in createOptimizedClass<KoReportCurrentArch>(KoReportCurrentArch::ParamType) (param=0x0) at /usr/src/debug/calligra-2.9.11/libs/pigment/compositeops/KoVcMultiArchBuildSupport.h:90 #3 0x00007ffff7de947a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffda88, env=env@entry=0x7fffffffda98) at dl-init.c:72 #4 0x00007ffff7de958b in _dl_init (env=0x7fffffffda98, argv=0x7fffffffda88, argc=1, l=<optimized out>) at dl-init.c:30 #5 0x00007ffff7de958b in _dl_init (main_map=0x7ffff7ffe128, argc=1, argv=0x7fffffffda88, env=0x7fffffffda98) at dl-init.c:120 #6 0x00007ffff7ddacba in _dl_start_user () at /lib64/ld-linux-x86-64.so.2 #7 0x0000000000000001 in () #8 0x00007fffffffdf4a in () #9 0x0000000000000000 in () (gdb) disas Dump of assembler code for function Vc::CpuId::init(): 0x00007fffef9ced20 <+0>: push %r15 0x00007fffef9ced22 <+2>: push %r14 0x00007fffef9ced24 <+4>: push %r13 0x00007fffef9ced26 <+6>: push %r12 0x00007fffef9ced28 <+8>: push %rbp 0x00007fffef9ced29 <+9>: push %rbx 0x00007fffef9ced2a <+10>: sub $0x48,%rsp 0x00007fffef9ced2e <+14>: mov %fs:0x28,%rax 0x00007fffef9ced37 <+23>: mov %rax,0x38(%rsp) 0x00007fffef9ced3c <+28>: xor %eax,%eax 0x00007fffef9ced3e <+30>: movzbl 0x232b87(%rip),%eax # 0x7fffefc018cc <_ZZN2Vc5CpuId4initEvE4done> 0x00007fffef9ced45 <+37>: mov %al,0x19(%rsp) 0x00007fffef9ced49 <+41>: test %al,%al 0x00007fffef9ced4b <+43>: jne 0x7fffef9cf108 <Vc::CpuId::init()+1000> 0x00007fffef9ced51 <+49>: mov 0x230140(%rip),%rdi # 0x7fffefbfee98 0x00007fffef9ced58 <+56>: xor %eax,%eax 0x00007fffef9ced5a <+58>: mov 0x23015f(%rip),%r8 # 0x7fffefbfeec0 0x00007fffef9ced61 <+65>: cpuid 0x00007fffef9ced63 <+67>: mov 0x23016e(%rip),%rax # 0x7fffefbfeed8 0x00007fffef9ced6a <+74>: mov %ecx,%esi 0x00007fffef9ced6c <+76>: movb $0x1,0x232b59(%rip) # 0x7fffefc018cc <_ZZN2Vc5CpuId4initEvE4done> 0x00007fffef9ced73 <+83>: mov %ecx,(%rax) 0x00007fffef9ced75 <+85>: mov $0x1,%eax 0x00007fffef9ced7a <+90>: cpuid 0x00007fffef9ced7c <+92>: mov %ecx,(%rdi) 0x00007fffef9ced7e <+94>: mov 0x22feb3(%rip),%rcx # 0x7fffefbfec38 => 0x00007fffef9ced85 <+101>: bextr $0x404,%eax,%edi 0x00007fffef9ced8e <+110>: mov %edx,(%rcx) 0x00007fffef9ced90 <+112>: mov 0x230051(%rip),%rcx # 0x7fffefbfede8 0x00007fffef9ced97 <+119>: bextr $0x408,%eax,%edx 0x00007fffef9ceda0 <+128>: mov %dl,(%r8) 0x00007fffef9ceda3 <+131>: mov %dil,(%rcx) ---Type <return> to continue, or q <return> to quit--- On Sun, Oct 23, 2016 at 9:49 AM, Christian Boltz <opensuse@cboltz.de> wrote:
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
=> 0x00007fffef9ced85 <+101>: bextr $0x404,%eax,%edi
Does your CPU support this instruction? From this wiki page[1] it looks like this was added in Haswell+ processors, which you might not have. [1]: https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#BMI1 -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
If not, it looks like a bug in Vc::CpuId::init() in calligra. Specifically, it's trying to use instructions that are not supported by your architecture and it isn't correctly detecting they aren't supported. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/24/2016 12:57 PM, Todd Rme wrote:
What does `cat /proc/cpuinfo | grep bmi1` give you? -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/24/2016 01:22 PM, Todd Rme wrote:
Yeah, your CPU doesn't support that instruction. I'd submit a bug report to Calligra because their Vc::CpuInfo::init is broken. Provide all of the information you posted here (specifically the gdb session and the coredump). -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Aleksa, Am Montag, 24. Oktober 2016, 17:49:16 CEST schrieb Aleksa Sarai:
Was the Calligra you tried the one which had the PACKAGERS_BUILD cmake flag set? Otherwise please first try that. See also my email "Notes on Vc and PACKAGERS_BUILD flag (Re: [opensuse- factory] Calligra: core dumped)" from this early morning. Cheers Friedrich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2016-10-23 15:03, Todd Rme wrote:
That is usually a sign that someone failed to employ runtime cpu detection and instead hardcoded an instruction subset not everybody has, like AVX, SSE4, and so on. If and when you have the coredump, what you need is the "disas" command in gdb. The faulting instruction will be highlighted by, I think, an arrow. Confer with the flags line from /proc/cpuinfo to see which features your cpu can do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am Sonntag, 23. Oktober 2016, 09:03:03 CEST schrieb Todd Rme:
I checked KDE:Extra/calligra and it appears that PACKAGERS_BUILD=ON is missing. I added it in my branch https://build.opensuse.org/package/show/home:Vogtinator:branches:KDE:Extra/c... Can you check whether the issue is fixed after installing the packages from there? It may take a while until it built... Cheers, Fabian -- Maxfeldstr. 5 D-90409 Nürnberg http://www.suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, occasional Calligra contributor here. Am Sonntag, 23. Oktober 2016, 16:05:39 CEST schrieb Fabian Vogt:
Indeed, PACKAGERS_BUILD=ON needs to be used when using Vc and doing packaging builds, compare the notes at https://quickgit.kde.org/? p=calligra.git&a=blob&hb=1def80aec3a976608232404df4eac9297aa68822&f=README.PACKAGERS#l331 Vc is a headers-only library, so there are also no binaries for Vc and thus debug packages. Speaking about Vc: For Calligra 2.9 you need to make sure only to use Vc 0.7.* and not some newer 1.*, IIRC there are bugs with Vc 1.0 and newer CPU architectures. And with Vc
1.0 Calligra 2.9 builds will even fail IIRC.
Seems currently there is only the older Vc 0.7.5 available anyway, by what I see at https://build.opensuse.org/package/show?project=openSUSE %3AFactory&package=Vc so that should be fine. For latest Krita 3 (which is now independent of Calligra for versions >=3, though besides Kexi the rest of code from the Calligra project still needs to get a first v3 release) you should consider adding also a package with Vc 1.1 or newer, which is min. dep of Krita 3 and improves the painting speed quite a lot. So while the spec for Krita 3.* has Vc-devel-static listed that Vc version is too old and will be ignored. https://build.opensuse.org/package/view_file/openSUSE:Factory/krita/ krita.spec?expand=1 Of course Krita, using Vc, also has that PACKAGERS_BUILD CMake flag, though it is set to ON by default, given the Calligra times experience that packagers have no time to find and read the docs ;) So the Krita spec not setting it explicitely is fine. Sorry for dropping this slightly off-topic comment only here for now. If you tell where I could properly file these Vc issues to have them tracked and not buried in the mailinglist archive I will do so (sadly I always get lost where to file things with OpenSUSE when I try it once in a while every few months, and the time needed and unsureness of success flaws my motivation). Cheers Friedrich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Mon, 24 Oct 2016 05:11:08 +0200 "Friedrich W. H. Kossebau" <kossebau@kde.org> ha scritto:
Sorry for dropping this slightly off-topic comment only here for now. If you tell where I could properly file these Vc issues to have them
If I understand correctly what you need to report, you should file packaging issues at bugzilla.opensuse.org.
Am Sonntag, 23. Oktober 2016, 16:05:39 schrieb Fabian Vogt:
Unfortunately this didn't help, calligra is still crashing: https://forums.opensuse.org/showthread.php/520676-Calligra-office-dumping-co... Apparently Vc just would need to be rebuilt in Tumbleweed though. I just built it myself on OBS (against current Tumbleweed), built calligra against it, and the crashes were gone here. OTOH, I noticed that Vc 1.3.0 has been submitted to Factory today and will replace 0.7.5: https://build.opensuse.org/request/show/437524 So we probably should just remove the Vc-devel-static build requirement in calligra completely, as the KDE4 version is incompatible with Vc 1.3.0 anyway. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
You can get a bit more information from dmesg. But the really useful thing is the core dump. Unfortunately, systemd loves to mess around with coredumps (because that's what systemd does) so you'll have to sue coredumpctl or look inside /var/lib/systemd/coredump to find it. You could also play around with the kernel.core_pattern sysctl. Anyway, once you have the coredump you can run gdb on it and debug to your heart's content. Specifically you can look at the state of the registers and disassemble the instructions you were trying to execute. You could also try running calligraflow in a gdb session to get even more information. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Sonntag, 23. Oktober 2016, 09:03:03 CEST schrieb Todd Rme:
I'm far from being an expert on coredump handling, but I can at least get you started. I'd guess you have the coredump in /var/lib/systemd/coredump/ If so, coredumpctl list should list it, and coredumpcctl gdb calligraflow should open gdb with the coredump loaded. (I'm not sure about the exact "coredumpctl gdb" syntax - if the above doesn't work, use the result from "coredumpctl list" as parameter.) Inside gdb, run bt to get a backtrace. (You might need to install some debuginfo packages to get a useful backtrace, and gdb will even tell you the zypper command to install them.) If the backtrace doesn't tell you anything, poste it here - or open a bugreport and include it, because you'll probably end up with a bugreport anyway ;-) (as usual, please report back the bug number here) Regards, Christian Boltz --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I have taken the debuging information as far as I can, but I am concerned something is still missing. I don't know how to make much sense of this, but it keeps mentioning this Vc program. Vc only provides a -devel and -devel-static package. I can't find any -debuginfo or -debugsource packages. So I am not sure if this backtrace is useful or not. (gdb) exec-file /usr/bin/calligrawords (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/calligrawords [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. Vc::CpuId::init () at /usr/src/debug/Vc-0.7.5/src/cpuid.cpp:135 135 /usr/src/debug/Vc-0.7.5/src/cpuid.cpp: No such file or directory. (gdb) bt #0 0x00007fffef9ced85 in Vc::CpuId::init() () at /usr/src/debug/Vc-0.7.5/src/cpuid.cpp:135 #1 0x00007fffef9ce2d8 in Vc::isImplementationSupported(Vc::Implementation) (impl=impl@entry=Vc::AVXImpl) at /usr/src/debug/Vc-0.7.5/src/support.cpp:57 #2 0x00007fffef99af13 in createOptimizedClass<KoReportCurrentArch>(KoReportCurrentArch::ParamType) (param=0x0) at /usr/src/debug/calligra-2.9.11/libs/pigment/compositeops/KoVcMultiArchBuildSupport.h:90 #3 0x00007ffff7de947a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffda88, env=env@entry=0x7fffffffda98) at dl-init.c:72 #4 0x00007ffff7de958b in _dl_init (env=0x7fffffffda98, argv=0x7fffffffda88, argc=1, l=<optimized out>) at dl-init.c:30 #5 0x00007ffff7de958b in _dl_init (main_map=0x7ffff7ffe128, argc=1, argv=0x7fffffffda88, env=0x7fffffffda98) at dl-init.c:120 #6 0x00007ffff7ddacba in _dl_start_user () at /lib64/ld-linux-x86-64.so.2 #7 0x0000000000000001 in () #8 0x00007fffffffdf4a in () #9 0x0000000000000000 in () (gdb) disas Dump of assembler code for function Vc::CpuId::init(): 0x00007fffef9ced20 <+0>: push %r15 0x00007fffef9ced22 <+2>: push %r14 0x00007fffef9ced24 <+4>: push %r13 0x00007fffef9ced26 <+6>: push %r12 0x00007fffef9ced28 <+8>: push %rbp 0x00007fffef9ced29 <+9>: push %rbx 0x00007fffef9ced2a <+10>: sub $0x48,%rsp 0x00007fffef9ced2e <+14>: mov %fs:0x28,%rax 0x00007fffef9ced37 <+23>: mov %rax,0x38(%rsp) 0x00007fffef9ced3c <+28>: xor %eax,%eax 0x00007fffef9ced3e <+30>: movzbl 0x232b87(%rip),%eax # 0x7fffefc018cc <_ZZN2Vc5CpuId4initEvE4done> 0x00007fffef9ced45 <+37>: mov %al,0x19(%rsp) 0x00007fffef9ced49 <+41>: test %al,%al 0x00007fffef9ced4b <+43>: jne 0x7fffef9cf108 <Vc::CpuId::init()+1000> 0x00007fffef9ced51 <+49>: mov 0x230140(%rip),%rdi # 0x7fffefbfee98 0x00007fffef9ced58 <+56>: xor %eax,%eax 0x00007fffef9ced5a <+58>: mov 0x23015f(%rip),%r8 # 0x7fffefbfeec0 0x00007fffef9ced61 <+65>: cpuid 0x00007fffef9ced63 <+67>: mov 0x23016e(%rip),%rax # 0x7fffefbfeed8 0x00007fffef9ced6a <+74>: mov %ecx,%esi 0x00007fffef9ced6c <+76>: movb $0x1,0x232b59(%rip) # 0x7fffefc018cc <_ZZN2Vc5CpuId4initEvE4done> 0x00007fffef9ced73 <+83>: mov %ecx,(%rax) 0x00007fffef9ced75 <+85>: mov $0x1,%eax 0x00007fffef9ced7a <+90>: cpuid 0x00007fffef9ced7c <+92>: mov %ecx,(%rdi) 0x00007fffef9ced7e <+94>: mov 0x22feb3(%rip),%rcx # 0x7fffefbfec38 => 0x00007fffef9ced85 <+101>: bextr $0x404,%eax,%edi 0x00007fffef9ced8e <+110>: mov %edx,(%rcx) 0x00007fffef9ced90 <+112>: mov 0x230051(%rip),%rcx # 0x7fffefbfede8 0x00007fffef9ced97 <+119>: bextr $0x408,%eax,%edx 0x00007fffef9ceda0 <+128>: mov %dl,(%r8) 0x00007fffef9ceda3 <+131>: mov %dil,(%rcx) ---Type <return> to continue, or q <return> to quit--- On Sun, Oct 23, 2016 at 9:49 AM, Christian Boltz <opensuse@cboltz.de> wrote:
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
=> 0x00007fffef9ced85 <+101>: bextr $0x404,%eax,%edi
Does your CPU support this instruction? From this wiki page[1] it looks like this was added in Haswell+ processors, which you might not have. [1]: https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#BMI1 -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
If not, it looks like a bug in Vc::CpuId::init() in calligra. Specifically, it's trying to use instructions that are not supported by your architecture and it isn't correctly detecting they aren't supported. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Aleksa Sarai -
Christian Boltz -
Fabian Vogt -
Friedrich W. H. Kossebau -
Jan Engelhardt -
Luca Beltrame -
Todd Rme -
Wolfgang Bauer