gfortran -fsanitize=address: basic example?

[Sebastien Bardeau]

Dear all,

I would like to test the new gfortran option -fsanitize=address (using
gfortran 4.8.0). However I could find no example of use of the
AddressSanitizer, or at least no example in the Fortran context.

Below is an example inspired from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341

From the error trace I can only tell that a writing problem occurs in
the "test_asan_01" procedure. It does not indicate where/when it occurs
(I have in mind the -fbounds-check error traces).

Does this mean that the sanitizer can not be used out of the box? Do I
have to some extra tools in order to get some relevant information of
the error trace? Or maybe my questions and/or example are too naive...

Thank you,

Sébastien


Fortran/Sanitizer> cat test.f90
program test_asan_01
implicit none
integer :: i,j,k
integer :: a(10),b(10),c(10)
i = 0
j = 1
k = 2
a(i) = 0
b(j) = 0
c(k) = 0
end program test_asan_01

Fortran/Sanitizer> gfortran -fsanitize=address test.f90 -o test

Fortran/Sanitizer> ./test
=================================================================
==25133== ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fffd6edbc1c at pc 0x4009a8 bp 0x7fffd6edbbe0 sp 0x7fffd6edbbd8

WRITE of size 4 at 0x7fffd6edbc1c thread T0

#0 0x4009a7 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x4009a7)

#1 0x400ad4 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400ad4)

#2 0x3c7c81ecdc (/lib64/libc-2.12.so+0x1ecdc)

#3 0x400798 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400798)

Address 0x7fffd6edbc1c is located at offset 28 in frame <test_asan_01>
of T0's stack:
This frame has 3 object(s):

[32, 72) 'a'

[128, 168) 'b'

[224, 264) 'c'

HINT: this may be a false positive if your program uses some custom
stack unwind mechanism or swapcontext

(longjmp and C++ exceptions *are* supported)

Shadow bytes around the buggy address:

0x10007add3730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x10007add3740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x10007add3750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x10007add3760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x10007add3770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

=>0x10007add3780: f1 f1 f1[f1]00 00 00 00 00 f4 f4 f4 f2 f2 f2 f2

0x10007add3790: 00 00 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00

0x10007add37a0: 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
0x10007add37b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007add37c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007add37d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==25133== ABORTING

[Tobias Burnus]

Hi,

Sebastien Bardeau wrote:
> From the error trace I can only tell that a writing problem occurs in
> the "test_asan_01" procedure. It does not indicate where/when it occurs
> (I have in mind the -fbounds-check error traces).

You can use "addr2line" to convert the address information to line numbers.

For:

> WRITE of size 4 at 0x7fffd6edbc1c thread T0
> #0 0x4009a7 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x4009a7)
> #1 0x400ad4 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400ad4)
> #2 0x3c7c81ecdc (/lib64/libc-2.12.so+0x1ecdc)
> #3 0x400798 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400798)

Try:

addr2line -e /home/bardeau/Scripts/Fortran/Sanitizer/test 0x4009a7
0x400ad4 0x400798



I think the ASAN library should also be able to call addr2line
internally, but I have not found out how. At least on finds in the
source code:

./tsan/tsan_symbolize_addr2line_linux.cc: execl("/usr/bin/addr2line",
"/usr/bin/addr2line", "-Cfe", m->fullname, 0);


Alternatively (and untried): one can also use the following Python
script, to which you can pipe the output from the failure message. See:
https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/asan/scripts/asan_symbolize.py


Finally: I think it should be also possible to show the unwind
information by calling from within the sanitizer library libbacktrace,
but that is currently not done. I do not recall why, but seemingly it is
not as simple as one would think.

Tobias

[Sebastien Bardeau]

Hello Tobias,

