Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157286 - 'this' pointer corrupted with -O2 optimization
Summary: 'this' pointer corrupted with -O2 optimization
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc34
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-10 07:16 UTC by Ben Greear
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-19 14:28:01 UTC

Attachments (Terms of Use)

Description Ben Greear 2005-05-10 07:16:59 UTC
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

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) {
   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;
      //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;

      this2 = this;

      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:

Steps to Reproduce:
1. See comments.

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

Additional info:

Comment 1 Jakub Jelinek 2005-05-10 07:23:00 UTC
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 14:28:01 UTC
If you come up with a self-contained testcase, please reopen.

Comment 3 Ben Greear 2005-08-26 19:57:13 UTC
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.