I was closing dillo. So far as I can recall, I just hit ^Q a couple times (my usual method), but I don't think that would explain the win_cb(). (gdb) bt #0 0x08055a00 in UI::tabs (this=0x0) at ui.hh:105 #1 0x080555ef in win_cb (w=0x813fe48, cb_data=0x8190618) at uicmd.cc:351 #2 0x080df426 in fltk::handle () at ../fltk/Widget.h:127 #3 0x080e0995 in do_queued_events () at x11/run.cxx:399 #4 0x080e0c16 in fltk::wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #5 0x080e0db0 in fltk::run () at run.cxx:399 #6 0x0804f737 in main (argc=1, argv=0xbffffb34) at dillo.cc:353 (gdb) p num_bws $13 = 2 (gdb) p bws[0] $14 = (BrowserWindow *) 0x81da720 (gdb) p bws[1] $15 = (BrowserWindow *) 0x81e4a10 (gdb) p bws[2] $16 = (BrowserWindow *) 0x81da720 Perhaps I had just closed the old bw[0], with a_List_remove moving the old bw[2] there. Here's a patch, since it's a good idea in any case to check what we've been given in a callback, but there is a bit of symptom-vs-disease in that I'm not positive how I got here in this situation.