How 10 years ago the project PVS-Studio started

Ten years ago we created a simple utility called Viva64, designed to detect some problems in 64-bit code. This was the beginning of the static code analyzer PVS-Studio. Although 10 years have passed since that moment, something more or less with us, like a company, began to turn out only a few years ago. This article is not a success story, as we believe that everything interesting is just beginning. However, 10 years is a reason to sum up the interim results and tell our readers how it all began, what mistakes we were waiting for, and what we have done so far. In some places, I may not be quite chronologically accurate when describing events. My memory is not perfect, and 10 years is a long period of time. I wish you all a pleasant reading.

Prehistory

I (Andrei Karpov) and Evgeny Ryzhkov worked in a small Tula company engaged in the creation of packages of numerical modeling and data visualization. The work was interesting and managed to touch the most advanced technologies of the time. For example, working with data visualization tasks, we experimented with 3D glasses, which work on the principle of alternating eye closure. Images were displayed on a CRT monitor, which showed the image for the left, then for the right eye. I think very few people have seen such antiquity: glasses connected to a computer via a wire, and a CRT monitor operating in interlace mode (100 frames per second), so that each eye has at least 50 frames. It looked, in fact, all this was terrible, and my eyes instantly began to hurt, so it’s not surprising that this technology did not take root widely.

Also, for example, we were engaged in independent manufacturing of a budget cluster based on ordinary computer motherboards. We used boards with two physical AMD processors. Now you will not surprise anyone with an 8-core processor. At the same time in Tula shop motherboard with two cores - it was a wonderful miracle, a marvel. We combined 4 such boards and got an 8-core mini-cluster, where we carried out various calculations. I directly participated in the soldering of this device:
')

Figure 1. A mini cluster assembled from scrap materials. Features: 8 processors, 16 gigabytes of memory.

It didn’t work out very well, as the issue of ventilation could not be properly resolved and I had to sacrifice beauty to remove the back covers. However, the cluster coped with its tasks.

We also ran into the first 64-bit computers available for ordinary users. These were machines with Opteron processors and a huge, as it seemed to me, memory capacity of 4 gigabytes. But with these machines it all started.

In 2005, Visual Studio 2005 was released, in which it became possible to develop 64-bit programs for 64-bit architecture (at that time it was called AMD64). I also remember I went to Moscow to a conference of the Microsoft company, where they showed how now it is easy and simple to recompile the code for a 64-bit processor. In general, 64-bit - this was a new important trend in the development of computers.

Of course, there were 64-bit microprocessors before that. For example, you can remember the same Itanium . But it was the appearance of AMD64 that had a significant impact on the IT industry: 64-bit processors appeared available to the average user, and applied Windows programmers had the opportunity to write programs for these processors in the usual Visual C ++ development environment.

In tasks of visualization and numerical simulation, a large amount of memory is extremely important. Therefore, immediately with the release of Visual Studio 2005, we began work on creating 64-bit versions of applications.

It is not surprising that we were one of the pioneers who adapted their application code to 64-bit processors and, as a result, stepped on many new rakes. For example, it turned out that the hardware security keys used for software distribution are not quite ready for 64 bits. I do not remember what exactly was wrong, but I had to tinker with the new version of code protection. There were also some nuances with the program for creating distributions. But all this - little things. The most interesting was waiting for us further.

Microsoft did not deceive us, we really quickly managed to recompile our applications in x64 mode. It took about 3 weeks. And as it seemed to us then, we received a 64-bit distribution of our applications.

Ha! That's just the program did not work correctly. And in their wrong work was some kind of meanness. Programs successfully passed all internal tests, correctly worked on test data. But when we wanted to use all the power of a 64-bit application, strange strange errors began. The program began to fail when allocated more than 10 gigabytes of memory for processing large sets of input data.

Figure 2. I have not saved any pictures that demonstrate rendering errors in a 64-bit application. I could not assume that in many years I would need them. But this picture is very similar to the result of the errors that I observed. Unexpectedly, only part of the object could be rendered.

