Why is it that C++ programs behave differently on different systems?

[Red Squirrel]

Ex: an error in some of my code on one system continues to execute (probably a bad thing).

on another system, it does this:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
Aborted

And aborts. Probably ideal given it lets me find an issue so I can go fix it. But why is it that on some systems it will do that and on others it wont? Is there a way to force it to behave that way on all systems?

System that does it is running CentOS 5, the other is running 6. Whatever feature that is, I'd like to turn it on, given the CentOS 6 machine is actually where my development happens.

 

[degibson]

Did you compile on CentOS 5, or compile on CentOS 6 and move the binary to 5? If the latter, the machines likely have different versions of, e.g., the libstdc++ library.

 

[Red Squirrel]

I compiled it on each system. Is there perhaps a debug service or something that needs to be running?

 

[dighn]

it shouldn't have anything to do with debug services. sometimes the implementations of the standard library are different, where one may be more strict than the other. your code may have a technical error that doesn't trigger an exception/assert with some version of the library. I would check your library/compiler versions as degibson suggested. I've had code that ran fine when built with visual c++ 2003 but asserts on 2008 due to strict STL iterator checks.

 

[mv2devnull]

... the machines likely have different versions of, e.g., the libstdc++ library.

Yes,
CentOS 5.8# rpm -q libstdc++
libstdc++-4.1.2-52.el5_8.1

CentOS 6.3# rpm -q libstdc++
libstdc++-4.4.6-4.el6.x86_64

Features and defaults have changed both between 4.1 and 4.4 as well as between 5 and 6.

However, one cannot judge by the plain numbers because The Upstream Vendor tends to backport fixes and features. Still, one could quite safely assume that a library based on gcc version 4.1 does not have exactly everything that is included in the library based on gcc version 4.4.

 

[Nothinman]

Ex: an error in some of my code on one system continues to execute (probably a bad thing).

on another system, it does this:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
Aborted

And aborts. Probably ideal given it lets me find an issue so I can go fix it. But why is it that on some systems it will do that and on others it wont? Is there a way to force it to behave that way on all systems?

System that does it is running CentOS 5, the other is running 6. Whatever feature that is, I'd like to turn it on, given the CentOS 6 machine is actually where my development happens.

Because there are a ton of variables involved, no pun intended. Different versions of systems will have different bugs and even possibly different implementations of things that are loosely defined within the spec. One bug that may have worked in your favor in the past may have been fixed with others being introduced, it's unavoidable as long as people are writing the software.

This is why most developers only support a specific set of systems and versions. Those are the ones they've compiled and tested on.

 

[Merad]

Your error probably involves something that's undefined behavior. It's entirely up to the person who writes the compiler what will happen.

Consider for example dereferencing a null pointer:

class Foo
{
  void bar() {}
};

int main()
{
  Foo* foo = nullptr;
  foo->bar();
  return 0;
}

You'd probably expect this code to crash with a segfault, but in fact on many platforms it will appear to run just fine (since Foo::bar() never actually dereferences the this pointer, it's possible for the function to run without a segfault - depends on the implementation). Undefined behavior.

 

[Pia]

Always compile with all warnings on, run lint or equivalent, run valgrind or equivalent, and hopefully you'll find your bug. You could also try compiling on a different compiler (as picky as possible) and platform to try to uncover bugs that are silent in your gcc.

Less than 1% chance that it's a bug with anything other than your own code.

 

[Red Squirrel]

How would I go about turning all warnings on? It was definitely a bug in my code and I found it and fixed it, but had it not been for that crash on the other system I would have never found it, and it would have been a source of aggravation in the future. Turned out I had if(pointer==NULL) instead of if(pointer!=NULL) somewhere, so an easy fix but easy to miss if it never crashes right away.

 

[Nothinman]

http://lmgtfy.com/?q=gcc+all+warnings