[Bug fortran/36379] New: preprocessing preprocessed output: invalid reads

[Bug fortran/36379] New: preprocessing preprocessed output: invalid reads

[dfranke at gcc dot gnu dot org]

http://gcc.gnu.org/ml/fortran/2008-05/msg00354.html, issue 3:

If I compile the following a.F90 file:

# 1 "a.F90"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.F90"
  print *, "foo"  "bar""gee"
  end

with "gfortran -E", I get garbage in the output:

# 1 "a.F90"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.F90"
# 1 "a.F90*"
# 1 "<built-in>&#2026;&#9618;*"
# 1 "<command-line>"
# 1 "a.F90*"
  print *, "foo"  "bar""gee"
  end

and valgrind says:

==28934== Invalid read of size 1
==28934==    at 0x4A1C713: strlen (mc_replace_strmem.c:246)
==28934==    by 0x410D99: print_line (cpp.c:753)
==28934==    by 0xB53574: do_linemarker (directives.c:993)
==28934==    by 0xB51F98: _cpp_handle_directive (directives.c:483)
==28934==    by 0xB624DE: _cpp_scan_out_logical_line (traditional.c:634)
==28934==    by 0xB62BF6: _cpp_read_logical_line_trad (traditional.c:305)
==28934==    by 0x41105F: gfc_cpp_preprocess (cpp.c:699)
==28934==    by 0x46FB35: gfc_new_file (scanner.c:1916)
==28934==    by 0x48720C: gfc_init (f95-lang.c:295)
==28934==    by 0x704A88: toplev_main (toplev.c:2045)
==28934==    by 0x4B3B4C9: (below main) (in /usr/lib/debug/libc-2.3.6.so)
==28934==  Address 0x4E2C13D is 0 bytes after a block of size 5 alloc'd
==28934==    at 0x4A1B95B: realloc (vg_replace_malloc.c:306)
==28934==    by 0xB7713C: xrealloc (xmalloc.c:179)
==28934==    by 0xB648DC: cpp_interpret_string (charset.c:1392)
==28934==    by 0xB64E90: cpp_interpret_string_notranslate (charset.c:1416)
==28934==    by 0xB5360A: do_linemarker (directives.c:956)
==28934==    by 0xB51F98: _cpp_handle_directive (directives.c:483)
==28934==    by 0xB624DE: _cpp_scan_out_logical_line (traditional.c:634)
==28934==    by 0xB62BF6: _cpp_read_logical_line_trad (traditional.c:305)
==28934==    by 0x41105F: gfc_cpp_preprocess (cpp.c:699)
==28934==    by 0x46FB35: gfc_new_file (scanner.c:1916)
==28934==    by 0x48720C: gfc_init (f95-lang.c:295)
==28934==    by 0x704A88: toplev_main (toplev.c:2045)


-- 
           Summary: preprocessing preprocessed output: invalid reads
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: dfranke at gcc dot gnu dot org
        ReportedBy: dfranke at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379

[Bug fortran/36379] preprocessing preprocessed output: invalid reads

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2008-05-29 21:00 -------
Duplicate of PR 36276 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379

[Bug fortran/36379] preprocessing preprocessed output: invalid reads

[fxcoudert at gcc dot gnu dot org]