On 05/28/2013 03:01 PM, Tobias Burnus wrote:
> Hi,
>
> Sebastien Bardeau wrote:
>> From the error trace I can only tell that a writing problem occurs in
>> the "test_asan_01" procedure. It does not indicate where/when it occurs
>> (I have in mind the -fbounds-check error traces).
>
> You can use "addr2line" to convert the address information to line numbers.
>
> For:
>
>> WRITE of size 4 at 0x7fffd6edbc1c thread T0
>> #0 0x4009a7 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x4009a7)
>> #1 0x400ad4 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400ad4)
>> #2 0x3c7c81ecdc (/lib64/libc-2.12.so+0x1ecdc)
>> #3 0x400798 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400798)
>
> Try:
>
> addr2line -e /home/bardeau/Scripts/Fortran/Sanitizer/test 0x4009a7
> 0x400ad4 0x400798

Thanks for your help. However I am not very successful:

Fortran/Sanitizer> addr2line -e
/home/bardeau/Scripts/Fortran/Sanitizer/test 0x4009a7 0x400ad4 0x400798
test.f90:0
??:0
??:0

> I think the ASAN library should also be able to call addr2line
> internally, but I have not found out how. At least on finds in the
> source code:
>
> ./tsan/tsan_symbolize_addr2line_linux.cc: execl("/usr/bin/addr2line",
> "/usr/bin/addr2line", "-Cfe", m->fullname, 0);
>
>
> Alternatively (and untried): one can also use the following Python
> script, to which you can pipe the output from the failure message. See:
> https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/asan/scripts/asan_symbolize.py

Same problem here:

#0 0x4009a7 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x4009a7)
#1 0x400ad4 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400ad4)
#2 0x3c7c81ecdc (/lib64/libc-2.12.so+0x1ecdc)
#3 0x400798 (/home/bardeau/Scripts/Fortran/Sanitizer/test+0x400798)

is converted into:
#0 0x4009a7 in MAIN__ test.f90:0

#1 0x400ad4 in main ??:0

#2 0x3c7c81ecdc in ?? ??:0

#3 0x400798 in _start ??:0



Can it be linked to the fact I do not use the GNU compilers installed on
the system, but others which I compiled in a custom directory? e.g. some
compiler library mismatch...

[Tobias Burnus]

Sebastien Bardeau wrote:
> On 05/28/2013 03:01 PM, Tobias Burnus wrote:
>> You can use "addr2line" to convert the address information to line
>> numbers.
>

> Thanks for your help. However I am not very successful:

Sorry, I forgot to mention that you should also compile with "-g". With
"-g" the compiler generates debug information, which allows to obtain
the source file and line numbers.

