To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
PVS-Studio and 3DO Emulators

PVS-Studio and 3DO Emulators

Apr 08 2014
Author:

I know I promised not to touch upon the topic of 3DO console emulators anymore - well, sorry for breaking that promise. You see, I've recently had an opportunity to try such an exotic thing as a static code analyzer - PVS-Studio, to be exact. The first project I decided to try it on was, naturally, my 3DO console emulator (Phoenix Project). It was the first 32-bit console with a CD drive, dating back to the beginning of the 90-s. Dad bought it in Moscow as a present for me and my brother - and I've been fond of it since then :-). And since I've got such an opportunity, why not check all the other 3DO emulators too? Here we go...

0247_FreeDOCore/image1.png

FreeDOCore, an original core from GoogleCode's repository

0247_FreeDOCore/image2.png

Project website: http://www.freedo.org/.

Revision: 8.

Note: it is the first and actually the only emulator of this console because all the others make use of its code one way or another.

Writing error.

V523: The 'then' statement is equivalent to the 'else' statement.

Line 673 - clio.cpp

0247_FreeDOCore/image3.png

An ordinary compiler doesn't treat this lovely error even as a Warning:

if((cregs[0x404])&0x200)
{
  ptr=0;
  while(len>=0)
  {
    b3=_xbus_GetDataFIFO();                
    ...
  }
  cregs[0x400]|=0x80;
}
else
{
  ptr=0;
  while(len>=0)
  {
    b3=_xbus_GetDataFIFO();                
    ...
  }
  cregs[0x400]|=0x80;
}

In this case, it's not only excess code but an emulation error as well; the XBUS protocol is two-party, but in this particular case it always performs reading only, which is not a critical issue for CD drive emulation, of course, but still a crude and potentially dangerous error for emulated games - what if one of them decides to burn through a CD?! Joking apart, this code will spoil the memory area specified in the DMA registers instead of writing data into the emulated XBUS interface. And it surely won't let you emulate such a rarity as FZ-EM256 3DO Memory Unit.

Reading error.

V614: Potentially uninitialized variable 'val' used.

Line 803 - clio.cpp

0247_FreeDOCore/image4.png

At first I thought it to be an insignificant defect, but then I recalled the ghosts in FIFO...

unsigned short  __fastcall _clio_EIFIFO(unsigned short channel)
{
  unsigned int val,base,mask;
  ...
  if(FIFOI[channel].StartAdr!=0)//channel enabled
  {
    ...
  }
  return val;
}

This code may cause reading some unpredictable values in certain cases as the val variable is initialized only when executing the condition. Theoretically, the DSP's FIFO must return the last value, kind of a ghost, read from it when cleared. In practice, the program can't read from empty FIFO, but who knows - what if a new game will be born after fixing?

Thus, we have two errors worthy of attention. Honestly, I thought there would be more.

FourDO, a modified core from the repository at SourceForge

0247_FreeDOCore/image5.png

Project website: http://www.fourdo.com/.

Revision: 387.

Note: This project has lived two lives: the first was when the authors had started writing the emulator from scratch on their own, but the patient unfortunately fell into a coma; and it was after the autopsy of FreeDO's source codes that the project started its second life with new organs. Let's see how well it gets along with implants...

A fixed error which is still an error.

0247_FreeDOCore/image6.png

I want to pass right on to the last discussed error in the original core (V614: Potentially uninitialized variable 'val' used. Line 803 - clio.cpp): the programmers have exorcised that ghost without much talking (or perhaps with quite a lot of?):

unsigned short  __fastcall _clio_EIFIFO(unsigned short channel)
{
  unsigned int val,base,mask;

  base=0x400+(channel*16);
  mask=1<<channel;

  if(FIFOI[channel].StartAdr!=0)
  {
    ...
  }
  else
  {
    val=0;
    // JMK SEZ: What is this? 
    // It was commented out along with this whole "else" block,
    // but I had to bring this else block back from the dead
    // in order to initialize val appropriately.
  }

  return val;
}

Well, they shouldn't have done that! The underlying problem was left unsolved but given a neat look so that nobody would have ever recalled it. The smartest solution would be to declare the val variable as static and initialize it to zero; the most correct solution would be to take it out of the function bounds and add into the list of variables for quick save - well, and delete the else block so that it wouldn't embarrass anyone.

Unfixed error.

V523: The 'then' statement is equivalent to the 'else' statement.

Line 673 - clio.cpp

0247_FreeDOCore/image7.png

