Bug 157286 - 'this' pointer corrupted with -O2 optimization
'this' pointer corrupted with -O2 optimization
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc34 (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-10 03:16 EDT by Ben Greear
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-19 10:28:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Greear 2005-05-10 03:16:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050417 Fedora/1.7.7-1.3.1

Description of problem:
In the code below, I get a SEGV on the line starting with ###
according to gdb (gdb and this code is running on FC2, though
compiled on FC3)

In gdb, this1 is 0x0, and this0 is 0x854c650
this is 0x54c650
(yes, the first 8 is really missing, and yes, it appears the
line assigning this1 to some value was not actually executed).

I am compiling with this command:
g++ -m32   -I/usr/include/libxml2 -march=i586 -m32 -g -static -O2 -Wall -I/home/greear/btbits/btbits/include -I/home/greear/btbits/btbits/l4libs/curl-7.13.2/include -c LFl4Endp.cc

If I add some logging statements or similar, the problem appears to
go away.  When the problem is here, it happens every time.

If I compile without the -O2, it works fine.

If I compile on x86-32 FC2 (GCC 3.3.3), then it works fine with -O2
and without optimization.

Similar code has worked when compiled with FC3 in the recent past, but
I believe the 'up2date' tool recently upgraded the compiler.  Or, maybe
some random change in the code started triggering the bug.


It is also possible, of course, that I simply have a bug.  But, I
certainly don't see it, and things like valgrind don't complain
about bad memory accesses (untill the actual crash, that is).

I don't have a simple test case, but I will try to help provide
whatever debugging info I can.



static void* this0 = NULL;
static void* this1 = NULL;
static void* this2 = NULL;

int L4Endp::onStopTest(const char* reason) {
   LF_TRC_IN;
      
   VLOG_WRN(VLOG << "Stopping layer-4 endpoint: " << self.toString() << " reason: "
            << reason << " this: " << this << " isConnected: " << isConnected()
            << endl);

   // The Manager mode handles this already (in a different manner).
   if (! LANforgeMgr::isManager()) {

      // We go through all this work because stopped endpoints are not actively
      // polled for read/write buffer needs.
      this0 = this;
      flushToRemote();
      //VLOG << "this1: " << this << endl;
      this1 = this;
 ###     reqUpdateFromHelper();

#if 0
      // This worthless little piece of code seems to fix a compiler bug on FC3
      // It will virtually never evaluate to true.
      if ((ms_sleep_total & 0xFFFF) == 0xFFFF) {
         cout << "this2: " << this << endl;
      }
#endif

      this2 = this;
      flushBinaryOutput();

      VLOG_DBG(VLOG << "this2: " << this2 << " this1: " << this1
               << " this0: " << this0 << " this: " << this << endl);


Version-Release number of selected component (if applicable):
g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)

How reproducible:
Always

Steps to Reproduce:
1. See comments.
2.
3.
  

Actual Results:  'this' pointer is corrupted...seemingly loosing it's high byte.

Additional info:
Comment 1 Jakub Jelinek 2005-05-10 03:23:00 EDT
To debug it, we really need either a self-contained testcase (ideally
a preprocessed source that can be compiled and run), or preprocessed source
and description on where in the assembly is a problem (if we can't run the
testcase to at least be able to just compile it and see whether the bug in
assembly still exists).
Comment 2 Jakub Jelinek 2005-07-19 10:28:01 EDT
If you come up with a self-contained testcase, please reopen.
Comment 3 Ben Greear 2005-08-26 15:57:13 EDT
It turns out that this was a bug in my code.  I was scribbling a zero byte
into memory where I shouldn't have been.  At different optimization levels
(and different compilers) this problem was hidden.  Since the object that
was overflowed was allocated on the stack, this messed up the stack instead of
producing a SEGV at the time of memory corruption.

Thanks for your time.

Note You need to log in before you can comment on or make changes to this bug.