Side remark 1: You can use "-g" with any optimization level - and in
case of GCC the generated code should be the same with and without -g.
(That's different to many other compilers.)

Side remark 2: The higher the optimization level, the worse the
debugging experience as, e.g., inlining can mess up with the line
numbers. Use "-Og" if you want best debug experience while allowing some
optimizations.

Side remark 3: The same applies to -fbacktrace, which also requires "-g"
for source files and line numbers.

Fine side remark: You can use the program "strip" to remove debug
symbols from a binary.

> Fortran/Sanitizer> addr2line -e
> /home/bardeau/Scripts/Fortran/Sanitizer/test 0x4009a7 0x400ad4 0x400798
> test.f90:0
> ??:0
> ??:0

Tobias

[Robin Vowels]

On May 28, 9:55 pm, Sebastien Bardeau <bard...@no.domain> wrote:
> Dear all,
>
> I would like to test the new gfortran option -fsanitize=address (using
> gfortran 4.8.0). However I could find no example of use of the
> AddressSanitizer, or at least no example in the Fortran context.
>

> Below is an example inspired fromhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341

>
>  From the error trace I can only tell that a writing problem occurs in
> the "test_asan_01" procedure. It does not indicate where/when it occurs
> (I have in mind the -fbounds-check error traces).
>
> Does this mean that the sanitizer can not be used out of the box? Do I
> have to some extra tools in order to get some relevant information of
> the error trace? Or maybe my questions and/or example are too naive...
>
> Thank you,
>

> S bastien

For something like this you ought to be using a language that
supports debugging.

Your program in PL/I:
(subscriptrange):
test_asan_01: procedure options(main);
declare (i,j,k, a(10),b(10),c(10)) fixed binary;

i = 0;
j = 1;
k = 2;
a(i) = 0;
b(j) = 0;

c(k) = 0;
put skip data (a(i), b(j), c(k));
end test_asan_01;

And the output:

IBM0421I ONCODE=0520 The SUBSCRIPTRANGE condition was raised.
At offset +000001A8 in procedure with entry TEST_ASAN_01
_________________

For something more informative:

(subscriptrange):
test_asan_01: procedure options(main);
declare (i,j,k, a(10),b(10),c(10), SL) fixed binary;
on subscriptrange begin;
put skip list ('at line ' || trim(SL) );
end;

i = 0;
j = 1;

k = 2;
SL = SOURCELINE();

a(i) = 0;
b(j) = 0;

c(k) = 0;
put skip data (a(i), b(j), c(k));
end test_asan_01;

The output this time is:

at line 11
IBM0421I ONCODE=0520 The SUBSCRIPTRANGE condition was raised.
At offset +000001D6 in procedure with entry TEST_ASAN_01

[Tobias Burnus]

Robin Vowels wrote:
>> Fortran/Sanitizer> cat test.f90
>> program test_asan_01
>> implicit none
>> integer :: i,j,k
>> integer :: a(10),b(10),c(10)
>> i = 0
>> j = 1
>> k = 2
>> a(i) = 0
>> b(j) = 0
>> c(k) = 0
>> end program test_asan_01

> For something like this you ought to be using a language that
> supports debugging.
>
> Your program in PL/I:
> (subscriptrange):
> test_asan_01: procedure options(main);
> declare (i,j,k, a(10),b(10),c(10)) fixed binary;
>
> i = 0;
> j = 1;
> k = 2;
> a(i) = 0;
> b(j) = 0;
> c(k) = 0;
> put skip data (a(i), b(j), c(k));
> end test_asan_01;
>
> And the output:
>
> IBM0421I ONCODE=0520 The SUBSCRIPTRANGE condition was raised.
> At offset +000001A8 in procedure with entry TEST_ASAN_01
> _________________

Do you mean like Fortran, where running the code - compiled with
-fcheck=all - produces at runtime:

At line 8 of file test.f90
Fortran runtime error: Index '0' of dimension 1 of array 'a' below lower
bound of 1

In that case, I prefer the Fortran error message as it is more
informative :-)


Still, any run-time diagnostic requires some additional check which
slows down the program. The address sanitizer causes only a minor
performance reduction but is not as informative. -fcheck= has a higher
penalty with a better output. And either one diagnoses different issues
- even if there is some overlap.

I don't know how how PL/I handles it, but either it is also optional
(which means that one has to remember to explicitly enable/disable it)
or you have always a performance penalty.

Tobias

[Sebastien Bardeau]

On 05/28/2013 05:43 PM, Tobias Burnus wrote:
> Sebastien Bardeau wrote:
>> On 05/28/2013 03:01 PM, Tobias Burnus wrote:
>>> You can use "addr2line" to convert the address information to line
>>> numbers.
>>
>> Thanks for your help. However I am not very successful:
>
> Sorry, I forgot to mention that you should also compile with "-g". With
> "-g" the compiler generates debug information, which allows to obtain
> the source file and line numbers.

Indeed this makes sense. But it still does not work:

gfortran -g -fsanitize=address test.f90 -o test

addr2line -e ./test 0x4009a7 0x400ad4 0x400798

test.f90:0
??:0
??:0

Is it working for you?

Sebastien

[glen herrmannsfeldt]

Tobias Burnus <bur...@net-b.de> wrote:
> Robin Vowels wrote:

(snip)

