Jump to content


P4 C++ API 19.2 issue: FileSys::Name()


  • Please log in to reply
1 reply to this topic

#1 MikeW

MikeW

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 28 January 2020 - 10:16 PM

Hi, I have an odd issue.

When calling FileSys::Name() I am getting a thrown exception. Running in debug the debugger says the exception (read access violation) occured in FileSys::Set which makes little sense. If I check the dissassembly I see that the vtable entry for FileSys::Set is indeed being called (this+30h, slot 6, is called. The debugger says this vTable entry is for Set, Path appears in the vtable in slot 8).

Is it possible that the headers on the FTP for 19.2 are not the same as the versions you used to build the lib files? I can't seem to find something else that could cause this.

As an example:

               FileSys* pTestFile = TheClientUser.File( FST_TEXT );
                    pTestFile->Set( "C:\\A\File\Path" ); // This call works correctly. I see the path member set.
                    char const* pName = pTestFile->Name(); // This call throws a read access violation exception

I encountered this error first while reimplementing the Merge method of ClientUser.

The only other possible contributing factor is that I am using the P4 API from a background thread - but it is only ever used from that one thread.

I'm using the 19.2 C++ API on Windows, 64 bit (downloaded from ftp://ftp.perforce.com/perforce/r19.2/bin.ntx64/ ). Compiler is Visual Studio 2017.

Thanks in advance for any help,

Mike.

#2 MikeW

MikeW

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 29 January 2020 - 05:43 PM

Ok, I tracked this down. Including the cause & solution here for others:

The P4Api headers require a platform define to be set, OS_NT for windows. If this is set then FileSys includes two additional virtual methods. If it is not set then these two virtual methods are not included hence the FileSys vtable structure used by your code will differ to that used by the precompiled P4API libs.

So the solution is obviously to define the correct platform #def. :-)

Maybe the headers should detect if no OS_* define has been set and error out in the future?

Mike.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users