Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)

[Andrey Rahmatullin]

Control: reassign -1 src:freefem++
Control: severity -1 serious
Control: retitle -1 Baseline violation in i386 (-mmx -msse2) and amd64 (-mavx)
Control: found -1 3.47+dfsg1-1

On Sun, Mar 24, 2019 at 09:52:28PM +0100, Bernhard Übelacker wrote:
> Unfortunately I saw some bugs in the debian bug tracker
> that were told a "baseline violation", I never saw it somewhere
> explained what exactly the cpu feature baseline is.
It's indeed unfortunate that this info is hard to find and many
mainatiners don't know it. It's currently available at
https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines
The baseline for amd64 is basic amd64, so only SSE2 and below.
The baseline for i386 is i686 without MMX.

While for amd64 the problem appeared in 3.61.1 (so since buster), for i386
it exists even in stretch.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)

[di dit]

As suggested, I rebuilt the debian package (version 3.61.1+dfsg1-4)
with and without adding --enable-generic to configure using a PC with
AVX support. I tested the resulting packages using 2 PCs without AVX
support. The package built with --enable-generic doesn't crash while
the other one always does.

Applying this fix to the freefem++ package for buster would be really nice.

Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)

[di dit]

Hello Bernhard and Dimitrios,

> I think the issue is that freefem++s configure activate
> AVX instructions when the build CPU supports it.
>
>
> I could reproduce the crash in a Buster amd64 qemu VM, that
> unintentionally did not support AVX (while the VM host would).

I reproduced the crash with a Buster amd64 PC without AVX support
(Intel(R) Celeron(R) CPU  N3050). In other words, freefem++ crashes
here on 2 amd64 PCs without AVX but not on 2 others with AVX.
Congratulations Bernhard, I think your diagnostic is good!

Regards

Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)

[Bernhard Übelacker]

Hello Dimitris, hello di dit,

I think the issue is that freefem++s configure activate
AVX instructions when the build CPU supports it.


I could reproduce the crash in a Buster amd64 qemu VM, that
unintentionally did not support AVX (while the VM host would).
That led to following backtrace:

Program terminated with signal SIGILL, Illegal instruction.
...
(gdb) bt
#0  0x5627165a7801 in C_F0::C_F0 (this=0x562716c49c20 ) at 
./../fflib/AFunction.hpp:633
#1  __static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535) at lg.ypp:105
#2  _GLOBAL__sub_I_lg.tab.cpp(void) () at lg.ypp:989
#3  0x562716a51dd5 in __libc_csu_init ()
#4  0x7f6573ed002a in __libc_start_main (main=0x5627165a74c0 , argc=2, argv=0x7ffc53da1d48, init=0x562716a51d90 <__libc_csu_init>, 
fini=, rtld_fini=, stack_end=0x7ffc53da1d38) at 
../csu/libc-start.c:264
#5  0x5627165abcda in _start () at ../Graphics/rgraph.hpp:145


The instruction at this address is a "vpxor":

(gdb) disassemble $pc-0x20,$pc+0x20
Dump of assembler code from 0x5627165a77e1 to 0x5627165a7821:
...
   0x5627165a77fa <_GLOBAL__sub_I_lg.tab.cpp(void)+42>: lea
0x6a23ef(%rip),%rsi# 0x562716c49bf0 
=> 0x5627165a7801 <_GLOBAL__sub_I_lg.tab.cpp(void)+49>: vpxor  
%xmm0,%xmm0,%xmm0
   0x5627165a7805 <_GLOBAL__sub_I_lg.tab.cpp(void)+53>: lea
0x6a2414(%rip),%rax# 0x562716c49c20 
...
End of assembler dump.


Therefore the local rebuild worked, when the package was built
at the CPU that were using it later.

In the latest available build log [1] are compiler flags
"-mmmx -mavx" shown.

Unfortunately I saw some bugs in the debian bug tracker
that were told a "baseline violation", I never saw it somewhere
explained what exactly the cpu feature baseline is.

Best would be if this detection would take place at runtime
instead of compile time.