Now I know all the reasons that led to such strange behavior of programs. Somewhere the pointer was turned into an int , and then back into the pointer. If the pointer referred to an object in the lower 4 gigabytes of memory, then everything was fine. But if the object was created abroad in 4 gigabytes, then problems were inevitable.

There were errors in the calculations of the form:

unsigned int X, Y, Z; Uint64 Q = X * Y * Z; 

Although the result is a 64-bit variable, this does not help. Overflow occurs when multiplying 32-bit variables.

Naturally, there are many other ways to shoot yourself a leg. You can learn more about all these troubles here: " A collection of examples of 64-bit errors in real programs ."

Then, in 2005, what was happening with our programs looked like incomprehensible magic. And most importantly, at that moment we did not understand how we could find and eliminate defects. All of our methods unexpectedly refused us.

I repeat that unit tests work correctly and do not reveal anything. On small test data, everything is fine too. Debugging on large amounts of data is almost impossible. First, it is very slow. If the release of the program should work for half an hour in order for errors to begin to manifest themselves, then the debug version of the program works for long hours. Secondly, it is not clear, and what, in fact, in the debugger to watch. Do not study the billions of iterations of the cycle to find when something starts to go wrong. When debugging, programmers always try to use the minimum data set to reproduce the error. And here on the small sets everything is fine.

We turned to the then popular BoundsChecker program, which had helped us more than once. It just turned out that she still does not know how to work with 64-bit applications. However, if I worked, I don’t think it helped us a lot. The speed of the program when using BoundsChecker slows down tenfold. I think for our cases this would have resulted in days of waiting.

We understood that a deadlock had come: we know that there are errors in the program, but we don’t know how to look for them.

Our team began to study the situation in more detail. Conducted experiments, read the Internet. Gradually it became clear what we were facing. We began to understand what mistakes live in our programs, only it didn’t make it any easier. Suppose we suspect that overflows in arithmetic operations are to blame for some errors. So what's next? How to find them, these places?

From despair, we began to look for new ways. The option to replace all integer types with special classes, such as SafeInt, was considered. This would at least make it easy to find integer overflows. However, it turned out that to make it for existing applications is very difficult.

Then we got acquainted with some static code analysis tools and even bought Gimpel PC-Lint . But this analyzer almost did not help us. It was not focused on finding 64-bit errors.

And here we realized the consequences of the fact that we are pioneers. We are faced with 64-bit errors for which the world has not yet offered any solutions.

How did we get out of the situation? We decided to read the code. Of course, not all. We configured PC-Lint so that it issues warnings on all explicit type conversions, on an implicit int extension to 64-bit types, and so on. Of course, it turned out an incredible amount of useless messages, but it's still better than just reading all the code from beginning to end.

We studied the potentially dangerous places to which, after special configuration, we were pointed out by PC-Lint. Fully read the most important modules and functions. And now, after a few months, we finally got a stable version of 64-bit applications.

As you may have guessed, two people were engaged in porting to the 64-bit system: me and Yevgeny Ryzhkov.

The conclusions we then made:

• when switching to 64-bit systems, people will encounter 64-bit errors in their code;
• these errors are very difficult to look for;
• There are no tools to help find such errors.

At about the same time another fateful event took place. Yevgeny Ryzhkov became interested in reading books about startups and the new-fangled ISV (Independent software vendor). However, the word "startup" then, it seems, was not yet. In any case, in the sense in which there is now.

11 years ago, the phone industry was not yet developed, the App Store did not exist, and the like. If there were, Eugene, perhaps, would be engaged in the creation of games for phones and tablets. At the same time he was limited to an ordinary computer. He tried to make an application - a coloring for children, and tried to sell. In general, it was possible to realize everything and even make a few sales, but, of course, there was no need to talk about any success and income from this undertaking. He began to look for a new application of his forces.

I also had an entrepreneurial spirit, and I wanted to try to create something of my own. However, at that time all these thoughts were fuzzy and did not find any real incarnation. And then Eugene suggested thinking about creating something that would conquer the world and make us rich and famous. In general, I infected a classic startup starter. And we started thinking.

