[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3549.0. "Calling wrong virtual function - Alpha VMS V7.0, DEC C++ V5.2" by STAR::DANTONI () Tue Apr 22 1997 13:32

A customer sent me the following problem description:

Alpha VMS V7.0, DEC C++ V5.2
When calling a virtual function (say func1) in a class, control actually
passes to another virtual function (say func2) in the same class. A little
research showed that func2 is declared after func1 in the class declaration.
Along the same lines, calling func2 would actually call func3 which is a
virtual function listed right after func2. The class which contains func1,
func2, and func3 (and a lot more functions) is derived from another class
which has virtual functions and there is a bit of a hierarchy of classes.
All of the code is built into a large shareable image (161524 blocks in the
.EXE file)

Some of their compilation switches which may be relevant are:
 /reentrancy=MULTITHREAD /standard=MS /noopt /debug (linking /debug also)

I've asked them to create a small sample which duplicates the hierarchy but
this may take a while given the complexity of the code. Is there anything
else I can have them do to try to isolate this problem?
T.RTitleUserPersonal
Name
DateLines
3549.1Some suggested actionsDECC::MDAVISMark Davis - compiler maniacTue Apr 22 1997 15:1932
1. I assume they have confirmed the bad calls by modifying their
code:

	func1(){ cout << "Entering func1 in class foo"<<endl; ...}

,...
	cout<< "about to call p->func1"<<endl;
	p->func1(...);

2. Getting a cut-down, ill-executing case is always best (for us :-)

3. I looked through our notesfiles, and didn't find anything mentioning
this kind of problem.

4. 5.2 is kind of old (Fall '95); do they want to upgrade to a newer compiler?

5. We could do some diagnosis by generating assembler listings from:
	a. the file containing the call p->func1()
		this will show us the offset into the virtual function
		table that is used for the call
	b. the file that defines a constructor or destructor for the
	class (e.g., foo.cxx if func1 is in class foo).
		this will show us the initialization of the virtual
		function table - we can match the index used in the call
		with the function name used at that offset in the table.

	We would need the customer to generate just the preprocessed version
	of these 2 files; then we could compile them here using 5.2 and
	other versions.

Mark Davis
c/c++
3549.2SPECXN::DERAMODan D'EramoTue Apr 22 1997 15:336
        The symptoms suggest to me that not all of the code has been
        recompiled and relinked since the last change to the class
        hierarchy (or they aren't using the shareable image they think
        they are using).
        
        Dan
3549.3ResponsesSTAR::DANTONIWed Apr 23 1997 12:2250
Re: .1 & .2

>1. I assume they have confirmed the bad calls by modifying their
>code:
>
>	func1(){ cout << "Entering func1 in class foo"<<endl; ...}
>
>,...
>	cout<< "about to call p->func1"<<endl;
>	p->func1(...);

I don't know the exact method they used but they did confirm that a call to
func1 results in the execution of func2.

>2. Getting a cut-down, ill-executing case is always best (for us :-)

They're working on it.

>3. I looked through our notesfiles, and didn't find anything mentioning
>this kind of problem.

I did find a similar problem in note 1388 but that was in V1.1 days and there
was no ultimate solution in the responses. However, one suggestion from that
string was to recompile and relink everything. I had the customer do this but
the problem persists. (Re: .2)

>4. 5.2 is kind of old (Fall '95); do they want to upgrade to a newer compiler?

I mentioned this to them but they are near the completion of a release and
don't want to change the environment at this time if they can avoid it. They
do plan to upgrade to the latest version of the compiler as soon as this
release is out the door.

>5. We could do some diagnosis by generating assembler listings from:
>	a. the file containing the call p->func1()
>		this will show us the offset into the virtual function
>		table that is used for the call
>	b. the file that defines a constructor or destructor for the
>	class (e.g., foo.cxx if func1 is in class foo).
>		this will show us the initialization of the virtual
>		function table - we can match the index used in the call
>		with the function name used at that offset in the table.
>
>	We would need the customer to generate just the preprocessed version
>	of these 2 files; then we could compile them here using 5.2 and
>	other versions.

I'll pass this along and see if they can provide the preprocessed files.

Thanks.
3549.4Problem resolvedSTAR::DANTONIWed Apr 23 1997 15:275
I just got word that the problem has been resolved. A missing definition in the
compilation of one of the modules somewhere in the hierarchy resulted in a
mismatch of functions between the classes and the application. The customer was
able to isolate the problem by analyzing the .IXX files. Thanks for all the
suggestions.