It has happened with me before too! Few months back while working on Priority queue in C language, I successfully compiled the code and it gave the desired outputs, I showed the running code to my other seniors and committed it to the repository at 21:00 (I was in the office till late night), next day my boss asked to show the running code, and it didn't work!!! I updated from the repository whatever I had committed but still nothing worked?? My boss was smiling thinking I had lied last night!

and then on this Saturday, my boss fixed a bug and committed to the repository and asked me to checkout which I did today morning, and when I ran the code it didn't work??? I stared at him and smiled, he swore that he had fixed the bug, and then he tried on his own machine, thinking I had messed up something on mine, but that was a futile effort and he banging his head to the walls now!

Valgrind didn't show any causes of concern both the times, anyone faced the situation before?

You and your boss committed code written/fixed by you/him, but not the compiler, linker, libraries. I.e. if you are compiling code on a different machine, it can fail.

Also, the code may have some kind of race condition - in such a case its proper operation is a random event.

Or use of uninitialized values - '-Wall -Wextra' 'gcc' switches are a must.

I did think on these issues before posting here,

We used same version of Kdevelop and OpenSuse for compiling and running the code and in the second case both of our machines are 64 bit!

And the trivial thing - never trust a repository (the SW or configuration can be buggy). Always maintain a local copy, and if you can be accused of cheating (expect you can) have the code stored as, say, an Email attachment on company mail server - in such a case it's "write once" storage (i.e. you can not modify the file on company mail server once it's written), so you can show everybody that you did change the code.
...
On my machine (I am also running SUSE) there are rare 'gcc' crashes under heavy load, and the statement is true for both stock 'gcc' and self-built 'gcc' of various versions.

I can't reproduce the bug, i.e. relaunching the same command with the same input files and the same 'gcc' produces normal results.

I mean, there can be some kind of random failure, but you'll have to dig this.

Thanks for your input, now I am forced to keep the local copies on the code on my computer but in the second case, I somehow feel, the repository is not at the fault, since my boss went to his seat and ran the same code from his computer, and it didn't work today!

I think there must be some kind of memory error involved somewhere which Valgrind doesn't show??

Are you sure the repository is not at fault ? For example, if repository SW just somehow ignores checkin, the the code in the repository is not updated.

There may be odd things due to NFS problems because of network problems - depends on how NFS is configured. Most likely your repository is on a separate machine.

You really have to make sure that the code checked out from the repository does contain the changes you expect it to have.

I do agree with you on the repository issue but still (if the repository in not in picture) the change which made the code work two days back on a computer should make the code work again if run 2 days later on the same computer! That is the issue here.

Check out the broken revision that you showed your boss, and diff it against your local copy of the tested, working code that you checked in. I bet they will be different.

The standard solution to this is to set up continuous integration.

Committing to a version control repository commits only the changes that you made since your last commit. If you've commit a change to file A and someone else committed a change to file B, then the repository would contain your changes to file A and your co-worker's changes to file B. You would have tested your work on file A and your co worker would have tested her work on file B. The project in the repository, which depends on both files, would be untested. The solution to is to use a continuous integration tool (like Hudson, Cruise Control, etc) to automatically build, unit test and lint the code in the repository after each commit.

Furthermore, if you mess-up a check-in by, say, forgetting to mark a file for "add", you want the continuous integration software to catch you. Not your boss.

In any case, you should always check out the repository after each commit and try to build it. Have unit tests to catch runtime errors, and design your software's architecture to make unit testing both possible and efficient. To give an extreme example of what not to do, putting XML parsing code in a constructor makes the XML parsing code impossible to unit test. In the case of your priority queue, putting in the inputs and checking the output should have been done by a unit test.

Finally, some version control systems have more of a problem with this than others (I remember reading that Mercurial has less of a problem with this than Subversion, for example).

EDIT: with this post, my post count is exactly 1337!