samedi 26 mars 2016

Threaded C++: this=0x0 When Called on Valid Object, Segfault, Valgrind crashes

When running with multiple threads (on shared memory, std::mutex's regulate access- only discontinuities detected by helgrind are from within std::cout), I'm seeing a function call on a non-NULL object suddenly have a NULL this reference:

class BakedContourTrans{
public:
...
void calculate(BakedContour *a, BakedContour *b, Workplane planeA, Workplane planeB, float epsilon = 0.08f);
}
...

std::cout << "Calculating on " <<this << ", trans="<<&trans<<"\n";
(&trans)->calculate(contours[i].getBaked(epsilon), contours[i+1].getBaked(epsilon), Workplane(), Workplane(), epsilon);

Output is something like the following:

Calculating on 0x1b75c90, trans=0x7fffe0854aa0 
Thread 2 "r" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe3c55700 (LWP 19014)] 
0x00000000004586e0 in BakedContourTrans::calculate (this=0x0, a=0x0, b=0x0, planeA=<error reading variable: Cannot access memory at address 0x0>, planeB=<error reading variable: Cannot access memory at address 0x0>, epsilon=0)

And address are confirmed by GDB:

info args
this = 0x0
a = 0x0
b = 0x0
planeA = <error reading variable planeA (Cannot access memory at address 0x0)>
planeB = <error reading variable planeB (Cannot access memory at address 0x0)>
epsilon = 0
(gdb) up
#1  0x000000000047060a in ContourObject::construct (this=0x1b75c90, epsilon=0.0599999987, meshBuff=0x7fffe0855690, dbg=0x7fffe22556a0) at game/uni/ContourObject.cpp:66
...
(gdb) info locals
trans = {_vptr.BakedContourTrans = 0x508e58 <vtable for BakedContourTrans+16>, contours = {0x7fffe0854b00, 0x7fffe0854b30}, points = std::vector of length 0, capacity 0}
...
(gdb) p &trans
$2 = (BakedContourTrans *) 0x7fffe0854aa0

Running Helgrind produces no complaints (outside of std::cout calls), while running valgrind cause a glorious segfault with absolutely zero output (last line printed was the "using valgrind x.x.x" header. GDB reports the above.

Changing ulimit and stack size has no effect on execution. I'm presuming this to be a stack smash, but the fact that absolutely nothing reports anything of that nature makes me quite hesitant indeed. Any ideas what might be causing this?

Edit: Thought I should mention that running the exact same code, but all shunted through a single thread, produces no such errors. "Race condition" popped in my mind, but Helgrind didn't seem to confirm this.

Aucun commentaire:

Enregistrer un commentaire