This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

How to debug an issue with invalid virtual method calls?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]