So, that's probably a memory leak. How to find it? With some quick IRCs to some helpful GNOME engineers (GMan and
Laca, to the rescue, as so often happens), I discover that I can remove gnome-panel from my session so it doesn't auto-restart when I kill it, by using

gnome-session-remove gnome-panel

(from a command line, of course, because...I can't launch anything). First,
though, I copied down its current arguments for restart, which were
--session default1. Then, I'm ready to try out libumem.

Adam has a wonderful introduction,
Jonathan Adams wrote a really nice reference on the topic of libumem and mdb, and there are plenty of other examples of use around. My particular method
was to enter the command

and then use mdb -p $(pgrep gnome-panel) to start up an mdb and access libumem's debugging features.

::findleaks immediately showed some false hits, and ::umem_verify was clean,
so I waited for a little while and saw no further leaks in ::findleaks. Then
I started a terminal from my custom terminal launcher on the panel. Bam!
New leaks from ::findleaks! After messing about with manual ::bufctl_audits
on the bufctl addresses in ::findleaks output, I decided that ::help findleaks might be handy, and indeed, it showed the -d option which put it all together,
showing stack backtraces for the leaked buffers, which allowed us to examine
the code and spot the leaks.

GMan and I were quickly able to find a bug in libgnome-desktop and another in gnome-panel itself (a fix to one of the Sun patches for gnome-panel,
in panel_lockdown_is_forbidden_key_file). I was able to verify that all the leaked buffers sprang from one of those two sources.

I can't even begin to tell you how much faster and more fun that was with
libumem than without. If you have any sort of allocation problem at all,
you should seriously consider libumem debugging...free with Solaris.