In the configure script there are several lines were CPU flags
are checked from /proc/cpuinfo - these might "just" be disabled
to avoid newer CPU instructions.

Therefore this bug might really be valid und might be reopened again.

Kind regards,
Bernhard


[1] 
https://buildd.debian.org/status/fetch.php?pkg=freefem%2B%2B=amd64=3.61.1%2Bdfsg1-2%2Bb1=1542831124=0

# Buster amd64 qemu VM 2019-03-24

apt update
apt dist-upgrade

apt install systemd-coredump xserver-xorg lightdm openbox devscript dpkg-dev mc 
gdb freefem++ freefem++-doc freefem++-dbgsym
apt build-dep freefem++


systemctl start lightdm

cp /usr/share/doc/freefem++/examples/examples++-tutorial/a_tutorial.edp .

FreeFem++-nw a_tutorial.edp




mkdir /tmp/source/freefem/orig -p
cd/tmp/source/freefem/orig
apt source freefem++
cd





set width 0
set pagination off
directory /tmp/source/freefem/orig/freefem++-3.61.1+dfsg1/src/fflib
directory /tmp/source/freefem/orig/freefem++-3.61.1+dfsg1/src/lglib



###


benutzer@debian:~$ FreeFem++-nw a_tutorial.edp
Ungültiger Maschinenbefehl (Speicherabzug geschrieben)

[  418.337266] traps: FreeFem++-nw[12191] trap invalid opcode ip:5627165a7801 
sp:7ffc53da1c20 error:0 in FreeFem++[562716592000+4c]

root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sun 2019-03-24 17:53:20 CET   12191  1000  1000   4 present   /usr/bin/FreeFem++


root@debian:~# coredumpctl gdb 12191
   PID: 12191 (FreeFem++-nw)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 4 (ILL)
 Timestamp: Sun 2019-03-24 17:53:20 CET (1min 54s ago)
  Command Line: FreeFem++-nw a_tutorial.edp
Executable: /usr/bin/FreeFem++
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (benutzer)
   Boot ID: 01f85948a1e64e6794d6e1702ad3beea
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.FreeFem++-nw.1000.01f85948a1e64e6794d6e1702ad3beea.12191.15534464.lz4
   Message: Process 12191 (FreeFem++-nw) of user 1000 dumped core.

Stack trace of thread 12191:
#0  0x5627165a7801 n/a (FreeFem++)
#1  0x562716a51dd5 __libc_csu_init (FreeFem++)
#2  0x7f6573ed002a __libc_start_main (libc.so.6)
#3  0x5627165abcda _start (FreeFem++)

GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual 

Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)

[di dit]

> Both commands
>
> FreeFem++ a_tutorial.edp
>
> and
>
> FreeFem++-nw a_tutorial.edp
>
> work fine on an updated unstable/amd64 installation.

Indeed, it does not manifest on every computer as I wrote there:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924009#10

Still I believe it is a real bug. I filled it upstream. See:
  https://github.com/FreeFem/FreeFem-sources/issues/77
I also provided a backtrace which I paste below.
__static_initialization_and_destruction_0 points to a possible static
initialization order issue.

Anyway, thank you for your work. I hope this bug will be fixed
upstream and that this bug report will make you want to have it fixed
in buster too.

Thank you again.

---

backtrace:

$ gdb FreeFem++
(gdb) set pagination 0
(gdb) run
Starting program: /usr/bin/FreeFem++
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
__static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535) at lg.ypp:105
105 lg.ypp: Aucun fichier ou dossier de ce type.
(gdb) bt
#0 __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535) at lg.ypp:105
#1 _GLOBAL__sub_I_lg.tab.cpp(void) () at lg.ypp:989
#2 0x55f16dd5 in __libc_csu_init ()
#3 0x7728202a in __libc_start_main (main=0x55a6c4c0
, argc=1, argv=0x7fffe098, init=0x55f16d90
<__libc_csu_init>, fini=, rtld_fini=, stack_end=0x7fffe088) at
../csu/libc-start.c:264
#4 0x55a70cda in _start () at ../Graphics/rgraph.hpp:145