3

Here is a minimal code that will produce a Segmentation fault.

#include<vector>
int main() {
  std::vector<double> a;
  a.resize(10);
  return 0;
}

Obviously there is nothing wrong with this code. I have run it on several systems without issue, but it produces a segmentation fault on my work pc.

Code is compiled using g++ file.cpp on a system running openSUSE 11.1. I know it is an older OS, but I am not allowed to upgrade or reinstall. The only thing I have permissions for is zypper (the command line utility to install and remove programs).

My assumption is it has something to do with the c++ libraries. I have tried reinstalling everything I can think of related to gcc/g++ and libstdc++, but I still see the same issue.

Has anyone seen something like this before? Any ideas?

Thanks!

user1955591
  • 116
  • 5
  • 3
    Can't think of any reason beyond a _horribly_ broken OS. – Lightness Races in Orbit Jan 07 '13 at 16:43
  • 1
    try rebooting your system? that's messed up – Andy Prowl Jan 07 '13 at 16:44
  • 1
    Have you thought about using a debugger and figuring out where exactly it crashes? – PlasmaHH Jan 07 '13 at 16:59
  • @LightnessRacesinOrbit No surprise here - assuming that the PC runs Windows, at least... –  Jan 07 '13 at 17:06
  • @H2CO3: No, it's still a pretty massive surprise, your childish Microhate notwithstanding. :) – Lightness Races in Orbit Jan 07 '13 at 17:12
  • @LightnessRacesinOrbit For your information, I have used all the major OSes out there (Windows [98, XP, Vista, 7], Linux [Ubuntu, from 9.10 to 12.04 in particular] and OS X [10.6 and 10.7]). I have had several serious problems with Windows (the most significant being the overall fragility of the system), the two other OSes produced very few errors. This is not childish microhate, this is personal experience. –  Jan 07 '13 at 17:15
  • Try to use other toolchain. – Mihai8 Jan 07 '13 at 17:17
  • @H2CO3: This problem has occured to you on Windows, then? – Lightness Races in Orbit Jan 07 '13 at 17:20
  • @LightnessRacesinOrbit No, not this one. –  Jan 07 '13 at 17:20
  • @H2CO3: Didn't think so. If a bug like this were inherent in Windows, I can't imagine that _anything_ in the OS would work. – Lightness Races in Orbit Jan 07 '13 at 17:26
  • 2
    The problem is common to both Windows and Unix (at least when you use g++ under Unix---Sun CC avoids it... by maintaining an extremely antiquitated standard library interface). Different versions of `libstdc++` are not binary compatible (although I am rather surprised to see the problem with `std::vector`). – James Kanze Jan 07 '13 at 17:40
  • 1
    @LightnessRacesinOrbit I don't know. In pre version 10 VC++, `std::string` would crash if you didn't use the default options for the debug build. Not systematically, just on some odd functions. – James Kanze Jan 07 '13 at 17:42
  • 1
    Sorry I never responded. Tried AndyProwl's suggestion and I could never get the system to come back up. Only boots to console and gives the occasional "Kernel Panic". I guess @LightnessRacesinOrbit was right. Hopefully the IT staff can either fix it or give me the permission in install an up-to-date OS. Thanks for your help everyone. – user1955591 Jan 07 '13 at 23:01

1 Answers1

1

Where did you build and link the application? And with what options? If you're dynamically linking the C++ standard library, you can easily run into problems; the C++ standard library has changed several times in ways that break binary compatibility, and binary compatibility can be affected by compiler options as well. In general, you should use the options -static-libstdc++ when building, to avoid such problems. (Note that the same is not true for the system libraries, where dynamic linking is to be preferred.)

James Kanze
  • 150,581
  • 18
  • 184
  • 329