Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Thursday, January 06, 2005

Ahh, the wonderful microsoft compiler

You'v heard me cursing the microsoft compiler for quite some time now, and have probably thought "bah, what does this guy know. MSVC is a wonderful compiler. I love it." Well, let me tell you a story.

On Dec 17th, 2004, your favourite kitty developer deployed new event handling subsystem, which was based on Boost.Function and Boost.Signals libraries, being significently cleaner and more flexible. It only had one problem - it caused access violation on startup on win32/MSVC.

Madcat spent two days debugging it, with little or no progress, and finally got so frustrated, and so tired that decided to take a longer break. The following two weeks, Madcat could not help but remember the seemingly unfixable problem that he had no leads to track on or nothing. Returning to development on Jan 3rd, 2005, after some initial comeback things had been done, Madcat returned to the problem, and spent another two long sleepless nights debugging it, using various tools and utilities, with still no success.

Until, on the 16th hour of the second long development session after the vacation, suddenly he discovered the problem. Here's the details:

In function Scheduler::addSocket():

boost::signals::connection c = Impl::getEventTable().addHandler(
s, &EventHandler::template onEvent<scheduler>);

EventTable::addHandler function takes boost::function type argument, which is constructed here on the fly from EventHandler::onEvent function (which is a static member function of EventHandler class). Debugger showed that one member object of the boost::function object, namely, manager member, had invalid address 0x0000e460, causing the access violation. As last resort, Madcat attempted to change the call:

Impl::HandlerType hfunc(&EventHandler::template onEvent<scheduler>);
boost::signals::connection c = Impl::getEventTable().addHandler(s, hfunc);

Technically, there was no change, except the fact that now the boost::function object (typedefed in Impl::HandlerType) is constructed as temporary object, and passed to the addHandler() function as copy. Lo' and behold - suddenly there is no bug anymore, no access violation, no crash, everything working as intended.

Who is to blame? Apparently, the wonderful Microsoft compiler generates wrong code for the first version of those lines, and thus broke it. There is no explanation to my knowledge that would explain this behaviour.

4 full development days and lot of frustration just because compiler generates wrong code. Ain't that just fun?


Are you even trying to question Microsoft's great compiler and compare it to the still-trying-to-catch-up GCC?

It is a fact that different compilers treat different code with different ways.

To get to the point, Send some newsgroup at MS a message, and I'm sure they will answer all your questions quickly.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?