2

So I've got a pretty basic class that has a few methods and some class variables. Everythings working great up until I add a vector to the member variables in the header file:

std::vector <std::string> vectorofstuff;

If all I do is add this line then my program run perfectly but at the end, after all the output is there, I get a message about a seg fault.

My first guess is that I need to call the destructor on the vector, but that didn't seem to work. Plus my understanding is I don't need to call the destructor unless I use the word 'new'.

Any pushes in the right direction? Thanks bunches!

adammenges
  • 7,848
  • 5
  • 26
  • 33
  • 2
    Please post your actual code. Declaring the vector isn't the problem. You may be able to solve this using valgrind (if you're on a platform that supports it). – Brendan Long Oct 03 '11 at 03:52
  • 5
    You never need to call the destructor yourself, and I mean *never*, unless you did something called an "in-place new," which I can assure you did not. Obviously there's nothing wrong with this line, you'll need to share more code. Post the *very minimum* amount of code that reproduces this problem. – Mahmoud Al-Qudsi Oct 03 '11 at 03:53
  • 1
    Your real issue is probably not the vector, since you did not alter the `std::string` or `std::vector` class, but rather another problem which was masked until you made the class containing `sumofurls` larger. Try running the program in a debugger and seeing where you get the segfault, keeping in mind that the issue may have actually been caused by earlier memory corruption. – Borealid Oct 03 '11 at 03:53
  • There isn't enough information here to say what is going wrong. You should be able to add a string vector as a member to a class in the manner you describe. Can you run in `gdb` and get a stack trace (use the `bt` command) when it crashes, and post that? – i_am_jorf Oct 03 '11 at 03:54
  • 1
    Ugh sorry I forgot you have to post links like this: [valgrind](http://www.valgrind.org) – Brendan Long Oct 03 '11 at 03:58
  • Thanks for the help! Fixed it! See above. (@BrendanLong, I'll be using valgrind for now on, thanks for the tip, teaching myself c++) – adammenges Oct 03 '11 at 04:18
  • 3
    @InBetween: your makefile is possibly broken (check dependencies for each compilation unit…) – Benoit Oct 03 '11 at 07:10
  • Valgrind is great but will tell probably not tell you anything useful (only random horror!) if the real problem is the issue explained in my answer, which I think was the case here. – underscore_d Feb 17 '16 at 08:50

3 Answers3

3

I guess the following either happened to you, or it was something similar involving unrealised dependencies/headers. Either way, I hope this answer might show up on Google and help some later, extremely confused programmer figure out why they're suddenly observing arbitrary crashes.

So, from experience, this can happen if you compile a new version of SomeObject.o but accidentally have another object file #include an old version of SomeObject.hpp. This leads to corruption, which'll be caused by the compiler referring to outdated member offsets, etc. Sometimes this mostly works and only produces segfaults when destructing objects - either related or seemingly distant ones - and other times the program segfaults right away or somewhere in-between; I've seen several permutations (regrettably!).

For anyone wondering why this can happen, maybe this is just a reflection of how little sleep I get while programming, but I've encountered this pattern in the context of Git submodules, e.g.:

  • MyRepo
  • / GuiSubmodule
  • / HelperSubmodule
  • / / GuiSubmodule

If (A) you have a new commit in GuiSubmodule, which has not yet been pulled into HelperSubmodule's copy, (B) your makefile compiles MyRepo/uiSubmodule/SomeObject.o, and (C) another translation unit - either in a submodule or in the main repo via the perils of #include - links against an older version of SomeObject.hpp that has a different class layout... You're in for a fun time, and a lot of chasing red herrings until you finally realise the simple mistake.

Since I had cobbled together my build process from scratch, I might've just not been using Git/make properly - or strictly enough (forgetting to push/pull all submodules). Probably the latter! I see fewer odd bugs nowadays at least :)

underscore_d
  • 6,309
  • 3
  • 38
  • 64
2

You are probably corrupting the memory of the vectorofstuff member somewhere within your class. When the class destructor is called the destructor of the vector is called as well, which would try to point and/or delete to invalid memory.

K-ballo
  • 80,396
  • 20
  • 159
  • 169
  • I haven't added anything to vectorofstuff at all, haven't touched it, just added that line to my .h file. How would I be corrupting vectorofstuff? (I'm not trying to sound sarcastic, I'm honestly wondering, haha) – adammenges Oct 03 '11 at 04:00
  • @InBetween: For instance, by trying to write to a static array within the same class and failing to operate within its bounds. Or even dumber things, like calling `memset( this, 0, sizeof( *this )` (believe me I've seen those)... – K-ballo Oct 03 '11 at 04:03
1

I was fooling around with it and decided to, just to be sure, do an rm on everything and recompile. And guess what? That fixed it. I have no idea why, in the makefile I do this anyway, but whatever, I'm just glad I can move on and continue working on it. Thanks so much for all the help!

adammenges
  • 7,848
  • 5
  • 26
  • 33
  • 2
    I think this supports @Benoit's earlier comment and my (much belated) answer, in that it seems to have been caused by some header/object files disagreeing on class layout or similar. This is then effectively UB as some parts of the code can end up reading/writing at now-incorrect offsets of objects, etc. Glad you got it sorted! So did I... eventually ;-) – underscore_d Feb 17 '16 at 08:53