The foot of "the Creator" has never stepped here - just like in the original. A note for those out of the swim: "the Creator" is one of the FourDO's authors, Victor (I don't know for sure if this is his true name or not; he's quite a bit of a Stierlitz ); he is also the author of 3DOPlay, another FreeDO's fork with the same errors inherited from the original project. There was a funny story about 3DOPlay: Victor decided to troll the community and said he was the Creator of the 3DO Emulator and FreeDO's developers had stolen his code. Shame on me, I, as a co-author of FreeDO, couldn't avoid getting involved into the conflict and was actively fighting against his project 3DOPlay. By the way, this is truly a very nice name for a project, but someone had come up with the nickname "three holes" (a literal translation of the Russian phrase "tri dupla" sounding similar to "3DOPlay", which makes a pun - a comment by translator) and thus the fight had begun... The story ended up with Victor moving to the FourDO team, and he actually deserves a highest praise as he was the only person who contributed to 3DO emulation development besides the authors of the original project.

Not an error yet.

V550: An odd precise comparison: Rez2T != 0. It's probably better to use a comparison with defined precision: fabs(A - B) > Epsilon.

Line 778 - madam.cpp

0247_FreeDOCore/image8.png

The code below works absolutely well, but it does make me worry quite a bit.

static double Rez0T,Rez1T,Rez2T,Rez3T;
...
Rez2T=(signed int)((M20*V0+M21*V1+M22*V2)/65536.0);
if(Rez2T!=0) M=Nfrac16/(double)Rez2T;
else M=Nfrac16;

In the original project, Rez2T used to have the int type. I guess the authors must have tried to get rid of the type conversion warnings that way, and they did it alright, but if someone decides to remove the forced conversion to the signed int type, there'll be a potential danger of getting an exception from the co-processor when dividing Nfrac16 by Rez2T.

And here is another piece of code that makes me worry about the health of the FourDO team's members:

void __fastcall _qrz_PushARMCycles(unsigned int clks)
{
    uint32 arm,cnt;
    int timers=21000000; //default
    int sp=0;
    if(sdf>0) sdf--;
    if(sf>0) sf--;
    if(unknownflag11>0)unknownflag11--;
    if(ARM_CLOCK<0x5F5E10)ARM_CLOCK=0x5F5E10;
    if(ARM_CLOCK>0x2FAF080)ARM_CLOCK=0x2FAF080;
    if(speedfixes>0&&speedfixes<0x186A1) 
      {/*sp=0x2DC6C0;*/ speedfixes--;}
    else if(speedfixes>0x186A1&&speedfixes<0x30D41)
      {/*if(sdf==0)sp=0x4C4B40; */speedfixes--;}
    else if(speedfixes<0) {sp=0x3D0900; speedfixes++;}
    else if(speedfixes>0x30D41) {/*sp=0x249F00;*/ speedfixes--;}
    else if(speedfixes==0x30D41||speedfixes==0x186A1) speedfixes=0;
    if((fixmode&FIX_BIT_TIMING_2)&&sf<=2500000) 
      {sp=0; timers=21000000; if(sf==0)sp=-(0x1C9C380-ARM_CLOCK);}
    if((fixmode&FIX_BIT_TIMING_1)/*&&jw>0*/&&sf<=1500000)
      {/*jw--;*/timers=1000000;sp=-1000000;}
    if((fixmode&FIX_BIT_TIMING_4)/*&&jw>0*/)
      {/*jw--;*/timers=1000000;sp=-1000000;}
    if((fixmode&FIX_BIT_TIMING_3)&&(sf>0&&sf<=100000)/*&&jw>0*/)
      {/*jw--;*/timers=900000;}
    if((fixmode&FIX_BIT_TIMING_5)&&sf==0/*&&jw>0*/)
      {/*jw--;*/timers=1000000;}
    if((fixmode&FIX_BIT_TIMING_6)/*&&jw>0*/)
      {/*jw--;*/timers=1000000; if(sf<=80000)sp=-23000000;}
    if(fixmode&FIX_BIT_TIMING_7){sp=-3000000; timers=21000000;}
    if((sf>0x186A0&&!(fixmode&FIX_BIT_TIMING_2))||
       ((fixmode&FIX_BIT_TIMING_2)&&sf>2500000))
         sp=-(12200000-ARM_CLOCK);
    if((ARM_CLOCK-sp)<0x2DC6C0)sp=-(0x2DC6C0-ARM_CLOCK);
    if((ARM_CLOCK-sp)!=THE_ARM_CLOCK)
    { THE_ARM_CLOCK=(ARM_CLOCK-sp);
        io_interface(EXT_ARM_SYNC,(void*)THE_ARM_CLOCK); 
        //fix for working with 4do
    }
    arm=(clks<<24)/(ARM_CLOCK-sp);
    qrz_AccARM+=arm*(ARM_CLOCK-sp);
    if( (qrz_AccARM>>24) != clks )
    {
        arm++;
        qrz_AccARM+=ARM_CLOCK;
        qrz_AccARM&=0xffffff;
    }
    qrz_AccDSP+=arm*SND_CLOCK;
    qrz_AccVDL+=arm*(VDL_CLOCK);
    if(_clio_GetTimerDelay())qrz_TCount+=arm*((timers)/
      (_clio_GetTimerDelay()));
}