Viva64 version 1.0

So, there are:

1. two people who want to start a startup;
2. these two people are familiar with the existence of the problem of finding errors in 64-bit programs in C ++.

It would seem, so what is there to think about? We must make and sell a tool to search for 64-bit errors. However, we have long enough come to this idea. It seemed to us that this is a complex, incomprehensible task that no one knows how to solve, since there are no tools yet.

At the beginning we went over some simple and clear ideas. Sites do not want to. I wanted to create exactly the finished software product. But this is what the world has to offer - we did not understand for a long time. I wanted to choose a direction in which there can be real demand, and not just an abstract beautiful idea.

After a while, we started thinking about the tool for searching 64-bit errors in C and C ++ programs. For a start, we figured out exactly what it should be. At first we thought about some kind of dynamic analyzer, such as BoundsChecker. However, it was too difficult, plus it was not clear how to make the search for errors of some species.

Gradually, it became clear to us that this should be a static code analyzer. Those. a program that points programmers to code points that need to be checked. It was necessary to create a tool like PC-Lint or Parasoft C ++ test, but only focused on finding specific types of errors.

An important question was whether it was possible for us to make such a tool at all, after all it was a question of parsing C ++ code. I had to study this question.

There was no LLVM at that time, so we considered the option to use the GCC compiler or one of the free libraries as a basis. It is clear that there were also paid libraries for parsing C ++ code, but we didn’t even consider them. GCC seemed to us to be too complicated and ponderous, plus it was not clear if it was possible to somehow create a closed application based on it. Open did not want to do, because it is not clear how to earn it. As a result, the choice fell on the little-known OpenC ++ library. By this time the library was abandoned, but this did not stop us, especially since it seemed very simple, and we very quickly were able to write the simplest test diagnostics with its help.

And so we decided and decided that we would do a tool to search for 64-bit errors in C / C ++ code. In fact, it will be a classic static code analyzer, but at that time we tried not to use these words. It seemed to us that this would only confuse people who would search the Internet for “a tool for finding 64-bit errors”.

Having experience with Gimpel PC-Lint, we immediately decided that we would do the tool as a plug-in to Visual Studio. In those days, to use PC-Lint from Visual Studio, you had to dance with a tambourine. Later I even wrote a short note on this topic, which, by the way, was popular: Installing PC-Lint and using it in Visual Studio 2005 . In general, we believed that such integration is no good and we must immediately provide users with a convenient interface. Those. the person must install the tool and immediately be able to proceed with the verification of the project. It is this principle that our team still follows and considers it very important.

At that time, we imagined Viva64 as a simple utility that we would sell for only $ 200, but massively. We thought that this tool should sharply demand in connection with the global rewriting of programs for 64-bit processors. The plan was this: we make a simple tool, which will soon be in great demand, we sell it 3-4 years. Then, having earned money on this ingenious foresight, we will be engaged in some other project. In general, youthful fantasies about what a cool idea we came up with and how quickly we will rise on it. Even such a graph was drawn about how, in our opinion, the demand should look like:

Figure 3. In 2006, Eugene drew such a graph of the alleged relevance of the solution for testing C ++ code for compatibility with the AMD64 platform. It was assumed that in 2010 the demand will decline and, in addition, Microsoft will release some kind of standard solution that will push the Viva64 analyzer out of the market. However, in 2-3 years we hoped to remove the “cream” and save money for future undertakings.

Having inspired ourselves with dreams of success, we started programming, creating a distribution kit and the first version of the site. All this was done in the evenings, as during the daytime we still worked in the office at work. The path from the idea to the first version took about a year.

And here was a landmark event: December 31, 2006, we posted the first public release of Viva64 version 1.00 on the Internet. I remember Eugene told me that it is necessary to lay out before the new year, so that 2006 will appear in the version history. It will seem to users that the tool already exists for at least a year, and this will give it solidity. Now, after a long journey of 10 years, it all looks naive, but then it all seemed very important.

