Weird Sigsegv Segmentation Fault in Std::String::Assign() Method from Libstdc++.So.6

Weird SIGSEGV segmentation fault in std::string::assign() method from libstdc++.so.6

There are two likely possibilities:

• some code before line 798 has corrupted the local tmpTimeStamp
  object
• the return value from FormatTimeStamp() was somehow bad.

The _GLIBCXX_FULLY_DYNAMIC_STRING is most likely a red herring and has nothing to do with the problem.

If you install debuginfo package for libstdc++ (I don't know what it's called on CentOS), you'll be able to "see into" that code, and might be able to tell whether the left-hand-side (LHS) or the RHS of the assignment operator caused the problem.

If that's not possible, you'll have to debug this at the assembly level. Going into frame #2 and doing x/4x $ebp should give you previous ebp, caller address (0x081402fc), LHS (should match &tmpTimeStamp in frame #3), and RHS. Go from there, and good luck!

c++ seg fault issue

Your issues are probably due to due memory corruption occurring at some point in the program sometime prior to the actual errors you are seeing.

One potential issue in the code you posted is the loop:

 for(int k = numBucketsThisWindow; k<numDiscontigBuckets && k < blockSize; k++){

which uses blockSize instead of the correct blockCount which leads to a possible overflow of both the totalWindows[] and containBreak[] arrays. This would overwrite the speciesMain and speciesOther strings, alonth with anything else on the stack, which might very well result in the errors you are seeing.

Getting unknown Segmentation Fault (address) in std::__cxx11::basic_stringchar, std::char_traitschar,..., std::allocatorchar const&) const ()

Your problem is Tree_create(this->node_root);

Tree_create creates copy of pointer passed to it and assigns NULL to this copy, while this->node_root stays unchanged and is uninitialized when Tree_sort is called.

Simplest solution is to assign NULL (or nullptr which is preferable in c++11) directly to this->node_root

The same applies to your other methods. When you pass pointer by value, any assignment to it is done on copy. Solution here is to pass pointers by reference (e.g. Tree_create(Tree_node*& root))

SIGSEGV segmentation fault when writing, but not reading?

char* str = new char[13];
str = "Hello world!";
ECFS::changeData(str, 12); // SIGSEGV

You allocate 13 bytes and store a pointer to them in str. Then you throw that pointer away and change str to point to a constant. Then you try to modify what str points to, which is a constant. You can't modify a constant.

You wanted:

char* str = new char[13];
strcpy(str, "Hello world!");
ECFS::changeData(str, 12);

Why doesn't the program throw segfault error on editing fixed string?

Let me breakdown what is happening here line by line:

1. Struct Test st1, st2;
   creates two local struct Tests. These are not pointers / references, but the structs themselves.
   if you try to print out the structs, they will have random characters since str is not initialized.

2. strcpy(st1.str, "GeeksQuiz");
   Copies the string literal GeeksQuiz to st1.str, so st1.str should have GeeksQuiz with null terminating character.

3. st2 = st1;
   We set st1 to be equal to st2. Both are not pointers or references, (flat objects) so its like

   int a = 5;
   int b = 6;
   a = b; // a = 6
   a = 7; // a = 7, b is still 6
   

So st2.str = GeeksQuiz, st1.str = GeeksQuiz, but they (st1, st2) both are separate entities.

4. st1.str[0] = 'S';
   st1.str = SeeksQuiz, st2.str = GeeksQuiz.

5. cout << st2.str;
   st2.str = GeeksQuiz, which is what gets outputted.

We are nowhere trying to change the actual literal itself, anytime we use literals to initialize something, it is copied to that variable. I hope all this clarifies your question.

If st1 and st2 were pointers to structs, then setting st1 = st2 both will point to the same place in memory, so changing something through *st1 will be reflected in *st2 as well, but thats not the case here.

Segfault when adding an element to a std::map

This is the static initialisation fiasco: static variables defined in different translation units are initialised in an unspecified order, so there's no guarantee that _wrapperMap is initialised before it's needed by the initialisation of wrapper.

The best solution is to avoid static/global variables. They usually cause nothing but trouble.

If you really want global state, a safer option is to use a local static variable:

std::map<std::string, S3Wrapper*> & wrapperMap() {
    static std::map<std::string, S3Wrapper*> map;
    return map;
}

This is guaranteed to be initialised the first time the function is called, so there's no danger of using the map before initialisation. You may still have issues when static variables are destroyed at the end of the program.

Note that _wrapperMap is reserved (in the global namespace) so you should choose a name without a leading underscore, or put it in a namespace.

---

Related Topics