Uhaw Pa Sa Camel

The daemon I mentioned in my preceding post did fail some debug assertions which I found out came from the U++ MAP containers. Now this confirms my suspicion that there was a race condition in my app which puts the container in a "volatile" state. Digging though my code I found out that this code:

#ifdef GUI_POST_CALLBACK
#define MUTEX_LOCK(mutex)   Mutex::Lock __(mutex)
#else
#define MUTEX_LOCK(...)   ((void)0)
#endif

should have been:

#ifdef GUI_POST_CALLBACK
#define MUTEX_LOCK(...)   ((void)0)
#else
#define MUTEX_LOCK(mutex)   Mutex::Lock __(mutex)
#endif

Let me explain. Posted callbacks (using U++ PostCallback() in GUI mode) are called with mutex locking automatically done by the U++ framework. Since a daemon is not a GUI app, GUI_POST_CALLBACK is not defined, which leaves me to create my own locking. In the incorrect code above the ifdef guard was reversed thus calling MUTEX_LOCK(mutex_) had no effect in my code, leaving the daemon code vulnerable to non-preemptive data sharing! Reversing it solved the problem. No more crashing!

Whew, definitely NOT python + twisted! :D

0 Comments:

Post a Comment

<< Home