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
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