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:
Hello,
Am Sonntag, 23. Oktober 2016, 09:03:03 CEST schrieb Todd Rme:
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.
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 --
The kernel will stay the same between SUSE Linux 10.1 and SLE10 - it just might be that we release them at different days, Good. Let the SLED customers test it for us first ;) [> Andreas Jaeger and Martin Schlander in opensuse]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org