[Bug lto/110605] New: Possible lack of error checking in lto-common.cc ?

[Bug lto/110605] New: Possible lack of error checking in lto-common.cc ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605

            Bug ID: 110605
           Summary: Possible lack of error checking in lto-common.cc ?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I am investigating a valgrind error in the lto code:

==910546== Conditional jump or move depends on uninitialised value(s)
==910546==    at 0x71DF70: lto_resolution_read (lto-common.cc:2126)
==910546==    by 0x71DF70: lto_file_read (lto-common.cc:2351)
==910546==    by 0x71DF70: read_cgraph_and_symbols(unsigned int, char const**)
(lto-common.cc:2805)
==910546==    by 0x706FA9: lto_main() (lto.cc:654)
==910546==    by 0xCE0F39: compile_file() (toplev.cc:444)
==910546==    by 0x6C26F9: do_compile (toplev.cc:2126)
==910546==    by 0x6C26F9: toplev::main(int, char**) (toplev.cc:2282)
==910546==    by 0x6C3FDA: main (main.cc:39)

The line 2126 is

^d4ba3b369 (Jonathan Wakely          2022-11-01 09:48:41 +0000 2126)      if
(strcmp (lto_resolution_str[j], r_str) == 0)

I had a look around and I noticed just before this is:

^d4ba3b369 (Jonathan Wakely          2022-11-01 09:48:41 +0000 2106)   fscanf
(resolution, "%u", &num_symbols);

It has no error checking. I think this will produce a warning with
-D_FORTIFY_SOURCE=1.

I can't prove the lack of error checking on the fscanf line is related to
my valgrind problem, but it does look suspicious. Suggest fix.

[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
most likely not a big issue of not checking the return value here as the next
fscanf that is the first thing inside the loop around num_symbols .

[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 55507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55507&action=edit
object module

[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---

Given the command line:

/home/dcb38/gcc/results.20230706.valgrind/bin/gcc cpgarro.o libpgplot.a

then I get the valgrind error. I have attached cpgarro.o, but libpgplot.a,
even with compression from xz, is 2,248,588 bytes long, so still too large.

Any hints to avoid this file size limit would be most welcome.

[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-07-10
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
If you do -save-temps -v you should see the actual resolution file passed as
-fresolution=foobar.res to lto1 - can you attach that foobar.res file?

[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 55511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55511&action=edit
res file