• The feature abbreviations now resemble the ones in the Intel and AMD documentation.
• features() is now a function and returns a list of strings, instead of being a comma separated string.
• Added some functions like vendor() and brand_string() as handy wrappers.
• pycpuid is now a combination of a pure python module pycpuid.py and an extension _pycpuid.c. The extension module is only responsible for the actual cpuid call. All the fancy wrapper bits are implemented in Python.
• Added gcc support. Using __cpuid intrinsic on MSVC to support x64.

Share and Enjoy!

#include <iostream>

struct A
{
	void fun(int x) { std::cout << "int A\n"; }
};

struct B: A
{
	void fun(float x) { std::cout << "float B\n"; }
};

int main()
{
	B b;
	b.fun(3);
	return 0;
}

What shall it print? If your answer is int A, you’re probably assuming that the compiler will choose the best possible overload between A::fun and B::fun. In that case however you’re ignoring an often overlooked rule called name hiding.

The truth is that when you declare a function in a derived class, any function in the parent class that goes by the same name will be hidden from B‘s interface. From the C++ standard (C++ 98, 3.3.7 § 1): “A name can be hidden by an explicit declaration of that same name in a nested declarative region or derived class.” The consequence is that A::fun will never be considered as a possible overload, and only suitable function to call is B::fun. And so, the program will print float B.

Can it be fixed? Well, it depends on what you mean by “fixed”, as nothing is broken. But it surely is possible to bring back A‘s fun into B‘s interface so that it is considered as a potential overload again. One labourious way to do it is by declaring a new function in B that forwards the call to A:

// laborious solution
struct B: A
{
	void fun(int x) { A::fun(x); }
	void fun(float x) { std::cout << "float B\n"; }
};

However, if there are many fun overloads in A, and many different derived classes like B, this quickly gets very annoying …

A far more easier solution is the using-declaration (C++ 98, 7.3.3 and 10.2 § 2): “A using-declaration introduces a name into the declarative region in which the using-declaration appears. That name is a synonym for the name of some entity declared elsewhere.” It will declare A‘s fun into B‘s scope, and make it as such available as a potential overload:

// easier solution
struct B: A
{
	using A::fun;
	void fun(float x) { std::cout << "float B\n"; }
};

Now the compiler will also consider A::fun as a possible overload and print int A.

There are however a few cases in which the using-declaration won’t help: e.g. you can’t use it on constructors as they don’t have a name. For more details, see section 7.3.3 of the C++ 98 standard.

Most people using Python know how to format output using string interpolation. It works much like C’s sprintf, except for the funny % operator:

>>> a = "the Knights"
>>> b = "Ni"
>>> "we are %s who say %s" % (a, b)
'we are the Knights who say Ni'

What is less known is that you can replace the right hand argument by a dictionary and use its keys to tell what value goes where. That’s handy when you need to insert more than one or two in a string, or when a single value is used more than once. Especially for localisation strings, it gives you the flexibility to determine the when and where of the values in the string itself.

>>> "we are %(who)s who say %(what)s" % {"who": a, "what": b}
'we are the Knights who say Ni'

Combine that with the even lesser known function vars() which returns a dictionary of the local variables and their values:

>>> vars()
{'__builtins__': <module '__builtin__' (built-in)>, '__name__':
 '__main__', 'b': 'Ni', '__doc__': None, 'a': 'the Knights'}

Use it at the right hand, and you can simply use the variable names as keywords:

>>> "we are %(a)s who say %(b)s" % vars()
'we are the Knights who say Ni'

This probably is the closest you can get to the Perl and PHP style syntax "we are the $a who say $b".

Share and Enjoy!

What’s going on here? Does devenv.exe rely on a quirk of the Core 2 Duo that is now patched by that update? Or is it all just coincidence? Yet, the patch seems to be a critical update.

Hopefully to be continued …

update 11th July 2007: I tried to reinstall the patch, and this time, things are still working (knocking on wood). So, perhaps it was just a one-time quirk of the gods?

update 12th July 2007: It seems that other people have experienced the same problems as well. Though they’re reporting the KB928365 update as the culprit, which is a security update for the .NET Framework v2.0. Same symptoms, uninstalling/reinstalling the patch did the trick. It’s quite weird that uninstalling a different patch resolved the problem (I have the KB928365 patch installed as well), and that reinstalling that patch didn’t result in the same problem again. So, maybe the real culprit is still something else?

