Chaos Ensues When You Use Wrong Headers

I'm staring at a GDB console window investigating why int pthread_cond_signal ( pthread_cond_t * ) returns EINVAL (error# 22).
In my project, I'm using the Boost::Thread static library, which came with debug and release versions. Even though I have no problem in release mode, deep within Boost::Thread, assertion error is always triggered by that pthread function in debug mode.


Spending over 6 hours, I finally found why int pthread_cond_signal ( pthread_cond_t * ) returns EINVAL.


At a stack frame boost::shared_mutex::shared_mutex, type boost::condition_variable has a member variable pthread_cond_t cond, 28 in total size.
But, one stack frame down, at a stack frame boost::condition_variable::condition_variable, type boost::condition_variable has 2 member variables pthread_mutex_t internal_mutex and pthread_cond_t cond, 72 in total size. WTF, why 2 different definitions exist for 1 type!?
int pthread_cond_signal ( pthread_cond_t * ) was passed a wrong address, because of the messed-up definition.

Hmm, what kind of things, at compiling stage I guess, caused this mess?
Does my home-brew Boost have a problem? But I believe Boost's bjam does not screw up.
Then, most likely my part was bad. Xcode generally passes many options to gcc, maybe some of them are causing this.


I've remembered Boost is available in MacPorts. Yeah, I can use MacPorts, and it's turned out MacPorts provides multithread-enabled, debug/release static libraries of Boost. Looks much reliable than mine.

P.S.


Well, I killed that darn gremlin!
I used a debug version of Boost::Thread 1.46 static library from MacPorts, and voila, my project ran perfectly. For this fact, I'm really sure my part (my home-brew Boost::Thread static library) is bad.


And here is a revelation: I used Boost 1.42 header files with a Boost 1.47 static library.
Between those two versions, "boost::condition_variable" has different definition. That was the cause of this mess. Damn it, I had a suspicion about that (then what about 6 hours+ I spent on that!).
One of header path options (-I) was the gremlin. So with my mighty index finger, I flicked that to kingdom come!

Hmm, for a serious build/compiling, one should prepare a clean development environment, that's for sure. A duplicatable disk image or virtual machine containing adequate development environment comes in handy in this case, I guess. Huh, though some tweaks must be needed for my project's path settings, I think I can afford that.
Maybe in free time ... Now, I'm tired.

Comments

Popular posts from this blog

Hardcoding Data Like Images and Sounds into HTML or CSS

DDS for GIMP (Mountain Lion, Native, no X11 GUI)

Make It Work: Global .gitattributes