Goodbye Livejournal

I've decided to discontinue using Livejournal. The posts on this blog will remain up but future posts will appear on Google+.

Syndicated 2011-12-24 12:45:22 from fragglet

Initialisation dogma considered harmful

In C, variables aren't initialised to a value automatically. I've seen some people who seem to have adopted a rule of initialising every variable they use when they declare it. That is to say, they write code like this:

   void frobnicate(void)
   {
       int num_frobs = 0;
       void *frobs = NULL;

       num_frobs = get_num_frobs();
       frobs = malloc(num_frobs);

       ....

Even though they initialise the variables before using them in their code, they include an initialiser in the declaration to set the value to zero or NULL. Presumably the logic is something like: variables that aren't initialised can hold any value, which can cause bugs, so it's a good idea to always initialise every variable just in case.

I think this is an actively harmful practise and should be discouraged. The reason I think this is that modern C compilers can detect when variables might be used without being initialised first (and gcc is scarily good at it), and adopting a rule like this of initialising everything breaks that functionality. Consider an example like this:

    void clever_function_name(void)
    {
        mystruct *obj = NULL;
        int bar = 0;

        if (somecondition) {
            obj = new_mystruct();
            bar = 1;
        } else {
            // oops, forgot to initialise obj here as well
            bar = 2;
        }

        ...

        obj->member = bar;
    }

In this situation, "obj" is "uninitialised", as there is a code path where it isn't set that leads to a crash. But technically, it has been initialised in the variable declaration, as part of this initialisation dogma. If it hadn't, the compiler would have been able to detect this bug, but it can't.

I think the key thing is that initialising to a value like zero or NULL doesn't actually solve anything or prevent any bugs because it's just an arbitrary value. In a general sense, having a variable that is set to those values isn't any more helpful than having some random garbage that got left on the stack. It doesn't prevent uninitialised variable bugs, but it does prevent the compiler from detecting them.

Syndicated 2010-11-25 21:56:37 from fragglet

How to coerce gdb into giving a backtrace

When debugging with gdb, I sometimes encounter a problem in getting it to recognise a stack trace. Sometimes it only gives a few function calls, or none at all. Here's an example:

(gdb) bt
#0  0xb7886424 in __kernel_vsyscall ()
#1  0xb7559163 in ?? () from /lib/i686/cmov/libc.so.6
#2  0xb74f1387 in ?? () from /lib/i686/cmov/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

This obviously isn't a very useful backtrace. At this point it can be useful to have a look at the registers and the contents of the stack.

(gdb) info registers
eax            0xfffffe00	-512
ecx            0x80	128
edx            0x2	2
ebx            0xb75c33a0	-1218694240
esp            0xbfe55018	0xbfe55018    <= stack pointer on x86 
ebp            0xbfe55048	0xbfe55048
esi            0x0	0
edi            0x0	0
eip            0xb7886424	0xb7886424 <__kernel_vsyscall+16>
eflags         0x202	[ IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
(gdb) x/64x $sp
0xbfe55018:	0xbfe55048	0x00000002	0x00000080	0xb7559163
0xbfe55028:	0xb75c33a0	0xb75c1ff4	0x09ec0470	0xb74f1387
0xbfe55038:	0xb77c4afd	0xb782199c	0xb782199c	0x09ec0478
0xbfe55048:	0xbfe55078	0xb77c4bf4	0x09ec0478	0xb782199c
0xbfe55058:	0x0000ffff	0xb75c3438	0xbfe55098	0xb789a240
0xbfe55068:	0x00000000	0xb782199c	0x0000ffff	0xb75c3438
0xbfe55078:	0xbfe55098	0xb7818736	0x09ec0478	0x00000000
0xbfe55088:	0xb77c50cd	0xb782199c	0xb7818709	0xb782199c
0xbfe55098:	0xbfe550b8	0xb77c54ad	0x00000000	0x00000000
0xbfe550a8:	0x0000000b	0xb75c3438	0xb77c5449	0xb782199c
0xbfe550b8:	0xbfe550c8	0xb77bb7dd	0xb782199c	0x0000000b
0xbfe550c8:	0xbfe550e8	0xb77bb84e	0x0000ffff	0xb789a240
0xbfe550d8:	0x00000000	0xb77bb830	0xb77bb839	0xb782199c
0xbfe550e8:	0xbfe55108	0xb77bc08f	0x0000000b	0x00000000
0xbfe550f8:	0x00000000	0x00000010	0xb75c1ff4	0x3efafafb
0xbfe55108:	0xbfe556c8	0xb7886400	0x0000000b	0x00000033

The values in bold are the frame pointers, forming a linked list back up the stack. If you compiled with -fomit-frame-pointer things will be harder to figure out. In this case it certainly doesn't look like the stack is corrupt. Perhaps gdb is just confused.

Pick a location slightly further up the stack and set the $sp variable, and suddenly backtrace works!

(gdb) set $sp=0xbfe55048
(gdb) bt
#0  0xb7886424 in __kernel_vsyscall ()
#1  0xb782199c in ?? () from /usr/lib/libSDL-1.2.so.0
#2  0xb7818736 in ?? () from /usr/lib/libSDL-1.2.so.0
#3  0xb77c54ad in ?? () from /usr/lib/libSDL-1.2.so.0
#4  0xb77bb7dd in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#5  0xb77bb84e in SDL_Quit () from /usr/lib/libSDL-1.2.so.0
#6  0xb77bc08f in ?? () from /usr/lib/libSDL-1.2.so.0
#7  
#8  0xb74ede80 in ?? () from /lib/i686/cmov/libc.so.6
#9  0xb74efc8c in malloc () from /lib/i686/cmov/libc.so.6
#10 0xb7764eec in ?? () from /usr/lib/libSDL_mixer-1.2.so.0
#11 0xb7765b98 in Mix_SetPanning () from /usr/lib/libSDL_mixer-1.2.so.0
#12 0x080828b1 in I_SDL_StartSound (id=-1218694088, channel=-1218699276, 
    vol=120, sep=38) at i_sdlsound.c:671
#13 0x08073e9b in S_StartSound (origin_p=0xb624f990, sfx_id=22)
    at s_sound.c:656
#14 0x08061459 in T_MoveFloor (floor=0xb63271b8) at p_floor.c:220
#15 0x0806d0ea in P_RunThinkers () at p_tick.c:119
#16 0x0806d161 in P_Ticker () at p_tick.c:153
#17 0x08052fb6 in G_Ticker () at g_game.c:1151
#18 0x0804dbf4 in D_DoomLoop () at d_main.c:437
#19 0x0804ecc0 in D_DoomMain () at d_main.c:1506
#20 0x08054d1c in main (argc=5, argv=0xbfe55d04) at i_main.c:152

Syndicated 2010-11-23 20:38:03 from fragglet

Most absurd CMOS battery ever?

I have a Performa 6400 PowerMac, which I bought off a friend several years ago. It runs Linux and I use it for portability testing (as it's a big endian machine). Considering its age, it's not surprising that the battery for the onboard clock ran out years ago. It's not a huge problem, but it's certainly annoying to have make complain about modification dates in the future, and be confronted with "filesystem has not been checked for 19370 days" on boot-up. So I decided to replace the battery.

This is the battery that is supposed to go in it. Almost £15 for a battery! This seemed far too expensive to me, so I set out to find an alternative. Unfortunately 4.5 volt batteries are rather uncommon. However, I managed to find this, which was listed as a "lantern battery" used for torches, bike lamps and doorbells. I suspect that there are probably 3 AA batteries inside:

- Greencell 312G 4.5V lantern battery alongside the original (depleted) CMOS battery.

I did a quick sanity check of the old battery to make sure I had the polarity right. The voltage is down to 1V:

All that needs to be done now is to connect the connector from the old battery to the new one. I've always been hopeless at soldering, but fortunately this is a job that is simple enough for sellotape.

This is the logic board from the Mac. I've maxed out the RAM and added PCI Ethernet and USB cards. The black square at the bottom left is where the battery is supposed to be attached (it has a velcro strip at the back).

Obviously this is far too small for the new battery, and the card slides into the back of the machine, mounted vertically. It has to be attached to the board somehow. Where can it go?

Fortunately, the engineers at Apple were apparently smart enough to anticipate this very problem, and designed a convenient space on the riser card to put the battery in.

Syndicated 2010-09-06 11:16:19 from fragglet

Interview with me

fragorama.se is a new website about Classic Doom, and they have just published an interview with me!

Syndicated 2010-07-29 21:01:22 from fragglet