Initial sanity check failed (Class x inherits from y at offsets a and b)

[pawelktk]

I have the following problem at the ooprolog stage while analyzing the Guild 2 game binary (6.8 MiB):

tail ooprog.log

reasonForwardAsManyTimesAsPossible
Starting reasonForward.
reasonMergeClasses_K(0x9abb1c, 0x9aacec, 0x735f30).
reasonMergeClasses_K(0x9aacec, 0x9abb1c, 0x701450).
reasonForwardAsManyTimesAsPossible complete.
Entering stage 'Initial reasoning complete'.
Consistency checks failed.
Class 0x9edbdc inherits from 0x9f99cc at offsets 0 and 0x70
Initial sanity check failed, indicating the OO rules are incorrect.
Please report this failure to the Pharos developers!

Container version

seipharos/pharos:latest
Digest: sha256:eb35bcecb2f84f907d5506bc2e240768267dca2f396b2f79ff04dcd37f9b8839

Options

partition --serialize=ooprog.ser --maximum-memory=1280000 --per-function-maximum-memory=200 --per-function-maximum-memory=200 GuildII.exe

ooanalyzer --serialize=ooprog.ser --maximum-memory 1280000 --prolog-facts=ooprog-facts.pl --per-function-timeout=90 --per-function-maximum-memory=200 --threads=16 GuildII.exe

ooprolog --facts ooprog-facts.pl --results ooprog-results.pl --log-level=6 >ooprog.log

Files

Source binary

Serialized

Ooanalyzer facts

ooprog.log (loglevel=6, zipped)

[sei-eschwartz]

Thanks! This looks like everything we need. I'll take a look at it and try to see what is going wrong.

[sei-eschwartz]

I am finally getting a chance to look at this now. We have run into similar problems before with this sanity checking rule here:

    % ejs: Technically this should be factDerivedClass below, since it is possible in theory to
    % inherit and embed the same class.  But this is pretty unlikely, and would result in us
    % making some stupid guesses in which we inherit the first instance of a class and then
    % embed the rest.  Maybe a better fix would be to modify guessDerivedClass so that we don't
    % make the guess if there are multiple objectInObject facts.

So one thing you can try while I look at this further is to change factObjectInObject(A,B,O2), on line 71 to factDerivedClass(A,B,O2).

It could be due to that comment, or it could be due to something else. I will continue investigating.

[sei-eschwartz]

So if I check for inconsistency after each step, we fail at a slightly different spot as expected:

Class 0xa02f4c inherits from 0x9abb1c at offsets 0 and 0x8

0xa02f4c is ahead::services::i_File::vftable, whereas 0x9abb1c is ahead::cl_Root::vftable.

The last conclusion is:

Concluding mergeVFTables(0x9abb1c, 0x701450).

These come from:

reasonDerivedClass_D(0xaa6950, 0xa93028, 0xa02f4c, 0x9abb1c, 0).
Concluding factDerivedClass(0xa02f4c, 0x9abb1c, 0).

and

56563204: Retracting factObjectInObject(0xa02f4c, 0x701450, 0x8) and asserting factObjectInObject(0xa02f4c, 0x9abb1c, 0x8) ...
56562598: Merging class 0x701450 into 0x9abb1c ...
56492757: Retracting factObjectInObject(0x748190, 0x701450, 0x8) and asserting factObjectInObject(0xa02f4c, 0x701450, 0x8) ...
56492692: Merging class 0x748190 into 0xa02f4c ...
51599450: Concluding factObjectInObject(0x748190, 0x701450, 0x8).
reasonObjectInObject_D(0x748190, 0x701450, 0x8, validMethodCallAtOffset(0x7481a4, 0x748190, 0x701450, 0x8)).

Function 0x748190 calls 0x701450 at offsets 0 and 8. Here is binja's HIL:

00748194        sub_701450(arg1)
0074819e        *arg1 = &ahead::services::i_File::`vftable'
007481a4        sub_701450(&arg1[2])
007481ae        arg1[7].b = 0
007481b0        arg1[6] = &arg1[7]
007481b7        arg1[4] = 0
007481ba        arg1[2] = &ahead::kernel::cl_String::`vftable'
007481c0        arg1[5] = 0x20
007481c7        arg1[0x11] = 0
007481ca        arg1[0x10] = 0
007481d0        sub_401b40(&arg1[2], arg2)
007481dc        sub_747790(arg1, arg3)
007481e5        return arg1

