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

...

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

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:

On Sun, Oct 23, 2016 at 9:41 PM, Aleksa Sarai wrote:

...

...

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

It looks like I am using Sandy Bridge.

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:

On Sun, Oct 23, 2016 at 10:13 PM, Aleksa Sarai wrote:

...

On 10/24/2016 12:57 PM, Todd Rme wrote:

...

On Sun, Oct 23, 2016 at 9:41 PM, Aleksa Sarai wrote:

...

...

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

It looks like I am using Sandy Bridge.

What does `cat /proc/cpuinfo | grep bmi1` give you?

Nothing at all.

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, occasional Calligra contributor here. Am Sonntag, 23. Oktober 2016, 16:05:39 CEST schrieb Fabian Vogt:

Hi,

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 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/ calligra Can you check whether the issue is fixed after installing the packages from there? It may take a while until it built...

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

Am Sonntag, 23. Oktober 2016, 16:05:39 schrieb Fabian Vogt:

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/ calligra Can you check whether the issue is fixed after installing the packages from there? It may take a while until it built...

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