Piero Bosio Social Web Site Personale

Some software, when it segfaults, just segfaults. Other software tries to be helpful, by catching the signal and printing a backtrace of where the crash happened, annotated with symbols from the ELF image.

In this example, which happened to a friend's machine yesterday, it _looks_ clear enough what happened. The crash occurs in OsLookupColor(), and "Segmentation fault at address 0x30" suggests trying to look up a struct field at offset 0x30 from what turned out to be a null pointer.

But this is all an illusion. OsLookupColor() is less than 0x14c bytes long. Line 0 of the backtrace really points into OsSigHandler(), just after OsLookupColor in the binary, but defined as 'static' so that the linker threw away its symbol name. And it's not the location of the crash: it's just the location of the call to the diagnostic function that printed the backtrace.

To find the actual fault we must look at line 2, in pci_device_vgaarb_set_target. That's _really_ where a NULL struct pointer was dereferenced. But most callers of that function check first if it's OK to call it. Where's the one caller that didn't?

Certainly not in DRICreatePCIBusID, which is (a) a pure string processing function; (b) _much_ smaller than the offset 0x39a0 shown in the backtrace. Again, this is going to be some other function whose name was thrown away at link time.

That backtrace function _tried_ to be helpful, but it didn't succeed. I'd almost rather have no annotations at all than ones this misleading!

An amusing but also actually useful thing in #RustLang: I realised this week that in some situations there's a good reason to write an apparent no-op let statement.

let x = x;

Because if x was previously mut, this makes it not mut any more.

In particular, this is a useful precaution for algorithms that use a data structure like a collection in two phases: (1) populate the data structure, (2) read stuff back out of it. If a stray mutation of the DS were to appear in phase 2 then perhaps it would invalidate all the stuff you'd already read out. Making the DS immutable at the end of phase 1 means the compiler will complain instead of letting the bug get as far as run time.

Perhaps this is a well-known technique already? But I worked it out for myself, by thinking "it would be nice to be able to remove 'mut' from this variable here … hmm, I feel as if just 'let x=x' ought to have that effect … yes it does, aha!"