Segfaults in FinalProject, initialization phase

[jnsnow]

There's a memory problem. glutInit segfaults trying to process argc/argv, setting a watchpoint for _argc in MONOLITH:

Setting Cameras WxH: 0[Switching to Thread 0x7ffff6f1b700 (LWP 25655)] Hardware watchpoint 2: *0x7fffffffde60

Old value = 1 New value = 1064548855 Hardware watchpoint 3: *0x7fffffffde60

Old value = 1 New value = 1064548855 MONOLITH::aRomanticEvening (this=0x7fffffffddf0) at Classes/MONOLITH.cpp:460 460 lightDiffuse[1] = lightness;

[nickavv]

For the record, not seeing this issue on Mac. Project builds and runs fine

[jnsnow]

going to remove morphing, debug, then put it back. would like to commit my changes before bed but I'm stuck in a pull-debug-fix cycle :(

[jnsnow]

http://pastebin.com/Xc9rvAxZ

@nickavv , did the stuff you edit touch the romantic evening flicker function? It's dying hard there, it looks like that pointer it is using never gets initialized, so it's barfing on everything.

[nickavv]

My implementation of lights sort of just ignores the romantic evening thing. My light shouldn't be being flickered by the function, but it shouldn't break there. I can rewrite the romantic flicker to use my light

[jnsnow]

OK, I didn't know if you had touched it or not.

The problem is here: http://pastebin.com/2Ss5cSW3

I'm not really sure how to fix it because I haven't touched lighting at all, but the variables this function is using are not being initialized; including extinguish and the arrays

[nickavv]

Okay, rewrote it to use my lights. However the flicker function is never actually being run on my machine (I stuck a printf in there and everything). It might be a boost problem, since the romantic flicker seems to be being driven by boost, which I don't really understand. Anyway, your results may vary

[InspectorConstructor]

so is it a race condition? do we need condition variables?

actually, do we really need a separate thread to change these variables on each frame? could we call aRomanticEvening() in a idle loop somewhere?

[jnsnow]

The initialization problem is likely a race condition. It never, ever being called for nickavv sounds like ghosts.

[nuclearmistake]

Idle loop is dependant on the frame rate.

Just add a boost::scoped_lock or make it free spin until a conditional is true. On May 5, 2013 3:54 AM, "Nick St.Pierre" notifications@github.com wrote:

so is it a race condition? do we need condition variables?

actually, do we really need a separate thread to change these variables on each frame? could we call aRomanticEvening() in a idle loop somewhere?

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/76#issuecomment-17448142 .

[jnsnow]

This has been "fixed," in that I have solved the race conditions that led to the issues in the boost thread. The boost thread, however, isn't actually updating the lighting anymore, but I will create a separate bug for that.