June 2008

A Mystery Explained

Peter McCurdy, 29 June 2008

Back in the day, I worked on a Linux system running a version 2.4 kernel, and commonly run on VMware.  We had to pay fairly close attention to the system time, and were continually confounded by the fact that time would occasionally go backwards, a situation that occurred much more frequently on VMware.  These weren’t small jumps either; they were sometimes 200ms or more.  At one point we even had to turn off log messages that commented on this problem, as they simply happened too frequently on VMware to be useful.

I recently ran across an article from VMware titled Timekeeping in VMware Virtual Machines, which explains the cause of the problem. Apparently it came down to the 2.4 Linux kernel using a poor algorithm for interpolating the system time in between timer interrupts, which would occasionally overestimate the elapsed time, and then reset itself backwards when a timer interrupt arrived. Life is somewhat better on Linux 2.6, though the paper only covers up to version 2.6.8.1. It would be nice to have an updated version of the paper, as Linux timer handling has changed fairly drastically in later releases of 2.6.

It’s nice to know that we weren’t going crazy when we were seeing these things, and that there wasn’t much of a sensible option to fix the root cause. The solution we came up with actually worked quite well; we simply stopped calling gettimeofday(2) directly in our application, and instead called a library function that returned a cached value. We then updated this cached value fairly frequently, but checked to make sure that it didn’t randomly jump backward. This ended up being a superior solution anyway, as it gave us better control over clock values in the application, and avoided making tons of redundant system calls.

1 Comment »

Bill C-61: The Canadian DMCA

David Carney, 14 June 2008

I normally keep my political sentiments to myself, but Thursday’s introduction of Bill C-61 by Canada’s Minister of Industry, The Honourable Jim Prentice, warrants a response. In short, even through the Bill attempts to give consumers some additional rights, they are crippled by additional stipulations and regulations. In the words of Dr. Michael Geist, “While Prentice has given a handful of new rights to Canadian consumers, each is subject to many limitations and undermined by the digital locks provisions that may effectively render the new rights meaningless.”

For a far better summary than I could ever write, check out Geist’s blog here. As for what you can do, I’ve reproduced part of his most recent post below:

1. Write to your MP, the Industry Minister, the Canadian Heritage Minister, and the Prime Minister.  If you send an email, be sure to print it out and drop a copy in the mail (no stamp is needed – c/o House of Commons, Ottawa, ON, K1A0A6).  If you are looking for a sample letter, visit Copyright for Canadians.
2. Take 30 minutes from your summer, to meet directly with your MP.  From late June through much of the summer, your MP will be back in your local community attending local events and making themselves available to meet with constituents.  Give them a call and ask for a meeting.  Every MP in the country should return to Ottawa in the fall having heard from their constituents on this issue.
3. If you are not a member of the Fair Copyright for Canada Facebook group, join.  If you are, consider joining or starting a local chapter and be sure to educate your friends and colleagues about the issue and starting working through the list of 30 things you can do.

No Comments »

Learning Git

Peter McCurdy, 11 June 2008

Git is pretty awesome. Except when you want to actually learn it. I’m reminded of C, in the sense that it’s “a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language“. And the git manpages (which are the only built-in documentation) are daunting, at best.

There are many git tutorials around, but they’re mostly of the form “just type these commands, and stuff will happen, and it’ll sort of look like those other source control systems you’ve heard of”. This may be an effective strategy for other source control systems, but git, being written by kernel developers, makes no serious effort to hide the underlying complexity from users, so it won’t be long before you get awfully confused by something.

I’ve recently come across two interesting things that help this situation somewhat, from different directions. First, we have Git From the Bottom Up. This takes the opposite approach from most tutorials; instead of saying “here are some common commands, and this is kind of what they do”, it tries to explain the fundamental building blocks of git, which you can’t avoid anyway. The real benefit of this is that an understanding of these underlying concepts makes a lot of the more complicated functionality a lot more comprehensible. Some of my appreciation for the article is due to my natural learning style, which is generally bottom-up anyway, but if you’re ever going to use git seriously you’ll have to learn this stuff sometime, so you might as well get it presented to you sensibly.

The other approach is Easy Git, subtitled “git for mere mortals”. This is an attempt to make git more usable, simply by presenting its existing concepts in a sensible way, and by providing documentation that’s usable for people who aren’t git developers. It’s described as a brainstorming session, so it’s not perfect, but it looks like it solves a good few usability problems right off the bat, and is completely interchangeable with the regular git commands. I haven’t tried it myself yet, but I’m going to have to give it a look.

1 Comment »

How to automatically get stack traces when your program crashes with glibc

Peter Zion, 9 June 2008

Since I had to explain this to someone today, I’m posting here in the hopes that someone won’t do it from scratch again.  Note that if you use WvStreams you get this for free.

#include <signal.h>
#include <execinfo.h>
#include <unistd.h>

static int writestr( int fd, const char *str )
{
  int len = 0;
  while ( str[len] ) ++len;
  return write( fd, str, len );
}

/* signal handler */
static void last_rites( int signum )
{
  /* We must use at little of the standard library as possible
   * since we don't know what state it might be in
   */

  static const int output_fd = 1; /*stdout */
  char signum_text[4] = { signum/100 + '0',
    signum/10%10 + '0', signum%10 + '0', '\0' };
  void *stack[64];
  writestr( output_fd, "Dying on signal " );
  writestr( output_fd, signum_text );
  writestr( output_fd, ":\n" );
  backtrace_symbols_fd( stack, backtrace( stack, 64 ), output_fd );
  signal( signum, SIG_DFL );
  raise( signum );
}

int main( int argc, char **argv )
{
  /* Ensure that signals are thrown on an alternate stack
   * so that we get backtraces for stack overflows
   */
  static const int sigstk_size = 1<<16;
  char sigstk_data[sigstk_size];
  stack_t sigstk;
  sigstk.ss_sp = sigstk_data;
  sigstk.ss_size = sigstk_size;
  sigstk.ss_flags = 0;
  sigaltstack( &sigstk, 0 );

  /* get backtraces for certain-death signals */
  signal( SIGSEGV, &last_rites );
  signal( SIGABORT, &last_rites );
  signal( SIGBUS, &last_rites );
  signal( SIGILL, &last_rites );

  /* rest of program here */

1 Comment »

On causes

Mark Côté, 2 June 2008

On causes

One of our main difficulties in understanding historical phenomena in general, and biological and human phenomena in particular, is our cultural manner of thinking in local, linear causal terms. Thus, our usual form of arguing is that “A” causes “B,” as if “A” determined “B” by itself. And we are frequently unaware that what we call a causal relation is an abstraction of some local regularity of the structural dynamics of a larger system that we have not distinguished as such in our attempt to understand, in local linear terms, the situation that we want to explain. In other words, we frequently do not see or are not fully aware of the system with which we are dealing at any instant, and as we attend to the linear local relations that constitute the particular situation under our view, we do not grasp the systemic structural coherences to which it belongs.

– Humberto Maturana, “Systemic versus Genetic Determination”, Constructivist Foundations 3.1

4 Comments »