The Registry is also reporting on problems due to .NET updates of last Patch Tuesday, though their reference is to patch MS07-040 of KB931212 which actually includes KB928365 and KB928366

The first thing one tries to resolve the problem is to reboot … to no avail. Uh-oh … Trying to start devenv.exe from another account? It doesn’t start either. Double Uh-oh …

OK, no panic yet. If rebooting doesn’t help, reinstalling the product will. It’s a bit tedious, but it has to be done. Removing the current installation, installing VS2005 from scratch. Freeing 3 gigs on C: to reinstall SP1, installing SP1, fingers crossed … still doesn’t reboot! Now I’m really scared!

WTF may be causing that much of trouble to devenv.exe? The only thing left to do is to try to reverse the windows updates …

To be continued …

An interesting article on the subject is debugging custom filters for unhandled exceptions, especially the part about patching the SetUnhandledExceptionFilter function once you’ve set your filter, to prevent other modules (and even the runtime library) to set their own exception filters and thereby disabling yours. They do that by dynamically replacing the first instructions of that function by:

xor eax, eax
ret 0x4

Crude, but effective.

Once I’ve got it working on Win32, I started looking around for ways to deal with crashes in a similar way on the Linux platform. This has lead me to the discovery of Google-Breakpad (formely known as Airbag). It is a small open-source library that does exactly what I need: cross platform generation of minidumps on windows, mac and linux. It includes client and server parts, the client existing of a handler and sender. The handler is the actual exception handler that generates the minidump, the sender can be attached to the handler as a callback, in order to submit the minidump to a (public) server. Breakpad does not include an complete functional server, but it includes an minidump processor that converts the minidumps in human-readable stack walk, using local (local to the server) available symbol information. The benefit of doing this conversion on a server, in contrast to GNOME’s Bug-Buddy and Apple’s CrashReporter, is that the symbol files do not have to be shipped to the customer.

Breakpad surely looks like a promising tool that could be used in many (open-source) projects. Currently, there’s a mutual effort to include Breakpad in the next Firefox, replacing the closed source Talkback. This will certainly be a good test case, tremendously improving the library with experiences from a large scale project. For me, I certainly will try to include Breakpad in our software as well. There’s one part missing though: how to set up a public server that can receive the minidumps, automatically process them and inform me of the result. A few hints about deploying such a server may be found on the Mozilla wiki.

Our current noise mapper is pretty young and only supports full multi-threading since recently. Since we use this to squeeze out that extra bit of performance on machines that have more than one core, we started noticing – not surprisingly – inconsistent and hard-to-reproduce crashes. Reproducing the crashes on the development box was not feasible as you could just spend hours waiting for the crash to happen. Debugging the crashed programs locally wasn’t an option either, as most of them didn’t have any debugging tools installed whatsoever.

Last week, I’ve found some time to investigate the problem further, and I first started poking around with remote debugging in Visual Studio 2005, but it wasn’t really helpful. Normal use requires that you have identical accounts on both PCs. In the heterogeneous environment of our lab, without central user management and where everyone admins his own desktop PC, this is not a easy thing. However, it also has a no-authorization mode (who needs security anyway =), and after disabling the firewall (the rule automatically created by the remote debugger somehow wasn’t enough) and modifying some obscure security setting, I finally was able to connect to it from my dev box. Unfortunately, I only got corrupted call stacks, so it wasn’t of any help at all.

But that’s when I noticed something really wonderful: minidumps. When your program crashes the hard way on WinXP and later, it pops up a dialog box asking if you want to send debug information to Microsoft. You of course don’t want to do that, but at that moment, a minidump already has been created. You just need to secure it before you click away the dialog box. Then you copy it to your dev box, open it in visual studio and press F5. Et voila, you get an instant reproduction of the crash, ready to be debugged. Then it was almost a breeze to solve the problem.

Why have I never noticed this before? It’s so helpful to investigate problems that happen on machines other than yours. It’s plain magic. I’m thinking of building it in in our software so that the crash dumps are automatically send to me. If I also can avoid the dialog box, I can run the simulations unattended, and still be reported of any issue. When a crash happens, the program simply sends me the crash dump and tries to run the next job. I already have something similar for problems that arise in the Python code of the simulations, but this would make it complete.

Perhaps to be continued =)