[Bug c++/17132] New: Improper evaluation of expressions involving virtual method invocations under EVAL_AVOID_SIDE_EFFECTS

["sivachandra at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17132

            Bug ID: 17132
           Summary: Improper evaluation of expressions involving virtual
                    method invocations under EVAL_AVOID_SIDE_EFFECTS
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: sivachandra at gmail dot com

When GDB "evaluates" expressions under EVAL_AVOID_SIDE_EFFECTS it incorrectly
emits "Cannot access memory at address 0x0" in some cases. Examples:

/* Example 1  */

struct base
{
  virtual void func();
};

void base::func ()
{
}

base *b = 0;

Then in GDB:

(gdb) ptype b->func()
Cannot access memory at address 0x0

(gdb) p sizeof(b->func())
Cannot access memory at address 0x0

/* End example 1  */

/* Example 2  */

#include <memory>

class A
{
public:
 virtual int type (void);
};

int
A::type ()
{
 return 3;
}

int
main ()
{
 std::unique_ptr<A> a (new A);

 // Invoke A::type so that unique_ptr::operator-> gets generated.
 return a->type();
}

Within GDB, I see this:

(gdb) p a->type()
$1 = 3
(gdb) p 1 && a->type()
Cannot access memory at address 0x0
(gdb) p 1 + a->type()
$2 = 4
(gdb) p 1 || a->type()
Cannot access memory at address 0x0

It does not happen if A::type is not virtual.

/* End example 2  */

I traced this and what I find is that, since the expression involves invoking a
virtual method, find_overload_match tries to pick the implementation of this
method for the most derived type. And for doing that, it tries to read the
vtable for the object via its vptr. Since the object is NULL in example 1, it
trips.

Example 2 is slightly complicated. For logical operations && and ||, GDB
evaluates the first operand, and only evaluates the type of the second operand
as a first step. The reason being, if evaluating the logical operation does not
require invoking an overloaded operator, then the boolean value of the first
operand could determine the result of the operation even without requiring to
evaluate the second operand.

The observed error message is coming when GDB is trying to evaluate the type of
a->type(). At a high level, there are two operations in this expression: '->',
and invocation of method 'type'. Since GDB only wants the type of the
expression, it evaluates it under EVAL_AVOID_SIDE_EFFECTS. The intermediate
results are zeroed values of the correct type. But now, since 'type' is a
virtual function, GDB internally looks up the vtable of the zeroed intermediate
object to pick the implementation for the most derived type. This is where it
trips with "Cannot access memory at address 0x0".

-- 
You are receiving this mail because:
You are on the CC list for the bug.