>> For something like this you ought to be using a language that
>> supports debugging.

(snip)

>> IBM0421I ONCODE=0520 The SUBSCRIPTRANGE condition was raised.
>> At offset +000001A8 in procedure with entry TEST_ASAN_01

(snip)

> Do you mean like Fortran, where running the code - compiled with
> -fcheck=all - produces at runtime:

> At line 8 of file test.f90
> Fortran runtime error: Index '0' of dimension 1 of array 'a'
> below lower bound of 1

> In that case, I prefer the Fortran error message as it is more
> informative :-)

One difference is that the PL/I version can be turned on or off
at the procedure or statement level. In general, that doesn't help,
but reasonably often you know which parts of a program are more
likely to have array bounds problems and only turn it on there.

> Still, any run-time diagnostic requires some additional check which
> slows down the program. The address sanitizer causes only a minor
> performance reduction but is not as informative. -fcheck= has a higher
> penalty with a better output. And either one diagnoses different issues
> - even if there is some overlap.

> I don't know how how PL/I handles it, but either it is also optional
> (which means that one has to remember to explicitly enable/disable it)
> or you have always a performance penalty.

Java requires bounds checking. As I understand it, either the compiler
or the JIT at run time can optimize out cases where it isn't needed.

for(i=0;i<x.length;i++) sum += x[i];

can't go outside x, and it can tell at compile time.

Do any Fortran compilers have an option to check others, but not
loops where it is obvious it is safe?

-- glen

[Tobias Burnus]

Tobias Burnus wrote:
> Robin Vowels wrote:
>>> Fortran/Sanitizer> cat test.f90
>>> program test_asan_01
>>> implicit none
>>> integer :: i,j,k
>>> integer :: a(10),b(10),c(10)
>>> i = 0
>>> j = 1
>>> k = 2
>>> a(i) = 0
>>> b(j) = 0
>>> c(k) = 0
>>> end program test_asan_01

Am 29.05.2013 13:54, schrieb Sebastien Bardeau:> On 05/28/2013 05:43

> Indeed this makes sense. But it still does not work:
>
> gfortran -g -fsanitize=address test.f90 -o test
>
> addr2line -e ./test 0x4009a7 0x400ad4 0x400798
> test.f90:0
>

> Is it working for you?

Yes, it does on my openSUSE system (x86-64-gnu-linux); using both the
GCC 4.8 from SUSE and a self-built GCC 4.9.


$ gfortran -g -fsanitize=address test.f90 -o test
$ ./test
...
WRITE of size 4 at 0x7fffabbb005c thread T0
#0 0x4009d7 (/dev/shm/test+0x4009d7)
#1 0x400b04 (/dev/shm/test+0x400b04)
#2 0x7f5254e93a14 (/lib64/libc-2.17.so+0x21a14)
#3 0x400838 (/dev/shm/test+0x400838)
...

$ addr2line -e /dev/shm/test 0x4009d7 0x400b04 0x400838
/dev/shm/test.f90:8
/dev/shm/test.f90:11
/home/abuild/rpmbuild/BUILD/glibc-2.17/csu/../sysdeps/x86_64/start.S:123

$ addr2line -e /lib64/libc-2.17.so 0x21a14
/usr/src/debug/glibc-2.17/csu/libc-start.c:258

