public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* How to debug an issue with invalid virtual method calls?
@ 2010-04-02 10:50 Артем Анисимов
  0 siblings, 0 replies; only message in thread
From: Артем Анисимов @ 2010-04-02 10:50 UTC (permalink / raw)
  To: gcc-help

Hi!

  Recently I've written a program that works fine when compiled by GCC 4.4.X, 
but calls function at address 0x0 when compiled with current revision of GCC 
4.5.0.

  I tried making a self-contained testcase to post to bugzilla, but my 
attempts have failed, because a module that fails in a large program works fine 
when compiled by itself.

  I'm confident that failing in large program is not caused by bugs in other 
code, because the whole program works just fine when compiled by different 
versions of GCC 4.4 and for different platforms (Linux x86, Linux AMD64, win32) 
and runs under Valgrind without triggering errors.

  Since I am unable to separate the failing module from the rest of the 
program, I'll try to explain the problem here -- probably someone who has 
experience with C++ part of GCC can help with this issue.

  First, I've bisected GCC tree to find the change that caused the regression. 
Here are the results:
  rev. 148491 is ok,
  rev. 148492 fails to compile,
  rev. 148943 fails to compile, too (both fail in cgraph.c:1892),
  rev. 148944 miscompiles my program.

  Now a bit about the failing code itself.

  I have an interface that defines single pure virtual function:

class XBElementDefinitionFactory
{
public:
        virtual ~XBElementDefinitionFactory() {}
        
public:
        virtual XBElementDefinition* create(
                const XBContext *ctx,
                const QByteArray &propertyName,
                PropertyAccessorPtr propertyAccessor,
                const QString &elementName=QString()) const = 0;
};

  Another class stores a collection of these factories and, when necessary, 
calls

	const XBElementDefinitionFactory *f = factories.value(typeId);
	if(!f)
		return NULL;
	return f->create(this,propertyName,propertyAccessor,elementName);

  At this point f->create() jumps to address 0x0:

#0  0x0000000000000000 in ?? ()
#1  0x00000000004eb3a2 in XBContext::elementFor (this=0x25a1a80, typeId=285, 
elementName=..., propertyName=..., 
    propertyAccessor=...) at src/util/xmlBeans/XBContext.cc:271

  Some more notes:
  1. I've made sure that the factory instance does not get destroyed before 
invocation of f->create().
  2. Additionally, Valgrind shows no errors while running this program before 
call to create(). Only when this call is made, it reports "jump to invalid 
address". 
  3. This issue is likely to be a front-/middle-end issue because it's 
reproduced with binaries compiled without optimization and on x86 and AMD64 
platforms.
  4. It's worth noting that at point of failure f points to a factory that is 
an instance of class declared inside a function.

  How can this problem be debugged?

  If necessary, I can supply full source code for this program and provide 
instructions about running it. Unfortunately, it requires Qt 4.6 or higher to 
build and some special preparation before it can be used.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2010-04-02 10:50 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-02 10:50 How to debug an issue with invalid virtual method calls? Артем Анисимов

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).