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