Uhaw Pa Sa Camel

  HITS:  
 
d'Doc
Alabang, Muntinlupa City, Philippines
Beer-loving Gunner extraordinaire, perennial vocalist, guitarist, dog person, and wet kisser in one neat li'l package.

>> VIEW MY COMPLETE PROFILE

>> Home  

Subscribe to
Posts [Atom]  

Links
Previous Posts
Archives

Powered by Blogger

 
Sunday, November 22, 2009

Macros are Evil, a Multi-Threaded Scenario

 
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

Subscribe to
Posts [Atom]

 
 
 
Friday, November 20, 2009

Using SetAssertFailedHook() in U++

 
A few months back, I started using Ultimate++ which is IMHO, a very elegant development framework in C++. One interesting facet of U++ (and one which deserves a more comprehensive treatment treatment than a side note) is its aggressive use of C++, which deviates from the standard. U++ containers, unlike STL ones do not require their contained objects to have a deep copy constructor. That being said, U++ or NTL containers can be magnitudes faster in performance than their STL counterparts by virtue of not having to copy an element every time you insert or append one. The caveat is you have to follow (a few) certain rules, which someone coming from an STL background can forget from time to time. Luckily for noobs like me though, the debugging facilities of U++ are excellent, with the downside of being poorly documented!

I am currently writing a daemon in U++ and I am constantly wondering why my app (built in debug mode) gets terminated from time to time with only a "Received Terminate Signal" in my logs (for some reasons I am using my own logging facility and not syslog). Digging down deeper into my code, I found out that the daemon terminates with this message when it receives either a SIGABRT or a SIGTERM signal. Now the only reason I can suspect is that a debug assertion is failing and the abort(3) funtion of stdlib is sending the SIGABRT. So how to catch that assertion?

Although the forum members of U++ are very friendly and comes to your rescue ASAP, my philosophy in development is if you don't need to ask, don't, and this is how I got by all this time in Symbian and other forums---by just using the search button or its command line brother, grep. Anyway, I wasn't in the mood to dig up forum posts and thought it's easier to grep through U++ code (yeah, you get the U++ source code too, swell huh?). The result? SetAssertFailedHook().

void MyAssertFailedHook_(const char* msg)
{
// Log msg here
}

// ...

SetAssertFailedHook(MyAssertFailedHook_);

That's it. Problem licked!

Oh, btw, the daemon is called sentinel. :D

Subscribe to
Posts [Atom]