public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/63489] New: stack allocated array pointer corrupted
@ 2014-10-08 16:01 jonathan.hogg at stfc dot ac.uk
  2014-10-08 17:53 ` [Bug c++/63489] " redi at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: jonathan.hogg at stfc dot ac.uk @ 2014-10-08 16:01 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 63489
           Summary: stack allocated array pointer corrupted
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jonathan.hogg at stfc dot ac.uk

Created attachment 33667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33667&action=edit
test case

The attached code, when compiled as
g++ -g -O2 testcase.cxx  -o testcase && ./testcase

and run, produces:
Try 0x7fff1cbe0a00 0x7fff1cbe0a00
Perm exit:  0 1 2 3 4 5 6 7
GO 0x7fff1cbe0a00
Try2 0x100000000 0x100000000 
Segmentation fault


g++ --version:
g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


The lines "Try" and "Try2" should be identical, as they refer to the same
stack-allocated array perm[]. Running under valgrind is clean until the last
line of ldlt_test() is encountered (which is clearly a segfault as perm is a
bad pointer).

Compiling without -O2 changes something, and the code crashes differently. I
can supply a larger test case (from which this was created) that shuold produce
meaningful answers if the code works correctly, but it will need to be provided
privately for IP reasons.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/63489] stack allocated array pointer corrupted
  2014-10-08 16:01 [Bug c++/63489] New: stack allocated array pointer corrupted jonathan.hogg at stfc dot ac.uk
@ 2014-10-08 17:53 ` redi at gcc dot gnu.org
  2014-10-08 17:53 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-08 17:53 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That was pretty easily found with -fsanitize=address


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/63489] stack allocated array pointer corrupted
  2014-10-08 16:01 [Bug c++/63489] New: stack allocated array pointer corrupted jonathan.hogg at stfc dot ac.uk
  2014-10-08 17:53 ` [Bug c++/63489] " redi at gcc dot gnu.org
@ 2014-10-08 17:53 ` redi at gcc dot gnu.org
  2014-10-09  8:28 ` jonathan.hogg at stfc dot ac.uk
  2014-10-09 12:36 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-08 17:53 UTC (permalink / raw)
  To: gcc-bugs

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Do you have a testcase that doesn't exhibit obvious undefined behaviour that's
easily pointed out with -Wall, such as dividing by uninitialized values?

There's a buffer overflow here:

      for(int i=0; i<2; i++) invp[oldp[i]] = i;

Try adding an assertion that oldp[i] is in range.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/63489] stack allocated array pointer corrupted
  2014-10-08 16:01 [Bug c++/63489] New: stack allocated array pointer corrupted jonathan.hogg at stfc dot ac.uk
  2014-10-08 17:53 ` [Bug c++/63489] " redi at gcc dot gnu.org
  2014-10-08 17:53 ` redi at gcc dot gnu.org
@ 2014-10-09  8:28 ` jonathan.hogg at stfc dot ac.uk
  2014-10-09 12:36 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: jonathan.hogg at stfc dot ac.uk @ 2014-10-09  8:28 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Jonathan Hogg <jonathan.hogg at stfc dot ac.uk> ---
Confirmed, this is the cause is the larger example as well. I had missed the
introduction of -fsanitize=address, useful feature. I'd assumed something like
that valgrind would have picked up for me however!


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/63489] stack allocated array pointer corrupted
  2014-10-08 16:01 [Bug c++/63489] New: stack allocated array pointer corrupted jonathan.hogg at stfc dot ac.uk
                   ` (2 preceding siblings ...)
  2014-10-09  8:28 ` jonathan.hogg at stfc dot ac.uk
@ 2014-10-09 12:36 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-09 12:36 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think valgrind only checks heap memory, so doesn't help for buffer overflows
on the stack.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-10-09 12:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-08 16:01 [Bug c++/63489] New: stack allocated array pointer corrupted jonathan.hogg at stfc dot ac.uk
2014-10-08 17:53 ` [Bug c++/63489] " redi at gcc dot gnu.org
2014-10-08 17:53 ` redi at gcc dot gnu.org
2014-10-09  8:28 ` jonathan.hogg at stfc dot ac.uk
2014-10-09 12:36 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).