public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/17132] New: Improper evaluation of expressions involving virtual method invocations under EVAL_AVOID_SIDE_EFFECTS
@ 2014-07-09  0:33 sivachandra at gmail dot com
  2014-07-09  0:35 ` [Bug c++/17132] " sivachandra at gmail dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: sivachandra at gmail dot com @ 2014-07-09  0:33 UTC (permalink / raw)
  To: gdb-prs

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-12-26 18:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-09  0:33 [Bug c++/17132] New: Improper evaluation of expressions involving virtual method invocations under EVAL_AVOID_SIDE_EFFECTS sivachandra at gmail dot com
2014-07-09  0:35 ` [Bug c++/17132] " sivachandra at gmail dot com
2014-08-16  1:33 ` cvs-commit at gcc dot gnu.org
2023-12-26 18:24 ` ssbssa at sourceware dot 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).