Jim King said:
Actually, gdb tells the truth. And the template class has been
constructed by Temp<...>(a, b). When I acquire member a through
getA(), it returns the value of b instead. It leads to crash
consequently. That's the very abnormal. I didn't see any memory
corruption anyway.
I am just curious that if you met such a weird thing, how could you
do?
You seem to have all the tools that you need but, it being a large
codebase (as you have said), you appear to be having problems utilizing
them to good effect.
You are using gdb and you are able to locate points in the execution
where the problem, as you have identified it, occurs. I don't know how
you are invoking gdb or what debugging options you are passing to your
compiler but, from my own use of gdb, I am able to know at all times
both the source file I am `in' and the line number of the current
executing line. Consequently, I would expect that you would be able to
do the same.
Having located the source of the error, what source file contains the
code you are at that point executing? Once you have identified this,
then you have localized the problem within your huge codebase
dramatically. Then, in that file, what #include is provided to bring in
the definition of your Temp class? Have a look at that file. Is there
something wrong with the definition of Temp there? Perhaps the
definition of that type from that header is not too large to post here.
Maybe you notice that, at other points in the execution, you do *not*
get the same problem. At /these/ points, are you in a different source
file? Is the header file #included in this instance /different from/
the one that you identified what you encountered the problem (above)?
Possibilities are:
1. your code does not comply with the One Definition Rule (with
different headers used and containing, perhaps subtly, but
significantly different definitions for Temp). In this case, you
have bought for yourself undefined behaviour, and you may fairly
expect *anything* to happen.
2. you have a problem with your initialization order in the definition
of your Temp class. According to [class.base.init]/5, after
initialization of virtual base classes and direct base classes, then:
"nonstatic data members shall be initialized in the order in which
they were declared in the class definition (again regardless of
the order of the /mem-initializers/."
Are you perhaps relying on the order of the /mem-initializers/ in the
belief that everything is being initialized in the correct order
where, in fact, the order as determined by the declaration order in
the class definition results in initialization using indeterminate
values? (There is a thread about this on comp.lang.c++.moderated
currently).
3. You have not yet performed a full clean and build to remove (at your
own suggestion) the possibility of having object files still hanging
around that were built using an outdated (and incompatible)
definition of your class, previously in a header that may not itself
be present in the codebase.
It really shouldn't be too hard, and the size of the codebase shouldn't
be causing too much of a problem now that you have, as you say, already
been able to track down where the error is occurring and have been able
to say something about what is happening at that point. There, the use
of your Temp instance will require a definition in some header. Find
it. Look at it. Something is wrong, /there/, most probably.
These are some ideas but first of all, please... *ensure* that you have
entirely ruled out point 3. above. If you have not yet done this, then
everything else could be wasted time. As explained, it could indeed be
(in this case) that the problem code is not actually present in the
codebase for you to find. If you do not have faith in your build script
(makefile) to do the clean properly, run it and then check afterwards to
see that all object files and such like are actually removed.
Failing any such strategy, perhaps you should respectfully accept that
the problem is too big for you (if, that is, you are working on this
huge project in a professional context) and pass it on.
Good luck!
Regards
Paul Bibbings