I subscribe to cairo-list just to read what Carl Worth has to say. Carl is smart, fair, level-headed, perceptive, very sympathetic to people that come with problems, yet opinionated as well. It's refreshing, inspiring, and humbling at the same time.

This blathering inspired by one random post, although it could have been any other post just as well.

One of my first tasks at Oblong was to migrate their code for playing video from some very tricky, threaded ffmpeg + portaudio code to using GStreamer. The playback interface is fairly standard, but thorough: seeks to time, segment seeks, variable speed and reverse playback, frame stepping, etc. There were some twists: we do colorspace conversion on the GPU, and there's a strange concept of "masks", which is useful for operating on rotoscoped video, and there's integration with the GL main loop.

But anyway, I felt finished with all of that a while ago. The only problem was a lingering memory leak, especially egregious in the context of the art installation, which has yet to switch to my code.

So it was with a queasy, helpless feeling that I sat down and tried to systematize the problem, come up with a test case, and see if I could track down where the leak was. I tried code inspection at first, and I proved my code correct. (Foreshadowing, that.) I at least narrowed down the situations under which it occured. I then despaired for a while, before I hit on the way to make memory leak detection fun: turn it into a tools problem. Now instead of finding the leak, all I needed to do was to find the leak detector!

So I checked out valgrind from CVS; it crashed on me. Then I decided to see if libc had anything to offer me; indeed it does, mtrace. But alack, deadlocks. I even went so far as to include mtrace in my code, and applied Jambor's patch from the bug report on my sources, but lost because the ELF symbol resolution is intertwingled with libc's build system.

So back to valgrind, this time the 3.2.3 version packaged with Fedora, and lo and behold, exhibit A:

<center>houston, we have a leak</center>

My test is adding a video, waiting a while, removing the video, waiting again, then repeating. You can see the obvious video-playing versus video-removed phases.

Fortunately, you can also see the leak, and where it is: in the green part, corresponding to something that's calling g_try_malloc. This was comforting to find. It could have been something involving GL contexts or whatnot, and I'm using the babymunching nvidia drivers. So g_try_malloc was where it was coming from. But what was calling g_try_malloc?

For that, you have to dive into the textual output produced by massif. And sure enough, following things back far enough, you find that it is a GStreamer video buffer:

Context accounted for  7.2% of measured spacetime
  0x5F27E60: g_try_malloc (gmem.c:196)
  0x52E1487: gst_buffer_try_new_and_alloc (gstbuffer.c:359)
  0x530367B: gst_pad_alloc_buffer_full (gstpad.c:2702)
  0x53039FA: gst_pad_alloc_buffer (gstpad.c:2823)
  0xB9C11BF: gst_queue_bufferalloc (gstqueue.c:502)
  0x53034C0: gst_pad_alloc_buffer_full (gstpad.c:2668)
  0x53039E6: gst_pad_alloc_buffer_and_set_caps (gstpad.c:2850)
  0xBBECB4F: gst_base_transform_buffer_alloc (gstbasetransform.c:1112)
  0x53034C0: gst_pad_alloc_buffer_full (gstpad.c:2668)
  0x53039E6: gst_pad_alloc_buffer_and_set_caps (gstpad.c:2850)
  0xBBECB4F: gst_base_transform_buffer_alloc (gstbasetransform.c:1112)
  0x53034C0: gst_pad_alloc_buffer_full (gstpad.c:2668)
  0x53039FA: gst_pad_alloc_buffer (gstpad.c:2823)
  0x52F6C68: gst_proxy_pad_do_bufferalloc (gstghostpad.c:182)
  0x53034C0: gst_pad_alloc_buffer_full (gstpad.c:2668)
  0x53039E6: gst_pad_alloc_buffer_and_set_caps (gstpad.c:2850)
  0xC452722: alloc_output_buffer (gstffmpegdec.c:764)
  0xC454504: gst_ffmpegdec_frame (gstffmpegdec.c:1331)
  0xC45635D: gst_ffmpegdec_chain (gstffmpegdec.c:2236)
  0x5303C06: gst_pad_chain_unchecked (gstpad.c:3527)
  0x530421C: gst_pad_push (gstpad.c:3695)
  0xB9C0A3E: gst_queue_loop (gstqueue.c:1024)
  0x531E418: gst_task_func (gsttask.c:192)
  0x5F4338E: g_thread_pool_thread_proxy (gthreadpool.c:265)
  0x5F41C4F: g_thread_create_proxy (gthread.c:635)

For this level of information, you have to run massif with special options. I ran my test like this:

G_SLICE=always-malloc valgrind --tool=massif --depth=30 ./.libs/lt-vid-player

So now that I knew what was leaking, I decided to run with fewer, longer cycles to see the allocation characteristics were. And thus, exhibit B:

<center>bucket effect -- watch the cyan trough fill up</center>

You can see that after the video was removed from the scene the cyan part representing g_try_malloc allocation does not drop down to zero; indeed it starts to "fill up the trough", getting larger at each iteration.

Of course at this point I realized that I probably wasn't freeing the buffer that I kept as a queue between the GStreamer and GL threads on teardown. Indeed, indeed. Two lines later and we have the much more agreeable long-term plot:

<center>memleak fixed</center>

Moral of the story: "proof of correctness" is not proof of correctness.

Valgrind turned out to be much more useful to me in this instance than it was when I looked at before, when hacking Python. But again, the CVS/3.3 version was of no use, yet. Since then, 3.3 does indeed do graphs again, but in ascii. As a palliative, the textual output appears to have improved. Still, ascii graphs?

We've been using git at work for a few months now, and finally settling down reasonable workflow. As reasonable as anything might be with a 9 hour difference between me and Los Angeles, and for a cross-platform project that uses autotools.

Regarding the latter, the autotools have been a constant source of pain for my co-workers. I don't mind it myself, but I feel bad because I had a hand in inflicting it on them. So now when hacking on a bit of test code, I decided to take a look at Quagmire, Tom Tromey's experiment in replacing automake, libtool, and (to a large degree) autoconf with portable GNU make.

With Quagmire, all of the autofoo is replaced with one makefile, Quagmire.mk. Its format is much like that of a Makefile.am. A simple project with a few source files, that depends on pkg-config, might look like this example, taken from the Quagmire distribution:

# this is Quagmire.mk, in the top-level source directory
# -*- makefile-gmake -*-

bin_PROGRAMS = ekeyring

lib_LIBRARIES = libzardoz.a

libzardoz.a_SOURCES = zardoz.c

ekeyring_SOURCES = ekeyring.c something.h
ekeyring_PACKAGES = gnome-keyring-1
ekeyring_CONFIG_HEADERS = config.h

config.h_FUNCTIONS = strcmp strdup
config.h_HEADERS = string.h nothing.h strings.h sys/types.h

data_SCRIPTS = ekeyring.c
data_DATA = something.h

EXTRA_DIST = README.simple

The syntax will be familiar to anyone who has used automake. It is further described in the README.

Then you add the following configure.ac to the same directory:

AC_INIT(ekeyring, 1.5.1)
AC_CONFIG_SRCDIR(ekeyring.c)
AC_ARG_PROGRAM
AM_QUAGMIRE
AC_OUTPUT

And copy quagmire.m4 (from http://quagmire.googlecode.com/svn/trunk/m4/quagmire.m4) to aclocal.m4, to provide the AM_QUAGMIRE definition. Then import the quagmire files into your source tree by running:

svn checkout http://quagmire.googlecode.com/svn/trunk/src quagmire

At this point you run autoconf, in order to produce configure, and then ./configure. It doesn't configure much. Most of the actual configure checks are run at make-time.

For example the ekeyring_PACKAGES line specifies the pkg-config files that are needed to compile ekeyring. Those checks are made as dependencies of the ekeyring target.

status

Quagmire is promising, and is quite fast, as is appropriate for an underfeatured project. It's not there yet though. It doesn't yet understand differing shared library extensions (.so versus .dylib), it doesn't (I don't think) know about static linking like libtool's .la files do, and I haven't gotten programs that depend on in-tree dynamic or static libraries to build yet.

And yet, it does a proper distcheck. It integrates with pkg-config. The makefiles are understandable -- I can get the whole process in my head. Tom Tromey is either exactly the person to fix autotools, considering that he wrote automake, or exactly the wrong person, depending on your religion. And GNU make is actually quite an OK language for expressing functional dependencies.

For now I'm going to hold off on trying to use Quagmire for a while at work, given that I need to do some static linking stuff on the mac. But it's an idea that will be in the back of my mind.

This morning's cafe-hack has brought forth a right jewel, Guile-GNOME 2.15.98. Since simplifying the base GObject wrapper, things seem to have gone fairly well. So with that bit out of the way, I decided we're ready to go stable, finally. The next release will be 2.16.0, which wraps the GNOME developer's platform at version 2.16: GTK+ 2.10, GLib 2.10, Pango 1.14, etc. More about that in a couple weeks.

Part of this release was to bump the "major version" already, in order to shake out any bugs in that mechanism. I mentioned this to Edward today at lunch, and he said that it makes two major version bumps today. Happy birthday Edward!

Well, it's been a little while since I wrote about tekuti, my Scheme-powered, git-backed blog software. Time for an update.

features

I added a global tag cloud, in addition to the abridged cloud on the main page. Clicking on a tag takes you to a time-ordered list of posts having that tag, with a cloud of related tags. The post list could use some improvement, mostly because my titles are nonsensical.

I also implemented full-text search, which uses git grep under the hood. Amusing.

Also amusing is the "related posts" list, which shows up individual post pages. It's calculated as the set of posts which share the most tags with the post in question. The indexes that are automatically rebuilt when the master ref changes makes this a relatively cheap set to compute.

Also also: some artificial intelligence anti spam foo. Ha!

This stuff is actually fun to hack on, and is self-contained -- I'm almost spending more time writing about the features than I did implementing them.

documentation

I fleshed out tekuti's web page today, giving reasonably detailed install, deployment, and hacking instructions. It even includes a description on how to migrate from wordpress. I'd appreciate any comments that folks might have, probably better on this post than via email.

Stop the madness: uninstall PHP from your servers. We can do better than that!