(Side remark: I have installed glibc-debuginfo, otherwise there wouldn't
be a line number for #3. For #2, one has to take the address after the "+".)

Tobias

[Tobias Burnus]

glen herrmannsfeldt wrote:
> One difference is that the PL/I version can be turned on or off
> at the procedure or statement level. In general, that doesn't help,
> but reasonably often you know which parts of a program are more
> likely to have array bounds problems and only turn it on there.

First, my impression is that one often does not know - at least not for
stack allocated memory. Especially not with C code, which intrinsically
lacks bound information. You stack allocate a variable in one file, pass
it as actual argument and after a function calls, you access invalid
memory. However, the sanitizer can only detect this if you have already
instrumented the original stack allocation - and the place where you use
the it.

For Fortran 90 code that's less relevant as the array descriptor
provides the bound information. For Fortran 77 code with assumed-size
arrays (explicit size is a bit better), you run into the same issue.

Secondly, with both -fcheck=... and with -fsanitize=address (or thread),
you can selectively compile only part of your code, which only
instruments those parts. However, most of the time it is much simpler to
turn on all diagnostic and see where it fails. Fortunately, many
failures already occur with smaller examples.

> Java requires bounds checking. As I understand it, either the compiler
> or the JIT at run time can optimize out cases where it isn't needed.
> for(i=0;i<x.length;i++) sum += x[i];
> can't go outside x, and it can tell at compile time.
>
> Do any Fortran compilers have an option to check others, but not
> loops where it is obvious it is safe?

I fail to see why loops are safe. However, with optimization turned on,
the compiler will also optimize checks away. In this case it should be
able to optimize internally added
"if(i >= x.length) { throw out of bounds }"
away.

Actually, with loops one has to be even more careful - one easily
exceeds bounds or integer ranges without realizing. For instance:
do i = n, huge(i)
...
end do
What's the value of "i" after the loop?

Or for bounds, an issue which occurs with SPEC 2006 for a C and a
Fortran code. See the item about -fno-aggressive-loop-optimizations in
http://gcc.gnu.org/gcc-4.8/changes.html

A description of the issue with the C code can be found at
http://blog.regehr.org/archives/918 (Note that GCC warns by default
when it does the mentioned optimization; it didn't do so in GCC 4.8.0rc1
but it does so in the 4.8.0 release.)

Hence, it is actually good to stick to standard conforming code - and
never lie to the compiler. They will do all permitted optimization -
which can break legacy code. And compilers will exploit more
optimization opportunities in the future.

Tobias

[Robin Vowels]

It isn't "like Fortran". The debug facilities in PL/I are
part of the PL/I language.
They are not part of Fortran.
You don't get the same messages or level of detail with different
Fortran compilers.

> where running the code - compiled with
> -fcheck=all - produces at runtime:
>
> At line 8 of file test.f90
> Fortran runtime error: Index '0' of dimension 1 of array 'a' below lower
> bound of 1
>
> In that case, I prefer the Fortran error message as it is more
> informative :-)

Then take a look at the second example, which produces
the line number also.
It can also, with a trivial addition, print the value of the
subscript variable, and much more.

> Still, any run-time diagnostic requires some additional check which
> slows down the program.

You wouldn't notice it.

> The address sanitizer causes only a minor
> performance reduction but is not as informative.

That's the understatement of the year.

> -fcheck= has a higher
> penalty with a better output. And either one diagnoses different issues
> - even if there is some overlap.
>
> I don't know how how PL/I handles it, but either it is also optional
> (which means that one has to remember to explicitly enable/disable it)
> or you have always a performance penalty.

You can enable or disable it with the first line.
As I said, you wouldn't notice the extra time.

[Robin Vowels]

Typically undefined.
That's where PL/I checks come in handy. You would get an
overflow message for that.

Alternatively, you can use:
do i = n upthu 2147483647;
and the value of i on loop exit is the value that was
used in the final iteration.
An overflow cannot occur.

[glen herrmannsfeldt]

Tobias Burnus <bur...@net-b.de> wrote:
> glen herrmannsfeldt wrote:
>> One difference is that the PL/I version can be turned on or off
>> at the procedure or statement level. In general, that doesn't help,
>> but reasonably often you know which parts of a program are more
>> likely to have array bounds problems and only turn it on there.

> First, my impression is that one often does not know - at least not for
> stack allocated memory. Especially not with C code, which intrinsically
> lacks bound information. You stack allocate a variable in one file, pass
> it as actual argument and after a function calls, you access invalid
> memory. However, the sanitizer can only detect this if you have already
> instrumented the original stack allocation - and the place where you use
> the it.

