OOAnalyzer reports DLL built by Visual C++ 6.0 contains no classes about pharos HOT 12 CLOSED

@holesmr For now as a work-around, you can comment out this rule:

from pharos.

Hmm, that is odd. It looks like Prolog may have failed. Can you share the .facts file?

from pharos.

Here's output from a run where I enabled Prolog facts/results output:

OPTI[INFO ]: Analyzing executable: engine-netbabel.dll
OPTI[INFO ]: OOAnalyzer version 1.0.
OPTI[INFO ]: ROSE stock partitioning took 71.0342 seconds.
OPTI[INFO ]: Partitioned 187777 bytes, 67592 instructions, 15381 basic blocks, 3 data blocks and 1092 functions.
OPTI[INFO ]: Pharos function partitioning took 94.2604 seconds.
OPTI[INFO ]: Partitioned 212992 bytes, 71498 instructions, 17081 basic blocks, 1112 data blocks and 2492 functions.
[INFO ]: Function 0x10005080 has no out edges.
OOAN[ERROR]: Found only 2263 functions of 2268 specifically requested for analysis.
OPTI[INFO ]: Function analysis complete, analyzed 2263 functions in 61.023 seconds.
PLOG[FATAL]: No complete solution was found!
OPTI[ERROR]: No C++ classes were detected in the program.
OPTI[INFO ]: OOAnalyzer analysis complete.

And the actual .facts file outputted (renamed to .txt so GH issues upload will accept it)
ooa-engine-netbabel.facts

from pharos.

Concluding mergeClasses(0x10035154, 0x10035164).
Merging class 0x10035164 into 0x10035154 ...
Retracting trigger_fact(factClassSizeGTE(0x10035164, 0)) and asserting trigger_fact(factClassSizeGTE(0x10035154, 0)) ...
Retracting factClassSizeGTE(0x10035164, 0) and asserting factClassSizeGTE(0x10035154, 0) ...
reasonForwardAsManyTimesAsPossible
Consistency checks failed.
A class may not have more than one real destructor:
 Class=0x10035154 Dtor1=0x10035164 Dtor2=0x10035154
Failed sanity check during forward reasoning

So the problem is that during the initial forward reasoning process, before any guesses have been made, we make a bad conclusion. Because there are no guesses, there is nothing to backtrack into, and we just give up.

So we need to figure out why the reasoning rules decided to (wrongly) try to merge those two classes.

This sounds like a job for @sei-ccohen! Can you take a look at this? I'll attach the full log.

from pharos.

log.txt
Here is an updated log with some more debug output. Interestingly:

reasonMergeClasses_G(0x10035154, 0x10035164, std::basic_ostringstream<char, struct std::char_traits<char>, class std::allocator<char> >, 0x10035154, 0x10035164).

which means that the class merger is coming from import symbols. So that is probably correct. So our reasoning about the real destructors must be incorrect.

from pharos.

It gets weirder. Both of the real destructors also come from symbols.

from pharos.

symbolClass(0x10035164, 'std::basic_ostringstream<char, struct std::char_traits<char>, class std::allocator<char> >', '`vbase destructor''').
symbolClass(0x10035154, 'std::basic_ostringstream<char, struct std::char_traits<char>, class std::allocator<char> >', '~basic_ostringstream').

There can be both a regular destructor and a vbase destructor apparently...

from pharos.

I'll give this a go later and see how it turns out.

from pharos.

Here's what I got:
final.txt

from pharos.

There can be both a regular destructor and a vbase destructor apparently...

Huh. I'm pretty sure that we have a rule that says that there can only be one real destructor per class. Apparently that's incorrect. It's always fun to learn something new about the compilers. :-) We can discuss in person and try to correct the rule. In the meantime, I agree the disabling the broken rule is the correct workaround.

from pharos.

@sei-ccohen We never decided on a course of action here. I am going to disable this rule in our next update. #75 is a more open ended issue for how we should handle vbase destructors in general.

from pharos.

This rule is disabled, though we still need a more complete fix

from pharos.