C++ codes that seem similar but have differents behavior : any idea why?

Question

I have a c++ code of a segment tree that often it works, but with a big input it fails. Any way, tracking the bug I have figured out that changing some part of the code for something that seems to be "equivalent" the code works without failures.

Some context :

struct state {
    int v, pos;
    state (int v, int pos) : v(v), pos(pos)  {}
};
int split(state s);
state go(state, int, int, int);

struct node{
    int link;
...
};
vector<node> t;

This code doesn't work :

int get_link (int v) {
    if (t[v].link != -1)  return t[v].link;
    if (t[v].par == -1)  return 0;

    int to = get_link (t[v].par);
    state aux = go (state (to,t[to].len()), t[v].l + (t[v].par==0), t[v].r, t[v].i_str);

    return t[v].link = split (aux);
}

This one works :

int get_link (int v) {
    if (t[v].link != -1)  return t[v].link;
    if (t[v].par == -1)  return 0;

    int to = get_link (t[v].par);
    state aux = go (state (to,t[to].len()), t[v].l + (t[v].par==0), t[v].r, t[v].i_str);

    int ret = split (aux);
    t[v].link = ret;
    return ret;
}

This one works :

int get_link (int v) {
    if (t[v].link != -1)  return t[v].link;
    if (t[v].par == -1)  return 0;

    int to = get_link (t[v].par);
    state aux = go (state (to,t[to].len()), t[v].l + (t[v].par==0), t[v].r, t[v].i_str);

    int ret = split (aux);
    t[v].link = ret;
    return t[v].link;
}

This one doesn't works :

int get_link (int v) {

    node &w = t[v];
    if (w.link != -1)  return w.link;
    if (w.par == -1)  return 0;

    int to = get_link (w.par);
    state aux = go (state (to,t[to].len()), w.l + (w.par==0), w.r, w.i_str);

    int ret = split (aux);
    w.link = ret;
//  assert(t[v].link == ret);

    return ret;
}

moreover, in this last case the assert fails. it is weird because in all the failures cases, the get_line function runs many times without problems.

Any idea what is wrong or what I am misunderstanding.

if it is useful

$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)

john john · Accepted Answer · 2013-04-04T09:43:38

Seems pretty likely that your split function is resizing the t vector. So in an expression like this t[v].link = split (aux) if the vector::operator[] is being evaluated before the split call (which is possible) and the split function is reallocating the vector then you may be accessing a reference to an object which no longer exists.

Your alternative code, which uses a temporary variable, doesn't have this problem because then the call to vector::operator[] definitely happens after the call to split.

C++ codes that seem similar but have differents behavior : any idea why?

1 Answers