Sometimes you know better than others. For one, PL/I only passes
arrays by descriptor, so length information is available. (Assumes
you don't mess up the argument list.)

> For Fortran 90 code that's less relevant as the array descriptor
> provides the bound information. For Fortran 77 code with assumed-size
> arrays (explicit size is a bit better), you run into the same issue.

> Secondly, with both -fcheck=... and with -fsanitize=address (or thread),
> you can selectively compile only part of your code, which only
> instruments those parts. However, most of the time it is much simpler to
> turn on all diagnostic and see where it fails. Fortunately, many
> failures already occur with smaller examples.

Reminds me of many years ago, a large (at the time) Fortran program
with array problems. Fortran H has no bounds checking option, so
I ran it on WATFIV. Compiles about 10 times faster, runs about 10
times slower, but I found some of the problems using smaller (faster)
input data sets.

>> Java requires bounds checking. As I understand it, either the compiler
>> or the JIT at run time can optimize out cases where it isn't needed.
>> for(i=0;i<x.length;i++) sum += x[i];
>> can't go outside x, and it can tell at compile time.

>> Do any Fortran compilers have an option to check others, but not
>> loops where it is obvious it is safe?

> I fail to see why loops are safe. However, with optimization turned on,
> the compiler will also optimize checks away. In this case it should be
> able to optimize internally added
> "if(i >= x.length) { throw out of bounds }"
> away.

I suppose if you use enough tricks you can make an unsafe loop.
Java doesn't have EQUIVALENCE, though.

EQUIVALENCE a DO variable, and you can make all kinds of strange
things happen to a loop.

> Actually, with loops one has to be even more careful - one easily
> exceeds bounds or integer ranges without realizing. For instance:
> do i = n, huge(i)
> ...
> end do
> What's the value of "i" after the loop?

> Or for bounds, an issue which occurs with SPEC 2006 for a C and a
> Fortran code. See the item about -fno-aggressive-loop-optimizations in
> http://gcc.gnu.org/gcc-4.8/changes.html

> A description of the issue with the C code can be found at
> http://blog.regehr.org/archives/918 (Note that GCC warns by default
> when it does the mentioned optimization; it didn't do so in GCC 4.8.0rc1
> but it does so in the 4.8.0 release.)

Pretty interesting, though a little unusual. If the loop was written
in the usual way, that wouldn't happen.

> Hence, it is actually good to stick to standard conforming code - and
> never lie to the compiler. They will do all permitted optimization -
> which can break legacy code. And compilers will exploit more
> optimization opportunities in the future.

-- glen

[Sebastien Bardeau]

On 05/29/2013 03:36 PM, Tobias Burnus wrote:
> Tobias Burnus wrote:
>> Robin Vowels wrote:
>>>> Fortran/Sanitizer> cat test.f90
>>>> program test_asan_01
>>>> implicit none
>>>> integer :: i,j,k
>>>> integer :: a(10),b(10),c(10)
>>>> i = 0
>>>> j = 1
>>>> k = 2
>>>> a(i) = 0
>>>> b(j) = 0
>>>> c(k) = 0
>>>> end program test_asan_01
>
> Am 29.05.2013 13:54, schrieb Sebastien Bardeau:> On 05/28/2013 05:43
> > Indeed this makes sense. But it still does not work:
> >
> > gfortran -g -fsanitize=address test.f90 -o test
> >
> > addr2line -e ./test 0x4009a7 0x400ad4 0x400798
> > test.f90:0
> >
> > Is it working for you?
>


> Yes, it does on my openSUSE system (x86-64-gnu-linux); using both the
> GCC 4.8 from SUSE and a self-built GCC 4.9.

Ok, it seems that the addr2line version installed on my system (2.20.51)
is too old in this context, I installed the latest one (2.23).

Thanks for your help,

Sebastien