I am pretty sure that what is happening is that cl_Root is probably the base class in this framework. So 0x748190's class inherits from cl_Root. 0x748190 embeds a cl_String at offset 8, which also inherits from cl_Root. This is the rare situation that I mentioned in the comment above.

TLDR: You should do this:

So one thing you can try while I look at this further is to change factObjectInObject(A,B,O2), on line 71 to factDerivedClass(A,B,O2).

[pawelktk]

So one thing you can try while I look at this further is to change factObjectInObject(A,B,O2), on line 71 to factDerivedClass(A,B,O2).

After changing that and running ooprolog again, another consistency check fails:

Entering stage 'Initial reasoning complete'.
failed.
Consistency checks failed.
Contradictory information about merging classes: Method1=0x9aacec Method2=0x9abb1c
Initial sanity check failed, indicating the OO rules are incorrect.
Please report this failure to the Pharos developers!

[sei-eschwartz]

Oops, mine had not gotten there yet, but it eventually did. I will look at this.

…

________________________________________ From: pawelktk ***@***.***> Sent: Friday, August 15, 2025 4:52 PM To: cmu-sei/pharos Cc: Edward J Schwartz; Assign Subject: Re: [cmu-sei/pharos] Initial sanity check failed (Class x inherits from y at offsets a and b) (Issue #287) Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. [https://avatars.githubusercontent.com/u/67957305?s=20&v=4]pawelktk left a comment (cmu-sei/pharos#287)<#287 (comment)> So one thing you can try while I look at this further is to change factObjectInObject(A,B,O2), on line 71 to factDerivedClass(A,B,O2). After changing that and running ooprolog again, another consistency check fails: Entering stage 'Initial reasoning complete'. failed. Consistency checks failed. Contradictory information about merging classes: Method1=0x9aacec Method2=0x9abb1c Initial sanity check failed, indicating the OO rules are incorrect. Please report this failure to the Pharos developers! — Reply to this email directly, view it on GitHub<#287 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AL6ZAVAXVO27PSS2BKFA7FL3NZB75AVCNFSM6AAAAACDRYM6DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJSG4ZDGNZVGM>. You are receiving this because you were assigned.Message ID: ***@***.***>

[sei-eschwartz]

0x9aacec is ahead::services::cl_Vector3::vtable, and 0x9abb1c is ahead::cl_Root::vftable. Clearly these are not on the same class.

The merging is coming from:

reasonMergeClasses_K(0x9abb1c, 0x9aacec, 0x735f30).
reasonMergeClasses_K(0x9aacec, 0x9abb1c, 0x701450).

% If two methods are present on the same object, and we know neither method's class has a base
% class, the methods must be on the same object.
reasonMergeClasses_K(Class1, Class2) :-
    factClassRelatedMethod(Class1, Method),
    factClassHasNoBase(Class1),
    find(Method, Class2),
    factClassHasNoBase(Class2),
    iso_dif(Class1, Class2),
    logtraceln('~@~Q.', [not(find(Class1, Class2)),
                         reasonMergeClasses_K(Class1, Class2, Method)]).

0x735f30 looks like cl_Vector3's constructor, and 0x701450 is cl_Root's constructor.

Seems weird that cl_Vector3 would have no base classes... I would imagine that would inherit from cl_Root?

Not according to OOAnalyzer rtti parsing:

rTTINoBaseName(0xa93028, '.?AVcl_Root@ahead@@').
rTTINoBaseName(0xa933f8, '.?AVcl_Vector3@services@ahead@@').

IDA seems to agree.

So I guess the question is: Why is 0x735f30 (cl_Vector3) related to 0x9abb1c (cl_root)?

[pawelktk]

It looks like cl_Vector3 really doesn't have any base classes. The only relation between cl_Vector3 and cl_root I see is that they share 0x00747de0 method.

0x00747de0 just returns string "cl_Root".

The other one of the two methods in cl_Vector3 vtable - 0x00402540 - returns string "cl_Vector3".

I imagine those methods purpose is to be used by the object tree (that doesn't necessarily resemble the true class structure) of the game debugger and that every entry needs to be under cl_root by a convention.

[sei-eschwartz]

Here is where the relation is coming from:

reasonClassRelatedMethod_C(0x9ef0fc, 0x6bd190, 0x9abb1c, 0x735f30).
reasonClassRelatedMethod_C(0x9e9d84, 0x68c460, 0x9abb1c, 0x735f30).
reasonClassRelatedMethod_C(0x9b2db4, 0x4457d0, 0x9abb1c, 0x735f30).
reasonClassRelatedMethod_C(0x9eeb6c, 0x6ba7a0, 0x9abb1c, 0x735f30).
reasonClassRelatedMethod_C(0x9eeea4, 0x6bbe20, 0x9abb1c, 0x735f30).

This rule is not super clear...

reasonClassRelatedMethod_C(InnerClass, InnerMethod) :-
    % An outer method calls and inner method on a this pointer.
    thisPtrUsage(_Insn, OuterMethod, InnerThisPtr, InnerMethod),
    % There's an offset from the outer this pointer to the inner this pointer.
    thisPtrOffset(_OuterThisPtr, Offset, InnerThisPtr),
    % BUG!!! We should really tie the OuterThisPtr to the OuterMethod, but we don't presently
    % export the facts required to do that, so we'll just assume they're related for right now.
    find(OuterMethod, OuterClass),
    % We must know that there's an object within an object at that offset.
    % See comments in reasonClassCallsMethod_D about using reasonClassAtOffset...
    reasonClassAtOffset(OuterClass, Offset, InnerClass),
    iso_dif(OuterClass, InnerClass),
    iso_dif(InnerClass, InnerMethod),
    % Debugging
    logtraceln('~@~Q.', [not(factClassCallsMethod(InnerClass, InnerMethod)),
                         reasonClassRelatedMethod_C(OuterClass, OuterMethod,
                                                    InnerClass, InnerMethod)]).

But basically it seems to say that we see a call to an offset of ecx, and we know there is a class at that offset. Here, 0x9abb1c is the InnerClass and 0x735f30 is the InnerMethod. Huh?

Ok, so at 0x6bd190, there appears to be a call to 0x735f30 at some offset, but we know that class 0x9ef0fc contains a sub-class of 0x9abb1c at the same offset?

Let's take a look at 0x6bd190. There are calls to 0x735f30 at offsets 0x37c and 0x398.

Retracting factObjectInObject(0x9ef0fc, 0x735f30, 0x37c) and asserting factObjectInObject(0x9ef0fc, 0x9aacec, 0x37c) ...
Retracting factObjectInObject(0x9ef0fc, 0x735f30, 0x398) and asserting factObjectInObject(0x9ef0fc, 0x9aacec, 0x398) ...

51599268: Concluding factObjectInObject(0x6bd190, 0x735f30, 0x398).
56630844: Merging class 0x6bd190 into 0x9ef0fc ...
56630909: Retracting factObjectInObject(0x6bd190, 0x735f30, 0x398) and asserting factObjectInObject(0x9ef0fc, 0x735f30, 0x398) ...
58331804: Merging class 0x735f30 into 0x9aacec ...
58332102: Retracting factObjectInObject(0x9ef0fc, 0x735f30, 0x398) and asserting factObjectInObject(0x9ef0fc, 0x9aacec, 0x398) ...

This is just telling us that the offset above was 0x398. But wouldn't the inner class be 0x9aacec then, not 0x9abb1c?

To state more clearly for myself, we must have reasonClassAtOffset(0x9ef0fc, Offset, 0x9abb1c) for Offset=0x398 and Offset=0x37c. But then why don't we have factObjectInObject(0x9ef0fc, Offset, 0x9abb1c)?

[eschwartz@pd4 GuildII]$ cat -n guild.results.log | fgrep 'factObjectInObject(0x9ef0fc'
108881  Concluding factObjectInObject(0x9ef0fc, 0x9e3804, 0).
56630908        Retracting factObjectInObject(0x6bd190, 0x735f30, 0x37c) and asserting factObjectInObject(0x9ef0fc, 0x735f30, 0x37c) ...
56630909        Retracting factObjectInObject(0x6bd190, 0x735f30, 0x398) and asserting factObjectInObject(0x9ef0fc, 0x735f30, 0x398) ...
58332101        Retracting factObjectInObject(0x9ef0fc, 0x735f30, 0x37c) and asserting factObjectInObject(0x9ef0fc, 0x9aacec, 0x37c) ...
58332102        Retracting factObjectInObject(0x9ef0fc, 0x735f30, 0x398) and asserting factObjectInObject(0x9ef0fc, 0x9aacec, 0x398) ...

Ah, there are many levels of inheritance:

.data:00AA1040 ; public class ahead::guildgameobjects::cl_FishSwarm /* mdisp:0 */ :
.data:00AA1040 ;   public class ahead::guildgameobjects::cl_GuildObject /* mdisp:0 */ :
.data:00AA1040 ;     public class ahead::gamebase::cl_MeasureSimObject /* mdisp:0 */ :
.data:00AA1040 ;       public class ahead::gamebase::cl_ScriptSimObject /* mdisp:0 */ :
.data:00AA1040 ;         public class ahead::gamebase::cl_SimObject /* mdisp:0 */ :
.data:00AA1040 ;           public class ahead::kernel::cl_CoreNode /* mdisp:0 */ :
.data:00AA1040 ;             public class ahead::kernel::cl_PropertyHolder /* mdisp:0 */ :
.data:00AA1040 ;               public class ahead::kernel::cl_Serializeable /* mdisp:0 */ :
.data:00AA1040 ;                 public class ahead::cl_RootRef /* mdisp:0 */ :
.data:00AA1040 ;                   public class ahead::cl_Root /* mdisp:0 */

So I suspect I have an inkling about what is going on. It all boils down to reasonClassAtOffset(OuterClass, Offset, InnerClass). I think that for a given OuterClass and Offset there can be multiple InnerClass values.

I am getting tired though and I will have to look at this tomorrow. It's unclear where exactly the problem is: MergeClasses_K or RelatedMethod_C.

[sei-eschwartz]

Looking at this with fresh eyes again. This is closely related to some problems we have discovered. For context, we have a paper about finding bugs in OOAnalyzer rules, and there is a branch of pharos where we patched these rules here: master...sei-eschwartz:pharos:paper-2022 One of the things we realized is that we did not have a consistent definition for "ClassCallsMethod" and whether it applied to both inheritance and embedding, or just inheritance. In the branch, we decided on "just inheritance". And here is how a similar ClassCallsMethod_C rule was fixed: https://github.com/sei-eschwartz/pharos/blob/paper-2022/share/prolog/oorules/rules.pl#L2491

Looking back at reasonClassRelatedMethod_C(0x9ef0fc, 0x6bd190, 0x9abb1c, 0x735f30)., it says that cl_FishSwarm's 0x6bd190 is related to cl_Vector3's 0x735f30. But looking at the base classes of cl_FishSwarm, I don't see cl_Vector3. So under the "just inheritance" definition of related methods, I don't believe the fact is correct. Instead, I suspect that cl_FishSwarm (or its base) likely embeds a cl_Vector3 at offset 0. In other words, I think this is the analogous problem fixed in ClassCallsMethod_C on the branch.

@pawelktk What this means for you is that you can temporarily disable reasonClassRelatedMethod_C while we figure out the more general solution. An easy way to do that is to insert fail, on this line: https://github.com/cmu-sei/pharos/blob/master/share/prolog/oorules/rules.pl#L2357

What this means for us:

• Why didn't I merge the ClassCallsMethod changes back into master? I don't remember...
• Should we just apply the same fix to ClassRelatedMethod_C?

[pawelktk]

Thank you so much, now it passes the initial sanity checks!

I left it running overnight and it's been running for 25 hours, it's using up ~200GB of memory (mostly swap at this point). Is there any way to estimate from the log how far into the process are we?

pawel@archlinux-ll /d/analysis_08_08_2025> tail -n 20000 ooprog3.log | uniq | grep "There are"
There are 1,723,822 known facts.
Starting guess. There are currently 16,517 guesses.
There are 1,723,808 known facts.
Starting guess. There are currently 16,518 guesses.
There are 1,723,794 known facts.
Starting guess. There are currently 16,519 guesses.
There are 1,723,796 known facts.
Starting guess. There are currently 16,520 guesses.
There are 1,723,780 known facts.
Starting guess. There are currently 16,521 guesses.
There are 1,723,764 known facts.
Starting guess. There are currently 16,522 guesses.
There are 1,723,748 known facts.
Starting guess. There are currently 16,523 guesses.
There are 1,723,732 known facts.

[sei-eschwartz]

Glad to hear that it is running. The best method is probably to grep for "Entering stage". You should be able to get the complete list of stages by running on a small binary.

It is very possible that you won't be able to run your file to completion. We have had mixed luck with similar large executables. Sometimes with a lot of RAM and patience they do complete. And sometimes they slow to the point of being impractical. We worked for a while with the maintainer of SWI Prolog on this, but we ultimately did not solve it :-(

I am trying to run your file as well on a new branch for testing, so at least you'll have two attempts at it!