The analyzer finds this code correct, but common sense tells us it is just awfully bad to do that (what exactly "that", I can only guess), taking into account the emulated processor's clock rate. Here is the original code sample:

void __fastcall _qrz_PushARMCycles(unsigned int clks)
{
 uint32 arm;
        arm=(clks<<24)/ARM_CLOCK;
        qrz_AccARM+=arm*ARM_CLOCK;
        if( (qrz_AccARM>>24) != clks )
        {
                arm++;
                qrz_AccARM+=ARM_CLOCK;
                qrz_AccARM&=0xffffff;
        }
        qrz_AccDSP+=arm*SND_CLOCK;
        qrz_AccVDL+=arm*(VDL_CLOCK);
        if(_clio_GetTimerDelay())
            qrz_TCount+=arm*((__temporalfixes?12500000:25000000)/
               (_clio_GetTimerDelay()));
}

Speaking generally, the patient is neither dead nor alive; there are few changes in the emulator's core, not all of them to the best; and they are all more than a year old according to the repository.

Phoenix Emu-Project: new bugs for a new core

0247_FreeDOCore/image9.png

Project website: http://www.arts-union.ru

Version: 1.7

Note: this is a 3DO emulator written from scratch with a maniacal purpose of making 3DO emulation as perfect as possible, though I actually meant it to be a multi-system emulator with the corresponding code infrastructure. Well, here's only 3DO for now.

Error: stripped textures!

V501: There are identical sub-expressions to the left and to the right of the '!=' operator: val.flags != val.flags.

Line 207 - gfx_celengine.h

0247_FreeDOCore/image10.png

struct gfxCelTexturePDECAttrib
{
    uint32 pre0;
    uint32 flags;

    int plutcount;
    uint16 plut[32];

    bool operator==(const gfxCelTexturePDECAttrib &val) const
    {
        if(val.pre0!=pre0)return false;
        if(val.flags!=val.flags)return false;
        if(val.plutcount!=plutcount)return false;
        for(int i=0;i<val.plutcount;i++)
        {
            if(val.plut[i]!=plut[i])return false;
        }
        return true;
    }
};

This is an error made from inattention and leading to defects in textures while playing. The reason is that when textures stored in the cache are only different in their CEL flags but identical in all the other parameters, this subtle difference may stay unnoticed, thus leading to using an incorrect shader for texture representation. The correct code should look like this:

if(val.flags!=flags)return false;

Error: garbage on the screen!

V579: The memset function receives the pointer and its size as arguments. It is possibly a mistake. Inspect the third argument.

Line 36 - vdlp_3do.cpp

0247_FreeDOCore/image11.png

This issue is very simple: VDLP fell a victim of inattention (again) during code modification about adding support for PAL games. The emulator had used to support NTSC games only, which is the most widely spread format, and the frame buffer had used to have a fixed size of 320 x 240 pixels - that's why it was declared inside a class as an array, without memory allocation.


screen=new uint8[384*288*3*4];
memset(screen,0,sizeof(screen));

To drive the error out of sight (I mean literally - because the first frame which is hardly noticeable is filled with garbage when the game starts), we can use the following code:

memset(screen,0,sizeof(uint8)*384*288*3*4);

Error: no CD found!

V595: The 'adapt' pointer was utilized before it was verified against nullptr. Check lines: 375, 376.

Line 375 - dumplibrary.cpp

0247_FreeDOCore/image12.png

My inattention again... Before addressing an object, I should have checked if it was correct, so the last two lines should be swapped. Otherwise, we'll get an exception when trying to load a saved game, with the required images absent.


dumpAdapter *adapt=createDumpAdapter(j,
  inf->Parent()->Attribute("attach").toString());
adapt->SetSign(signs[names[i]]);
if(!adapt)break;

What to say about all this? I ought to be more attentive or simply have enough rest in the evenings instead of programming emulators :-).

Conclusion

So, my first experience has shown that static code analysis is obviously a useful technology that can help developers save quite a lot of time and nerves. Of course, the price is pretty high for the emulators' area - just like it is for the Hex-Ray decompiler for ARM, that could push 3DO emulation much farther.

Popular related articles
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept