Segmentation fault during a function call from a non-reference std::vector parameter

Question

At a certain point in my program, I am getting a segmentation fault at a line like the one in g() below:

// a data member type in MyType_t below
enum class DataType {
    BYTE, SHORT, INT, VCHAR, FLOAT, DOUBLE, BOOL, UNKNOWN
};

// a data member type in MyType_t below
enum class TriStateBool {
    crNULL, crTRUE, crFALSE
};

// this is the underlying type for std::vector used when 
// calling function f() from g(), which causes the segmentation fault
struct MyType_t {
    DataType    Type;
    bool        isNull;
    std::string sVal;
    union {
        TriStateBool  bVal;
        unsigned int  uVal;  
        int           nVal;
        double        dVal;
    };

    // ctors
    explicit MyType_t(DataType type = DataType::UNKNOWN) :
        Type{type}, isNull{true}, dVal{0}
    { }

    explicit MyType_t(std::string sVal_) : 
        Type{DataType::VCHAR}, isNull{sVal.empty()}, sVal{sVal_}, dVal{0}
    { }

    explicit MyType_t(const char* psz) : 
        Type{DataType::VCHAR}, isNull{psz ? true : false}, sVal{psz}, dVal{0}
    { }

    explicit MyType_t(TriStateBool bVal_) : 
        Type{DataType::BOOL}, isNull{false}, bVal{bVal_} 
    { }

    explicit MyType_t(bool bVal_) : 
        Type{DataType::BOOL}, isNull{false}, bVal{bVal_ ? TriStateBool::crTRUE : TriStateBool::crFALSE} 
    { }

    MyType_t(double dVal_, DataType type, bool bAllowTruncate = false) {
        // sets data members in a switch-block, no function calls
        //...
    }
};

void f(std::vector<MyType_t> v) { /* intentionally empty */ }    // parameter by-val

void g(const std::vector<MyType_t>& v) {
    //...
    f(v);    // <-- this line raises segmentation fault!!! 
             // (works fine if parameter of f() is by-ref instead of by-val)
    //...
}

When I inspect the debugger, I see that it originates from the sVal data member of MyType_t.

The code above does not reproduce the problem, so I don't expect any specific answers. I do however appreciate suggestions to get me closer to finding the source of it.

Here is a bit of context: I have a logical expression parser. The expressions can contain arithmetical expressions, late-bind variables and function calls. Given such an expression, parser creates a tree with nodes of several types. Parse stage is always successful. I have the problem in evaluation stage.

Evaluation stage is destructive to the tree structure, so the its nodes are "restored" using a backup copy before each evaluation. 1st evaluation is also always successful. I'm having the problem in the following evaluation, with some certain expressions. Even then, the error is not consistent.

Please assume that I have no memory leaks and double releases. (I am using an global new() overload to track allocations/deallocations.)

Any ideas on how I should tackle this?

Answer 1

f(v); // <-- this line raises segmentation fault!!!

There are only two ways this line could trigger SIGSEGV:

1. You've run out of stack (this is somewhat common for deeply recursive procedures). You can do ulimit -s unlimited, and see if the problem goes away.
2. You have corrupted v and so its copy constructor triggers SIGSEGV.

Please assume that I have no memory leaks and double releases.

There are many more ways to corrupt heap (e.g. by overflowing heap block) than double release. It is very likely that (if you do not have stack overflow) valgrind or AddressSanitizer will point you straight at the problem.

Answer 2

When I inspect the debugger, I see that it [the segfault] originates from the sVal data member of MyType_t.

Well, now that you've actually added most of the relevant code, we see why asking for help with no/insufficient code, because you just know the rest is A-OK, is a terrible idea:

Problem 1

explicit MyType_t(std::string sVal_) : 
    Type{DataType::VCHAR}, isNull{sVal.empty()}, sVal{sVal_}, dVal{0}
{ }

AWOOGA! Your initialiser for isNull is checking whether the member, sVal, is empty(), before you have initialised sVal from the parameter, sVal_. (N.B. Although they're the same in this case, the real order is that of declaration, not of initialisation.) You might think isNull will always be set true as it's always checking the initially default-constructed, empty member sVal, rather than the input sVal_...

But it's worse than that! The member isn't default-constructed, because the compiler knows that's pointless as it's about to be copy-constructed. So, at the point of calling empty(), you are acting on an uninitialised variable, and that's undefined behaviour.

(Aside: This vindicates my preferred naming convention, m_sVal. It's much more difficult to accidentally type 2 characters than to forget a trailing underscore. But if anything, people normally include the trailing underscore in the member, not the argument. Anyway!)

But wait!

Problem 2

While your first constructor for the VCHAR variant of MyType_t guarantees UB, your second strongly invites it:

explicit MyType_t(const char* psz) : 
    Type{DataType::VCHAR}, isNull{psz ? true : false}, sVal{psz}, dVal{0}
{ }

In this version, you allow the possibility that sVal will be constructed from a null pointer. But let's have a look at http://en.cppreference.com/w/cpp/string/basic_string/basic_string - where the std::string constructors taking char const *, (4) and (5) with the latter being the one called here, are annotated as follows:

5) Constructs the string with the contents initialized with a copy of the null-terminated character string pointed to by s. The length of the string is determined by the first null character. The behavior is undefined if s does not point at an array of at least Traits::length(s)+1 elements of CharT, including the case when s is a null pointer.

This is formalised in the C++11 Standard at 21.4.2.9: https://stackoverflow.com/a/10771938/2757035

It's worth noting that GCC's libstdc++ as used by g++ does throw an exception when passed a nullptr: "what(): basic_string::_S_construct null not valid". I might infer from your mention of gdb that you're using g++ - in which case, this probably isn't your problem, unless you're using an older version than me. Still, the mere possibility should still be avoided. So, guard your initialisation as follows:

sVal{psz ? psz : ""}

Result

From this point on, due to UB, anything can happen - at any point in your program. But a common 'default behaviour' for UB is a segfault.

With the constructor taking std::string, even if the invalid call to .empty() completes, isNull won't just get a 'random' value based on the uninitialised .size(): rather, because it's constructed from UB, isNull is undefined, and tests of it might be removed or inlined as some arbitrary constant, potentially leading to wrong code paths being taken, or right ones not. So although sVal gets a valid value eventually, isNull doesn't.

With the constructor taking char const *, your member std::string sVal itself will be followed everywhere by UB if the passed pointer is null. If so, isNull would be OK, but any attempts to use sVal would be undefined.

In both cases, any number of unknowable things might happen, because UB is involved. If you want to know exactly what's happened in this case, disassemble your program.

The reason for the segfault not occurring when the vector is passed by reference is nebulous and of little discursive value; in either case, you're reading or copy-constructing from MyType_t elements whose construction involved UB in one way or another.

Solution

The point is that you need to fix both of these erroneous, UB-generating pieces of code and determine whether it resolves the error. It's very likely that it will because what the first and possibly second constructor are currently doing is so UB that, in a practical sense, your program nearly guaranteed to crash somewhere.

You must now comb over your program for any such coding errors and eliminate every single one, or they will catch you out eventually, "on a long enough timeline".