I'd like to quickly talk about something that's really, really awful.

I just bought a Cybershot WX1 camera from Sony. The camera itself is very nice, very small, very fast, quite powerful, loaded with features, etc. Now have a look at the camera itself. Look at the way the flash and the lens are placed.

Now look at this picture. This is a picture I took in my room, of my wall, with the zoom at 1x, in complete dark, using the flash. Notice the black portion at the bottom left. This isn't the shadow of my finger or what. This is the shadow of the lens itself.

The Sony engineers who slapped together this piece of crap didn't even see that, when taking a picture with the flash on, the lens itself would interfere with the ray of light from the flash itself. To me it just means they haven't even tested the product. I mean, seriously ? How could you ship such a product without testing something as basic ? Or maybe they didn't care ? I don't know. I'm tempted to ask for a return for a "defective product", as this is obviously defective to me.

The title of this article is actually something I wrote on the corner of the whiteboard at work. We've recently had a few issues which all dealt with stack abuses. We added some instrumentation to help us, and I thought about sharing that a bit.

Here is a little trick that saved my life a few month back when I was dealing with a virtual pure function been called.

In a program I wrote, I had a very very rare bug where the code would crash in a completely improbable way. I finally figured out that it was due to abort() beeing called, and that was crashing the all other threads in random place. Now, where did that call come from was the big question. With one lucky crash dump, I was able to find that it was due to a virtual pure call, obviously due to a boggus cast.

By default, it seems that the virtual pure handler in gcc just call abort, making it hard to debug. The trick I used to find the actual bug was to override the default virtual pure handler:

extern "C" {

static int __cxa_pure_virtual() __attribute__((noinline, used));
static int __cxa_pure_virtual()
{
    assert(0);
    return 0;
}

}

That way, every time a virtual pure function will be called, it will assert instead of simply aborting, giving way more useful information about what's happening.

For the people who know me, this is just a repost of a very old article I wrote. I just think this is the perfect spot for it. I'm just changing the wording a bit, but this is essentially the same thing.

As I said during the opening post, Yazoo and I are quite into Reverse Engineering, which is usually called "Hacking". While this word is always causing some controversy, we claim to be on the right side of the line.

That being said, we still receive a lot of mail and queries so we can teach people how to hack, or shorter, so we can write some so-called tutorials. We always denied such requests. This article is attempting to explain why. The main, short-hand reason is "because any hacking tutorial can only be crap", but I hope that I can point to the full reasons why this methodology doesn't work at all. Don't read this as a real attempt to teach you how to hack, but as an attempt to explain why usual tutorials just can't work.

Picture the situation. You've just spent 2 days trying to figure out a bug that randomly crash your application. You've nailed it down to a memory corruption somewhere, and you finally find that it's due to an out of bound access to an array. A single little assert you have saved you hours of heavy debugging...

In my previous entry, I've been ranting about compiler bugs. I finally discovered that it's absolutely RedHat's fault. Their compiler is a bug pit of hell. I ran the latest gcc testsuite on it, and on Debian's compiler in order to compare. I've stopped after finding 15 bugs in the first batch of basic test, which is like one tenth of the whole list of tests. This is just not acceptable. RedHat's compiler is deliberately buggy, maybe for the sake of "Backward Compatibility", but that's bullshit, especially since we're always writing crossplatform code. We're expecting that a piece of code that compiles and runs fine on one platform would also compile and run fine on a similar one. Which isn't guaranteed by RedHat. I'm now officially boycotting RedHat. Don't use their compiler, and don't use their distribution, because it's compiled with this compiler as well, so you can't possibly trust it at all. Don't bother with RedHat, it's a waste of time and money.

For your interest, here's a list of all the basic gcc bugs I've found active in RedHat's compiler. Again, this is not an exhaustive list, as I got fed up seeing all of these.

19606 28778 32244 33779 34971 35456 35472 36013 36077 36093 36137 36691 38151 38819 40404

UPDATE:

Well, it seems a retail 4.1.2 has them too. Well, not all of them. So I'd need to cross-check them. Well, whatever... RedHat's gcc still has more.

We will be starting a serie about the compiler myths. What people assume the compiler is doing, while the reality is way different. The first part is about static class initialisation.

Another notable game developer also tried to conceil its game data on the disc. The game's Kingdom Hearts 2. Their idea was to identify each file by the hash of its name. Smart don't you think? Well, not quite...

This has been a long, long time since I had the idea of this blog. We're finally opening it.

The two people behind it, Yazoo and myself, know each other since many years now. We met by discussing programming while being students, and we still discuss programming nowadays while being employed as seasoned programmers. Also, we're both passionate about reverse engineering.

The blog's name is very obviously inspired from Ron Gilbert's blog, http://grumpygamer.com/. The idea is to rant talk about programming in general, what we discover, what surprises us, and most importantly, what disgusts us.

Stay tuned, and enjoy the stay.