The budget for creating the first version of the analyzer and the site was 43200 rubles. Naturally, our time and energy are not included here. These were additional expenses. To make it easier to understand the amount, we will recalculate at the dollar rate of those times and get $ 1710. We can say that we all did almost no spending.

Since 2007, we began to try to sell our instrument, gradually improving it. Work added even more. In addition to programming on previous work and programming of the analyzer, added work to promote Viva64 among programmers. Eugene and I began to learn how to write articles, communicate in forums, and try out some variants of paid advertising.

All this very quickly exhausted our moral and physical strength. In addition, in the previous work, everything was not so bright and rosy. We realized that we could no longer work in this mode and quit, temporarily becoming unemployed.

And sales did not go and did not go. Rather, we managed to sell something a little bit, but so little that it makes no sense to talk about it.We did not even try to withdraw the money accumulated on the reseller account, as they would not help us.

It was a difficult phase. Cash reserves melted, and there was no place to replenish them. There was a great temptation to quit and just get a job somewhere. But we held on. We were reassured by the idea that programmers are always in demand everywhere, and if everything becomes really sad, we will work somewhere during the week.

We were looking for some options to find money to continue development and believed that we had to hold on a little bit and the growth in demand for our tool would begin. I already poorly remember our chaotic actions of that time. I remember, for example, a trip to Sergey Lisitsyn at AutomatedQA, whose development office is located in Tula. We tried to interest him in our work. But what we were doing was somehow not met with any interest. Although, perhaps, we just knocked on the wrong door or did not know how to tell about ourselves.

- , Viva64 . . , . Ingate Intelsys. . , . , . , CAD . , . , NURBS .

4. . , , , , .

. 8 CAD , , , Viva64, , - . , , . , . . , , - , . , .

Viva64 , . , . , , - 64- .

, 64- . 32- 64- . . PVS-Studio, - , , 64-.

, 64- , . , 64- . 10 Viva64, PVS-Studio 64- . . , 2-3 , . , , . , , 10 .

, , . «64- » .

2008,

, 2008 . , 2007 , 2008. , . :

« — , , , - , . , „“ , ».

, : . , . , , . , .

. , . , . , . .

. , ( 750 000 ). . , , . , . , - , . . - .

Figure 5. OOO “Program Verification”, 2008. The first day in the first own office.

In total, participation in the Start program made us leave the house and start not playing the Viva64 project, but actually doing it. Start pushed us to register an LLC, hiring the first employees, and generally made us feel like the real organizers of the company.

This is the main value of this program for us. She organized us and made us think about ourselves not just as programmers with an interesting technical project, but as entrepreneurs. This program has become a kind of catalyst for our project. She forced out of the comfort zone and begin to deal with new issues and challenges. For this thanks to the government and everyone who organizes this program.

This ends the good. . , . , , . , . , , . , . , , , . , .

, : . - « », . . , , , : .

It was "Hell." And when the year 2008 ended, we decided that we would not try to extend our participation in the Start program. The bureaucracy takes too much, and the time and effort we spend on it is wasted. At that time, some sales of Viva64 started to go on the sly, and we saw that we clearly were devoting less effort to the project than we could. We decided that we would rather tighten our belts, but then we would be more engaged in promising areas, and not in printing Talmud reports. We did not apply for the next year. From the side of such a decision, it may seem silly. But I am sure that then we did the right thing and, perhaps, saved ourselves 1 or 2 years.

I mentioned that some sales of Viva64 began. Yes exactly.And we began to gradually increase the price, since the clients were large companies. It was then that the suspicion crept in that we were making the product not for programmers, but for companies. However, to the realization that we are B2B, it was still far away.

VivaMP, the first error

. , , -, , , -, . , , . , 5 — . , , .

. VivaMP. 2008 , 2009 .

So, we have already accepted that 64-bits did not give us a quick “take-off”, and began to look for a new direction, where we can get ahead of others. And as it seemed to us - they found it.

