I have been running into a lot of runtime problems bringing a
CodeWarrior C++ project over to Xcode. The most problematic
classes seem to be those where I have a base class with some
virtual methods and a class template deriving from it. If the
template object calls on a base class method which, in turn, calls
a virtual method implemented back in the template, the Xcode
executable sometimes drops the ball and can't find the right
virtual method. (The method dispatch table, when gdb lets me see
it, seems to have an unusually low address in those instances, and
may be pointing to unmapped memory?) This has never occurred in
CodeWarrior, and what is frustrating is that the behaviour in Xcode
can be unpredictable and difficult to reproduce.
Going back to this earlier problem, I have come across what appears
to be a bogus virtual method dispatch table working its way into my
executable. The situation is that I have a polymorphic template
class with two constructors: one default and one that takes
arguments. There are a fair number of global instances of this class
(mostly static class variables) which invoke one or the other of the
constructors even before we reach main().
gdb doesn't seem to like break points at this stage of the game, so
what I tried instead was to print some diagnostics into a log file
whenever either of the constructors was triggered. In particular, I
wanted to see what was going on with the method dispatch tables,
since my app was crashing the moment I tried to call a virtual
method. The log came out looking like this:
The entries with dispatch table address 0x35100 or 0x89108 are the
exact same class (i.e. the template made out for SInt32's). The
0x16b3040 table entry was for the same template but a different data
type (Float32).
It immediately struck me as odd that there would be two tables for
the same data type. In the early part of the log, it seemed as
though all instances using the default constructor used a different
table from those using the one with arguments. Eventually, however,
there came a point where the default constructors decide to adopt the
other table.
At runtime, the first case where I try to call a virtual method off
0x89108 results in a crash (bad memory access or bad instruction,
depending on the run), so it looks like 0x89108 is bad news. How can
I get rid of it?
I don't think the constructors themselves are doing anything illegal
(e.g. calling virtual methods themselves) or dangerous (e.g
allocating memory). They just initialize their data members.
Really, that's all the code that should have run before main(), so I
can't think of what I might be doing wrong. Any ideas?
-Ted
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