------- Comment #2 from fxcoudert at gcc dot gnu dot org  2008-05-29 22:18 -------
(In reply to comment #1)
> Duplicate of PR 36276 ?

Doesn't have the same location, so I don't think so :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379

[Bug fortran/36379] preprocessing preprocessed output: invalid reads

[dfranke at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]



------- Comment #3 from dfranke at gcc dot gnu dot org  2008-06-07 12:56 -------
Traced this down to libcpp, charset.c(cpp_interpret_string). There, the 'to'
string is not properly NUL-terminated, although the comments indicate that this
is the intention of the code.

Example:
$> cat x.f90
# 1 "y.f90"
end

(gdb) break do_linemarker
(gdb) run -cpp dummy -E x.f90
[step to cpp_interpret_string]
(gdb) print *from
[at beginning of cpp_interpret_string]
$19 = {len = 7, text = 0x89dd3d1 "\"y.f90\""}
[at end of cpp_interpret_string]
(gdb) print *to
$39 = {len = 5, text = 0x89d3f48 "y.f90òô·"}

$> valgrind f951 -cpp dummy -E x.f90
[...]
==29785== Invalid read of size 1
==29785==    at 0x805995F: print_line (cpp.c:755)
==29785==    by 0x8059BAF: cb_file_change (cpp.c:811)
==29785==    by 0x87C6865: do_linemarker (directives.c:993)
==29785==    by 0x87C543E: _cpp_handle_directive (directives.c:483)
==29785==    by 0x87D427F: _cpp_scan_out_logical_line (traditional.c:634)
==29785==    by 0x87D4961: _cpp_read_logical_line_trad (traditional.c:305)
==29785==    by 0x805981D: scan_translation_unit_trad (cpp.c:701)
==29785==    by 0x805945B: gfc_cpp_preprocess (cpp.c:568)
==29785==    by 0x80B0C0C: gfc_new_file (scanner.c:1929)
==29785==    by 0x80C74E7: gfc_init (f95-lang.c:303)
==29785==    by 0x8374465: toplev_main (toplev.c:2045)
==29785==    by 0x8114E81: main (main.c:35)
==29785==  Address 0x425bd25 is 0 bytes after a block of size 5 alloc'd
==29785==    at 0x402298D: realloc (vg_replace_malloc.c:429)
==29785==    by 0x87E8066: xrealloc (xmalloc.c:179)
==29785==    by 0x87D61AF: cpp_interpret_string (charset.c:1392)
==29785==    by 0x87D6B42: cpp_interpret_string_notranslate (charset.c:1416)
==29785==    by 0x87C689D: do_linemarker (directives.c:956)
==29785==    by 0x87C543E: _cpp_handle_directive (directives.c:483)
==29785==    by 0x87D427F: _cpp_scan_out_logical_line (traditional.c:634)
==29785==    by 0x87D4961: _cpp_read_logical_line_trad (traditional.c:305)
==29785==    by 0x805981D: scan_translation_unit_trad (cpp.c:701)
==29785==    by 0x805945B: gfc_cpp_preprocess (cpp.c:568)
==29785==    by 0x80B0C0C: gfc_new_file (scanner.c:1929)
==29785==    by 0x80C74E7: gfc_init (f95-lang.c:303)
[...]

Interestingly, an equivalent c-code does not give the invalid reads. Either the
C-frontend does account for this, or it works by chance?!

Added Tom Tromey as CC. 

Tom any insights from your point of view?


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379

[Bug fortran/36379] preprocessing preprocessed output: invalid reads

[dfranke at gcc dot gnu dot org]

------- Comment #4 from dfranke at gcc dot gnu dot org  2008-06-07 16:06 -------
Some progress:

libcpp, charset.c (emit_numeric_escape): here 
  cvt.width != CPP_OPTION (pfile, char_precision) [0 != 8]

If the logic of the check is inverted, everything works as expected. This
indicates that something might be missing in the setup of libcpp?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379

[Bug fortran/36379] preprocessing preprocessed output: invalid reads

[dfranke at gcc dot gnu dot org]

------- Comment #5 from dfranke at gcc dot gnu dot org  2008-06-07 16:51 -------
This should help:

+  cpp_option->char_precision = TYPE_PRECISION (char_type_node);

However, now I'm stuck with an ordering problem ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379

[Bug fortran/36379] preprocessing preprocessed output: invalid reads

[hjl dot tools at gmail dot com]

------- Comment #6 from hjl dot tools at gmail dot com  2008-06-09 20:00 -------


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


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379