In 2008, multi-core processors began to appear massively. On the agenda of programmers there was a question: which technology will dominate in the development of parallel programs in C and C ++? The options were different: MPI, OpenMP, some already existing libraries, or that could soon appear.

Intel OpenMP. , . : , OpenMP. , — . . - , , , , . OpenMP . "#pragma omp ...." , .

We studied in detail the topic of programming using OpenMP and made sure that there are errors that can be detected by static code analysis. Those interested can get acquainted with our article: " 32 OpenMP pitfalls when programming in C ++ ."

In general, the new theme was chosen incorrectly. Totally wrong. If with 64 bits the interest was and is, even if not as big as desired, then in the case of OpenMP there was no interest at all.

The reasons for bad luck, apparently, were several:

1. OpenMP technology does not become mainstream. It occupies a modest position on a par with other technologies of parallel programming.
2. , OpenMP . , . , , , VivaMP.
3. .

VivaMP . . .

VivaMP PVS-Studio, 2014 . OpenMP , . , . . .

VivaMP — . - — .

, 2009 . Viva64 , , . , , - .

PVS-Studio ,

2009 Viva64 VivaMP VivaMP 64- . , .

, 2009 , . PVS-Studio, Viva64 VivaMP.

, , . Viva64 : « 64- !». «viva» «Viva Forever». , . www.viva64.com , , .

PVS-Studio . — OOO «Program Verification Systems». «Studio» , , , , . , , : - , - PVS PSV . , - . , , CppCat, , .

Let us return to the main story line. In 2010, we decided that we could increase interest in the PVS-Studio analyzer, adding to it some general-purpose diagnostics. And we planned to make these diagnostics free, because we didn’t believe that they could earn something. In the field of general-purpose diagnostics for C and C ++, tools such as Coverity, Parasoft C / C ++ test, Klocwork, Gimpel PC-Lint and so on reigned at that time. We did not see any sense even trying to press these tools. Therefore, we planned to make free general-purpose diagnostics exclusively for promotional purposes. The idea was this: a person checks his project for free, and at the same time learns about paid diagnostics related to 64-bit and OpenMP.

2010 - PVS-Studio 4.00, . 45 . : " , ! PVS-Studio 4.00 ".

, . , , . , - , « ».

We were written by a programmer who assessed our general-purpose diagnostics and asked how much he should pay for them in order to continue using them. We replied that not at all, but perhaps he would be interested in 64-bit diagnostics, which are extremely useful. He answered that he doesn’t need 64-bit and VivaMP diagnostics at all. And thank you very much for such a cool tool, especially since he can continue to use general-purpose diagnostics for free.

We heard this signal from space and quickly revised our approaches. Therefore, the release version of PVS-Studio 4.00, released a month later, was already paid. I even had to write an explanatory article why we changed our mind so quickly: " Why is PVS-Studio 4.00 a paid solution ". , , « ».

, PVS-Studio (Viva64, VivaMP, ), . (Site License).

, PVS-Studio . PVS-Studio 4.30 — , . PVS-Studio .

And in PVS-Studio 4.32, which was released in July 2011, we refused licenses for one user. It was one of the best business decisions in the history of the company. We realized that PVS-Studio is a team tool that benefits the entire project, no matter how many people work directly with it.

At the beginning of 2012, PVS-Studio 4.53 was released, in which there were already 100 messages of general purpose analysis (V501-V600). Soon, a set of diagnostics “Micro-optimization” also appeared to search for those places of performance drop that can be detected by static analysis.

So 3 years have passed when we made the right and useful decisions on the development of the project. This is too long, it was time to do stupid things.

Embarcadero RAD Studio, the second error

, . PVS-Studio 5.00 Embarcadero RAD Studio. , C++Builder. . .

, VivaMP. , - RAD Studio , . . VivaMP, , . .

, Embarcadero RAD Studio .

, Embarcadero RAD Studio , , , .

CppCat,

