[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2018-12-26 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #14 from kargl at gcc dot gnu.org ---
"We are weighed down, every moment, by the conception and the sensation of
Time. And there are but two means of escaping and forgetting this nightmare:
pleasure and work. Pleasure consumes us. Work strengthens us. Let us choose."

Charles Baudelaire

*** This bug has been marked as a duplicate of bug 81984 ***

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2017-04-14 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #13 from Vittorio Zecca  ---
In C strings are pointers, in Fortran they are not.

So ptr="string" is wrong.

As in the following:
character, pointer :: cptr
cptr="qwerty"
end
Running it I get a SIGSEGV.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2017-04-13 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #12 from Dominique d'Humieres  ---
> Actually, the null pointer str4 is dereferenced four times:
> at lines 39, 40, 68, 69.

I agree for lines 39 and 68, but in lines it points to the strings 'ABCDEFGH'
and 4_'ABCDEFGH' AFAIU pointers.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2017-04-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #11 from Vittorio Zecca  ---
Actually, the null pointer str4 is dereferenced four times:
at lines 39, 40, 68, 69.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2017-04-13 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #10 from Dominique d'Humieres  ---
> This test case is wrong.

Well, I don't if strings comparison is allowed or forbidden by the standard
when one string is a non-associated pointer as in

program test
  implicit none
  call source_check()
contains
  subroutine source_check()
character(len=:), pointer :: str4
str4 => null()
print *, (str4 < '1')
  end subroutine source_check
end program test

which gives

../../../p_work/libgfortran/intrinsics/string_intrinsics_inc.c:90:7: runtime
error: null pointer passed as argument 1, which is declared to never be null
 T

If this is forbidden by the standard, the test could be fixed with

---
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03  
2011-02-23 16:42:20.0 +0100
+++ allocate_deferred_char_scalar_1.f03 2017-04-13 14:49:35.0 +0200
@@ -36,7 +36,8 @@ contains
 if(.not.associated(str4, str)) call abort()
 str4 => null()
 str = '12a56b78'
-if(str4 == '12a56b78') call abort()
+!if(str4 == '12a56b78') call abort()
+if(associated(str4)) call abort()
 str4 = 'ABCDEFGH'
 if(str == 'ABCDEFGH') call abort()
 allocate(str5, source=str)
@@ -65,7 +66,8 @@ contains
 if(.not.associated(str4, str)) call abort()
 str4 => null()
 str = 4_'12a56b78'
-if(str4 == 4_'12a56b78') call abort()
+!if(str4 == 4_'12a56b78') call abort()
+if(associated(str4)) call abort()
 str4 = 4_'ABCDEFGH'
 if(str == 4_'ABCDEFGH') call abort()
 allocate(str5, source=str)

If it is allowed, then null pointers should be handled in

compare_string (gfc_charlen_type len1, const CHARTYPE *s1,
gfc_charlen_type len2, const CHARTYPE *s2)

> It dereferences thrice a NULL pointer str4.

I see it only twice.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2017-04-12 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #9 from Vittorio Zecca  ---
This test case is wrong.
It dereferences thrice a NULL pointer str4.
Unfortunately -fcheck=pointer does not detect this one. 
Just added to the CC list the test case author.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2017-04-07 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

Vittorio Zecca  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Host||x86_64-pc-linux-gnu
Version|5.2.0   |7.0.1

--- Comment #8 from Vittorio Zecca  ---
Still in trunk 246751.

Running testsuite program allocate_deferred_char_scalar_1.exe

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #5 from Vittorio Zecca  ---
On the same line
CFLAGS="-fsanitize=undefined -Og -g -fno-omit-frame-pointer"
CXXFLAGS=$CFLAGS LDFLAGS="-lubsan -ldl -lpthread"
/home/vitti/gcc-5.2.0/configure
--prefix=/home/vitti/1tb/local/gcc-5.2.0-undefined --disable-bootstrap
--enable-languages=c,ada,c++,fortran,go,lto,objc,obj-c++ --no-create
--no-recursion : (reconfigured) /home/vitti/gcc-5.2.0/configure
--prefix=/home/vitti/1tb/local/gcc-5.2.0-undefined --disable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto

Then "make"

but it is not that easy, I had to tweak and modify some configure
files to keep going and libtool as well. But I made it. I even got a
-fsanitize=address version working.

BTW can you confirm that the test case is erroneous
because it dereferences a NULL pointer?
Is that intended?


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-13 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #7 from Vittorio Zecca  ---
str4 used to point to str so the "logic" seems to check that str4 does
not follow any more str.
But the test is erroneous.


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-13 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres  ---
> BTW can you confirm that the test case is erroneous
> because it dereferences a NULL pointer?

Well I am pointer challenged thus I cannot understand the logic behind the
lines

str4 => null()
str = '12a56b78'
if(str4 == '12a56b78') call abort()

and

str4 => null()
str = 4_'12a56b78'
if(str4 == 4_'12a56b78') call abort()

I am expecting an error (or a segfault).

> Is that intended?

CCed the author of the test.


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-12 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #4 from Dominique d'Humieres  ---
> If you had a sanitized version of libgfortran you could check them by 
> yourself.

Could you please post the exact command line you are using for configure and
make and, if needed, the environment?


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-12 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #3 from Vittorio Zecca  ---
I believe the test case is erroneous. NULL pointers are dereferenced
in subroutines
source_check and source_check4:

if(str4 == '12a56b78') call abort()

and

if(str4 == 4_'12a56b78') call abort()

are dereferencing the null pointer str4 and this goes down to
string_intrinsics_inc.c

There are more test cases with lvz==0.
If you had a sanitized version of libgfortran you could check them by yourself.


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-12 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-12
 CC||fxcoudert at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Francois-Xavier Coudert  ---
(In reply to Vittorio Zecca from comment #0)
> During make check-fortran in gcc build the sanitizer complains
> that a null pointer is passed to memcpy in string_intrinsics_inc.c:89

Which test case generates that? It seems weird to be calling string_compare()
with a NULL pointer, so it may actually be a front-end issue.


[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

2015-09-12 Thread zeccav at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540

--- Comment #2 from Vittorio Zecca  ---
The pointer is NULL but the length is zero.
The test case is allocate_deferred_char_scalar_1.exe
on all eight combinations. As in

Executing on host:
/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../gfortran
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/
/home/vitti/gcc-5.2.0/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O0
-pedantic-errors
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libatomic/.libs
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
 -lm -L/home/vitti/local/gcc-5.2.0/lib64 -lasan -lubsan -ldl -lpthread
 -o ./allocate_deferred_char_scalar_1.exe(timeout = 300)
spawn -ignore SIGHUP
/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../gfortran
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/testsuite/gfortran/../../
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/
/home/vitti/gcc-5.2.0/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0
-pedantic-errors
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libgfortran/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libatomic/.libs
-B/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-L/home/vitti/1tb/vitti/gcc-5.2.0-undefined/x86_64-unknown-linux-gnu/./libquadmath/.libs
-lm -L/home/vitti/local/gcc-5.2.0/lib64 -lasan -lubsan -ldl -lpthread
-o ./allocate_deferred_char_scalar_1.exe^M
PASS: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O0  (test for
excess errors)
Executing on unix: ./allocate_deferred_char_scalar_1.exe(timeout = 300)
spawn -ignore SIGHUP ./allocate_deferred_char_scalar_1.exe^M
lvz=0^M
lvz=0^M
Executed ./allocate_deferred_char_scalar_1.exe, status 0
lvz=0^M
lvz=0^M

PASS: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O0  execution test

lvz=0 is my addition to expose the issue