CppCat 1.00 — PVS-Studio . « PVS-Studio $250». , , . . . , PVS-Studio, , CppCat, .

, , . , " CppCat ". , .

6. CppCat . , , . : .

CppCat, . , , . , .

, CppCat, Embarcadero RAD Studio OpenMP. , , , .

Our days

Failures with CppCat, VivaMP, Embarcadero RAD Studio did not undermine our enthusiasm, and we invested in three new areas:

1. C # code analysis;
2. Linux support;
3. Free license option PVS-Studio.

. . - , , .

2009 , . 4 . 7 PVS-Studio 24 . , , , . . 10 , , - .

, . - .

7. !

, Viva64 v1.0

, Viva64 PVS-Studio. . , , , 3-4 . Viva64 210 37 KLOC. , PVS-Studio C/C++ 320 208 KLOC. , , , - 40 .

Note. , C C++ . , Plugin Visual Studio, C#, Standalone . .

, , , .

 rw_table_sanity_check(const rw_table table[]) { unsigned n = (sizeof table)/(sizeof table[0]); if (n < 2) return; for (const char* old = (table++)->name; --n; old = (table++)->name) if (strcmp(old, table->name) >= 0) { cerr << "FAILED: '" << old << "' < '" << table->name << "'" << endl; assert(! "invalid order in presorted array"); } } 

PVS-Studio:

• V511 The sizeof() operator returns size of the pointer, and not of the array, in 'sizeof table' expression. lex.cc 822
• V514 Dividing sizeof a pointer '(sizeof table)' by another value. There is a possibility of logical error presence. lex.cc 822

Error refers to the unit test subsystem. The test, in fact, does not check anything, since the variable n is assigned the value 0. The error is that table is just a pointer, not an array.

But the mistake that I personally made:

 bool IsLiteralFFFFFFFF(const char *buf, size_t len) { if (len < 10) return false; if (buf[0] != '0' && (buf[1] != 'x' || buf[1] != 'X')) return false; .... } 

PVS-Studio warning: V547 Expression 'buf [1]! =' X '|| buf [1]! = 'X' 'is always true. Probably the '&&' operator should be used here.vivacasts.cpp 632

A quick check does not work that the literal must begin with the characters "0x" or "0X". The check considers valid any lines that begin with the character '0'.

A bit long code, but I decided not to shorten it:

 Ptree* Append(Ptree* p, Ptree* q) { Ptree *result, *tail; if(p == 0) if(q->IsLeaf()) // <= return Cons(q, 0); else return q; result = tail = Cons(p->Car(), 0); p = p->Cdr(); while(p != 0){ Ptree* cell = Cons(p->Car(), 0); tail->SetCdr(cell); tail = cell; p = p->Cdr(); } if(q != 0 && q->IsLeaf()) // <= tail->SetCdr(Cons(q, 0)); else tail->SetCdr(q); return result; } 

PVS-Studio: V595 The 'q' pointer was utilized before it was verified against nullptr. Check lines: 360, 374. ptreeutil.cc 360

, nullptr.

, :

 Class* Environment::LookupClassMetaobject(Ptree* name) { TypeInfo tinfo; Bind* bind = 0; if (this == 0) { TheErrorLog().Report( MopMsg(Msg::Fatal, "Environment::LookupClassMetaobject()", "0 environment")); return 0; } .... } 

PVS-Studio: V704 'this == 0' expression should be avoided — this expression is always false on newer compilers, because 'this' pointer can never be NULL. environment.cc 115

10 .

That's all. , , , , . 37 KLO — , .

Conclusion

, 10 . , , , . , , , . , , «» . : , , , 1 , . , , , , . , .

Figure 8. Fresh winter problem. Here are the difficulties of startups. They are not at all in that the wrong Framework is chosen.

However, sometimes you have to really pick up a tool and do something to make it work.

9. Press Wall. - , .

, , , , . , , , , . , .

. .


If you want to share this article with an English-speaking audience, then please use the link to the translation: Andrey Karpov. PVS-Studio project — 10 years of failures and successes .